Business Capabilities: Hype or Panacea
Blog: BPTrends - Articles
In enterprise and business architecture circles, business capabilities are all the rage. Business capabilities, it seems, are next best thing since sliced bread. Anytime a concept – like an enterprise business capabilities model – receives hype beyond reason there is always a risk of backlash and under-performance.
There are some excellent definitions of Business Capability Map, but for our purposes, let’s stipulate that a business capability is an atomic building block of a business which describes what business does and what it can do while being agnostic to how it is done and what system realizes the function.
Business capabilities – an abstraction of what business does and can do – are a great concept, but there is a lot of ambiguity and misinformation about the construct. There are some that consider a capability map as wall art with highest level functions listed as capabilities. For some others, capabilities are an unnecessary nuisance as they think Value Streams and Process Maps are a better way to represent how things work in a company. Moreover, for some others, after weeks and months of effort constructing a business capabilities map, there is a sense of “Now What?”
Business Capabilities: The Myth, The Reality, and the Use Cases
Dispelling the Myths of business capabilities:
• Business capabilities are not processes. A process is an end-to-end depiction of activity flows by various actors to consummate a business outcome.
• A business capability is not a business service. A business service is an agglomeration of multiple capabilities which enables a business process.
• A Capability is not a system. An application or a system is necessary to realize a capability or a cluster of business capabilities.
• A Capability is not an organization chart. An organization chart describes the structure of who does what. A capability map may influence the organization chart (which is called a Capability-based Organizational Design), but it is not the organization structure or chat.
The Realities of Business Capabilities:
• Capability Models are a business deliverable. An ideal scenario is when business architects facilitate a business-driven effort to document business capabilities. The buy-in and alignment will be far higher than if an IT team were to create a capabilities map and ask the business to adopt.
• Capabilities are a tool for business and technology alignment. As the adage goes, business is from Venus, and IT is from Mars, business capabilities are an excellent common language between business and tech teams.
• Enterprise Capabilities should be Granular for being Valuable beyond Wall Art. Super high-level business capability models are a good beginning, a strategic deliverable, and excellent wall art. However, for capabilities map to be useful, a detailed decomposition of the capabilities into atomic building blocks will help a great deal.
• Mixing and Matching Capabilities and combining them represents business services. Moreover, the business services influences the shape, modularity, and granularity of the SOA services, including Microservices.
• Capabilities map to different steps/stages of Value Streams. As Value Streams represent stakeholder-centric end-to-end activities to consummate a business outcome, mapping capabilities to various steps/stages of a Value Stream allow linkage of “What” with the “How.”
• Classifying and categorizing business capabilities helps sharpen focus. Managing hundreds of the business capabilities as a big block is difficult and will be impossible to
focus on all of them equally. Hence, categorizing capabilities into appropriate groups such as strategic, core, context, and commodity helps the cause.
• Business Capabilities Models should conform to the construct of MECE (Mutually Exclusive and Collectively Exhaustive). Constructing a business capability model is outside the scope of this article. However, models that do not have a consistency of levels, lack logical and business-centric groupings, structural coherence, and internal integrity will be more of a hurdle than real help.
Key Use Cases of Business Architecture and Capability Modeling:
Business capabilities are Lego blocks or elemental building blocks and are the glue that holds different components of business architecture together. Here are some use cases that are an excellent way to use business capabilities models.
• Product Roadmaps: Develop holistic capability-centric 18-24 month roadmaps.
• Application Footprint: Juxtapose applications and services to capabilities to understand footprint and level of IT enablement
• Service Definition: Leverage clusters of capabilities to form business services and determine the modularity and granularity of IT Services
• Vendor Evaluation: Detailed decomposition of capabilities will enhance the vendor evaluation process
• Merger Analysis: Conduct pre-merger target analysis based on capability gaps, and post-merger integration analysis based on overlaps.
• Application Portfolio Optimization: Capability-to-Application footprint analysis will help as the first step in APR projects
• Budget Analysis: Capability-based budgets will assist in understanding where the IT spend has occurred vis a vis the priorities of capabilities.
• Strategy Linkage: Assigning capabilities to strategy pillars provides the linkage between execution and strategy
• Customer Experience: Combining the capabilities and value streams – the yin and the yang – will allow enterprises to optimize customer experience
Author Bio: Ravi Mehra is a business architect at Capstera.com, a business architecture company offering software and offerings.
Leave a Comment
You must be logged in to post a comment.
