Modeling Business Capabilities by Combining Services with Communication Patterns (2)
Introduction
In my previous post I introduced the idea of a Service Capsule. Now I want to dig into the rationale for this kind of service component or concept.
There are those that believe, and I am certainly one of them, that business models are essential to help you understand the structure and dynamics of the organization you are trying to support with IT systems. The key is to develop effective modeling techniques which enable the development of agile and flexible businesses. Effective business models must address at least two main factors.
- The richness of the information needed to accurately reflect what actually happens in your business, and
- The way in which you are able to translate your business model to a technology model.
While many different approaches for business modeling exist, two essential ingredients that should be defined by any effective business model are:
- The core, stable functions of the business, referred to as business capabilities.
- The interaction or communication patterns that occur between the business capabilities that are necessary for them to provide value and deliver a service.
The Microsoft Services Business Architecture (MSBA) methodology, formerly codenamed Motion, defines an approach for identifying business capabilities and creating a business architecture model referred to as a capability map. Business capabilities define "what" the business does irrespective of "how" it is performed. In "Service Oriented Modeling for Connected Systems" published in Issue 7 of the "Microsoft Architecture Journal" we described how this methodology puts the right people in the right roles doing the right things and therefore recognizes that this is the first-order success factor for any business enterprise.
Business capabilities are not the same as business processes. Business processes are a composite set of business transactions involving one or more capabilities. They can also be viewed as manifestations of a sequence of interactions (i.e. the set of communications patterns) between a series of related business capabilities that combine to form a value chain. I use the term service capsule to represent the combination of a business capability and the communication patterns used for interaction with that capability.
I also want to examine how the three part model introduced in can be extended to support the modeling of communication patterns. This requires a richer expression of a "service contract" to include the interaction sequence required to communicate with the service in addition to the conventional WSDL contract.
The recent emergence of new technologies such as Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) present some interesting options for automating the generation of the conversation controllers necessary to support the service interaction.
Capabilities
The basic constituent of the module map is a capability which is a fairly rich concept. When businesses undertake to perform a capability, they firstly involve people. The human element of conducting business work is vital. Ad hoc manual practices of business performance are complementary to the systematic process-oriented methods of doing business. Both - practice and process - are intermingled and can rarely be separated.
Left unguided, people find ways to work as effectively as possible by establishing formal and informal relationships both inside and outside the organization they work for. Add a bit of repetition, some compliance, a dash of corporate culture, and codify the lot, and you have created a process - the steps and procedures that people follow to get work done. These days, businesses almost invariably use technology to underpin their people and processes, even if it is only a copy of Microsoft Office and a mobile phone.
So capabilities are made up of people, processes and technology platforms as shown in Figure 1:
Figure 1. Capabilities consist of people, processes and technology
If businesses were computer programs, capabilities would be the functions and procedures that you would encapsulate behind an interface to create a component.
From Capabilities to Service Capsules
Business capabilities have a strong degree of independence, although they need to collaborate to provide a service and achieve their objectives. They have well understood inputs, well understood outputs and measurable service level characteristics. For example, they might take a particular amount of time to perform a task and they cost a certain amount of money to run, and so on. MSBA defines over 100 attributes that you can capture for a capability.
The view most people have of the organizations they interact with is in terms of what is communicated for the purposes of conducting business transactions and exchanging information. Send an order and get a delivery; write a complaint and get an apology; send a tax return and receive a tax demand. People generally do not need to know or care what happens inside an organization provided that acceptable service levels are achieved.
In some cases businesses don't really care what happens inside a capability as long as acceptable service levels are achieved at a reasonable cost and unless it directly affects their brand value. This view of business capabilities is generally well understood by business people.
Business capabilities encapsulate internal complexity behind strongly defined interfaces and offer to meet a published service level. In this sense they can be viewed exactly like the services in a service-oriented architecture. Figure 2 shows the encapsulation of capabilities as services with the communication patterns that support their mutual interactions and coordination. This fresh perspective on a service is what I call a service capsule.
Figure 2. The service capsule - an encapsulation of capabilities as services and communication patterns
Thus, service capsules are quite a simple concept, but as we'll see later, this perspective will offer some very interesting and valuable service design insights.
I'll develop this topic in more detail in subsequent posts. Please come back or subscribe to my RSS feed.
Comments
- Anonymous
December 19, 2008
In my previous post I talked about encapsulating capabilities as services with communication patterns