Alignment - the missing Viewpoint
The (ISO Standard) RM-ODP model is a powerful and well reasoned mechanism for creating Architectural descriptions ("architectures"). Leveraging the IEEE-1471 taxonomy, and building out a visual style and standardized approach, there is tremendous value in learning and using this the RM-ODP (Reference Model for Open Distributed Processing), and I'm getting to the point of recommending it.
That said, there is a gap in one of the most fundamental areas of the RM-ODP model. RM-ODP specifies exactly five viewpoints. This term is defined by the authors of RM-ODP as:
A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns.
In other words, if you want to communicate with Joe, and Joe cares about 19 things, you'd better cover those 19 things when discussing the system with Joe. He has 19 concerns, and we can group those concerns together into 3 viewpoints (for example), and provide a "visual language" (my phrase) that can be used to communicate those concerns.
The next sentence, from the RM-ODP Overview (ISO/IEC 10746-1), is the problem:
Five viewpoints have been chosen to be both simple and complete, covering all the domains of architectural design.
Simple? Not so fast. The views produced by RM-ODP are far from simple... but...
Complete? I disagree. Big disagreement.
For those readers who are unfamiliar with the RM-ODP, this model describes five viewpoints:
- the enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;
- the information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;
- the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;
- the engineering viewpoint, which is concerned with the infrastructure required to support system distribution;
- the technology viewpoint, which is concerned with the choice of technology to support system distribution
(There are many things wrong with this list. I'm only describing one of them here. Another will be described in a later post).
One viewpoint that the RM-ODP forgot is the one that matters the most to Enterprise Architecture: Alignment. I propose that the RM-ODP be extended to include the Alignment viewpoint.
The alignment viewpoint is concerned with the strategic and measurable purpose for the existence of a process or business system, and the justification for changing the features, structure, and operational profile of a process or business system, at a particular time, and in a particular organizational and technical environment.
The key concepts here:
Process or Business System -- This viewpoint is NOT limited to describing a technology or line-of-business application. The views may (and typically do) limit themselves to business and informational views that do not illustrate any specific "ODP" system at all.
Purpose -- The notion that a system comes into existence for the sake of fulfilling a purpose. That purpose is described in terms of business capabilities, business processes, business policies, business quality metrics, and business information. These explicit concepts describe the environment in which a system adds value.
Justification -- The notion that any change to a system has to be justified. Enterprise Architecture is the business function concerned with insuring that all justifications align to the business changes implied by business strategy. Insuring that justification is based on strategy is an activity frequently referred to as 'alignment.'
Note that, in a mature organization, alignment must be demanded to justify a change in any system, not just a software system. Changing a system requires care to prevent negative consequences on routine business operations, whether it is a system of people behaving with common goals, or teams behaving in a process, or applications behaving in a sequenced activity.
Some examples of Architectural Views that fall into the Alignment viewpoint:
Business Capability View -- An illustration of the business capabilities of a particular business unit (at any level of a business hierarchy where clear responsibilities and accountabilities exist). Concerns for a business capability view may include the importance to strategy, staff readiness, process uniformity, cost of IT maintenance, flexibility of IT change, uniformity of information, maturity of process measurement, and scorecard value of process performance.
Business Process View -- An illustration of the business processes and process activities necessary to support one or more business capabilities. May be demonstrated at varying levels of granularity, with the highest level representing abstract business processes (like "Marketing") down to task level processes (like "Deliver Marketing Brochure to Publishing Team"). Concerns may include role and responsibility clarity, efficiency, effectiveness, uniformity, delegation of authority, and service level management.
Enterprise Project Portfolio View -- An illustration of the business change programs in place throughout the business and how they align to meet the strategic and operational needs of the business. Concerns for an Enterprise Project Portfolio View may include overlaps by feature area, relative budget estimates by category, interdependencies by time, and feature delivery by time.
Enterprise Application Portfolio View -- An illustration of the operational systems and processes in place to run the business, and how well those systems are prepared to adapt to potential risks and strategically driven projects. Concerns for an Enterprise Application Portfolio view may include applications that are impacted by multiple projects in close temporal proximity, applications that share similar functionality but different data stores, applications that share data stores but remain inconsistent in their implementation of rules, and applications that with high risk metrics (risk of failure * impact of failure).
Enterprise Information Federation View -- An illustration of the core informational elements of the enterprise (like "customer," "product," "market offer," "shipment," and "service request"). Concerns for this view include addressability (the ability to find a unique data entity, using a readily accessible identifier, anywhere in the enterprise), consistency (the ability to insure that information that is shared by many people has consistent use throughout those who use it), and federation (the ability to apply the control of key data elements to the level that is closest to the team that needs or uses it).
Enterprise Technology Portfolio View -- An illustration of the supporting business capabilities required by the business, and the use of shared technology platforms to meet those capability requirements.
While I have not met anyone who had told me that these views should be in the "enterprise viewpoint" as described by RM-ODP, I'm prepared to defend the notion that the enterprise viewpoint does not, in fact, cover this space. (A different post, perhaps, if it is necessary).