The first time published on NOVEMBER 11-17, 2017
Business Capability: Part 1
This is the first part of the three-part publication introducing the concept of Agile Business Capability for the use in the business design and planning for architected Target Operating Model
The Problem
Nothing in this world falls out of the blue; in the 21st century, we know this for sure. Also, we have learnt by hard that proactive business behaviour leads to competitive advantage. This is true in the sluggishly moving market because in the fast-moving market a proactive behaviour shifts from the luxury to the fundamental necessity of the business existence. Analysts alert companies to learn (again) how to live in uncertainty caused by an acceleration of changes in the business environment where reactive behaviour becomes equal to failure more certain than not.
An enterprise behaviour is expressed via two types of business capabilities – managerial and actionable. Managerial capability is set around management methods and culture that consider the intrinsic architecture of the business system in the company – management against this architecture usually results in management devastation. Actionable capability is an affair of what the business can do in certain situations or under certain external conditions. If the market changes quicken, the business reactiveness should be adequate in both aforementioned capabilities.
Our model of business capability (BC) is based on the previous researches and, particularly, on the works of David Teece, Gary Pisano and Amy Shuen, “Dynamic Capabilities and Strategic Management”, 1997, the New Dynamic Capabilities framework for Web 2.0[1] by Amy Shuen and the latest work of Teece AT AL.[2] We have deepened in the notion of owning a BC because corporate reactiveness and business flexibility are almost linear functions of the capability ownership.
An original version of Dynamic Capabilities theory recommended companies to check amendments in the market once in a while and adjust internal capabilities respectively. Teece mentioned a need in a “corporate agility” to the market back in 2007, but the industry has chosen a different route and poured investments into a so called digital revolution that started to progress on its own frequently forgetting about the business or corporate values and market agility.
At the same time, the New Dynamic Capabilities framework extended the view (based on internal capabilities only) and pointed to the “firm’s ability to quickly orchestrate and reconfigure externally sourced competences while leveraging internal resources such as platforms, know-how, user communities and digital, social and mobile networks”[1]. We interpret the “externally sourced competences” as external capabilities rather than the acquiring external competencies and converting them into internal assets. Using programmatic interfaces known as API, an invocation of external capabilities has become fast and inexpensive (though riskier). It is a classic usage of the Contingency Theory, but proposed framework contains one aspect that, in our opinion, does not fit well with the Dynamic Capabilities theory.
Particularly, in the previous publications, we discussed in detail the status of business capability in relation to outsourcing. In short, if a company owns the business function and all needed resources for the function realisation, the company owns the capability; if the company owns the business function and outsources some or all needed resources, the company owns the capability; if the company outsources both the function and needed resources, it loses capability. Therefore, if a company invokes, engages or orchestrates external capabilities, the company owns only the invocation or orchestration itself, not the actionable business capabilities. This is the fundamental statement well-known in the concept of service orientation for business operations [OASIS]. In other words, if a company orchestrates external capabilities, it does not create its own new business capability regardless if it is dynamic or not. At any moment, any external provider can stop its service, break the contract and the company will be incapable of delivering a particular outcome.
For the last 10 years after adoption of Web 2, the economic landscape has changed dramatically due to globalisation, digitalisation and instant information exchange. Nowadays, we have to face at least two factors, which we did not have before and which make relying on programmatic orchestration of external capabilities ‘on demand’ a highly risky strategy:
- A clear shift in technology onto assembly and use of external providers with no liability, assurance and legal contract validation. In essence, technology easily outsources business capabilities of the enterprise with no legal or business rational control.
- A trend of governments that want to leash the impact such externalisation by producing a tsunami of regulations.These factors lead to such pace of market fluctuations and modifications that external capabilities existed yesterday can easily become unavailable or unacceptable when needed.
We characterise a market as a Dynamic Market (DM) for the company when the pace of external changes attains or even exceeds the pace of their adoption inside the company. In the DM, re-training employees [2] who also have to maintain ‘business as usual’ work becomes an infeasible task. Also, there are no capacity and time for transforming existing (especially deprecated) assets of the company for new needs. In other words, internal organisational and operational structures, know-how and belated feedback, which Teece points [2] to as the core Dynamic Capabilities, cannot serve businesses as they did before.
The businesses need an additional mechanism of keeping them agile to the economic environment. Such mechanism has to be self-adjusting to the market dynamics. This is not about new competitive capabilities and technologies (Web 3.0, Web 4.0…), but about a new model of the business capability itself that can naturally link with the DM.
The following sections represent and describe such new capability model and the derived features for the Target Operating Model (TOM) in the DM.
_______________________________________________
[1] “The New Dynamic Capabilities framework, posed by Amy Shuen in her analysis of Web 2.0, focuses on the firm’s ability to quickly orchestrate and reconfigure externally sourced competences, ranging from Apple, Google Android, IBM Linux developer ecosystems to crowdsourced, crowdfunded open innovations such as the Obama08 mobile app—while leveraging internal resources such as platforms, know-how, user communities and digital, social and mobile networks” [Amy Shuen and Sandra Sieber, “Orchestrating the New Dynamic Capabilities”, IESE Insight 2010]
[2] They proposed three dynamic capabilities mandatory for organisations in modern environment are: “1) the ability of employees to learn quickly and to build new strategic assets; 2) the integration of these new strategic assets, including technology and customer feedback, into company processes, and 3) the transformation or reuse of existing assets which have depreciated” [Teece, David J. (August 2007). “Explicating Dynamic Capabilities: The Nature and Microfoundations of (Sustainable) Enterprise Performance”. Strategic Management Journal. John Wiley & Sons. 28 (13): 1319–1350. doi:10.1002/smj.640.]
The Roots: Part 2
As one of the experts in adopting changes has said , “… business leaders must learn to manage change as an ongoing process. The business must develop the ability to maintain a consistently high and successful pace of change”. Fortunately, business functionality is quite stable in the fluctuating environment, especially at the higher level. An architectural rule of thumb is: the business functionality and its outcome can be realised in many different ways using even more different resources. That is, a definition of a BC lasts much longer than the individual means of its realisation.
Due to the nature of a BC, it looks into the future, i.e. it has to be ready to execute under conditions of increasing uncertainty. The faster market changes, the more uncertain execution context and, therefore, an adaptability mechanism has to be stronger. Having a business capability in the DM has a precondition of procurement of advanced and reliable information and analytical abilities. The dynamics of resources (required for the capability realisation) are high and, as mentioned before, accelerate. This lead, as minimal, to a necessity to monitor the resource availability in the market in addition to the internal resources. The major conclusions we make are:
1) the business functionality has to be loosely-coupled with its implementation resources in the BC, and
2) a BC to be reliable should be accompanied by continuous monitoring of the resource availability.
In essence, an ownership of the business functionality and separation from its resources, combined with the resource-availability monitoring, constitutes a business agility to the market. Monitoring usually tracks several competing resources and allows switching from one to another on-demand. We call it an Agile Business Capability or ABC.
Looking through the lens of business, we can recognise three mechanisms of agility:
- dynamic engagement of external capabilities if available accompanied with appropriate business risk mitigation
- keeping awareness of the resource availability inside and outside of the company while preserving the ownership of the business functionality inside the company (ABC)
- creating ABC compositions that make adoption of market changes a relatively simple task.
In the concept of an Architecture of Business system or organisation, the ABCs constitute the major instrument for building the path from the statements of the corporate strategy to their implementation in TOM. The Architects of Business – people who define and design the company business – consider market dynamics regarding particular functionality and related resources. They identify the necessities in certain BCs for the TOM.
However, not every business task can be resolved by a single BC.
Moreover, it would not be wise and feasible constructing a single monolith ABC for a complex business task or function. In the DM, it is more likely than not that “tomorrow” such ABC needs to be modified. If we have a compound or a composite of ABCs, in many cases it would be enough to re-compose it to address the market change. We can introduce relatively stable compositions of ABCs for the future business agility via ABC compositions.
A routine procedure in designing architectural solutions for business tasks encompasses a separation between ABC definition and design. Defined ABCs are joint in the compositions that then analysed, reviewed, challenged and validated. When the best/optimal combinations are chosen, the ABCs included in them pass through the design procedure where the business functionality is linked with planned implementation resources, related availability monitors are created (as needed) and turned on.
As a result, when we design TOM based on the architectural solutions, we, actually, conduct this design based on selected/optimised compositions of ABC. In other words, we design TOM with the embedded mechanism of market agility. Therefore, depending on the confidence in the resource availability, we can plan short- and long-living business solutions.
Overall, we have a business capability until we are sure we have or can gain resources for its functionality. Our knowledge, skills or previous experience appears the less relevant the more dynamic the market becomes. If we want to hire external capabilities, we, first of all have to establish a business trust with the capability owners, which is not always possible. Hiring external capabilities on-demand, without preliminary established business trust, is a way too risky endeavor in the DM.
On the Go: Part 3
Let’s assume we did the right architectural work with business capability (BC) and have designed our Target Operating Model (TOM) at the high and middle level of operation granularity. We know what value streams should take place, where and when. We know what major business processes and adaptive cases we have to build as well as where we will need operational outsourcing versus what we will deliver by our internal resources. However, in a Dynamic Market (DM), it is not an end of the game – certain market positions and resources can change continuously even when we implement TOM. To minimise an impact such changes (not all changes have a global influence), we need to prioritise implementation tasks based on their inter-dependency, business values and complexity, and then go for the ‘lower hanging fruits’ first.
In the DM, TOM and its implementation have to be a live agile construct rather than a fixed stitch ed-up plan. The mechanism of monitoring market changes has to work continuously as well during the TOM implementation. The business architectural task during this period is in examining the severity and impact of the changes and related trends, and decide on the means of their adoption either in the TOM design or implementation or in the higher level of business capabilities.
The Agile Business Capabilities penetrate TOM resulting in an agile TOM.
Based on several recent years of our practice in the TOM design and implementation, we believe in implementing things quickly and go for quick wins or quick failure early when the implementation landscape is still relatively transparent. We can also recommend performing a TOM design and implementation following the same manner we used for defining business solutions for TOM, i.e. top-down and starting with more important operational processes or with relatively self-sufficient areas. This will help to avoid waiting for the whole TOM to be designed to all details. For the cases, where the low-level inter-dependencies are not pre-designed, an implementation design and related documentation is the way to go.
We believe it is important to explain an advantage of using ABC during TOM implementation and execution. Any value stream and value chain can be viewed as an abstraction of ordered value-flows – how each value is generated is a concern of Operating Management. However, it is not a trivial task to design the values in the right order – the mode details in the business processes and cases the more complex such design. Moreover, if a change in the market impacts the company while it designs and implements its operations, a chain of reaction from one local adjustment may be not only difficult to allocate, but it may be distractive as well. We have recommend to use an architectural service-based view to help the Operating Management is dealing with the on-going modifications.
Particularly, from the Architecture of Business Practice, we know that each consumer of a business process or an adaptive case concerns only about two aspects: 1) certain functional processing has been applied to the input entities/materials/ information, and 2) an expected result has delivered at the end. Note, that these two aspects constitute the simplest definition of a business service. Thus, each business process, action or case is a business service to the consumers of its outcomes. There are no processes and sub-processes anymore; there is one service that orchestrates or invokes other services. Who and how provides these services is a low-level detail of implementation. All process’ or case’s operational details are hidden behind the input-outcome-value, which significantly simplifies operational design.
A business service encapsulates one or a few ABCs; the service’s body is built using ABC’s resources. A composition of service bodies provides sets of required operational values delivered via related streams of business processes and cases.
If the Operational management needs to improve or adjust an operation or a process, this can be done inside a business service, i.e. no other service-processes can be impacted. The same relates to the situation where we need to replace resources: a business service – functionality and outcome – remains the same while the service body can be totally altered and even outsourced.
We can have a business service whose functionality is only an orchestration of external providers. In this case, the company has a capability (functionality/service) of engaging external capabilities/suppliers and the outcome of such capability is a composition of the supplied results. The main responsibility of this capability is to contract suppliers in a way that protects the reputation and business position of the company.
A fundamental pre-condition for effective ‘on the fly’ adoption of changes in the TOM implementation is a continuous assessment of the architectural and operational risks. Operational management has to be ready and open to changes even in the relatively stable processes, activities and cases as well. At the same time, an approach to the modifications has to be pragmatic and always accompanied by an ability to roll them back if needed. The managers, at least, have to be informed about emerging changes cascading from the upper management levels as early as possible because a DM does not give many chances for fixing mistakes.
HOW to ARCHITECT for DEVELOPERS 