In the post from last week I shared some thoughts on business capabilities and why they are important. Let’s discuss about how to use them.
Before talking about how to use them here is my definition of a business capability:
Business capabilities are atomic elements that in different combinations can deliver all the business processes of the enterprise. The business capabilities and their groupings are derived from the strategy of the company and help to optimize the tradeoff between flexibility and reuse. They are agnostic of current or past systems, organizational units and process flows.
Using a capability map is the core and center of Enterprise Architecture – they are by far the most common artifact used to plan the target landscape according to our research.
Henley Business School analysis, 2024, n=214
When I see a capability map my first question is always: “What happens if we move a box?” So what would happen if we would move the two account management domains from a bank that are currently present in retail and private banking into an overarching capability domain?
I have seen two answers to that question:
- “Streetmap”: If the capability map is like a street map it is only an analytical tool. When we move a box from one domain to another the only thing that changes in reality is the large poster hanging in the architecture office (which makes it the most expensive art piece in the buidling).
- “City development plan”: When changing something in a city development plan the change goes clearly beyond changing the paper. The change triggers changes in the real world. The plan is going to change, the roadmap is going to change and finally the distribution of budgets, features and teams is going to look differently.
When creating a capability map it often starts as a tool for analyzing the current state. It is however critical that one does not stop there but also starts to use the capability map as a planning and change management tool that leads the change – rather than only documenting it.
A good test to see if your capability map is living up to that standard is to see if there are at least 5 strategic board-level decisions clearly visible on the map and would be recognized by senior management.
An example of such a decision is this one here:
Here we discuss about the payment and basket evaluation for a retail example. There could be different scenarios on how this capability is implemented in the landscape:
- The payment and basked evaluation is implemented independently for ecommerce and the stores. Here the strategic intent would be to aim for as much flexibility in both channels (e.g. having data stored offline decentrally in the store in case of network outages) at the cost that most likely the customers will notice inconsistencies between the two channels.
- The payment and basket evaluation is implemented in the store domain and is used by ecommerce. This scenario assumes that the POS in the store is providing the functionality and is flexible enough to also cater for the needs of ecommerce. Depending on the underlying architecture ecommerce might be treated as yet another store.
- The decision could also go the other way around and ecommerce offers the functionality for the brick and mortar stores. Here the strategic assumption would be that ecommerce has such a high set of requirements in terms of nonfunctional and functional requirements that it will easily also cover the stores.
- The fourth alternative would be to establish the capability completely independent from store and ecommerce to make sure that new emerging channels could build on this set of features and there is no preferred service for one of the established channels.
There is no “right” answer for all retailers but it is important that the right answer for your specific case is documented on the capability map and aligned with all stakeholders.
When designing a capability map the tradeoff between reuse on the one hand side and flexibility on the other hand side will come up multiple times. It is critical that these areas are discussed with the decision makers on the business side rather than assuming a continuation of the status quo.
For the example above the two extremes would be:
- Flexibility: Redundant implementations of the functionality in ecommerce and POS
- Reuse: Implement the functionality once and consume the central service from both domains
Another example – also from the retail context would be inventory management. Imagine a retailer that is also producing goods and delivers these to its stores and directly to the end customer. When a store orders an item they order a pallet; the end customer usually a single piece.
With regards to inventory management the two options would be:
- Flexibility: One inventory management for the stores and one for the end customer. This way each area can optimize their processes – such as single item picking for the end customers – without time consuming alignments with the other area.
- Reuse: A single, central inventory management capability that serves stores and end customers. This way inventory levels can be optimized across both groups.
Designing the capability map in line with the strategic trade offs is key. One should always challenge capabilities that are suspiciously similar to the application landscape or the org chart.