Reuse of Existing Architectures
by David McAfee
Most architectures available to the public are from government entities. While you may not want to pattern your architecture after that of a government organization, tremendous amounts of effort and thought have gone into these architectures. Consider basing your architecture on these efforts--you can get your architecture operational earlier by using the information that is available on-line. Surprising amounts of information is transferable to a new architecture effort. Most public “keepers of the light”, the enterprise architects, are more than willing to assist by letting you know what areas to emphasize (or avoid) and what processes they used.
I have seen many attempts to clone an architecture by doing a copy, then doing search and replace to make it applicable to a new organization. The problems with that are twofold: the organization has not done the buy-in process, and they are overwhelmed with the sheer size of the architecture. However you can reuse many parts of that architecture.
Straw dogs. I recommend using a cloned architecture as a basis for discussion in meetings. I call these “straw dogs” and they become the first cut at the custom enterprise architecture. They are used as the base for discussion, and it is required that they be modified in a group situation (for buy-in). Carefully selecting an architecture that is similar to your organization's will ensure it is all the more useful.
Determination of Domains and Components. By doing a comparative analysis of the available architectures, a pattern of dividing up the architecture emerges. Whether they are called Domains, Components, Sections or Areas is not important, what is significant is that all architectures are segmented to two or three levels.
Table of Contents. Existing documents have table of contents that indicate the structure of the document and the architecture. Early into an architecture project, develop a table of contents that will allow the tracking, assignment, segmentation of the entire architecture.
Images and diagrams. Images and diagrams within various components are useful in understanding or transferring knowledge to the architecture team. Remember that if the document is copyrighted, get permission to use it. However if it is a government document, only those specific images that indicate "proprietary" or "copyright" are protected.
Schematics of architectures. There are as many schematics of architectures as there are architectures. They briefly and graphically display the relationships between the various levels of architecture. A comparative analysis of these schematics is useful in determining your own architecture schematic. Complex schematics are not good, so use the KISS principle (“keep it simple stupid”). Remember at the enterprise level, managers are your audience and many of them are not skilled at reading complex schematics.
If you follow these simple rules, you can reduce much of the effort, and accelerate getting to the ”good stuff” on your architecture. Many of the consultants hired to create an architecture simply reuse a previously developed architecture (including those done at government expense), modifying it to make it more applicable to the latest customer.
David A. McAfee dmcafee@lanset.com
References
See our links to state Enterprise Architecture sites (http://www.ewita.com/links/ptr.htm).
Back To:
EWITA Newsletter, Issue 22, July 2001
URL: http://www.ewita.com
Last Modified: July 6, 2001