Exploring Business Capability Mapping

"There is surely nothing quite so useless as doing with great efficiency what should not be done at all." - Peter Drucker

I started looking into the process of Business Capability mapping while following up on notes from my Advanced Distributed Systems Design using SOA & DDD course with Udi Dahan who mentioned it. The process dubbed MOTION by Microsoft was referenced during the course, as a good thing to follow up on later.

MOTION was the codename for the project, from which a process was created. It was later renamed as Microsoft Services Business Architecture (MSBA) and was available from Microsoft as consulting services for a fee (though not any more). Several patents were registered for this process methodology.

Process defined: Motion uses business architecture to expose the business model of an organization, and then applies that information either to resolving a specific problem, or to informing decisions related to project prioritization and selection. Motion includes a patent-pending business architecture model, a template-rich methodology, and a variety of tools for capturing the business architecture and business model information in a highly stable, objective, and metric-rich format. That business architecture information can be linked to process, organization, and IT architecture information. By design, everything about Motion is technology-agnostic and mostly acronym-free.

Wikipedia defines Capability as: the ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity.

Forrester Research says: A business capability defines the organization's capacity to successfully perform a unique business activity. Capabilities:

are the building blocks of the business
represent stable business functions
are unique and independent from each other
are abstracted from the organizational model
capture the business interests

A capability usually starts with a verb. So an insurance company might have a "Manage Life Insurance Contracts" capability, but not a "Contract System". Certainly, there may indeed be a system or set of services that support the capability of managing life insurance contracts, however, the contract system is more focused on the IT architecture, instead of the business capability.

The capabilities focus more on the "what" does a business do, and less on "how" the business does it. The advantage of modeling things this way is they are less prone to change. A simple example might be a Send Customer Invoice capability. Over time, the method of sending that invoice has changed, from printed and mailed bills, to emailed PDFs, but the business capability remains the same.

Sometimes, capabilities are automated using IT solutions, and other times, they may be supported and provided by manual office operations of the business (using email, spreadsheets, etc.). Capabilities can be composed of a combination of People, Processes and IT supported solutions.

Each capability can also have over 100 attributes (properties), for instance:

performance metrics (time, financial, volume, etc)
cost information
compliance criteria
service level agreements (SLA) or service level expectations (SLE)
owner
description
manual/automated
in-sourced/outsourced

Once the Business Capabilities are defined, they outline "what" the business does and this can be used to map out the areas of the business that:

might benefit from IT support.
are important
are less important
might be candidates for outsourcing
etc.

Processes and Technology(IT) often represent the "how" a business does something and not the "what" the business does.

Maybe an Example?

Sure. The following represents the expression of a set of sample business capabilities from a fictitious mortgage company.

Level 1 Capabilities

Develop Product/Service
Generate Demand
Fulfill Demand==============>
Plan and Manage the Business
Collaboration

Level 2 Capabilities for Fulfill Demand

3.1.   Provide Service
3.2.   Advanced Planning
3.3.   Procurement==========>
3.4.   Produce Product

Level 3 Capabilities for Fulfill Demand/Procurement

3.3.1.   Sourcing and Supplier Contract Management
3.3.2.   Purchase Resources========>
3.3.3.   Receiving of Indirect/Capital Goods and Services

Level 4 Capabilities for Fulfill Demand/Procurement/Purchase Resources

3.3.2.1.   Request Resources============>
3.3.2.2.   Acquire/Purchase Resources
3.3.2.3.   Manage Suppliers

Level 5 Capabilities for Fulfill Demand/Procurement/Purchasing/Request Resources

3.3.2.1.1.   Create Purchase Requisitions
3.3.2.1.2.   Manage Requisitions Approve Process
3.3.2.1.3.   Perform Encumbrance Check
3.3.2.1.4.   Create Auction Bids

So, Why Does This Matter?

There are different types of software architecture commonly employed in the enterprise space, including Object Oriented, Services Oriented (SOA), etc. The latter has gained popularity in the last few years and SOA in particular, can benefit from Business Capability maps, as they can assist in showing you "what" the business does, and provide direction on how the services in a system might be composed. In this context, I'm not referring to web services, but to the autonomous building blocks that make up a software system that supports the operation of a business.

There are several business benefits mentioned above, but from my perspective, as a software architect, the primary value I see in documenting business capabilities lies in uncovering tools and information that might help me to design systems and applications that will serve the business most effectively. It is difficult to design software to meet business needs, when the business does not have a clear definition of their needs. When you begin gathing requirements, it is too easy to start writing down the "how" things are done and skip over the "what" and the "why".

Since most ideas gain traction with a business case, it would be nice if there was a business case for the work required to develop Business Capabilities. This article talks about some ideas to consider for developing a business case for Business Architecture, which can include business capability mapping. Another must read is You Can't "Cost Justify" Architecture by John Zachman. It outlines great arguments of why architecture is important and in many ways, the examples demonstrate reasons for investing in your products' software architecture too.

I'm Still Not Sold

As I read ReThink: A Business Manifesto for Cutting Costs and Boosting Innovation by Ric Merrifield (the former Microsoft employee behind MOTION) I'm working my way through the steps of questioning the process of architecting software, and finding it an interesting journey.

For software companies that sell a software product, I can see value in thinking about this process from two fronts:

internally, reviewing the business capabilities of your own business, to ensure you are focusing on what is important and what you are good at
externally, look at the business capabilities of your customers' business or different business verticals, or by industry if applicable, trying to find ways to improve the fit of your software within the "whats" of their business

Having this information could allow different teams within your organization to perform better:

Marketing could target features of your product to specific customers whose business capabilities would be best improved by having it
Engineering could better focus on building new product features that would best serve target vertical markets or industries

In fact, SAP has done something similar, by mapping their product offerings, to Business Maps that they have defined for several different industries. Their maps define business capabilities and then each one has an icon that indicates if SAP sells a product module that will help their prospective customer with that business capability. (Although, I can't find them on their site anymore)

This demonstrates that Business Architecture is an asset, not an expense, because it is something that is used more than once (as was described in You Can't "Cost Justify" Architecture) .

Resources/Sources