Architecture Strategy

Visual Architecting Process™ Action Guides
- Init/Commit
- Meta-architecture
- Conceptual Architecture
- Logical Architecture
- Execution Architecture
- Architecture Deployment

Join our
mailing list

Meta-Architecture Paper in .pdf format

Architecture Training

Software Architecture Class:

- Washington DC area, October 1-4, 2007

Enterprise Architecture Workshop

- Washington DC area, October 23-26, 2007

Role of the Architect Workshop

- Chicago, IL, August 22-24, 2007

Enterprise Architecture Seminar (1-day)

Architecture Overview Seminar

Architecture Consulting

Consulting Services Overview

Meta-Architecture

by Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting, April 2004

Introduction

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.

Context
In the Init/Commit phase, much of what we did was geared to understanding the organizational context (considering where we have come from, what our current context is, and what our desired state is), and getting a high-level understanding of the system context, building up to a shared vision. The objective in Meta-architecture Requirements is to get more understanding of the context of use. The preliminary decisions about the system, and in particular determining system scope, rely on this understanding of context.

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.

Goals
In the Init/Commit phase, we identified the architecture stakeholders. These included users of the system as well as business stakeholders. We need to understand the important goals that various stakeholders have for the system (in use) and the architecture (supporting systems under development and evolution). We use stakeholder profiles (Stakeholder Profiles Action Guide, .pdf) to capture the business goals and system/architecture goals of the stakeholders (influential individuals, and groups of stakeholders).

Scope
The stakeholder profiles are analyzed to extract goals relating to system services, and system properties. System services can be shown as use cases on a use case diagram for the system. Users, as well as related systems, outside the scope of the current system, are placed as actors outside the system boundary. While the use case diagram shows system services that are determined to be in scope, a narrative or other mechanism is needed to record services and properties that are ruled out of scope and the rationale for doing so.

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.

Outcomes
Sponsorship: The architecture has a strong sponsor and champion in senior management. The commitment of the sponsor is evidenced when the sponsor:

fully resources the architecture project (e.g., the architecture team is not made up of “part-timers” who have competing responsibilities on other projects);

actively removes barriers to architecture progress; and

visibly champions the architecture among managers and the developer community.

Architecture Team Alignment: The team of architects is aligned and has strong forward momentum. This is evidenced by:

strong and accepted leadership within the architecture team;

creative, open and collaborative exploration of architectural alternatives; and

effective decision-making.

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:

others (not on the architecture team) are promulgating the architecture strategy, architectural style and architectural principles, and presenting the rationale you would give when someone challenges them.

Deliverables
Consider the concerns of each stakeholder group, as well as concerns of individual stakeholders in the case of those who have high impact on the success or failure of the architecture. Also, consider the communication styles of these stakeholders. Tailor views that address specific concerns, and tailor communication formats to match communication styles and needs. This process (consistent with the IEEE 1471 Standard for Architecture Description), will help you target your architecture deliverables most effectively. In the sections below, we cover deliverables that are generally useful.

Documents
Architecture Strategy Document: The audience is senior management, and the purpose is to show how the architecture strategy supports the business strategy, and indicate how the technical strategy will be implemented. Key artifacts to include in this document are the strategy map visually linking architecture objectives to business objectives, the architecture scorecard, and architecture principles.
Meta-Architecture Specification Document: The audience is the architecture team, and the purpose is to provide a complete record of decisions (and their rationale) made to guide the architects during the remainder of the architecting process. This record includes technical implications of the architecture strategy and high-level architecture decisions including architectural style, metaphors, early decisions around architectural mechanisms, together with the rationale for these decisions. It is helpful to include alternatives that were considered, and why they were ruled out.
White Papers: The audience is the technical community, and the purpose is to explain and achieve buy-in. White papers address a focused topic, such as discussing, motivating and illustrating an architecture principle or a key architectural mechanism.

Presentations
Here is a piece of advice from Rob Seliger that we have found useful: In communicating the architecture to upper management, start with the business strategy and work towards the technical implications. But in communicating with a technical audience, start with the technical content and work towards the business motivations driving the selection among technical alternatives. In other words, start in your audience’s mindspace, and provide the bridge to the implementation strategy, in the case of the business audience, or the business drivers, in the case of the technical audience.

Web Site
In this age of the Internet, it is imperative that you have an architecture web site! But, you need a site that is well-designed to present the architecture according to the needs of different stakeholders. Simply adding a web interface to a repository of architecture documents is going to confuse and overload your various audiences. Rather than supporting your effort to communicate, it will subvert this goal. Apply your architecting skills and techniques to the structure of the web site: identify stakeholders and their concerns, and structure views into the architecture documentation set accordingly. Do this early, so that your stakeholders will become eager followers of the unfolding architecture work, and your job during architecture deployment will be easier.

Conclusion

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.
References

Bredemeyer, Dana and Ruth Malan, "The Role of the Software Architect," published on the Resources for Software Architects web site at http://www.bredemeyer.com/papers.htm

Clark and Fujimoto, "Power of Product Integrity", Harvard Business Review, 1990.

Kaplan, Robert, and David Norton, The Strategy Focused Organization, Harvard Business School Press, 2001.

Malan, Ruth, and Dana Bredemeyer, "Less is More with Minimalist Architecture", IEEE's IT Professional, September/October 2002.

Malan, Ruth, and Dana Bredemeyer, "Architecture Strategy", published on the Resources for Software Architects web site at http://www.bredemeyer.com/ArchitectingProcess/ArchitectureStrategy.htm

Resources

Bredemeyer Consulting's Software Architecture Workshop covers the Visual Architecting Process. As the workshop progresses, small teams of participants take their project from vision to architecture. This format, punctuating lectures with exercises that build on one another, gives participants the opportunity to learn and practice techniques used in each of the process steps.