Capability architecture and microservices
Blog: Achieving Business Outcome With Enterprise Architecture
The Elements of a Capability Model
The capability model could contain a lot of different elements but the basic ones are:
- The Capability Areas which serve as a reflection of the functionality needed to run the business.
- The Capability Groups which serve as blueprints for responsibility.
- The Business Capabilities which serve as blueprints for business services.
- The Resource Capabilities which serve as blueprints for microservices.
Frequently I use the capability model to project other elements on it. A very useful projection is visualizing the information ownership (entity groups, entities and sometimes even attributes) and the information responsibilities (business objects).
The Capability Information Model
The model below is an example showing ownership of information from a capability perspective. The model is the same as the one further down but it is focused on showing what information a capability group is the owner of.
Zooming into one of the capability groups (claim settlement management) we see that it contains information elements.
The Capability Collaboration Model
The model does not show every business object needed or created by the business capabilities, this is by choice. The aim here is to show what a capability collaboration model looks like. The main objective on a capability collaboration model is to show the information responsibilities.
Whenever you start to develop a capability architecture you will soon need to verify that the boundaries are where they should be.
How to build the model
- Start by taking one of the business capabilities and look at what information it need that it doesn’t have in it´s own context. The business capability will need this information to do it´s work and to generate the outputs it is responsible for, as a result you get business object candidates.
- Assign the business object you´ve identified to the one business capability that would generate it.
- Draw an arrow from the providing business capability through the business object ending up on the consuming business capability.
- Continue with tying the string between every other business capability that you found. Follow the steps 1, 2, 3 and 4 until you´ve exhausted all identified capabilities.
Rules of thumb
If you find business objects appearing out of nowhere then it is a fair assumption that either the consuming business capability is wrongly specified or there is a providing business capability that has not been identified yet.
If there is reason for it then you should include business capabilities that belongs outside of your corporate context.
A definition of a business object
A business object is defined as a specific set of entities representing the total amount of information needed by one business capability from one other business capability.
Business object is part of the information domain in the Inventory Model (EA framework).
When you should use this
- Whenever you set about designing a capability model of your enterprise
- When you are set to create a target context map for microservice architectures
What you should consider when you view this
- This is not “the complete, nor may it be the correct” capabilities of any specific insurance company
- Continuously refine your capabilities as you go
- When naming capabilities think of each capability as part of a namespace
- In the end it’s all about just doing it
Other things to consider from a capability model
The organizational perspective
- If you work in an agile inspired environment then the capability groups gives guidance to where product managers would be responsible.
- Teams should be set out to take responsibility for governing the business services realizing business capabilities.
The service perspective
- The only way to access information governed by a capability group is through the business capabilities inside.
- Each capability group is the sole provider of it´s business objects.
The realization perspective
Realizing a capability architecture can be done in many ways
- The monolith pattern would use the capability areas as system boundaries and capability groups would then be represented by subsystems.
- The service pattern would use the capability areas as knowledge boundaries and capability groups as information boundaries. Business capabilities would be used to orchestrate access to sets of microservices (resource capabilities).
License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Related
- The Capability Canvas (local link)
- The Capability Inventory (local link)
- Other ways of thinking about capabilities (local link)
- Microservice Principles and Enterprise IT Architecture (external link)
- Microservices Are SOLID (external link)
- Lego-like software development take shape (external link)
Download note:
I’m currently in a process of changing my presentation design (the images shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.
Post change log
2015-06-30: Published initial post
2015-07-01: Minor spelling adjustments
Leave a Comment
You must be logged in to post a comment.
