Aligning Organisation Design & Software Architecture with Business Strategy: Business Capability Classification
How we define team boundaries and shape the architecture of our software systems is one of the biggest influencers of how successfully we execute on our business strategy.
Yet, I continue to see organisation design and software architecture heavily siloed from each other, and largely disconnected from the business strategy.
I see a mixture of ad-hoc process, naive HIPPO-driven design, and excessive technology-orientation. The result is a chaotic lack of focus and interdependence, inefficient investment of effort, and many missed opportunities.
We can turn things around dramatically by making business strategy a primary driver of our sociotechnical design. How do we do that? By analysing and classifying the business capabilities in our system across various dimensions. Here’s how I do it.
Structural Classification
Business capabilities are fractal. A capability can be composed of multiple sub-capabilities which may themselves be composed of sub-capabilities and so on. Consequently, ‘business capability’ is a fairly ambiguous term.
To avoid the typical confusions and debates over semantic definitions, I like to introduce the following layered model which is based largely on existing business capability theory.
Layer 1 capabilities are composed of organisational units (aka teams), their purpose, the technology needed to deliver the capability, along with team process, culture, and values.
Layer 2 capabilities are a partnership of layer 1 capabilities working to provide a higher-level capability. Layer 3 is a partnership of level 2 capabilities and so-on.
The number of layers is dependent upon the size of the organisation and the nature of the capability.
Layer 1 capabilities are the units of organisation design. Layer 2 and above capabilities are aggregations of sub-capabilities.
A layer 1 capability could exist as a website, an API, a database, or a vertical slice cutting through UI, API, and data, for example a search page, a search API, and a search engine all owned by a single team.
The general heuristic is that in most cases the team boundary is the layer 1 boundary, although sometimes a team can be part of multiple layer 1 capabilities (see the ‘capability roles’ section toward the end of this post).
Alignment maps are a useful tool for challenging the design of hierarchical capability boundaries.
Portfolio Classification
If we want to understand the strategic value of a capability, we should look to understand where the capability sits within the business’ innovation portfolio. For this purpose, I rely on Explore, Exploit, Sustain, Retire, introduced in my favourite book Lean Enterprise.
Explore capabilities are prospective initiatives, where the business is seeking to identify new revenue streams.
Exploit capabilities are about growing revenues and scaling up in an area where market demand has been validated.
Sustain capabilities are part of established services and products that generate significant business revenues. The challenge is to continue improving the capability while being careful not to degrade stability or quality of service.
Retire capabilities have passed their shelf life. The benefits they bring do not justify the maintenance costs. It’s time to retire them.
Buy capabilities. I believe there is another option which is linked to retire - buy. For when it’s more economical to retire the in-house capability and purchase an off-the-shelf solution instead.
We have to be careful with portfolio classification as we move up the layers. An L2 capability may have explore and sustain L1 sub-capabilities for example. Sometimes broad classification is possible though e.g. “We want to sustain our core business, CRM, and exploit Marketing for rapid growth”.
Value Chain Evolutionary Classification
Simon Wardley’s work on Value Chain Mapping teaches us that every capability progresses from genesis to a commodity. This aligns closely with the innovation portfolio stages, although not exactly, so I strive to discern both.
Wardley’s Value Chain Maps are also highly influential in the design of sociotechnical systems before we’ve even thought about the innovation portfolio. And the maps help us to understand the type of teams that should own each capability pioneers, settlers, and town planners.
Business Model Relevance
In addition to understanding how a capability fits into the innovation portfolio, gaining a general understanding of how much a capability contributes to the business model is precious information.
I’ve found the following classifications (from various sources) to be fairly useful.
Distinctive capabilities play a role in the unique identity of a business. They are capabilities that contribute to competitive business advantage and are not easy for competitors to match.
Strategic capabilities are key to the business strategy. They provide opportunities for competitive advantage to be gained.
Supporting capabilities are there to support strategic capabilities. Typically, there is a cliff whereby additional investments yield little or no return.
Utility capabilities are essential but highly-generic across different types of business and domain as opposed to supporting capabilities which are of similar strategic value but specific to the business domain.
Architectural Role
I find it vital to understand the dependencies between capabilities. I want to know when multiple capabilities are likely to co-change. This has a big impact on the design of team boundaries and aggregation capabilities.
In order to understand these challenges — understanding which capabilities form part of the same value stream — I classify the role a capability plays in the software architecture.
Autonomous capabilities provide an end-to-end behaviour with little or no dependence on other capabilities. For example, a search capability with self-contained UI, APIs, and data store.
Experience capabilities provide an interface to the outside world. Examples include websites, APIs, and mobile apps.
Aggregation capabilities call out to other capabilities and aggregate the results.
Platform capabilities are typically shared, providing behaviours consumed by multiple other capabilities (platform does not refer to infrastructure platform). Examples include an Identity/User Accounts capability or a Payments capability.
Infrastructure capabilities provide the tools, environment, and skills that the other capabilities rely on in order to operate. Examples include a software deployment platform or a centralised logging service.
It’s fair to consider experience, aggregation, and platform capabilities as activity-oriented capabilities. As this diagram illustrates, activity-oriented capabilities are prone to handovers and higher-coordination costs. As you’ll see in future posts, we often want to avoid activity-oriented contexts for our distinctive and strategic capabilities where higher innovation speeds result in greater competitive business advantage.
Putting it All Together
Classifying the capabilities in our system across a variety of business and structural dimensions is the starting point for a more inclusive and aligned sociotechnical design process.
If you’re not classifying the capabilities when designing teams and software services according to the following boundaries, you’re missing vital data that aligns your system to the business strategy:
- Structural Classification
- Portfolio Classification
- Value Chain Evolution
- Business Model Relevance
- Architectural Responsibility
These aren’t the only dimensions that matter. We also have to model the system of work via value streams, the domain we’re working in, and understand the social factors in our organisations.
In future posts and talks, I’ll be showing examples of how I use these classifications to facilitate workshops on modelling, designing, and evolving sociotechnical architecture. If you’re interested in learning more but don’t want to wait, check out the following posts:
- An Introduction to Sociotechnical Architecture Patterns
- Evolutionary Sociotechnical Architecture Patterns
- ‘Intentional Naivety First’ Bounded Context Modelling
- The Continuous Organisation Design Playbook
You may also be interested in a talk I recently gave at Codemotion Amsterdam: The Sociotechnical Organisation Design Playbook. And if you’d like to get some hands-on training, I’ll be running workshops with business process & workshop design expert Zsofia Herendi at the following events.
