Business-Capability Mapping: Staying Ahead of the Joneses

 

Denise Cook

March 2007

Summary: Business-capability mapping enables adaptive, sleek architectures that can respond quickly to changes in today's competitive business landscape. (6 printed pages)

Contents

Introduction
Existing Architecture: Silos Everywhere
Business-Capability Mapping
What, Not How
Determining the Business Architecture
Aligning the Technical Architecture to the Business Architecture
Capability Mapping to SOA
Conclusion
Critical-Thinking Questions
Further Study

Introduction

It was my first day on the project. I was brought in to replace the previous lead architect, who had been fired, in what had already been flagged by my consulting organization as a "troubled project." After my first two meetings, I knew why.

I first met with the client, the Phone Company. I was told to "Build a voice over IP (VoIP) infrastructure and operational/business support system (OSS/BSS) solution for us that will have all of the features of the VoIP market leader, Datum Corporation. Speed to market is critical, or we risk losing residential and business customers who are eager to move from wireline to VoIP phone service. And, by the way, the release date has already been announced to the public. We're 6 months behind, but we cannot push out the release. We brought in your company to help us meet that date."

I took a deep breath and tried to remain calm. Maybe it was not as bad as it sounded.

Next, I met with the architecture team, a mix of architects from the Phone Company and my consulting firm. As the various leads presented their status, I quickly observed that the project delays likely had not resulted from a lack of talent, experience, or resources. The project was constrained by a rigid, inflexible technical infrastructure that could not react quickly enough to the changing needs of the business. The architects were challenged by awkward, aging systems; silos of duplicate customer data; and a history of bottom-up technical decision making. To say that it was optimistic to build on top of this architecture in the timeline available would be the understatement of the year.

It was as bad as it sounded.

However, I was assigned to this engagement because of my experience with complex, large-scale systems of systems, and because of my previous successes in turning around troubled projects. I was up for the challenge and eager to do the best I could with the cards I had been dealt; but, in the back of my mind, I also wondered how the familiar symptoms of troubled projects could be avoided. This was not the first time that I had worked with a business that had to roll out new offerings faster than their IT groups could deliver.

Existing Architecture: Silos Everywhere

The Phone Company's IT infrastructure was extremely complex and had grown organically over time to meet the ongoing needs of the business. The IT group maintained core systems for each of the business units across the organization. While these business units served different customer markets, there was still a great deal of duplication in system functionality and data. In cases in which a level of integration did exist between business units (wireline customer data and wireless customer data for example), the connections were less than elegant.

These silos of systems and islands of data created challenges for customers as well as the business. Customers who subscribed to multiple communications offerings (phone, wireless, TV, Internet) typically felt as if they were doing business with multiple companies. They did not receive consolidated bills for their services or have a single customer-service phone number for interactions with the Phone Company. The customers did not want to know about the challenges of integration with legacy systems, or the expense of architectural redesign. They merely expected consistent, seamless interaction with the Phone Company for all their services. Telecom customers can also be very fickle. If a better deal, better offerings, or better customer service comes along, they will make a change.

For the business, the bottom line result of having these disconnected systems was a string of IT projects that could not deliver the necessary integration fast enough to roll out new offerings in today's hypercompetitive telecommunications market. In the case of our project, VoIP was the new wave for home and business communications. Not only did customers want to jump on the new technology for cheaper basic and long distance calls, but they were excited about the new features that this technology allowed. Voicemail could be delivered to their e-mail. They could carry their phone service with their laptop when they traveled by using a soft-phone client. Virtual phone numbers were a reality, so that a business could have an area code for New York City even if it was physically located in Topeka, Kansas.

There were a handful of startup companies that dominated the consumer, small-office/home-office (SoHo) and VoIP markets. They were grabbing all the early adopters with cool advertising and slick service offerings. They also had the advantage of designing their technical infrastructures from scratch. They built systems specifically tailored to deliver and support their service offerings. The big telecommunications companies were fighting to keep up with the Joneses.

To stay competitive, my client had to launch a VoIP offering. We didn't have time to rethink and rebuild the current IT environment. We assembled a platform based on commercial off-the-shelf (COTS) products and identified areas in which integration with existing systems and customer data was feasible, given our constraints. We were the next link in the chain to repeat the process of designing new silos of functionality in cases in which the cost of integration was too high or the timeline was too short. We acted tactically, knowing that we had to design a strategic road map to break the cycle for future initiatives.

Business-Capability Mapping

As the project wrapped up with a successful launch (the VoIP offering worked, customers could order services and be billed, and only we knew the limitations of the architecture), those of us considering that road map were still thinking in terms of modeling the business based on its processes. Business processes describe how an organization performs, or implements its capabilities. The thinking at the time was that the development of a business-process model would facilitate the alignment of IT with the business, which would be achieved by describing the business specifications for processes synchronized with the corresponding technical framework.

What, Not How

A new approach has emerged to challenge that thinking. Business-capability mapping is the process of modeling what a business does to reach its objectives (its capabilities), instead of how it does it (its business processes). The goal of this approach is to model the business on its most stable elements.

While the way in which a business implements its processes is likely to change frequently, the basic capabilities of a business tend to remain constant. For example, "Provision Service," "Activate Service," and "Generate Bill" are capabilities that the Phone Company maintained over many years. The hows of those capabilities, however, had changed dramatically over time. The "Activate Service" once required a truck dispatched to a customer's home. For VoIP service, activation could occur completely online with the customers installing their own equipment. The what remained the same; the how was continuing to change, as new technologies and offerings were being introduced.

The advantage of a model that is based on the most stable elements of the business is its longevity. Changes to how capabilities are implemented do not change the base model. A stable business model means good things for the IT infrastructure that supports it. Therefore, business-capability mapping promotes a strong relationship between the business model and the technical infrastructure that supports the business requirements, resulting in a view of the business model that can be understood by both the business and IT. Capabilities are defined and tied to business strategy. Architecture is aligned with those capabilities and thus, to the business strategy.

A series of activities must take place reach this Holy Grail of a flexible, adaptable architecture that can respond quickly to changes in the business. While there are variations in approach to business-capability mapping—for example, Microsoft Motion and Microsoft Motion Lite (see Further Study)—the high-level view of these activities looks like the following:

1. Determine the business architecture.
   1. Document the top-level capabilities of the business.
   2. Add next-level capabilities, and refine.
   3. Develop common semantics for operational terms across the business.
   4. Document the relationships between the capabilities.
2. Align the technical architecture to the business architecture by mapping the capability view to a technology architecture.

(Note that the business architecture also maps to the overall process and organization of the business. Here, we are focused only on its mapping to IT architecture.)

Diving into each of these activities in detail can produce a clearer understanding of the benefits associated with each part of the process, and will help illustrate how the results of these activities became part of the road map for the Phone Company.

Determining the Business Architecture

Business-architecture modeling focuses on capabilities, instead of process. This provides a crisper view of the organization's objectives and true requirements. Again, the focus is on what work is done in the business, instead of on the details of how the work is done.

Document and Refine Capabilities

The first step is to identify the highest-level capabilities of the business, which typically have an operational focus. For example, the Phone Company's list looked a little like the following:

• Develop Services
• Market Services
• Deliver Services
• Manage the Business

We decomposed these top-level capabilities into lower-level capabilities. A few examples of contained capabilities for the Deliver Services capability looked like the following:

• Deliver Services:
  • Create Order
  • Activate Service
  • Mediate Service
  • Bill for Service

The list was further decomposed into even lower level capabilities. We kept only those capabilities that related directly to the goals of the business, had an impact on the success of the business, or identified key-performance indicators (KPIs). While covering the complete business is always important for exercises of this type, capabilities that do not meet these requirements are not critical to the mapping process. Capabilities were described in noun-verb format. This helped us avoid the trap of listing a department or an IT system as a capability. For example, "Billing" was not considered a capability, while "Generate Invoices" was.

Throughout this exercise, we listed attributes for each capability and service level expectation. We captured key attributes such as the inputs and outputs for each capability, its owner, its customers, performance requirements, and information about what supports it such as people, IT, or process. We eventually used this critical information to translate the business architecture into the technical architecture.

Semantics

An important part of this process is development of common semantics across the organization. Business units often duplicate capabilities, many times because the use of different terminologies keeps the duplication from becoming readily identified. Taking the time to define terms and create a common operational vocabulary has a strong positive impact on communication among business units and IT.

Once the capabilities have been identified, they should be viewed as black boxes that represent real outcomes, and real service levels that create value for the business and its customers. Encapsulated in each black box should be all of the processes, people, technologies, and data that support that capability.

Connectors

Capabilities expose interfaces, and this is where connectors come in. To create a complete model of the business, relationships have to be considered between its capabilities. Connectors represent those relationships, and they consist of data exchanges, policies, and many other types of information. The Phone Company's Create Order capability had a relationship to its Activate Service capability. The connector between them represented the transition of output data from the first capability to the input of the second.

With the capabilities and associated connectors identified, we created a model to represent the business as a structured network of capabilities. The resulting model was the business architecture. The building blocks of that architecture were the capabilities, and the implementation was the set of business processes.

Aligning the Technical Architecture to the Business Architecture

After you have modeled a stable business architecture, its implementation in terms of a technical architecture can begin. Aligning IT with stable business requirements provides an opportunity to maximize the architecture's adaptability and longevity. To an architect, a model that describes the business's capabilities in detail provides a good understanding of what the business expects in terms of service-level agreements (SLAs) for those capabilities. The architect can use that model to determine the best implementation to deliver those capabilities in each of their contexts.

Capability Mapping to SOA

In terms of implementation, business-capability mapping provides a clear road map to service-oriented architecture (SOA). Business processes and IT services both exhibit external, observable, and measurable behavior, and both can be related to other black-box capabilities/services with connections. Business-capability mapping and SOA complement each other well, when it comes to aligning IT with the business. Business-capability mapping identifies the stable elements of the business around which architecture can be modeled, and service orientation supplies the flexible, modularized, interconnected framework to implement those capabilities.

No matter what the implementation (technologies do change), the architect's goal is to design a technical architecture with the durability, flexibility, and adaptability to provide the best return on investment (ROI) for the business. Mapping a technical architecture to a business architecture that is modeled on capabilities is good insurance against rigid infrastructures that constrain the business's ability to respond rapidly to change.

Conclusion

I never had the chance to develop that road map for the Phone Company, but I often wonder if the same challenges still arise with every new business offering that they have to roll out in a hurry. Is there an architect who's joining a project there right now, taking a deep breath, and thinking, "Maybe this is not as bad as it sounds"?

Critical-Thinking Questions

• How connected is your IT organization to the business? Do you as an architect have a clear picture of the business's capabilities?
• If a specific capability of your company is outsourced, should it still be considered a capability and be considered part of the business architecture?
• How does a technical architecture that is mapped to a businesses' capabilities deliver return on investment (ROI)?
• How could you implement business-capability mapping incrementally, instead of in one monumental exercise? What are the benefits of a phased approach? How would you prioritize areas of the business and IT on which to focus?

Further Study

Erl, Thomas. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Indianapolis, IN: Prentice Hall PTR, 2005.

Homann, Ulrich. "A Business-Oriented Foundation for Service Orientation." Microsoft Corporation, February 2006.

Krafzig, Dirk, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. Indianapolis, IN: Prentice Hall PTR, 2004.

McGovern, James, Oliver Sims, and Ashish Jain. Enterprise Service-Oriented Architecture: Concepts, Challenges, Recommendations. Dordrecht, The Netherlands: Springer, 2005.

Microsoft Motion:

"Microsoft Motion Business-Capability Mapping"

"Microsoft Gets Down to Business with Motion Initiative"

Microsoft Motion Lite:

"Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion"

 

About the author

Denise Cook is a method architect and method content author with IBM Rational, contributing to the definition of IBM's software-development methods, including the Rational Unified Process (RUP). Before joining the Rational team, Denise worked as a lead consulting architect for IBM and Andersen Consulting. Denise has 17 years of experience in the field of software engineering.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.