In the sixth article of this series (I.e. the previous one) I described a business stakeholder relationship and business concept (object) approach to defining the capability map, adding to the business process architecture from article 5 earlier. It is important to re-iterate that all of these models define key

Figure 1

concepts of the business. None of them tell us how to do things or what to do them with. The design of the business operating model later will show how we do work and employ the capabilities needed. The purpose of the architecture is to establish a set of constructs that will remain relatively stable over time and provide a reference to simplify transformation as we drive change.

Given an understanding of the strategy and intent of the business ,three of the essential aspects of the architecture are information, capabilities and value oriented business processes. This article will illustrate the needed alignment and connection among them. They do not stand alone.

The heart of the business architecture

In my meetings recently at Huawei Technologies in China with Bill Ulrich of the Business Architecture Guild and Giovanni Traverso, Chief Architect at Huawei and active participant in The Open Group standards activities, we established a simple conceptual model for the interplay among business strategy, value streams, business processes and capabilities shown in Figure 2. This is part of a bigger model including information and technology services but I will focus on this aspect for now and we will use this to frame the remainder of this article. I will expose other aspects of an extended view of this model in later articles.

Figure 2

What is the business strategy and how does it connect?

Earlier articles in this series have outlined the starting point of the strategic intent and strategy of the business as the prima facia of business architecture. Especially important is the connection to external stakeholders and their value expectations.

What is a business capability and how does it connect?

A business capability map is a business domain in its own right. If it’s on the map, you’ll need that capability in your business at some level of performance appropriate for your business. Capability in a business architecture sense has come to mean what is required to enable or contribute to the creation of value, directly or indirectly, to meet the intent of the organization or value chain stakeholders who receive our goods and services. The capabilities are used by business processes to enable the work to be done in an automated or manual way. No process usage means no need for capability.

What is a business process and how does it connect?

A business process defines the work we do for those who interact with us in order to deliver value externally. This is a very close definition to that of a value stream. For the purpose of this article I will treat them as equivalent concepts, feeling that you do not need both even though you may choose to build both if you wish. A business process gets executed in the business operating model and may be performed many times per day. The business process needs appropriate technological and human resources suitable to get things done and is therefore the place that capabilities come to life. Poor capabilities will no doubt lead to poorly performing processes and substandard measurements. A process will typically require multiple capabilities. Also a capability, if well scoped and structured ideally, will be used by more than one process.

What is a value stream and how does it connect?

Some business architects use the concept of value stream rather than business process. Historically that is because many process architectures were not constructed with a cross functional value creation point of view. If your process architecture is value centric I feel that you do not need both maps but you may have them if you wish.

The term ‘value stream’ is used in varying contexts by different communities and is thus potentially confusing. For those from the process improvement world it is typically seen as the scope of the end-to-end work to be improved in a Lean, Lean Six Sigma (LSS) initiative. Wikipedia states that ‘value stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer.’ It is used as the basis for the elimination of non-value added work (waste) for the benefit of the customer and thereby the business. It is a key approach to framing process improvement.

There are some similarities and differences in meanings when the term is used in business architecture. Similarities include a focus on value as seen by the recipient of the results of the stream and there is a strong likelihood of a similar logic at major value stages from start to end. Its purpose is to keep the architecture focused on value creation. However, there is no assignment or evaluation of ‘state‘, as in ‘current’ or ‘future’. Value Maps like sound process architectures are conceptual only.

Within the stream there are logical value creation points that a process practitioner may call an activity but a business architect may call a ‘value stage’. A value-oriented conceptual process architecture, as we advocate and described in an earlier article would look very similar to a set of value streams so it is easy to understand the potential confusion. For the remainder of the article I will use the value-oriented Process Architecture as a proxy for the value streams since our approach to establish both is virtually identical.

Connecting the concepts in the architecture

As we mentioned in the previous article, it is important to not build these domains into one another or ignore any of them since all are required to operate and design a business. In architecture we should be representing information, processes and capabilities in many-to-many relationships. Conceptually as shown below in Figure 3.

Figure 3

Stable Capabilities and Processes start from Business Objects

Using a business object (concept) view will assure that the capability map will contain “a concise, non-redundant, complete, business-centric view of the business”. Figure 4 was developed in the last article. Figure 5 delves little deeper. The model structure in 5 is also the basis for business decisions and rules determination so the concept model is extremely valuable all round.

Figure 4

Figure 5

These concepts can be discovered by identifying specific types of relationships with external stakeholders and other particular objects of interest (assets and other business concepts) that have to be managed by the business. They provide the structure of the capability map in a way that redundancy is avoided as shown in Figure 6 and 7.

Figure 6

Figure 7

Using the same business concepts again will give us the basis for an end to end process architecture that stands the test of time and is not at all dependent on an organization chart as shown in Figure 8.

Figure 8

Putting them together: Cross Mapping Processes and Capabilities

Value oriented business processes are about defining actions to create ultimate value for one or more of their recipients but just using these models alone may not sufficiently pinpoint the gaps, needed improvements or investment required in change and can lead to redundant development of resources to do work usually because of multiple requests from different organizational units for similar yet different solutions with varying scopes. However, looking from a capability map perspective alone also does not provide a context for the importance or effectiveness of a given capability, especially in how it and other capabilities in concert can impact and propel stakeholder value delivery through the processes within which they are applied. Both views are required to work together to make the right changes happen. If there is both a good capability architecture and process architecture in place then the mapping of one to the other will be straight forward. If poorly formed a value stream assessment one by one may be a useful tool to figure out what capabilities are needed.

Once we have a process architecture we can connect the dots so that once any of these are found to be lacking or a new strategy for it becomes apparent, we are in a position to determine all of the impacts of the changes. This includes impacts on the process operationally due to capability adjustments and also capability changes required due to process improvement or innovations. Figure 9 shows a sub set of the previously shown capability and process architecture maps and some of the connectivity between them. Note that a capability at any given level may affect a number of processes at any given level in the hierarchy. There is a many to many relationship between capabilities and processes and discovering the connection is a key to ongoing adaptability / easy of change.

Figure 9

Extending this picture to full capability and process diagrams is obviously not simple when shown graphically and I only show it to help the reader gain an understanding of the concept. Matrix views or queries may be a better way to show the connections captured. The use of repository tools based on an appropriate meta-model is essential once these types of architectures are being built to ensure integrity and to keep your sanity. Visio and the like cannot handle this integrity requirement.

The Burlton Hexagon

We have discussed capabilities, processes and information as concepts in this article and as we all gain more and more experience with them the professional body of knowledge will become richer. Realizing a new capability or a changed process in terms of making a difference in value creation of the business, however, may require many other architectural components to be changed. The Burlton hexagon (Figure 10) shows the relationships among several of these that are critical to bring the complex capability components to a higher state of ability and to improve the processes that execute them. I will just introduce it here but discuss it in detail as some point in a later article.

Figure 10

Future Articles

The business concepts, business capability, business process perspectives described here are still in their early days. Many organizations are still struggling to determine what to do. There is a lot of angst between business architects, enterprise architects, technology architects and business process professionals and of course operational managers regarding what is needed and how to tackle the capability versus process perspectives. The ability to drive measurable operational process work and develop the optimum set of capabilities requires a practical capability framework in concert with a sound business process view. Our need to focus on performance and measurement will be the topic of the next article in this series. A later one will describe the prioritization of changes in a portfolio that include both processes and capabilities by leveraging strategy with the connectivity between processes and capabilities as shown here.

That’s the way I see it.

Roger Burlton