Why you need granular business capabilities despite having business processes

As this is a topic of much debate in theory and practice I would like to emphasize the rational why something like business capabilities is necessary for most enterprise architecture setting:

Grouping

In Enterprise Architecture a key decision to make is to group resources together. These resources could be

• Functionalities – a large change in the features of Accounts Receivables is more likely to have code dependencies to Accounts Payable than to Property Managements
• Teams – the team of e-commerce checkout should be closer aligned with the Payments team than with the team providing IT support for Legal
• Decision making – Having someone being able to take tradeoff decisions between customer acquisition and customer loyalty management is more important than someone deciding on customer acquisition and transport management at the same time
• Many other groups: Budget, Timing, Data, Ownership, …

Labeling

We need labels that signal if a resource belongs to one group or another. I call these groups business capabilities – but choose the name you like. Domains, Boxes or Clusters are popular alternatives. I am not arguing about the naming but about the fact that you need some kind of boxes or groups.

These groups only make sense if they do not contain any unintentional duplication or redundancies:

• Functionalities should most of the time only be implemented once
• People should normally belong to one team
• One area should only have one decision maker
• You can’t spend the same money twice
• …

Processes alone do not work

If we agree that we need redundancy free groups to design the best possible resource allocation for the enterprise this disqualifies business processes. Business processes are by nature based on reusing the same functionalities and features across different areas.

Applications also don’t work on their own

One could argue that applications are ideally redundancy-free and therefore the perfect artifact. This could indeed be a possible solution for the plan of the future. If the name that works best for you is “future functional application clusters” rather than “business capabilities” – feel free to use this term.

The only caveat here is of practical nature: A lot of business stakeholders will have a more intuitive understanding of “Order management” rather than the application name “OXM-35” and when working with application names it can be irritating that the functionality that is this year part of “ERP Vendor x” will next year become “Demand Forecasting Vendor y” – and there will be an unhealthy tendency to stick to the established solutions rather than thinking about a new strategy.

Business capabilities as the translator

If business processes and applications are not the solution we need something else that business and IT people can understand and work with. For me this artifacts is a capability. These have to be documented properly (and communicated and used outside the Enterprise Architecture team) and they have to have the right granularity.

Granularity

Regarding the granularity of the business capabilities this also means that you have a granularity that is meaningful in supporting the resource planning. Think about this in analogy to budget planning. If you only had 5 budget positions for the entire company it would not be possible to strategically invest in customer acquisition over customer loyalty.

If we assume that an agile team consists of 10 people and one should have a sub-capability for each team the number of capabilities should be in the ballpark of the number of people divided by 10.

The same applies to money – the number of groupings should be granular enough to allow for strategic allocations of investments. Most companies with end up with 50-200 boxes as a minimum granularity.

Hierarchy

This one might be optional but most of the time you want to have some kind of hierarchy in the grouping. It should be easier to shift resources from demand forecasting to supply forecasting than from property management to customer management. Also two functionalities within supply chain (although being in different “boxes”) could be coupled more tightly than with one in a completely different area.

Having 2-4 level in a capability map (e.g. Supporting capabilities > Finance > Accounts payable) makes the discussions much more meaningful.