- Washington DC area, October 1-4, 2007
- Washington DC area, October 23-26, 2007
- Chicago, IL, August 22-24, 2007
Enterprise Architecture Seminar (1-day)
by Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting, April 2004
The meta-architecture collects together decisions relating to your architecture strategy. It sets direction for your architecture effort, with high-level decisions that will shape the architecture and guide the architects. These include architecture principles, statements of philosophy, metaphors and organizing concepts that will guide system decomposition and design of architectural mechanisms.
Ideally, these decisions are made early on, but pragmatically, some will arise later and simply be documented together with the other strategy-level architecture decisions that have their place in the meta-architecture document(s). On the subject of documentation, you will need to record all of these decisions and their rationale in the meta-architecture specification document. The broader the scope of your architecture, the more you need to invest in communication and supporting documentation. Thus, while you will at least want to supplement the specification with presentations, you may also include a page or set of pages on the architecture web site, white papers discussing, motivating and illustrating principles and key mechanisms, and so forth.
Meta Architecture Requirements: Context, Goals and Scope
In accordance with our "just enough" principle, we need to gather sufficient input to make quick but informed progress toward a first-cut meta-architecture. During subsequent cycles we will refine our understanding of the requirements, and mature the architecture. What, then, do we need to know to set architectural direction? Our primary outcome from this stage of requirements gathering needs to be an assessment of the scope of the architecture. In order to do a good enough job of setting scope at this point, we need an understanding of the system context and goals that the architecture will support.
So, we are interested in the usage context, such as the workflow or business process that the system will support, and the system context, meaning other related systems. For the former, we find process diagrams (like rich pictures, Rummler-Brache process diagrams or UML activity diagrams) most useful. Often, we also create a domain concept model (stereotyped high-level class diagram) to model the real-world problem domain. While these models are useful in setting system scope, we also use them downstream.
The models used to explore system context are also useful for exploring scope. In rich pictures, the system boundary is drawn around the pieces of the picture that are determined to be in scope. In UML activity diagrams, the system is explicitly added as a “swimlane”, and all activities carried out by the system are placed in the system swimlane.
Meta-Architecture Structuring: Setting Architecture Strategy
Gather lessons learned: Whether you're leading a new development effort, or a significant architecture refresh, you may want to spend some time investigating architectural styles, patterns, dominant designs and reference architectures, other architectures that you can get access within your own organization, or that partners or suppliers are willing to share, as well as any that your competitors happen to have documented in the literature, or presented at conferences or user group meetings, etc. Talk to peer architects and review their architectures with an eye to extracting organizing structures or mechanisms and key concepts that work for our system. Also, reflect on your own experience, so that you can make explicit the lessons that you have personally learned.
Define the architecture strategy: Define the architecture objectives, and principles (Principles Action Guide, .pdf) to guide achievement of these objectives. The architecture objectives are defined in the architecture scorecard (a la Kaplan and Norton, 2001), which links the objectives to strategic themes, identifies an owner who is responsible for ensuring the objective is met, and identifies intermediate measures to ascertain progress against the objective, as well as measures that identify when the objective is achieved.
Select an architectural pattern or style: Quite analogous to style in building architecture, an architectural style defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural pattern or style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined (Shaw and Garlan, 1996). A growing number of architectural patterns applicable to broad classes of systems are published in the literature.
The Enterprise Architecture team may already have identified architectural patterns, or created a Reference Architecture, to be used by the organization. If so, this would form your starting point.
Define unifying and simplifying theme, metaphor, or system concept:Metaphors, analogies and symbols convey rich meaning. Metaphors and analogies enhance system integrity and understandability. Examples include the "rugby player in a business suit" metaphor for a Honda driver used in designing the new (in the late 1980’s) Honda Accord (Clark and Fujimoto, 1990), and "blackboard", "pipe-and-filter", and "broker." These latter are names of architectural patterns. The use of metaphoric names conveys richly yet succinctly the intent and structure of the pattern.
Create Documentation: Architecture is, by nature, created by the few for the consumption of the many. You cannot bring “the many” into the process directly, so documentation is an important vehicle for communicating the architecture and educating the development community during design ramp-up, and clarifying and resolving issues later on.
It is important to record the reasoning behind architectural choices at the time that these choices are being weighed. This reasoning includes providing traceability to the driving forces behind the decisions (including business strategy, product requirements, etc.), the tradeoffs that were explicitly dealt with, and the experience, modeling and analysis that was brought to bear as alternative approaches were weighed. Later you can tailor your documents for different audiences, but if you neglect to provide a record as you go, you will have more work to do trying to resurrect the assumptions and assertions, rationale and reasoning that explain the architectural decisions. In short, don’t leave documentation until the end!
Note on Activity Sequence
We have listed a set of activities, but do not intend to convey a strict sequence. There is no easily identifiable "horse" to put in front of the cart here! For example, your survey of "history" needs to be focused by your understanding of the architecture objectives, but you should not establish principles without thoroughly referencing your own experience and that of other leading architects in your organization and elsewhere. Further, if you discover the need for an architectural principle when you are drafting the conceptual or logical architecture, it is not too late to add it to the meta-architecture. Later on, you will need to put the whole architecture under change control, but early on the process needs to be fluid and open to discovery. Yes, you need to explore deeply in some areas early on, and you will need to backtrack and sometimes even start over. One of the architects we respect most in ten years of working with top architects around the world, told us he and his team entirely re-architected their system 7 times before they got it "right." Naturally, on a big and complex system you want to do all you possibly can to do this learning and rethinking when it is "cheap" to change the architecture—when all you are building is models and prototypes.
Meta-Architecture Outcomes and Deliverables
For an architecture to be good, right and successful, we cannot focus on deliverables alone. In particular, we need to ensure that intangible outcomes like attitude shifts and understanding do not get brushed aside in the effort to produce “deliverables.” We have encountered architects who actually believe that their manager is judging their effectiveness based on the number and size of documents produced, since this is the visible workproduct of architecture. Indeed, in the absence of all other feedback, this is what your manager will have to fall back on. But the more positive “buzz” you generate in the organization, the more your manager will rely on intangible signals of intangible progress. And the longer you have been in this architecting game, the more you recognize that it is the intangibles that lead to success or failure.
Yes, we need documents that provide a formal “organizational memory,” that serve as a reference, and a medium to judge whether the architecture is good and right. They help determine whether we are ready to move to the next stage. They also serve as medium for broadcast to achieve broader understanding and buy-in than we might have the bandwidth to achieve through one-on-one contact. Some time in the future, the architecture specification may be enough, but in the foreseeable future, success for architecture is most likely going to mean you have to overcome resistance, educate, negotiate, coax and cajole, working formal and informal avenues of influence to achieve acceptance and readiness to apply the architecture.
Architecture Team Alignment: The team of architects is aligned and has strong forward momentum. This is evidenced by:
Community Buy-In: There is broad buy-in among impacted managers to the architecture strategy. Key influencers in the technical communities buy-in to the architectural style, principles, central concepts, metaphors, and architectural mechanisms. This buy-in is evidenced by:
Meta-architecture lays an important foundation, laying out the high-level path toward the architectural vision, before diving into system decomposition and design of architectural mechanisms.
This phase is especially important for large projects, with an architecture team rather than a single architect. It is where the chief architect, with the help of a small core team of architects, lays out the architecture strategy that aligns and guides the architecture team during the core phases of architecture specification.
The meta-architecture documents, moreover, provide the structure for keeping track of architecture strategy and high-level decisions that impact the architecture. Thus, later in the process you may discover that you are in fact applying an architectural principle that has not been articulated, and retrospectively document it. The natural place for it is in the meta-architecture.
We strongly encourage architects to allocate time to work on architecture strategy, and just as strongly, we encourage architects to quickly start to explore Conceptual Architecture, and even Logical and Execution Architecture. This is because direction needs to be set, so that we can head out on the architectural journey with focused intent. But it is far better to learn soon that the direction needs to be adapted, than to plan intensely and meet with failure because we spent so much time planning the trip that we have too little time left for the journey!
Just bear in mind that, when adapting the direction, changes and additions must be recorded. Thus meta-architecture can be held in suspension for a while, and adapted and matured. While it is still being worked, it will be validated among a close community of "friends of the architecture." At some point, though, it must be declared "done" so that it can be formally validated, progress can be metered and it can be broadcast to the community it impacts.
Note: This page is available in white paper form (MetaArchitectureActionGuide.pdf.)
Restrictions on Use
All material that is copyrighted Bredemeyer Consulting and published on this page and other pages of our site, may be downloaded and printed for personal use. I'm sorry we have to say this, but astounding as it will seem to most readers, we have come across authors who unabashedly use our work without giving recognition to the source. If you wish to quote or paraphrase fragments of our work in another publication or web site, please properly acknowledge us as the source, with appropriate reference to the article or web page used. If you wish to republish any of our work, in any medium, you must get written permission from the lead author. Also, any commercial use must be authorized in writing by Bredemeyer Consulting.