First time posted on SEPTEMBER 17, 2017
Defining Business Capability
An Architecture of Business concept defines and utilises a simple connotation of business capability (keeping in mind a famous expression of Einstein). A business capability is an ability of an entity – an organisation, or a team, or a person – to deliver certain real world effect or outcome in particular business execution context. In short, a business capability is a way to deliver, to do something. The following examples can help to feel the meaning of our definition.
1. In a Programme meeting:
An Architect of Business: We need the capability to gain an extra £145M in this year via trading at the LSE [1].
A Manager: We should not worry about this – it is almost our regular quarterly revenue; we made £420M for the Q1 to Q3.
An Architect of Business: Are you sure we can? About 85% of our revenue at LSE came from a short sale.
A Manager: So what? We have to make an increase of only 3.6% this time. I believe we have such capability.
A Business Architect: Well, but the downtick[2] short sale, which we used the most, will be prohibited in a week… So, do we have this capability or not?
2. From a conversation between a CFO and CIO:
CIO: We have saved some money and trained 5 people in GDPR compliance development for only £5K total. Now, we have a capability to perform the Regulation’s data privacy development.
CFO: Well, it is good to have trained specialists in the company, but we have allocated financial resources to outsource GDPR development. I do not think we will construct such capability in the company.
3. A company faces difficult financial situation and has to layoff certain number of
personnel. At the same time, a company cannot afford losing customers and asks people to “achieve more with less”, i.e. take on more work and switch from one role to another when possible. The company used to service customers by receiving and then fulfilling orders. After the layoff, number of orders had dropped sharply. What’s happened? The company is supposed to have the same servicing capability as before. An analysis of this issue has shown that in the period of time immediately following the layoff, the number of orders did not drop, but the operating teams missed orders because people were busy with other duties when orders came.
Summarising these examples, we can say that in the example 1, the manager believed the company had particular trading capability, but this believe was based on the precious experience that was not matched to the changing legal environment. Current capability supposed to vanish in a week while nothing changes in the company. In the example 2, when CIO planned for a capability of developing compliance, a need in such capability was omitted. Finally, in the example 3, a change of resource availability that was not compensated by other means, e.g. by creating an order queuing mechanism, resulted in unstable order processing, which resulted in financial and reputational losses.
Our conclusion: a business capability is not what the business does now or did yesterday – it is not a knowledge of how to do. A capability is contextual: an ability to do/deliver something yesterday does not guaranty an ability to the same tomorrow when the context changes. This is not a discovery – this effect existed in the past. Why we did not see it? – Because the business execution context did not change that fast as today. The mental pace of reaction to the market remains at the level of 30s last century in many businesses, i.e. it takes days while now the information reaches us in seconds, the decisions are needed in a matter of minutes and actions – in hours. Well, not all markets and industries are that fast yet, but we steadily move toward such conditions.
An ability to deliver is equal to an execution of a function while a context includes not only the state of market and laws/regulations, but also certain moments of the time or certain events when and the execution should take place. This leads us to a necessity to understand that an execution of a function requires and depends on the resources. A term “resources” here is used in a wide sense and contains everything that might be needed for the implementation/execution of functionality. The resources can include: finance, legal rights based on laws and regulations, specialists, managers, technology, methods, operations, tools/instruments, natural resources, energy, security, quality control, etc. – obviously, this is not the full list.
Thus, we have found that an ability to deliver comprises 1) business function and 2) resources for its execution or implementation. An absence of any one of these two annuls the capability.
A business function defined what the business should do in order to reach certain outcome. This also includes definitions of where and when this should be done and for whom. The function or functionality can be of different granularity, dedicated to different execution context and different customer base. The functionality can be presented via business services with a spectrum of interfaces and the body realised via different value streams.
For the company to be sure it has a particular capability, the company should be confident in the resource availability at certain time and place. The resources may be internal or external, this does not matter. The company has to monitor the resource availability all the time as a pre-condition for having the capability. If a company outsources an implementation of functionality, the company still owns the capability; if the company outsources the functionality (and implementation), it loses the functionality.
Thus, a business capability – the functionality and needed resources – should be accompanied by the assurance in the resource availability. Only in this case we can reliably plan and design capability-based business solutions for the corporate strategy that lasts a few years ahead.
The Architects of Business form these solutions and set them in the time in the form of Capability Distribution Plan. This plan becomes the baseline for the Business Transformation Plan used in the design of Target Operating Model (TOM) for the corporate strategy. We also call such TOM an architected TOM; it is optimised for both tasks of the corporate strategy and changes in the external business environment (context).
Making sense of Business Capability
Every company has i own collection of business capabilities and sets of capability compositions. At a glance, all, for example, retail businesses have the same top-level capabilities, but we know the businesses are different. This is because the uniqueness of the business organisation comes from the unique compositions of business capabilities that and the quality levels of the outcomes.
Indeed, when we understand that we can loose-couple business functionality and its resources, we do not need to implement (have) the capability up-front – we can build it when needed using the market sources that usually become cheaper over the time. We can also improve or increase the quality of the outcomes with no impact on business functionality and overall business solutions. We do not need to wait when we re-train internal specialists – we can get them from the market. The value of this approach is in that we usually have a market of specialists and can replace skill carriers faster than retraining existing personnel.
In the dynamic market, not only time to market has enormous value. An ability to change/ recompose business solutions is now a competitive advantage of a company.
How to define the low-level or leave business capabilities (business functionality) and how to compose them into business solutions is a purview of the Architects of Business. We cannot teach you how to reach required professional level for these tasks in one article, but we can give you a key to open the “magic door”.
We used to believe that a right name symbolises a right understanding of the thing. It is a noticeable trend in technology and in its “Business Architecture” to use marketing names instead of the ones that clearly articulate what we are dealing with when use/apply a method or an entity. Here are a few examples of what we face and have to get through. Let’s compare “Markets Capability” [3] with a collection of Market Researching Capability, Research Documenting Capability, Analysing Capability, Reporting Capability and Research Archiving Capability. Also, let’s compare “Workflow Capability” [3] with a collection of Workflow Configuring Capability, Workflow Deploying , Workflow Optimising Capability, Workflow Managing Capability, Workflow Replacing Capability.
When we read any item from the aforementioned collections, we clearly understand what we can do and we can count on it. When we read the quoted capability-entity, we hit the wall of ambiguity that forces us to guess what has been meant and whether it is what we need or can rely on. What kinds of architectural or business solutions can we compose in ambiguous realm? We believe, they would be the ambiguous solutions that can mean anything and not necessary what we need. This is why when architects use such terms, they should expect that the delivery and operating people would understand the intentions in the wrong way. So, to get the needed outcome, the ‘implementors’ should to be ‘waked by hand’, like in a kindergarten, instead of focusing on the professional tasks and work.
We assume that ambiguity has come from the slang used in IT departments aimed to shorten an expression that had particular business sense. Some time ago people used a noun as a type or category of capabilities and then, over the time, omitted and forgotten this important attribute. They started naming capabilities by their types instead of what can/should be done/delivered; they were “throwing the baby with the water”. The conclusion we make from this observation is that a name of business capability should reflect an action – the delivery – and, therefore, should include either a verb or gerund. This is the only commonly available way to minimise ambiguity.
If we finally return to the original business meaning of capabilities, both business and technology people would benefit from it. The Architects of Business will have a clear picture of what should be done and where the gaps in functionality and operations are. The people in technology will also have a clear picture of needed functionality, but also it will be much easier to map functionality onto the systems performing it. Nowadays, this is called an agility of technology to business.
Benefits of Business Capabilities Defined via Function and Resources (instead of conclusion)
A Practice of Architecture of Business comprises several major directions and one of them is about working with business capabilities as we defined them. A logical separation between business functionality and needed resources allows following architectural and business benefits:
- Simplified modelling the alternative combinations of business capabilities
- Simplified valuating combinations of business capabilities to identify the optimal one for the given business execution context
- Considering the use both internal and external resources, requiring the internal resources to be concurrent with the external ones
- Creating intermediate reusable compositions of business capabilities and gain competitive advantage in the market by re-composing business capabilities, which can be done at a magnitude faster than developing for a new market change
- Effectively manage the life-cycle of capability compositions and business (architectural) solutions remaining agile with the market.
These benefits make business capabilities the major instrument of the Practice of Architecture of Business. An Architects of Business decompose the statement of corporate strategy into a spectrum of business capabilities of different granularity to understand what should be done and what resources will be needed when and where. Then, the leave business capabilities are composed into the structures and solutions, which should be realised via corporate TOM.
The business capabilities even in compositions do not constitute Architecture of Business – they are the “bricks” for building the enterprise in accordance with its strategy and in the given (even changing) business environment. When one observes clearly named business capabilities of a certain category, the gaps between what is needed and what is available becomes apparent. This directs the decisions and speeds-up the whole process of adjusting the company to the market changes.
______________________________________________
[1] LSE here stands for Lahore Stock Exchange; it has a rule “Short Sale will only be permissible on Uptick or Zero-Plus Tick”. In the London Stock Exchange, there are significant constraints on short selling as well – “Short selling on a substantial scale can lead to significant settlement problems, which in turn can result in the Exchange having to issue a market status message warning the market of settlement problems” and others – enforced since 29 Sep. 2014.
[2] A transaction on an exchange that occurs at a price below the previous transaction.
[3] The quoted name of capability is provided in the Business Architecture Body of Knowledge (BIZBOK) book issued by the Business Architecture Guide. The full BIZBOK is available to Business Architecture Guild members only
HOW to ARCHITECT for DEVELOPERS 