By: Denise Cook
It was my first day on the project. The previous lead architect had been fired, and I was It was my first day on the project. The previous lead architect had been fired, and I was brought in as his replacement for what had already been flagged as a “Troubled Project” by my consulting organization. After my first two meetings I knew why.
brought in as his replacement for what had already been flagged as a “Troubled Project” by my consulting organization. After my first two meetings I knew why. I first met with the client, The Phone Company. I was told to “Build a VoIP infrastructure and 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 six months behind, but we cannot push out the release. We brought your company in to help us meet that date.”
I took a deep breath and tried to remain calm. Maybe it wasn’t as bad as it sounded. Next I met with the architecture team, a mix of architects from The Phone Company and from my consulting firm. As the various leads presented their status, I quickly observed that the project delays had likely 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 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, 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 wasn’t the first time I’d worked with a business that needed to roll out new offerings faster than their IT groups could deliver.
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 where 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 didn’t want to know about the challenges of integration with legacy systems, or the expense of architectural redesign. They simply 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. Voice mail 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 they were physically located in Topeka, Kansas.
There were a handful of start-up companies who dominated the consumer, 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 COTS products and identified areas where 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 where the cost of integration was too high, or the timeline was too short. We acted tactically, knowing that
we had to design a strategic roadmap to break the cycle for future initiatives. As the project wrapped up with a successful launch (the VoIP offering worked, customerscould order services and be billed, and only we knew the limitations of the architecture) those of us considering that roadmap 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.
A new approach has emerged to challenge that thinking. Business Capability Mapping is the process of modeling what a business does in order to reach its objectives (its capabilities), rather than 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 capability to “Activate Service” once required a truck roll to a customer’s home. For VoIP service, activation could occur completely online with the customer Installing his 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.
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 in order to reach the 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, the high level view of these
activities looks like this:
- Determine the Business Architecture
- Document the top-level capabilities of the business
- Add next-level capabilities, and refine
- Develop common semantics for operational terms across the business
- Document the relationships between the capabilities
- Align the Technical Architecture to the Business Architecture
- Map 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.Business Architecture modeling focuses on capabilities, rather than 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, rather than on the details of how the work is done. The first step is to identify what the highest-level capabilities of the business are, which typically have an operational focus. For example, The Phone Company’s list looked a little like:
- 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:
- Deliver Services
- Create Order
- Activate Service
- Mediate Service
- Bill for Service
The list was further decomposed into even lower level capabilities. Only those capabilities that directly related to the goals of the business, had an impact on the success of the business, or identified key performance indicators, were kept. While coverage of
the 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.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 between business units and with 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. Capabilities expose interfaces, and
this is where connectors come in. In order 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.
Once a stable Business Architecture has been modeled, 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 SLAs for those capabilities. The architect can use that model to determine the best implementation to deliver those capabilities in each of their contexts.
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 that architecture can be
modeled around, and service orientation supplies the flexible, modularized, interconnected framework to implement those capabilities.
No matter what the implementation (technologies do change), the goal for the architect is to design a Technical Architecture for durability, flexibility, and adaptability in order to provide the best ROI for the business. Mapping a Technical Architecture to a Business Architecture modeled on capabilities is good insurance against rigid infrastructures that constrain the business’s ability to respond rapidly to change. 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 they need to
roll out in a hurry. Is there an architect joining a project there right now taking a deep
breath, and saying to herself, “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, rather than 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?
Erl, Thomas 2005 Service-Oriented Architecture (SOA): Concepts, Technology, and
Homann, Ulrich 2006 A Business-Oriented Foundation for Service Orientation
Krafzig, Dirk, Banke, Karl and Slama, Dirl 2004 Enterprise SOA: Service-Oriented
Architecture Best Practices
McGovern, James, Sims, Oliver and Jain, Ashish 2005 Enterprise Service oriented
Architecture: Concepts, Challenges, Recommendations
Microsoft Motion, Business Capability Mapping November 2005
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. She has 17 years of
experience in the field of software engineering.
COTS. Commercial off the Shelf
OSS/BSS. Operational Support Systems/Business Support Systems support the
communications businesses. They cover key areas of service management such
as sales and order handling; provisioning and inventory; accounting, billing and
mediation; customer care and fault management; and configuration management
and service assurance.
SLA. Service Level Agreement
SoHo. Small Office/ Home Office
VoIP. Voice over Internet Protocol