How BUSINESS CAPABILITY may be built

The first time published on SEPTEMBER 27, 2017

What’s What?

For the last few years, a lot of people and publications were involved in the debates about what a business capability was, is and how to construct it. We will represent the view of Architecture of Business (AoB) on how one can build a business capability (BC). Actually, a BC can be built in many different ways, but the way we recommend is described in this article.

To form the context for our explanations, let us recall what a BC is (in an AoB). A BC is

an ability of a business entity to deliver (create, build, form, provide, do) a particular real world effect (outcome) in certain circumstances (business execution context).

Thus, a capability is defined around an action/activity/function, which if implemented would deliver expected outcome (see Figure 1).  Two crucial dependencies of a business capability should be outlined: 1) a dependency on the business execution context – in one context a capability delivers one outcome; in another context, it can deliver different outcome, 2) a dependency on the resources necessary for the implementation and execution of the function, or, in other words, a dependency on the availability of those resources.

Actually, the notion of resource availability includes an awareness of the execution context as well because resources are a part of this context. Mentioned notion of resources includes all types of resources that might be needed for an implementation, including: people skill-sets, custom and culture, laws and regulations, technology and management, natural resources, etc. For example, in different countries, trading financial regulations demand different formula for calculating prices of mutual funds and there are periods of time when the prices for the same fund may be different.

Another example, some of us are used to go to the Cleaning Shops, which are supposed to have a capability of cleaning our cloth from the food-stains. Such shops use different chemicals, ones should be applied to the stains with grease and others should be applied to the fruit juice stains. If a Cleaning Shop is out of grease stain remover, can it claim to have a general cloth cleaning capability? The answer is ‘no’; this shop may have only particular cleaning capability; in this case, it may announce only a fruit cleaning capability. Therefore, if the resource is unavailable, the capability vanishes.

 Figure 1.

Recommendations on How to Build

The capability-building process comprises two phases:

1. Definition
2. Design.

There may be significant time passes between these phases while many initially defined capabilities can be discarded before being designed.

Phase 1

In the definition phase, the first step should be dedicated to answering following questions:

• Why do we need the function we plan to build a capability around?
• For how long this function can be useful?
• What would happen if this function/capability would not be realised at all?
• What other functions this function is likely to be working with (in compositions)?
• What are the pre- and post-conditions for this function execution?

If the answers to these questions are convincing enough for accepting this function, the second step has to answer to these questions:

• What is the input information required for executing this function?
• What are the outcomes from the function execution should be expected?
• What is the customer base for this function/capability?
• What communication channels the provider of this function has to deliver to serve the customer base?

In the Practice of an AoB, Architects of Business construct architectural solutions as compositions of capabilities. At this moment, the capabilities are represented by well understood functions only. Business Capabilities are “building bricks” of architectural solutions – some capabilities can be used ‘as-is’, some others can form intermediary though relatively stable compositions of capabilities. Combinations of architectural solutions form a platform that is used to design the Target Operating Model (TOM) for the particular corporate strategy. In addition to BC, this platform includes relationships between BC themselves as well as between BC-based compositions. Those relationships are a specific element of AoB approach to the TOM design.

In the third step of constructing individual BC, we involve a concept of orientation on service (COS). Apparently, when two people conduct a business, they serve each other. This fact is visible not only in small businesses where every person performs a particular activity or function, but in big businesses as well where teams of employees de facto serve each other when operating accordingly to the structure of separation of labour. The COS is applicable to any business, in any industry domain, in any geography and jurisdiction. The COS is a global model of business as we know it.

Our economic environment, a market, is, in essence, a service-oriented ecosystem (SOE). In SOE, two roles operate: consumers and providers. Governance and controllers are typical service providers. Consumers interact with the providers via means of services. In SOE, a business entity can be in the role of service consumer and in the role of service provider at the same time. We all know that companies have their customers or clients and, at the same time, receive services from their suppliers and, sometimes, partners.

A service provider is understood as an entity offering and providing the service. There also may be a service owner and a service steward in SOE. A business service is defined as a “device” for accessing a business capability or its outcomes. That is, conducting a business service means executing a BC, i.e. the business function, and providing the specified outcome.

A business service comprises: pre-defined business functionality, pre-defined outcome, a set of interfaces for communicating with the potential service consumers, and a service “body” that, actually, performs the work, i.e. executes the function. Thus, a business service is a form that delivers the capability outcomes to the consumers. We can interchangeably use the terms “business capability” and “business service”. This means that the compositions of BC can be presented as the compositions of business services.

We can imagine an entire structure of an enterprise as a structure of interconnected and interacting business services. Before the SOE was recognised and defined, some business management schools taught that we should not allow internal services, i.e. services between the business teams within the enterprises. The reason for this has been explained as the following: if some internal teams would focus on servicing their internal consumers (which is native for any separation of labour) then such teams would lose focus on servicing external consumers who are the only ones bringing the revenue to the company. As a result, the internal orientation on service has been replaced by an orientation on loyalty and accountability to the upper manager and only external activities might be ‘properly’ named services.

A modern dynamic market dictates such pace of changes that traditional internal hierarchical management structures cannot handle anymore due to their limited flexibility. At the same time, growing globalisation of economic has made a lot of resources available on the market and the companies are not constrained any more by their internal resources for their capabilities. Now, we can have business services that consume resources from everywhere and this is totally transparent to the service consumers. For example, we are not surprised when getting a media-centre “Made in the USA” full of parts from China. The same is true for the business services – their “bodies” can engage suppliers from different companies and from different countries. The elements of the business service outcome can be created manually or automatically – this is immaterial for consumers.

Phase 2

When we talk about service “body”, we move into the second phase of the capability-building process – the capability design. We cannot be sure that we have a capability if we have the business function only; we need to be sure we have or will have the implementation resources for this function when needed. Particularly, we have/will have legal rights to use certain resources to produce the outcome in pre-defined time and place, we have/will have enough funds to pay for the internal/external resources or we can plan to outsource a part of (or the whole) implementation of the business service. In short, during the capability design phase, we link/map the business functionality with its implementation resources.

The procedure of capability design is time-consuming and laborious. It has to involve both architects of business and operational/delivery management that controls and rules the resources. This is why the design is applied only to those BC that are chosen after architectural reviews and challenges from functional, financial, and resource availability perspectives.

Value Streams and Distribution

A concept of Value Streams is utilised as external and internal aspects of business capabilities or business services in AoB (see Figure 2). We interpret Value Stream as a continuous flow of values that results – explicitly or implicitly – in an outcome valuable to a customer. In the external aspect of Value Streams, we compose business capabilities or business services, i.e. business values they deliver, in intermediary or final combinations that form the elements of TOM. These are the streams of capability/service values. In the internal aspect of Value Streams, we define and build the streams of values that form the service ‘body’ or a capability realisation. These are the streams of values provided by business activities, processes, cases, technology and other means implementing an individual capability.

 Figure 2.

Each Value Stream can be “abstracted” – defined by the chains of values to be built/delivered. The resulted implementation can be performed by different teams working in parallel and linking via pre-defined interfaces. The major benefit of “abstracted” value streams is in a) clear understanding of required values (purposes, benefits and risks) and b) clear boundaries of each stream and its steps/nodes. A recognition of stream boundaries allows setting them along the timeline.

It is apparent that the process transforming an enterprise to its strategic goals is spread in time and that certain results should be achieved in particular moments and places. The capability-based architectural solutions therefore are organised in the Capability Distribution Plan (CDP). At each step of the CDP, particular compositions of business services/capabilities form blueprints, which should be implemented.

As each business service consists of separate streams, and each business solution consists of separate business service/capabilities, each blueprint consists of separate solutions. Such subdivision at each level of building process makes the adoption of market changes the most flexible. An impact of a change is usually localised, which makes the whole plan relatively stable over the time of strategy implementation.

Benefits of Defined Business Capability

The Business Capability defined in this article has not only architectural benefits of separation between functionality and its resources, but also the benefits for the capability build. Particularly,

1. The decision-making, approving, designing and developing can be performed by different experts working in their own specify processes
2. Defining the development scope by the boundaries of value streams permits balanced decision between using internal and external resources even within the implementation of a single business capability. That is, the concept of business flexibility[1] regarding using whatever available resources penetrates the entire business capability design and build practices
3. An internal organisation of business capability allows and encourages using a powerful methodology of service orientation and results in a merge between a BC and Business Service from their usage, design and build. This provides the most flexible design and build of architectural and operational solutions for TOM
4. An embracing Value Streams as implementation containers leads to a parallel implementation of architectural solutions by different delivery teams, which makes time to market shorter and results adaptable to market changes.

An Alternative Path to the Same Result – Instead of Conclusion

Let’s validate our conclusions with a formal understanding of business capability offered by theDictionary. It states that the understanding is set around an ability of an entity to achieve its objectives, especially in relation to its overall mission.

Both objectives and mission are the “subjects of the future”. Considering current existing skills, knowledge, products, processes, resources and operations as capabilities is not justifiable enough because we do not really know what might happen to them in the future. Certainly, we can qualify our current tangible and intangible assets as more or less relevant to our objectives and mission, but this is the most what would be reasonable to do. This does not assure us that we will have them tomorrow or when they will be needed.

In contrast, if we do not rely only on what we have today and plan for the resources, we make the resource constraints more elastic and open a door to adoption to the coming changes. If a change happens, we have two ways to address it: 1) adjust our plan for the capability resources, or 2) re-build this capability immediately with new resources. So, if we need a capability in a few months, we can either change our plan a few times or we will re-build the capability again and again (to keep it current). I think the preferences here are almost obvious.

To be aware of changes in the market that impact our capability, we need to monitor the market and analyse its trends continuously. An awareness of resource availability is the cornerstone of having a capability in the AoB. If we cannot lead the market, we have to tail it as close as possible – only this will make our capabilities real and reliable.

__________________________________________

1    A business flexibility is a measurable value used for comparing business solutions via efficiency of their implementation. The formula  of flexibility operates with the cost of the change adoption, time to market of this adoption and the cost of modification of this adoption caused by another change.