Business processes vs. business capabilities...microservices. Till och med SOA-tjänster var ju då riktigt nytt. Vi hade med det under de första åren av programmet. Men det var

CSAMP – Annual Competency Service Quarterly Report Q1 2017

1

QUARTERLY REPORT Q1 2017

Business processes vs. business capabilities


2

Här kommer den första kvartalsrapporten för 2017. Vi hoppas som vanligt att du skall finna den intressant och

givande, kanske också lärorik. Vi tar upp delar av innehållet på sammankomsten den 30 mars, så du får en bra

chans att förbereda dig på det genom att läsa rapporten.

Den här rapporten är helt baserad på ett önskemål som kom in från Lajos Farkas. Han sickade ett mejl för nu ett

bra tag sedan och ville att vi skulle ta upp frågan om hur kopplingen mellan förmågor och processer ser ut. Det

är vad hela den här rapporten handlar om.

Vi gör också en del små avvikelser. Vi vill gärna peka ut några skäl till att förmågor är överlägsna, jämfört med

processer, när det gäller att etablera en tjänsteorienterad arkitektur.

Vi tar också upp en annan sak. Vi poängterar att även om förmågor och microservices är ”a match made in

heaven”, så är det inte så att förmågor förutsätter microservices. För mer än 10 år sedan tog först Microsoft

och sedan vi upp det så produktiva sambandet mellan förmågor och tjänster. Och då fanns ju inte ens begreppet

microservices. Till och med SOA-tjänster var ju då riktigt nytt.

Vi hade med det under de första åren av programmet. Men det var för tidigt. Det var ingen som ville ha det. Nu

börjar det ju bli ett mantra: ”You must organize your microservices around business capabilities!”

Men du kan lika gärna skriva och säga så här: ”You must organize your services around business capabilities!”

Och det gör vi i den här rapporten.

Vi är som vanligt intresserade av att få din feedback på kvartalsrapporten. Du får också gärna tala om vad du

helst ser att vi behandlar i kommande rapporter. Det tog ett tag, men till slut följde vi Lajos råd. Kommer du

med ett bra råd som vi har kompetens att följa så gör vi det.

Mejla dina synpunkter till Sten eller Per. Du har ju mejladresserna, men här får du dem en gång till på

klickavstånd:

[email protected] [email protected]

Published by Sundblad & Sundblad, Uppsala, Sweden Copyright © 2016 Sten and Per Sundblad, Sundblad & Sundblad ADB-Arkitektur AB, Uppsala, Sweden

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form

or by any means, electronically, mechanically, photocopying, recording, or otherwise, without the prior written consent of

the publisher. Produced in Sweden.

mailto:[email protected]

mailto:[email protected]


3

Business processes vs. business capabilities The most obvious difference between business process models and business capabilities is this:

A business process model presents a business process as a complex network.

A business capability model presents business capabilities as a much simpler hierarchy.

There’s another important difference too, but it’s somewhat less obvious:

A business process model shows HOW things are done.

A business capability model doesn’t show anything about how things are done; it just shows WHAT those

things are. WHAT processes and activities the business is capable of performing.

Let me rephrase that last sentence a bit. A capability model doesn’t just show what a business is capable of

doing today. It could include capabilities the business doesn’t have at the time. Capabilities it must acquire in

order to implement a new strategy.

An aspect of business process complexity What do I mean when I say that a business process model is complex?

Well, it tries to show a lot of things. It shows processes, sub processes and activities.

A business process is a high-level thing. A business doesn’t have too many of those. The American Productivity

and Quality Center (APQC) has published its Process Classification Framework (PCF). This is an open standard,

meant to “facilitate improvement through process management and benchmarking, regardless of industry, size,

or location”.

The PCF recognizes five operating processes and seven management and support processes. That’s a total of

twelve high-level processes. No more than that. Not even for the big corporations.

These processes are decomposed into sub processes. The decomposition is recursive, which means that there

can be several layers of sub processes, each layer on its own level of abstraction. At the bottom, there are so-

called business activities. A generally accepted definition of a business activity goes like this:

It should produce business value. This guarantees that the activity isn’t defined at too low a level. For

example, registration of a sales opportunity creates business value, available to and useful for other

employees than the one that makes the registration.

To register a sales opportunity, the person doing it must take several steps. The first step could be to get a

list of customer persons from storage. This is a valuable step for the person taking it, and it creates value for

him or her. But that value is neither available to nor useful for other employees.

So Get Customer Persons isn’t a business activity. It’s just a step needed to perform a business activity.

Register Sales Opportunity might be a business activity, because it creates true business value.

A business activity should normally be performed in one sitting. In the typical case, there should be no need

to interrupt it in order to wait for some other results to come in. Register Sales Opportunity qualifies on this

point too, so it is a business activity.

Register Sales Opportunity is part of the decomposition of a low-level sub process. Let’s call that process

Manage Sales Opportunities. Figure 1 shows the decomposition of Manage Sales Opportunity. As the text

below the diagram shows, Register Sales Opportunity and Close Sales Opportunity qualify as business

activities. Handle Sales Opportunity does not. It’s a sub process that needs to be further decomposed to

reach the business activity level.


4

Figure 1 - Manage Sales Opportunity consists of these three functions. It's likely that Register Sales Opportunity and Close Sales Opportunities are completed in one sitting. That makes them business activities, if they produce business value. It’s less likely that Handle Sales Opportunity can be completed in one sitting, so, most likely it’s a sub process.

Information flow Notice the arrows that go into and out of the diagram’s function boxes. These arrows represent information

flow. They also represent dependencies. In older times, diagrams like these were referred to as dependency

diagrams. For example, Handle Sales Opportunity depends on Register Sales Opportunity for registered sales

opportunities. Close Sales Opportunity depends on Handle Sales Opportunity for sales opportunity results.

And so on.

Figure 2 – Handle Sales Opportunity decomposes into these three functions, each one being a business activity.


5

Let’s see what happens with the Registered Sales Opportunity information flow when we decompose Handle

Sales Opportunity. Figure 2 shows this decomposition.

Notice that this information flow now enters from the outside. It goes into Plan Opportunity Contact, which

creates an Opportunity Contact Plan. This makes Perform Opportunity Contact depend on Plan Opportunity

Contact for that information. Create Quote, then, depends on either Plan Opportunity Contact of Perform

Opportunity Contact for offering requirements.

There are other information flows as well, even other kinds of information flow. For example, at the topmost

left side of the Figure 2 diagram, a Contract Terms flow goes into each one of the diagram’s three functions.

That’s a control flow, or a guide, but I won’t go into these. My purpose now was not to explain all the details of

these diagrams but just one aspect of business process complexity and then go on to show you a corresponding

but much simpler business capability map.

Capability model simplicity Figure 3 shows a capability diagram that corresponds to the Figure 1 process diagram.

Figure 3 - This capability diagram corresponds to the Figure 1 process diagram. For each business activity in the Figure 1 diagram, there’s a corresponding business capability in this diagram. For the sub process in Figure 1, there’s a corresponding business capability in this diagram. That is a “regular” business capability, not a leaf-level one.

The Figure 3 diagram is less complex than the Figure 1 diagram. That’s because it contains fewer elements.

It’s easier to create, because you won’t have to figure out the dependencies or the information flows. All you

have to consider is what the business must be capable of doing when managing sales opportunities.

It’s also easier to consume. The reason is the same. It’s less complex. If you’re more interested in the capabilities

as such than their internal dependencies, the information flows are just distractions.

One interesting point is this: in a way the Figure 3 diagram is richer in content than the Figure 1 diagram.

Consider the Sales Opportunity Handling capability in Figure 3 and the Handle Sales Opportunity sub process

in Figure 1. Notice that the capability box contains information about its decomposition, which the sub process

box does not. This extra information is worth a lot when you’re ready to analyze these capabilities’ cohesion

and coupling.

Also notice that the process diagram doesn’t classify its three main components as sub processes or activities.

There is one clue, though. Below the Handle Sales Opportunity box is the code A322. That’s the ID of the


6

diagram that contains its decomposition. You don’t decompose business activities, so this establishes Handle

Sales Opportunity as a sub process.

The other two boxes don’t have diagram codes below them. That indicates that they are business activities

rather than sub processes, but you can’t be certain. They could just as well be sub processes that haven’t yet

been decomposed.

In contrast, the capability diagram classifies its capabilities as either leaf-level capabilities or business

capabilities. A leaf-level capability represents ability to perform a business activity. A business capability

represents ability to run a sub process.

To make our comparison complete, Figure 4 shows the decomposition of the Sales Opportunity Handling

capability.

Figure 4 - This capability diagram corresponds to the Figure 2 process diagram.

A quick comparison between this diagram and the Figure 2 diagram will show you the same kind of similarities

and the same kind of the differences as the Figure 3 and Figure 1 comparison did. Perhaps the difference in the

number of elements is a bit larger. That’s because the Figure 2 diagram contains a larger number of information

flows than the Figure 1 diagram does.

My examples are quite simple in themselves. We have other examples of Sales Opportunity Management in

which additional capabilities, sub processes, and business activities are involved. The larger the number of

elements in a process diagram, the larger the difference in complexity between a process diagram and a

corresponding capability diagram.

The relationship between process and capability The major kinds of components of a business process model are these:

Business Process. These are high-level business processes, such as the 12 business processes that form the

upper layer of APQC’s Process Classification Framework.

Business Sub Process. Each of the high-level processes decompose into lower-level sub processes. These, in

turn, decompose recursively into lower-level sub processes until you reach the activity level. You can say

that sub processes are those structures that don’t qualify as high-level processes or bottom-level activities,

Business Activity. These are the structures that are signified by the facts that they deliver business value,

and can be completed in “one sitting”. As mentioned before in this document.


7

For each instance of each kind, the business must have a corresponding capability.

The following table draws on this document’s preceding four diagrams. It connects process components with

capabilities.

Process Element Capability Register Sales Opportunity Sales Opportunity Registration

Handle Sales Opportunity Sales Opportunity Handling

Close Sales Opportunity Sales Opportunity Closing

Plan Opportunity Contact Sales Opportunity Contact Planning

Perform Opportunity Contact Sales Opportunity Contacting

Create Quote Quote Creation

This kind of table tends to trigger several kinds of questions, such as these:

Which kind brings the most value to the business? Is it the process model or the capability model?

Can they co-exist?

If so, which comes first? Is it the process model or the capability model?

Which one is best for me as a software developer and architect?

Is business capabilities just for microservices, or can I use them for other kinds of architecture too?

I’ll get back to these questions a bit further on in this document. First, though, I’d like to talk a bit about a

different aspect of business process complexity.

A different aspect of business process complexity

The Figure 1 and Figure 2 diagrams are of a specific kind. They belong to a so-called IGOEi type of process

models. The acronym IGOE stands for:

Inputs. Something that goes into a process, sub process, or activity and either is transformed or consumed.

These always come in through the left side of the function box.

Guides. Anything that describes the when, why or how a process or activity occurs. Could be events that

determine when the process or activity begins or ends. Could be policies, regulations or requirements for

standards. Could be reference information or data. Could be knowledge or experience used to help

determine how the process or activity should occur. These always come through the top side of the function

box.

Outputs. The product or result of the changes that occur to the inputs, or the results of creating something

based on the guides. These always leave through the right side of the function box

Enablers. The resources or assets needed to transform an input into an output, or to create outputs. Could

be people, systems, tools, equipment, facilities or any type of useful resources. These always come in

through the bottom side of the function box.

We have used Microsoft Visio’s tool for IDEF0 modelling to create the Figure 1 and Figure 2 diagrams. IDEF0

(Icam DEFinition for Functional Modeling) is a methodology based on the IGOE type of process.

Actually, it’s more than that. It’s the process modeling technology upon which IGOE was based.

IGOE models have the following major purposes:

To model business functions and their decompositions

To model the information flows into, out from, and between these business functions

To model the dependencies that exist between the functions,


8

It’s not at all about modeling process flow or workflow. For that, you need different tools, different

methodologies, and different techniques.

Most of us software developers are more familiar with the workflow kind of process models than with the IGOE

kind. This is because they have the same kind of purpose as a typical data program has. The best examples are

sequences, iterations, selections, and parallelism.

These as well are interesting in terms of complexity when compared to business capabilities.

Business Process Modeling Notation (BPMN) Methods for modeling process flow has been available in large numbers for a long time. In the early days of

computing, programmers (they weren’t called developers then) would hand-draw simple flowcharts on

whatever surface was available to them. I have seen a flowchart drawn on a cigarette pack.

BPMN is one of the most modern methodologies for the modeling of process flow. It’s administrated by the

Object Management Group (OMG). Figure 5 is a BPMN diagram of the Manage Sales Opportunity process.

Figure 5 - A BPMN diagram picturing the Manage Sales Opportunity process from a process flow perspective. When you soon see blow-ups of its parts, you'll notice that some new activities have been added. You'll also see what effects this can have on the corresponding business capability models.

This diagram is almost unreadable, but I wanted to include it just the same. It will give you an overview of a

structure about which I’ll soon give you the details.

Notice first that there are three so-called pools, inside one of which the process is diagrammed. The middle one

is the Sales Opportunity Management pool. The top one is the Prospective Customer pool. The bottom one is

the Sales Order Management pool.

The entire process is modelled inside the Sales Opportunity Management pool, while the other two pools are

empty. They don’t have to, though.

The topmost pool is the Prospective Customer pool. It belongs to the customer, which typically is a different

company. Therefore, it’s normally out of control and would tend to be empty.

The bottommost pool is the Sales Order Management pool. It’s in the modeling company’s control, so it could

very well be populated with the Manage Sales Order sub process.

Figure 6 is a blow-up of the first part of the Manage Sales Opportunity process.


9

Figure 6 - The first part of the process. After being registered, a sales opportunity is qualified. Is this sales opportunity relevant to us? Is it something we can and want to do? If so, we qualify it. If not, we have to reject it.

Notice that this process (or, to be more formally correct, sub process) is started by an external event. A sales

opportunity turns up and is received. The Receive sales opportunity icon represents what’s called a Start Event.

Then control moves over to the Register Sales Opportunity activity, and then to the Qualify Sales Opportunity

activity. After that comes a Gateway. Is the sales opportunity qualified or not?

If it’s not, control moves over to the Reject Sales Opportunity activity, which triggers a Send Rejection End

Event. This leads to the sending of a rejection message back to the prospective customer.

In this diagram, sequence flows connect the nodes with each other. It has no information flows like those in

IGOE-type diagrams. You can have these too, though. You can use Data Association to model information

flows.. Figure 7 gives an example of that, using the same nodes as in Figure 6.

Figure 7 - Data Association show how information flows between diagram nodes. They add information to the diagram but also increases diagram complexity.

The diagram is now richer, but it also contains more elements. Miller’s law says that we can hold and process

about 7 ± 2 items in our short-term memories. This is referred to as the “Magical Number Seven Plus Minus

One”. Other researchers after Miller claim that this magical number could be closer to 4, or even 3, rather than

7.

Even this small part of this diagram contains as many as 17 elements. If you’re only interested in the business

activities, you can ignore the other 14. They will still serve as distractions, though, making it harder for you to

keep your focus.


10

I’ll take this opportunity to remind you of our goal. It’s to achieve software-to-business alignment. Do we need

process and information flows for that? Or, given our goal, are they just distractions? I’ll come back to these

questions a bit further on in this document. But both of us should keep that goal in mind as we go along.

Before coming back to our open questions I have a few things to do. The first is to show you the rest of the

BPMN model. Figure 8 shows its middle part. It shows how the process flows between activities, how decisions

are taken, and how information flows through the process.

Figure 8 - This is the middle part of our BPMN diagram. It shows how qualified sales opportunities are routed to proper sales resources, how customer contacts are planned and performed, and more.

Figure 9 shows the final part of the diagram.

Figure 9 - This is the final part of the diagram. Among other things, it contains two end events. One for situations where a sales order is taken, one for when it's not.

To complete this part of the content, Figure 10 gives you a new overview. It’s as hard to read as the first one,

shown in Figure 5, but it will show you the diagram’s added complexity after I’ve added data associations.


11

Figure 10 - The entire diagram after the addition of data associations.

This diagram now contains about 50 elements. Nine of them are business activities, the other about 40 are

gateways, connections, and events. We are far away from Miller’s Magical 7, even in this simple BPMN diagram.

Activities added If you compare the activities shown in Figure 6 to Figure 9 with those in Figure 1 and Figure 2, you’ll notice two

things:

Each Figure 1 and Figure 2 activity also occurs in the Figure 6 to Figure 9 diagrams.

Figure 6 to Figure 9 introduce a few new activities:

– Qualify Sales Opportunities

– Route Sales Opportunities

– Reject Sales Opportunity

– Negotiate Quote

Why these additions? It could be several reasons. It could for example be that you and your customer, while

working with your model, find that they are needed and missing. In our case the reason was different. I didn’t

want to include them in the early models. I wanted these to be as simple as possible and still relevant. I also

wanted to prove a point by adding them later. And that later is now.

Each of these need a corresponding business capability. So a new version of the Process Element/Capability

table will have to include these as well.

Process Element Capability Register Sales Opportunity Sales Opportunity Registration

Handle Sales Opportunity Sales Opportunity Handling

Close Sales Opportunity Sales Opportunity Closing

Plan Opportunity Contact Sales Opportunity Contact Planning

Perform Opportunity Contact Sales Opportunity Contacting

Create Quote Quote Creation

Qualify Sales Opportunity Sales Opportunity Qualification

Route Sales Opportunity Sales Opportunity Routing

Reject Sales Opportunity Sales Opportunity Rejection

Negotiate Quote Quote Negotiation

Proving the point It goes without saying that you should add these new capabilities to the capability model. Having done that, the

decomposition of your Sales Opportunity Management capability should be similar to the Figure 11 diagram.


12

Figure 11 - The Sales Opportunity Management capability is now decomposed into 6 leaf-level capabilities and one ordinary business capability. The latter is decomposed into 3 leaf-level capabilities. This model now corresponds well to the BPMN model. It's a bit richer than the IGOE model, which doesn’t contain the 4 recently added nodes.

Now assume one of two things:

The first is that you have a talk with a business-side person about this diagram. Together you come to the

conclusion that the content is fine, but that the structure isn’t optimal.

The second is that you own the model and have this conversation with yourself. And that you come to the

same conclusion.

High Cohesion and Loose Coupling Looking at this diagram you find that the cohesion of Sales Opportunity Management is high. It is, because it

contains not one single capability that hasn’t got with sales opportunity management to do.

The coupling between its sub capabilities could be looser, though. Sales Opportunity Handling contains a Quote

Creation sub capability. On the outside of Sales Opportunity Handling is Quote Negotiation. To achieve loose

coupling, Quote Creation and Quote Negotiation must be in the same capability.


13

Having come so far you decide that Sales Opportunity Management should decompose into two sub

capabilities: Sales Opportunity Administration and Sales Opportunity Converting. These do not exist, so you

define them and add them to the model. As children to Sales Opportunity Management. Then you start moving

over the existing capabilities to their new families.

As Figure 12 shows, moving a capability to another parent is dead easy.

Figure 12 - Moving a capability to a new parent is easy, especially if that new parent is a sibling. The default behavior is to show all its siblings in the SIBLINGS tab for easy picking. The optional behavior is to use the SEARCH tab for a name pattern search.

After moving all the existing sales opportunity management sub capabilities to their new parents, your diagram

should look something like the one in Figure 13.

Figure 13 - Sales Opportunity Management now decomposes into Sales Opportunity Administration and Sales Opportunity Converting

Making all these changes, improving the model by moving business capabilities to other environments, took me

less than 10 minutes. How long do you think it takes to do changes like these in a process model?

Because you can do them, and sometimes you have to do them.

The process diagrams in this document are rather simplistic. I wanted them as simple as possible in order not to

make the document too complex. But I wanted them complex enough to make sense. Many process models

start that way, being simple.


14

When analysts dig into the details of the processes, they tend to become increasingly more complex. They tend

to make the diagrams look more like spider-webs than process diagrams. The diagrams become difficult to

manage and difficult to consume. Their value, both for business and for software design purposes, decreases.

One way to fix this is to put activities in groups, just as I have done with the capabilities in this document. You

connect the groups together in one diagram and describe the details in a child diagram.

So, once again, how long do you think it would take to do these structural changes in a process diagram?

Much, much longer than 10 minutes, I can tell you. And it would be so much more difficult to get the new

structures right than it was for me in the business capability diagram. The process model has so many more

components to consider and get right.

So the higher complexity of process diagrams than that of capability diagrams cause a cost in time and money.

Sometimes at high cost. Is it worth it? Which kind of model is the better kind?

Which is the better kind? Well, that depends on the purpose.

If you need to chart the internal dependencies of processes and activities, then IGOE/IDEF0 may be your best

choice. It’s designed for that purpose. It’s also designed for decomposition of processes into sub processes and

activities. For that purpose, IGOE/IDEF0 is less complex than BPMN.

If you need to streamline the detailed flow of a process or a sub process, then BPMN (or one of its similar

alternatives) is the way to go. This is where you’ll find tools to model sequences, selections, iterations,

parallelism, events and more. You don’t get any of that in IGOE/IDEF0.

If you want to use a business model to create an architectural design of business-supporting software, then the

capability model is your best choice. It’s a WHAT model that doesn’t concern itself with any of the HOWs. It’s

strictly hierarchical and doesn’t contain any connections between capabilities at all.

All this is what makes a capability model less complex than any kind of process model.

In a service-oriented architecture, what you’re looking for are good services and good service APIs. In both

cases, you want high cohesion and loose coupling. Consider the Sales Operations cohesion and coupling of the

Sales Operations capability in the Figure 14 diagram!

Figure 14 - Consider the cohesion and coupling of the Sales Operations capability. The coupling seems to be loose enough, but the cohesion does not seem to be very high.


15

Let’s start with cohesion.

High cohesion requires close relationship between the members of the object under study. That object is the

Sales Operations capability. It has three members:

Immediate Delivery Selling

Sales Opportunity Management

Customer Account and Contract Management

They are all about some aspect of selling, so there is some level of cohesion. But is it high enough to be

considered for service support? Or could you find better candidates? You can’t tell until you have taken one

step down in the hierarchy. When you do, you arrive at the Figure 15 diagram.

Figure 15 - The cohesion of Sales Opportunity Management is clearly stronger than that of Sales Operations (in Figure 14). But what about the coupling. These capabilities are all about selling, so there’s obviously some coupling between them. But the purpose of each indicates that this coupling isn’t very tight. It seems to be loose enough for good service support.

Let’s say that we’re looking for a solution to some business problems around the handling of sales

opportunities. With that in mind, Sales Opportunity Management is a better candidate than Sales Operations.

There’s no question about it. Its cohesion is stronger. It has two members, and both are about sales

opportunities. Cohesion can’t be higher than that! Or can it? Figure 16 indicates that it can.

Figure 16 - Each of these two children of Sales Opportunity Management has higher cohesion than their father. But what about their coupling to each other?


16

Figure 16 decomposes Sales Opportunity into Sales Opportunity Administration and Sales Opportunity

Converting. Each handles a specific aspect of sales opportunity management, which makes their respective

cohesion higher than that of their father.

But what about the coupling between them?

Both are about sales opportunities. Sales opportunities refer to customers, to products, and to sales resources.

Both these capabilities will share a lot of data. In fact, they may use more data shared between them than data

not shared. So their coupling to each other is tight. Quite tight!

That makes them bad candidates for individual service support. They should share the same service. Which

takes us one step back up in the hierarchy. Back to the Figure 15 diagram.

The cohesion of Sales Opportunity Management is weaker than that of its two children. But its coupling to its

immediate environment is looser. There will be some sharing of data, but the purpose of Sales Opportunity

Management is different enough from that of Immediate Delivery Selling and Customer Account and Contract

Management.

This is by far your best candidate!

And it was easy to study the capability model to get to that conclusion. The business problem gave you focus

and scope. The rest was easy.

It would have been much more difficult to use a business process model for the same purpose. No matter if it

was an IGOE-type or a BPMN-type model.

You’d use the same kind of procedure for service API design. You start with the chosen capability, which is Sales

Opportunity Management. You consider its cohesion and coupling to decide whether to design one single API

to support that capability and all its descendants.

With API design, coupling gets a somewhat different definition. If the operations two

capabilities need are strongly overlapping, then the coupling is tight. If there’s no or just a few

overlaps, then the coupling is low.

Then you look at its children, using the same approach. We not surprisingly found that the cohesions of Sales

Opportunity Administration and Sales Opportunity Converting were stronger than that of Sales Opportunity

Management. We also found few overlapping operations. So we decided to design two APIs for the service. One

each for the children of Sales Opportunity Management.

And the procedure was just as comfortable for that as it was for choosing the service.

Notice that I’m using the word “service” in a general meaning. Lately, we have talked a lot lately

about “microservices organized around business capabilities”. That was inspired by the fact

that there’s a lot of talk about that in microservice circles right now. And we liked that very

much.

But business capabilities are equally relevant for the organization of traditional services as it is

for the organization of microservices.

When we started the architecture program in 2004, we had sessions about business

capabilities and how to use them for service design. And that was long before anyone had used

the term microservice. It was even in the early days of SOA. But students didn’t want it then. So

we removed them. Now is the time to put that back in again.

Can capabilities and processes coexist? A question we often get is this: Can I have process models even though I have a capability model, or does the

capability model replace the process models.


17

If you had that question in mind, chances are that you don’t anymore. You have seen in this document that this

is not the case at all. They depend on each other.

Capability models are more stable than process models. They are easier to create. They are easier to modify.

They are easier to consume.

What’s more, one business capability model describes an entire business. You would need quite a few business

process model to achieve the same.

They are easier (and safer) to use for service and service API design than process models. A big reason for that

is that they are less complex. They have fewer parts. Their focus is different too. They put decomposition in

sharp focus, and that is exactly what you need for making cohesion and coupling decisions.

But for some purposes, the parts they don’t have are needed. For these purposes, you need process models.

Another question we often get is this: Which should come first, the capability model or the process model.

In theory, the capability model should always come first. You start by deciding what capabilities you need. You

organize them as a hierarchy. Then you decide how to use them in business processes.

In practice, business capability models aren’t even closely as common as business process models. When no

capability model exists, you must take a practical approach to your software design efforts.

Let me finish this document by setting up a few scenarios to see what approach would serve you best in each. I’ll

assume that your purpose is to achieve software-to-business alignment by setting up an intentional, business-

driven, and service-oriented architecture.

When a capability model exists The first situation is when a capability model exists.

For you For your purpose, you don’t need a process model. You might need one or more to find out about lower-level

process flows, but you don’t need it to design your services and service APIs.

If the MS BC Designer™ has been used to develop that capability model, then you’re in good shape. You can just

take a copy of it and then use the designer to adapt it to the business problem you’re set to help solve.

Then you’d use it to analyze cohesion and coupling to arrive at that intentional and business-driven software

architecture that you’re after.

For the business A business that has a capability model is likely also to have and to need process models. Having a capability

model will help it to create more relevant process models. For every process, for every sub process, and for

every activity, there must be a corresponding capability.

So, being able to pick the capabilities you need for a specific purpose, adding corresponding nodes to the

process model, can’t but improve the quality of the process model. Its business relevancy. And to increase the

speed while reducing the cost of developing the model.

When only a process model exists What about the situation when there is a relevant process model but no capability model?


18

For you If you use a business process model for service and service API design, you’re better off than when not using it.

This is especially true for IGOE/IDEF0, which is based on information flow and process decomposition. It is less

true for BPMN, which is primarily based on process flow.

Using it will give you a good chance to achieve a business-driven intentional architecture, and therefore

software-to business alignment. Not using it will more than likely lead to a technique-driven accidental

architecture.

And yet, you’d be far better off if using a business capability model. That’s because it’s less complex, which

makes what you really need stand out. It’s also because it’s better suited to cohesion and coupling analysis. And

these are your best tools for deciding what services and service APIs to design and develop.

With MS BC Designer™ and the MS BC Generic Capability model you’re in a good position here.

The process model will contain nodes such as sub processes and/or business activities. For each one, you’ll need

a corresponding capability. You could take one process node at a time, see where it fits in to the capability

model. If it’s already there, you’re done with it. If it’s not, you can just add it.

If needed, you should use other sources to get down to your leaf-level capabilities. You need to do that, because

these are your user stories.

When you’re done, you can check it with business people to assure its quality. Then you’re already several steps

inside the 7 step MS BC Methodology™, which will help you get your services and service APIs designed.

For the business For most businesses, it’s well worth it in this situation to build a capability model. When they have one, they’ll

find many uses for it.

They can allocate responsibility for a core capability to a high-level manager. That manager can then delegate

the responsibilities for that core capability’s capability groups to suitable lower-level managers. And so on and

so forth.

They could use the same procedure as you did to start building the model. They could start out from a copy of

the generic model and then, when a process needs to be improved, integrate its corresponding capabilities with

the capability model.

They could do this one process at a time. When that process has problems and needs to be improved.

Doing that could save them time and get better focus. It’s easier to put your finger on a capability and say “this

one needs improvement” than to do it on a node in a process model. This could lead to better use of resources

and faster time to market.

When there’s neither a process nor a capability model This will probably be the most common situation you’ll find yourself in.

Capability modeling is still a young idea. There’s a lot of talk about it, and large corporations are trying to get a

hold on it. But it’s growing, as a McKinsey survey shows. Here’s an extract from their Building capabilities for

performance pageii:

“The strategic importance of capabilities is apparent around the globe: half of all respondents

this year say capability building is at least a top-three priority at their companies.”

Your chances of getting access to process models are better. They tend not to be included in the original

requirements, but if you ask for them you might get them.

But in the cases you can’t, it should be “business as usual” for you. At least initially.


19

For you The first step is to collect the user stories, as you always do. Don’t think too much about their internal structure,

just get them together. Figure 17 is an attempt to show what the result might look like.

Figure 17 - The user stories needed for your software to help improve your customer's handling of sales opportunities. Notice that they are not structured in any particular order at this point. I may even have exaggerated the disordering of these user stories here, but I wanted to make a point about the disorder.

The next step is to see if you can structure them in such a way that it makes business sense. The idea is to give

each user story a business context.

What you’re looking for is the usual high cohesion and loose coupling. We’ve been over that a number of times

now, so I’ll get straight on to Figure 18, which shows a picture you might arrive at.

Figure 18 – You have now put your stories in a business context. Notice that the context for each user story is exactly the same as the one you have seen before in this document. Only then it was in a capability model.

Notice that the structuring has added two high-level user stories to your set. You could describe them like this:


20

As an administrator, I want to administrate sales opportunities so that they can be converted as soon as

possible, and so that they can be analyzed for improved sales opportunity management,

As a sales person I want to convert sales opportunities into sales order, so that we as a business can reach

our sales goals.

The next step is to add these to your capability model. That model might have started out as a copy of the MS

BC Generic Capability model, but it could just as well have started out in any other way. In both cases, the

procedure is dead simple, once you know what you want to put in.

It shouldn’t take you more than 15 to 30 minutes. Time well spent, and time you will more than recover when

it’s time to design services and service APIs. Not to mention the increased chance the business context of your

user stories gives you of arriving at a business-driven intentional software architecture. One with strong

software-to-business alignment.

Figure 19 finally, shows you the same result as you have seen before. Only this time you’ve arrived at it in a

different way. A way that probably will be a very common way for a few years to come.

Figure 19 - The same decomposition of Sales Opportunity Management as you have seen before. This time, though, arrived at through a bottom-up rather than a top-down approach.

For the business A business that has modelled neither their processes nor their capabilities, but which wants to get structure to

the ways they perform their activities, has a choice. It can start modeling their processes or their capabilities.

For several reasons, it might be best to start with the capabilities.

With a capability model, there’s full focus on the capabilities. There are no connections, no sequences, no

selections and no iterations. It has fewer parts than process models. That’s one reason why setting up a

capability model is easier, faster and cheaper than to set up a process model.

There’s one single model. By time, the entire business will be described in that single model. This will be a boost

for the process models that come after. They will discover the need for new capabilities, but mostly they will be

designed from the capabilities already in the capability model. That strong connection between the capability

model and all the process models will conceptually keep the set of process models together in one coherent

unity.

Starting out from a generic model, such as the MS BC Generic Capability Model, makes that task even easier,

faster, and cheaper. And there’s a good chance the result will be better.

Conclusion It’s time to conclude.

The main purpose of this document was to explain the relationship between business capabilities and business

processes.


21

Business capabilities tell you WHAT a business must be capable to do – business processes tell you HOW they

do it. For every business process, for every business sub process, and for every business activity, the business

must have a corresponding capability. A business process model, then, tells you HOW the business makes use

of its business capabilities.

So, process models and capability models don’t exclude each other. They display two sides of the same things.

Capability models are strictly hierarchical. Process models can have a hierarchical side, but they don’t have to.

They are primarily vertical.

Some business capabilities can be used in multiple business processes.

Some closely related business capabilities can be used in different processes. For example, we have identified a

business capability called Sales Opportunity Analysis. As Figure 20 shows, it’s a child of Sales Opportunity

Administration. But, in contrast to the other children of that capability, it’s not used in the Manage Sales

Opportunity process.

Figure 20 - Sales Opportunity Analysis is a child of Sales Opportunity Administration but is not used in the Manage Sales Opportunity process.

The Sales Opportunity Analysis capability might be used in another process. It might also be an unused

capability. It may be a capability the business has used before but don’t have use for at the moment. It may also

be a capability the business is building up for future use.

This thing about modeling capabilities the business doesn’t have but will need to build up for future use gives a

strategic quality to capability models. One that process models typically don’t have.

Better for architectural design I also wanted to show that a capability model beats a process model in being a better foundation for

architectural design of service-oriented software. There are several reasons for this.


22

The structure is strictly hierarchical. It contains fewer parts than process model. For every capability it displays

that capability’s parent, its siblings, and its children. All this makes it easier to judge that capability’s cohesion

and its coupling to its immediate environment. And that is crucial for deciding what services to design and what

APIs it should expose.

Top-down, bottom-up, or both ways? The document contains examples of both top-down and bottom-up approaches for capability modeling.

The top down approach is when you look at a capability and consider what it’s made of. For capabilities above

the leaf-level, a capability is made of child capabilities. Leaf-level capabilities are made of business steps and the

operations the need access to.

The bottom-up approach is when you collect user stories the “old” way, then put them together in groups

according to their different business contexts, and then add corresponding capabilities to the capability model.

Which is best? The top-down or the bottom-up approach?

This is not a new question, valid only for capability models. It has been around at least as long as data modeling

has been around.

In that context, the question is whether it’s best to first identify entity types and then their attributes, or

whether it’s better to see what attributes are needed and then invent proper entity types for them.

The answer has always been the same: using both approaches together is the only way to go.

The top-down approach gives a better business context than the bottom-up approach, but it tends to miss

important information and add information that’s not needed.

The bottom-up approach gives more of reality to the model. Done right, you’ll include exactly what’s needed.

No more no less. But you won’t get the business context you need for an intentional, business-driven

architecture.

So you need to work top-down for business context and bottom-up for model reality. That’s the way it is.

And that statement concludes this document. Thank you for reading it all the way to its end.


23

i BRCommunity: What is an IGOE? http://www.brcommunity.com/b634.php ii McKinsey and Company: Building capabilities for performance. http://www.mckinsey.com/business-functions/organization/our-insights/building-capabilities-for-performance

http://www.brcommunity.com/b634.php

http://www.mckinsey.com/business-functions/organization/our-insights/building-capabilities-for-performance

http://www.mckinsey.com/business-functions/organization/our-insights/building-capabilities-for-performance

Documents

Business processes vs. business capabilities...microservices. Till och med SOA-tjänster var ju då riktigt nytt. Vi hade med det under de första åren av programmet. Men det var