Business Capability Architecture: Technology Strategy For Business Impact

I talk commonly to architects that are under pressure to create a cloud strategy. Or an SOA strategy. Or a BPM strategy. Or an XYZ strategy. Many will add up a few of these point strategies and call it an overall technology strategy. It’s good to know where we’re going, but is this the right way to do it? No. The problem is that this is technology-focused tech strategy. You can see it in the way we describe applications according to their dominant technology. We call them event-driven apps, or RFID apps, or whatever. Instead, to have a business-focused tech strategy, the starting point should be an understanding of what drives business outcomes. What would that look like?

Business architecture — an important and maturing domain of enterprise architecture — is changing the conversation between business people and technologists. Rather than centering on individual siloed applications, business architecture, at its best, centers conversation on the design of business outcomes and what it takes to achieve them. Within the realm of business architecture, models like business capability maps provide strong mechanisms for understanding and designing a business.

Building on these notions, a nascent industry conversation is working to establish the concept of Business Capability Architecture. This is good — we need this type of business foundation. But there’s a problem. The initial ideas don’t go nearly far enough. They are little more than fancier names for a business capability map. The industry needs a bigger vision that can carry the architecture all the way through to business implementation. This past Friday, in my keynote session at Forrester’s Enterprise Architecture Forum, I presented our vision for Business Capability Architecture, which goes significantly beyond current industry thought. In Forrester’s view, for Business Capability Architecture to provide a new foundation for technology strategy, it must:

  1. Start with business outcomes. To a CEO, the metrics — the business outcomes — that most determine the organization’s success boil down to the balance sheet, statement of operations, and statement of cash flow, combined with soft metrics that indicate the organization’s power, stature, and influence in the marketplace.
  2. Direct the evolution of business capabilities. Business plans make a poor foundation for tech strategy. They will — and should — constantly change in response to competitive and political dynamics. A better foundation is an organization’s core capabilities — product design, customer service, etc. — which we build on and evolve to achieve better outcomes. But we need to do more than model and plan business capabilities, we need to implement them using an integrated, operational, measurable combination of people, processes, technology, and physical resources. Thus, Forrester places the notion of an evolving business capability implementation — a complete running part of a business — as the target for Business Capability Architecture.
  3. Provide design implementation models oriented around business change. A business capability map is good, but if you can’t carry it through to implementation, it’s just a pretty picture. So Forrester’s Business Capability Architecture — by analyzing the ways that businesses change and evolve — provides design principles and implementation models for integrated, coherent, holistic implementation of business capabilities. This includes the notion of a business capability platform — a cohesive, integrated, multitechnology, business-focused platform — that gets past the single technology focus of our current day BPM apps, event-driven apps, and the like.

My keynote went farther to elaborate on Business Capability Architecture, but these three points provide the gist for how it can connect your technology strategy directly to business improvements that are meaningful to your top executives. That’s how you’ll get sustained business impact from your tech strategy.

Forrester’s vision for Business Capability Architecture builds on the foundation of Digital Business Architecture, Dynamic Business Applications, and numerous other design paradigms that we have been building over the past several years. It’s all part of helping Forrester clients develop a strategic view of business technology and architecture that can handle and drive the speed of change, business innovation, and technology complexity of our increasingly digital world.

This is where my research will be focusing in 2010. I’ll continue to talk about service-oriented architecture (SOA), which (done right) is a critical business foundation, for the new vision, but by moving to the bigger picture around SOA, I’ll be able to build a stronger and broader foundation for the future. BTW, I’ll do the keynote again at our EA Forum in London on 2-3 March .

I’d be curious to hear your reactions. What do you think is the best foundation for technology strategy? How do you ensure that your tech strategy delivers business impact that your CEO cares about?

Randy Heffner

Twitter: rh_forrester

Comments

re: Business Capability Architecture: Technology Strategy For B

I think "Business Capability Architecture" is a contradiction in terms. "Architecture" refers to how something is built. "Capabilities" are about what something does. We must know what something does before we can think about how it should be built.

The main advantage of capability mapping is it breaks down a highly complex system into manageable bites.

I agree that if you can't carry the Capability Maps into implementation, you "only have pretty pictures." But doing so requires an understanding of how complexity, functionality, and design relate to each other. It also requires a close working relationship between business and IT, not only for the usual reasons, but also because the IT architecture must be a projection of the business architecture. I think this agrees with your #3, "Provide design implementation models oriented around business change," but I'm not sure.

In my view, the critical foundation for technology strategy is an effective complexity management practice. There is very little that we don't know how to do for simple systems and there is very little that we do know how to do for complex systems. So we either need to figure out how to solve complex problems (which, for theoretical, is probably impossible.) Or we need to understand how to take unsolvable complex problems and restructure them as a solvable simpler problems.

Capability maps can be a good start to this, if they are done within the overall context of a complexity management strategy.

- Roger Sessions

re: Business Capability Architecture: Technology Strategy For B

Randy -

It's great to see the analyst community catching up with the practitioners. We've been deploying a capability-based approach to business architecture (TIMM) for the past several years now, formalizing it into an external service offering two years ago. In talking with my peers, most of the large consultancies have adopted the language of capabilities. Given the success that we and others are seeing from this approach, it may very well be one of the most effective ways to manage complexity.

Regards,

Aleks

re: Business Capability Architecture: Technology Strategy For B

It is about time that Business Architecture gets a serious uptake in large organizations. Technology must serve a business purpose and use of technology must bring about business benefits and outcomes.

An "architecture" contains a specification of key components and relationships between the components. Therefore, a Business Architecture should call out not only the key business capabilities (in terms of business functions, business information, resources, and so on), it must also define relationships between the business capabilities. Furthermore, it should also specify relationships between business capabilities and the technology capabilities that implement or enable the business capabilities. Making these linkages between business and technology capabilities lies in the heart of Enterprise Architecture - the essence of business IT alignment.

re: Business Capability Architecture: Technology Strategy For B

All good this thing with business capabilities, hey even "best practice" frameworks like TOGAF 9 has included this as a way of planning your future and managing your as-is. The worry I have is that you can't go out and find any one consultancy, researcher, analyst firm or other organization for that matter that works on the same thing as they say they do work with capabilities.

The Canadian Military Forces released their EA framework which has as a main part the dealing with capabilities and capability based planning. They did it just some while ago, so it's still fresh. However as I read through their material I find in their overview model (meta model) that capability is made up of well over 50 concepts. In TOGAF 9 capability is represented by one concept in the meta model and hinted at several more in the specification text.

Do any of you have what you would consider a stable definition of what actually constitutes a capability in the domain of Enterprise Architecture?

re: Business Capability Architecture: Technology Strategy For B

Roger: You begin your reply with “I think ‘Business Capability Architecture’ is a contradiction in terms.” I’m not sure whether this is intended as a critique or merely as an observation, but my point is precisely that this is the type of thinking that we need to change. There had better *not* be a contradiction between our understanding of the business and the architecture by which that understanding becomes embodied in our running business (of which our applications are only one integral part). We need to change our paradigms so that the work we do to understand our business (and its critical outcomes) flows directly into the design and implementation of the organization, people, processes, technology, and physical resources necessary to run the business. In other words, we need an architecture vision that is large enough to encompass both our *understanding* of business capabilities and our *implementation* of business capabilities. Thus, “Business Capability Architecture” is not a contradiction, it is precisely what sets the structure to eliminate the air gap between business architecture and a real-world, running business. Forrester’s architectural abstraction of a “business capability implementation” is precisely intended to provide the type of recursive complexity breakdown structure that your reply longs for.

Aleks: Of course, I applaud organizing tech investment around business capabilities, though as I move toward full publishing of the notions and architectural abstractions within Forrester’s view of Business Capability Architecture, it will go much farther than merely managing technology investments.

Jun: Right on. Building on what you say: As the target for business architecture, Forrester’s view of Business Capability Architecture defines the notion of a business implementation. This sets the structure for connecting the dots between business design and a running business.

Jörgen: It is indeed early days for business architecture and the specification of business capabilities, and the wide variation you see is part of this. In the perspective of Forrester’s Business Capability Architecture, the answer to “What constitutes a good definition of a business capability?” is fundamentally driven by the answer to the question “What defines the critical *business* success of the capability?” The definition of a business capability must build toward a clear understanding of *what* the capability is, how it is *measured* to determine its level of success, and what it will take to ensure that the *implementation* of the capability stays focused on business success. My colleagues, Jeff Scott and Bobby Cameron, have published on “Capability Maps Anchor Business Complexity” (http://bit.ly/advIUq) and “Five Basic Approaches To Business Architecture” (http://bit.ly/cMMo4H). Though these don’t directly address your question, they are further thinking on the matter.

I have to agree with Roger.

I have to agree with Roger. From my perspective "Business Capabilities" are only one element of an overall architecture, not an architecture unto itself. It is great to have a business capability MODEL, but what I really need (for it to be an "architecture") is to have that business capability model defined in relationship to the other important models such as the organization model, the strategic goals and objectives, and the systems/application model. And the real value is to be able to use these models to understand what impact there is and risks I take when the business wants to change itself.

There's a semantic issue here

Ah, the limitations of brevity in a blog post. We stumble upon semantic issues. In Forrester's angle on this, the term "Business Capability Architecture" is in no way chosen to *limit* elements of the overall model. Rather, it is chosen to highlight the primary foundation of an overall model that includes not only the additional elements David lists, but much more besides. Beyond understanding business change and the risks thereof, Forrester's Business Capability Architecture extends the models and paradigms down into the actual implementation of the business as a physical-digital world composite. Far from thinking that BCA should be an "architecture unto itself," Forrester is placing the notion of business capabilities at the center of a major reframing of technology and architecture vision, hence the choice of name.

Model relations

The Business Capabilities is the way to connect all models together within the Company. All from the Strategy to the implementation into the Application and their potential Services, even though the application is nothing less than the Automated Processes. But, the key to conducting them properly, one needs the Business Capabilities. They resides in the Heart of the companies Models. They will be implemented into a sequence into the Processes. The Business Capabilities not delivering value to any Stakeholder, will be eliminated and the less important/non differentiating ones can/will be outsourced. Business Capabilities are tight "married" to the Information. Doing this, IT will be driven from the Business.