This pattern is part of “Patterns of Legacy Displacement”

Identify Business Capabilities

Identify stable parts of the organisation to structure teams and software around

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 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?

In this section, we take a look at why we focus much of the subsequent discussion on Business Capabilities and their role in including people in the discussion around legacy displacement.