The drum beats are echoing across the Global 2000 about the value of business architecture, and more specifically business capability mapping. Business capabilities – in other words “What a business does” – are in vogue. Business capabilities, in conjunction with value stream (process layer) mapping and business service to IT service transition (service layer) mapping, are supposed to lead businesses to a state of nirvana.
A capability map, like any other map, is supposed to provide a precise direction to your destination. However, in many companies, capability maps have become yet another esoteric exercise, without much practical utility to business users. While a utopian view of business capability mapping remains to be debated and resolved, at a practical level, the question has become: “how do businesses avoid typical pitfalls and take advantage of this powerful methodology to capture the business essence, communicate its value, and realize the business vision thru technology enablement?”
Typical pitfalls range from the mundane to the profound:
- Boiling the ocean: Imagine a scenario, not too uncommon, where based on an executive fiat, a company embarks on a multi-year endeavor to define business capabilities for a firm. More often than not, such efforts involve purchasing and adapting an industry reference model, or utilizing high priced consultants, or both, without internal involvement, understanding or support. This results in a generic, high level capability map without capturing the syntax and nomenclature of the firm itself. In the end, many of these efforts are relegated to an esoteric enterprise architecture endeavor, unused and underappreciated by rank and file.
- Lack of business buy-in: A similar issue is when capability mapping falls to enterprise architects who believe that business does not understand business architecture and therefore take it upon themselves to do it “right” despite the lack of business’ “competence”. (My pet peeve against self-appointed business architecture gurus whose background is steeped deep in the vortex of technology is a topic for a separate column.) In almost all of these cases the business is consulted and involved, but without a clear communication of the practice of business capability modeling nor an understanding of the desired outcomes or value add. As a result, while business may be represented in the endeavor, lack of true buy-in and ownership make the business capability mapping endeavor degenerate into yet another IT artifact, that is driven by IT, created for IT, and accountable to IT.
- Only an inch deep: A business capability map should be a hierarchical decomposition to multiple layers of granularity – sometimes depending on the subject area, it warrants going to level 4, 5 and 6. A business capability that stops at level 1 is basically some type of value chain at best. Level 2 makes a pretty picture on the wall, but without the deeper levels of context, color and content, it is insufficient even for higher level strategic planning. For example, a level 2 map might decompose “Sales” into a set of capabilities including “CRM”. At the CRM level, it is difficult to operationalize a strategy, define business and IT requirements, select vendors or do any number of tasks that deliver the value of capability mapping. At a more granular breakdown (Figure 1), these tasks become significantly easier to do.
- Lack of rigor and refinement: A good capability map needs to comprise of a set of capabilities which are mutually exclusive, individual exhaustive and collectively a whole. Without rigor and iterative refinement, the capabilities will be a set of scattered ideas strewn together, rather than be a true representation of business decomposed hierarchically. Any analysis on a poorly designed capability map will inherit its flaws, such as redundancy, sparseness, or poor organization.
- Lack of executive support: Ideally,business capability mapping should be sponsored by the business owner and supported by the technology owner – both at the C-level. Executive buy-in and support should be based on a fundamental belief that business capability mapping is a “pain killer”, not just a nice-to-take “vitamin”. This foundational philosophy determines whether the discipline becomes an event or an integral part of everyday strategy and operations.
- Lack of use: A good business capability map should become a strategic tool and the compass for guiding both business and technology professionals in their day-to-day execution. If product managers, business managers/analysts, program/project managers are not using capabilities as a way to get things done, capability mapping will remain an ivory tower endeavor.
Figure 1. Illustrative Example of a Capability Map Decomposed to lower levels of granularity.
Now that we’ve identified the key challenges that impact a business capability mapping endeavor, let us examine some of the strategies and tactics to mitigate the pitfalls and minimize the perils.
- Educate: Ensure that business and IT leadership team is aware of and buys into the paradigm of business capability mapping. Instill a sense that this is not a one-time event, but a lifelong philosophy and discipline of getting things done. This may mean leveraging the bully pulpit of research analysts, evangelizing thru internal champions, showcasing small internal wins and their value add, using external peer inputs, or distributing case studies. Anything is fair game to help forward buy-in across the entire organization.
- Illustrate: Nothing succeeds like success. If business capability mapping, within the organizational context, has been applied and deemed transformative, it will go a long way. Therefore choose the right battleground to start with, ensure it has sufficient support, attention and involvement, and then publicly celebrate small victories on the way.
- Iterate: It is essential for continual iteration, rigorous analysis, and ongoing refinement to reach a stage where the capability set meets the foundational tenets of mutually exclusivity, individually exhaustiveness and collective wholeness. However, prioritize and phase this work over time and dig deeper into areas where there is greater need for coherence, clarity and depth.
- Incentivize: There has to be a carrot and stick approach to helping business capability mapping take root and flourish. Linking funding to multi-year capability evolution as opposed to annual projects is a powerful start. Setting and tracking capability-specific KPIs is another.
- Utilize: Using business capabilities to build common understanding between business and technology takes time even with sufficient structure and process in place. If senior management insists on evaluating projects/programs/products as an agglomeration of capabilities and their evolution, rather than as silo’ed projects, it will go a long way in making capabilities as the lingua franca of business and technology teams.
- Permeate: The true benefit of capability mapping comes from its use. Assessing projects and aligning discussions and performance assessment using capabilities is the start. You know you reach capability architecture nirvana when capabilities are used to inform and drive strategy, set investment priorities, gather and optimize requirements, rationalize business activities across BUs and help even with tasks like vendor management and merger integration.
While business capabilities may not be a panacea, the principles and practices help define the core essence of business and efficiently bridge the strategy to execution gap.
