Thursday, June 07, 2012

Six Views of Business Architecture

#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 2x2 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 or Cybernetic 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.

Responsibility View (aka Organization or Relationship)

The OMG defines an organizational view in terms of the relationships between organizational units, so I think the term Responsibility 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, and this work can be traced back to the ORDIT methodology of the early 1990s. 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.

Cybernetic View (aka Management or Governance)

Finally, the cybernetic view describes how the organization and its management thinks. This covers all the aspects of organizational intelligence, from information gathering, through sense-making and decision-making, to organizational memory and learning.

See separate post on the Cybernetic View.

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 Responsibility, while Stafford Beer's Viable Systems Model combines the Capability View and the 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.




My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/

6 comments:

Stuart Boardman said...

This is superb! Thanks. I have a few questions and comments.

Do you foresee a link upwards to stakeholders and their concerns a la ISO 42010 (IEEE1471)? Or are the viewpoints implicitly stakeholder specific?
And downwards to model types? I could imagine more than one model being useful for some of the viewpoints.
I very much like your use of “Business Knowledge View” – gets us away from endless discussions about data vs information. And it’s the knowledge that matters at this level.
I also strongly agree that strategy exists to realize motivation.
I’m hesitant about the idea that the organization can control the level of variety it needs to respond to. I agree that it can influence that by choosing to restrict its interfaces with the outside world but there are always going to be sources of variety it can’t avoid and which it therefore will have to take into account in its capabilities and/or organizational model.
Lastly, I may have missed something but I have the feeling that your viewpoint set covers everything apart from the implementation side of an enterprise architecture. That makes me slightly concerned about calling it all Business Architecture. It feels dangerously close to the TOGAF treatment of BA as everything that isn’t IT, which an increasing number of us (including friends of TOGAF) are uncomfortable about. I’m sure that’s not your intention but would like to know your take on this.

Once again thanks.

Richard Veryard said...

Some great questions from Stuart. Here are some quick answers.

Do you foresee a link upwards to stakeholders and their concerns a la ISO 42010 (IEEE1471)? Or are the viewpoints implicitly stakeholder specific?

I interpret ISO 42010 as mandating many-to-many relationships between stakeholder/concerns and viewpoints.

And downwards to model types? I could imagine more than one model being useful for some of the viewpoints.

Yes, absolutely. For example, within the Business Motivation view, we might have simple BMM models and more sophisticated i* models, as well as both qualitative and quantitative models.

I very much like your use of “Business Knowledge View” – gets us away from endless discussions about data vs information. And it’s the knowledge that matters at this level.

I'm not taking credit for the name, but I agree that we are interested in What-The-Business-Knows (as well as how it knows what it knows).

I also strongly agree that strategy exists to realize motivation.

This seems obvious to me, but it seems not to be obvious to everyone else.

I’m hesitant about the idea that the organization can control the level of variety it needs to respond to. I agree that it can influence that by choosing to restrict its interfaces with the outside world but there are always going to be sources of variety it can’t avoid and which it therefore will have to take into account in its capabilities and/or organizational model.

The word "needs" here is the problem. The organization effectively chooses how much variety to respond to and how much variety to ignore - and it can be staggering how much an organization can ignore things that others think to be important. (There is a link here to the Management View.) These choices may not be consciously debated, but they are implicit in the structure and behaviour of the organization.

Lastly, I may have missed something but I have the feeling that your viewpoint set covers everything apart from the implementation side of an enterprise architecture. That makes me slightly concerned about calling it all Business Architecture. It feels dangerously close to the TOGAF treatment of BA as everything that isn’t IT, which an increasing number of us (including friends of TOGAF) are uncomfortable about. I’m sure that’s not your intention but would like to know your take on this.

What exactly do you mean by "implementation"? The business architecture is implemented in many ways - for example, not only in IT systems but also in physical processes and bureaucracy. TOGAF may not have implementation domains called HR and Legal (where we would find implementation artefacts such as job descriptions and bonus schemes, as well as legally binding documents such as outsourcing contracts), but there's nothing stopping us defining such domains.

Stuart Boardman said...

Richard
I deliberately chose "implementation" in order to be broader than IT. Poor choice. No matter. My point was that TOGAF manages to define three architectures in just the IT domain and this creates an imbalance, which reflects TOGAF's IT orientation. If we were to have other domains like HR, Legal or any service delivery domain, then at least some of them would merit an architecture. So putting everything you've covered into one single architecture may create a greater imbalance than we already see in TOGAF.
Maybe it wouldn't but it struck me as worth thinking about.
That aside I'll come back on requisite variety, when I've thought about it some more.

Richard Veryard said...

What exactly is an architecture domain anyway? Wikipedia seems to think it is the same as a view or viewpoint. Or maybe it is a set of stakeholders/concerns.

TOGAF tells us that the world can be understood as a series of discrete domains, and then persuades us to worry about the balance or imbalance between these domains. But if we move away from TOGAF territory, I don't see why I need to care very much about this rhetorical imbalance.

As for the word "implementation", this implies a separation between design and execution, or between a decision/policy and the following action. But does that entail separate viewpoints for the design and for the execution, or for the decision/policy and for the action?

Alex Matthews (@remembermytweet) said...

Richard,

Thanks for another excellent post. I created a similar 6 view model a couple of years ago and have found it very useful for a variety of uses most notably benefits planning, portfolio management & alignment to motivation.

I personally use a separate layer for all of data, information and knowledge and then map them but I can see why and how you have included the knowledge view.

So the view that I have instead is a "business services" view which essentially allows for thinking through the lens of customer experience. I don't see where you are accounting for that in your views / model. Would you be kind enough to talk me through how you account for that please? Is it in the relationships view?

Also location. Location can be important for such things as business continuity planning and time zone planning, etc. Where do you account for location please?

Thanks again for the great post

Richard Veryard said...

Alex

I think the critical thing about services is the decoupling between the external view (Relationships, Interfaces) and the internal view (Capabilities, Components). See my post on Ecosystem SOA. There is then a further decoupling between the external view and the customer experience, which is covered by the Motivation view.

What about Location? As a business architect, I'm much more interested in organizational boundaries than geographical distance. Obviously there are some implementation issues and risks associated with location, especially when a capability is situated in a single place, or governed under a single regulatory regime, but I don't think these need to be part of the business architecture. As far as I'm concerned, location is just an attribute, like currency or timezone.