Business Capabilities

In my last post, I mentioned that we can achieve very stable service contracts by aligning our service boundaries with business capabilities. But this then begs the question, what is a business capability? In short, a business capability is something that an organisation does that contributes in some way towards the overall function performed by the organisation.

The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.

This means that any organisation operating within the same vertical industry will have a remarkably similar capability map. This is a result of the fact that what these organisations do and the services they offer are fundamentally the same. What differs from one organisation to the next is how these capabilities are implemented.

That is, the business processes, applications, data, technologies and human resources (including their roles, skills and knowledge) that support each capability will differ from one organisation to the next; but the nature of the capabilities themselves, the value they deliver, and their core responsibilities will not vary.

This means that whether a capability is implemented as a series of completely manual processes executed by employees, whether the capability is completely or partially outsourced, or whether the capability is fully automated with IT systems does not change the nature of the capability itself. Other capabilities within the organisation are concerned only with the fact that the capability is performed, not how it is performed.

As such we can change the implementation of a business capability without affecting any other capabilities supporting the organisation. This makes for a considerably more stable business architecture description. One problem commonly faced by business architects is that the organisation continues to change and adapt during the process of mapping out the business processes.

This is in part due to the fact that process maps in a typical business architecture tend to span multiple business capabilities. This significantly increases the number of process maps that contain implementation details of a single business capability. Consequently when we change the implementation of a business capability, there is a larger number of process maps that need to be updated.

By limiting the scope of our process maps to a single business capability, we substantially reduce the number of process maps affected by a change in the implementation of a capability. As a result, our business architecture description is more stable and by extension more manageable.

Business capabilities are hierarchical in nature. We can decompose a business capability into smaller capabilities that support the broader capability. We only decompose a capability into smaller capabilities where there is sufficient distinctiveness between those sub-capabilities to warrant separate and distinct process maps to describe those sub-capabilities.

Of course there are business processes that span multiple business capabilities. However, those processes are realised as event driven process chains. Each business process that executes within a business capability has the ability to raise business relevant events. Other business processes that execute within other capabilities subscribe to these events in order to trigger the execution of these processes.

As such, end-to-end business processes are realised implicitly by virtue of the event publications and subscriptions between processes defined within each business capability. Note that this notion of business event publication and subscription is not a technology concern. It is simply a stable means of describing how business processes execute within an enterprise.

Now, this is a really nice way of modelling a business architecture. But what is the relevance to SOA? Well, when we apply the SOA style of architecture to the business architecture domain we are concerned with business services. A business service is modelled around a business capability that has an appropriate level of coupling and cohesion.

If we choose a business capability that addresses too many unrelated concerns, then we will have low cohesion. If we choose a business capability that is too finely grained, we will have tight coupling between services as related concerns will be distributed across multiple business services.

So here we see that business capability mapping is an extremely valuable tool for deriving the business service model for an organisation. It is important to note that this entire discussion falls within the business architecture domain. The technical components that support a business service fall into the domain of the application and technology architecture.

We find that the business service model is an incredibly valuable tool for achieving alignment between the business and IT domains. This is because this single model has equal relevance in both domains.