One of the techniques that I, and many others in the industry, use to determine vertical slices for my architectures is called business capability mapping.
What is a business capability?
A business capability is a business architecture concept with the following official definition:
"A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome."
Business capabilities are the expression of all the things an organization needs to do in order to perform its core functions. They delineate WHAT a business does without attempting to explain how, why, or where the business uses it.
The are typcically expressed as a verbal noun, e.g. 'Order Booking' or 'Order Processing'
And the great thing about them is that they are inherently stable.
Mapping business capabilities
Using a business capability map you can document the relationships, and hierarchy, between the different things that the organization needs to do to keep their business running.
I learned about this technique from Udi Dahan about a decade ago in his nominal work around Service Oriented Architecture and still use it today.
"A service is the technical authority for a specific business capability." - Udi Dahan
Note: I rarely use the term Service these days as it has had so many different meanings over time that it has lost it's meaning. Hence I use the word slice, and sometimes capability.
It's not about you, it's about them!
One of the most common mistakes I see development teams make when searching for business capabilities, is to start off from the wrong domain.
When you want to create software to support a given audience, it is paramount that you investigate how they work, and not conflate their processes with how you work yourself (unless you are building the software for yourself of course).
This sounds like a no brainer, but in practice many types of businesses share several capabilities at first sight and it is very easy to assume they do it the same way as you do it... but I can assure you, they do it differently.
So who are they?
Before I can show you an example of a business capability map, I'll have to introduce you to the domain at hand first.
I'm currently designing software to support the business processes of sports clubs, mainly basketball clubs. The primary audience for the software are board members of these clubs: the president, the secretary, the treasurer, etc..
I called this domain 'Club Management', very original...
I also joined the board of a basketball club myself, so that I can learn the domain as well as possible. I cannot recommend this hard enough, if you want to learn a domain, go work in it for a while, this will give you a far better understanding then any other approach could ever give you.
Then use this technique to document what you learned.
Club Management - Level 1
When you look at a sports club from the highest possible level, there are only 4 things they need to do.
- Competition: this is the sport specific part, where they compete with each other, recruit and train players, find coaches, organize tournaments, book the gym, etc...
- Fan experience: sports clubs are ultimately in the entertainment business themselves and need to ensure that fans have a good time, both at the games and outside.
- Governance: clubs need to ensure they stay in business and don't overextend themselves for short term gains, also insurance, governmental compliance and such are also part of this capability. I personally value this capability a lot, as my own basketball career ended back in the day when the club I was playing for went bust.
- Fundraising: the more money a club can raise, the easier all of the above will be... so this capability naturally gets a lot of attention, at healthy clubs. So let's have a deeper look at this last capability.
Fundraising - Level 2
Sports clubs can get very creative at raising money and have a lot of tools in their toolbox in order to increase their budget. Here is a nice list of things they are capable of doing in order to obtain more funds.
I will not go over the full list here, but I can tell you that the club, where I volunteer at, collects membership fees, applies for grants, organizes fundraising dinners, sells wine and chocolates, organizes a mountainbike tour, obtains ticket income at games, has sponsor deals, sells merchandising and even used to organize it's own music festival. Quite impressive no?
Now, let's have a deeper look at one of these level 2 capabilities: selling stuff.
Sales - Level 3
Sports clubs sell a lot of things, from tickets over food to merchandising.
This is no different from any other businesses however. Therefor it's a prime example of the 'It's not about you, it's about them!' principle. There is significant risk to start looking at your own sales processes instead of actually talking to your users and figure out what their actual capabilities are.
Some things that are typical to the sales processes at sports clubs is that they are campaign based and orders come in bursts. The club will make a deal with one, or a few, vendors (usually sponsors). Select products from their catalogs, run a sales promotion for these products and collect the orders. At the end of the promotion (a few weeks typically), the sale will close and they'll pass the orders on to the vendor in bulk.
Order Booking - Level 4
These differences in process will reflect in lower level capabilities as well. As an example, all the products that club sold will need to be exported from the order bookings so that th ordered amounts can be forwarded to the vendor(s).
Level 5, 6, 7, ...
You can keep going to further split out capabilities into even lower level capabilities. But from a software perspective this usually isn't usefull.
For the purpose of slicing I typically rely on the capabilities identified as level 3 and 4.
From a planning and implementation perspective I will focus on level 4 capabilities. You will e.g. find me to build a new feature in order to accept bookings. I'll add a new slice (UI, Api, domain logic, persistence, etc...) to the system in order to make this specific capability a reality.
From an artifact management perspective I'll typically group the features together at level 3. So my code repositories will be named using level 3 terminology, so will nuget or npm packages, or my hosting artifacts (e.g. app service site names, etc..).
A note on stability of business capabilities
Business capabilities are inherently stable, but their realizations are not.
Assuming the organization is not pivoting, the established capabilities will stay in place.
E.g. an organization will need to provide their customers some way to inquire for available products.
This was true in the 1990's and still is today.
The realization of this capability however will change over time.
- In the 1990's: inquiry by a mail order catalog
- In the 2010's: inquiry through a webshop
- In the 2030's: who knows, maybe ask ChatGPT?
It's also possible that multiple realizations exist at the same time, due to differences in legislation or market desires.
E.g. Tax Compliance (in a large multinational)
- In the EU: VAT compliance
- In the US: Sales tax, per state
When choosing your boundaries, pick the boundaries of the stable capability and not that of the realization.
How I use capabilities
I mainly use the business capability mapping technique when I'm new to a given business domain. You can start top down from fairly obvious capabilities, and keep digging deeper into specific capabilities to get a better understanding of how they do things.
Over time, I will maintain the map as I learn more and more about the business.
Yet it's not the only usefull technique to identify capabilities. Other approaches include e.g. Event Modelling, where you start from the events occuring during the execution of business processes. In brownfield scenarios, where you have an existing domain model or database schema to start from, you could perform decomposition of this model to identify the capabilities, etc...
