#bizarch Does it make sense to produce a business architecture from a single viewpoint, such as a Process Viewpoint or a Capability Viewpoint? Or do we need a proliferation of viewpoints, perhaps arranged in a 2×2 matrix such as the Zachman Framework?
In its Business Architecture Overview, the Object Management Group Business Architecture Working Group has identified five key views of a business, which it calls 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view. See my previous post on the Five Views of Business Architecture (OMG), in which I also identify a sixth one, which I’ve been calling the Management view. (Strictly speaking these are viewpoints rather than views, but I’m trying to stick to the OMG terminology as far as possible.)
I have used all of these views for business modelling, and I am convinced that they are all useful – although they may not all be required on every project. (I don’t expect you to believe this without further evidence, and I am currently assembling a set of worked examples.) I have presented earlier versions of this schema in the past, with slightly different names, but I believe the current names and explanations are clearer.
Business Motivation View (aka Purpose)
This viewpoint describes what the business achieves for itself and its stakeholders (direct and indirect value). It specifies desired, potential and actual performance in terms of goals and objectives as well as positive and negative outcomes. (For example, a risk is a potential negative outcome.)
Outcomes may be described qualitatively or quantitatively, and there are different analysis techniques and notations associated with the transition from quantity to quality.
A more sophisticated view would consider the uncertainty associated with these outcomes, as well as the potential conflict between the goals and values of different stakeholders. It would also recognize that there is often a subtle difference between the official or espoused goals and objectives of an enterprise and its defacto goals and objectives. See my post on Enterprise POSIWID.
The OMG calls this the Business Strategy view, but I think this is a misleading name. The strategy doesn’t reside in motivation, but in how the business mobilizes itself to satisfy some set of motivations.
The name Business Motivation view reflects the Business Motivation Model (BMM), which provides some limited coverage of this view. Alternatively, I could call this the Business Performance view.
Business Capability View (aka Component)
This viewpoint describes how the business delivers direct and indirect value in response to the challenges of the environment. Many business architects merely decompose the business into something that looks like an old-fashioned functional hierarchy, but there are several important architectural issues that need to be addressed within the business capability view.
- Coordination of internal and external capability. When an organization chooses to delegate or outsource a particular capability, the coordination of the outsourced capability remains.
- Capability dependencies – how strength or weakness in one capability affects the performance of other capabilities.
- Requisite variety. An organization chooses what range and variety of events it is capable of responding to, and this variety is reflected in specific capabilities.
- Through-life capability management. Establishing a capability requires some level of investment, in terms of equipment and recruitment and training and so on. The costs of maintaining a capability may escalate, especially if the demands keep changing.
- Performance, quality and value-for-money. It is always possible to devote more energy and resources to improving any given capability, but this is only justified if it is reflected in business performance (aka “the bottom line”). Business excellence models (such as Baldrige and EFQM) address this kind of alignment.
Capabilities may be encapsulated in what I have called Business Components, as in my 2001 book on the Component-Based Business. Thus we could also call this the Component View.
Business Activity View (aka Process)
This viewpoint describes the day-to-day behaviour of the business, or what the OMG calls “business in motion”. Traditionally processes are seen as a chain of value-adding process steps, thus the OMG calls this the Value Stream view. However, the value network paradigm looks significantly more powerful than the value chain paradigm, and I prefer to use the neutral term Business Activity.
Business Knowledge View (aka Concept)
This is a well-established architectural viewpoint, previously known under various names such as Conceptual Information Model or Business Data Architecture. It basically captures what the business knows, and the semantics of how the business talks to itself and its partners. This viewpoint is critical for business interoperability. Knowledge also includes contextual knowledge, which is essential for providing differentiated services.
At this level, I’m not distinguishing between data, information and knowledge. Classifying information as “structured” and “unstructured” is not as important to the business architecture as it is to the IT architecture. What is important, however, is the question of business epistemology – what it is possible for the business to know, and with what level of confidence. There are various sociotechnical mechanisms that may make it possible for a 21st century business to know all sorts of things that were simply not available before. But of course, the business architect is not directly interested in the mechanisms themselves – these belong to some other architecture.
Business Relationship View (aka Responsibility)
The OMG defines an organizational view in terms of the relationships between organizational units, so I think the term Business Relationship View is a better name for this view. I have done a lot of work on business relationship modelling, looking in particular at questions of the organizational responsibility and accountability for activities and outcomes. These relationships and organizational interfaces may be represented as services, with various levels of formality in defining and measuring service levels. There are also important architectural issues in dealing with the idea of Business-As-A-Platform, in particular in relation to multi-sided markets.
Management View (aka Cybernetic)
Finally, the management view describes how the management thinks. This covers all the aspects of organizational intelligence, from information gathering, through sense-making and decision-making, to organizational memory and learning.
Hybrid Views
These views are not sacrosanct, and there are some useful business models that may not fit neatly into these six viewpoints. For example, Martin Ould’s Activity Role Diagrams seem to involve a combination of Activity and Relationship, while Stafford Beer’s Viable Systems Model combines the Capability View and the Management Cybernetic view.
I am also convinced that business strategy is not contained within a
single view (as the OMG would have it) but is about the relationships
between the views.
Levels of Abstraction
Each of these viewpoints can be applied at different levels of abstraction. For example, in business relationship modelling, we may identify a partner-independent model (which merely defines an abstract relationship with a notional business partner) and a partner-specific model (which defines a concrete and contractual relationship with a real business partner). Meanwhile, in the capability view we may need to distinguish between abstract capabilities (which some frameworks regard as the only true capabilities) and sociotechnical lumps that implement these capabilities (which may be called components or nodes).
This relationship between abstract and concrete is what Zachman calls reification, and everyone else calls realization. Note that both the partner-independent model and the partner-specific model belong to the business architecture and not to any other architectural domain.
