This pattern is part of "Patterns of Legacy Displacement"

The One True Ring

Segment the problem by identifying unique and shared business capabilities

This page is a stub. We intend to fully expand it in later revisions of this material. However we are still in the middle of developing these patterns, so it's likely that patterns will be renamed, split, or merged as we continue to learn how best to frame and explain these ideas.

A well known technique when faced by a large problem is to break it up into smaller ones. The question, as it often is with software architecture, is what should the smaller parts be? We've mentioned the problem with horizontal layers based around the logical separation of presentation,processing and data management elsewhere so don't need to go into them here, but if not logical separation then what other options do we have?

In the article defining microservices, the suggestion is made to Organise around Business Capabilities and this remains good advice, but what is a business capability?

A Business Capability is the collection of people, processes and tools that describe a stable boundary within a business.

The capabilities make up the set of things the business has to have in order to fulfil the delivery of value to it's customers. Within the same sector, such as retail, the set of business capabilities is usually very similar if not identical, but of course can change accross different sectors. You don't tend to need Warehouse Management in an insurer for example and likewise an online retailer will probably not need risk adjustment. The key point here is that the capability is the what and not the how.

To bring that statement alive somewhat, it's likely that an Insurer will always need to do risk adjustment. Identifying whether someone wanting to take out home insurance is dependent on lots of different factors. Is it in flood basin? Is the postcode known for high crime rates? What type of locks are on the doors?

In years past the processes followed to identify a price based on these risk factors was done manually by an Actuary. In todays world of machine learning and big data, a price is likely to be calculated automagically based on a computer algorythm rather than manually. Don't worry, the Actuaries didn't dissappear, they just decide what the algorithm does these days.

The point here is that capabilties are stable constructs and while the how they are implemented may change the what, the general boundary stays very much the same. So if we are in the business of writing software it sounds like a good plan to base the boundaries of the software we are writing as close to as stable a set of business boundaries as possible. That way we get to take advantage of the stable, slow changing interfaces betweeen different bits of our organisation.