Capability-based Enterprise Architecture (CBEA): A Very Short Introduction

1.???? Background

After about four decades of theory and practice of enterprise architecture (EA), it seems that we are at a turning point in the approach and application of the concept of EA. Business-led, strategic, outcome-oriented, and composable architecture demands from the customers' side, set pressures on the EA community to re-think and re-state the standard account of EA discipline.

The business capability (BC) concept has emerged in recent years, as a reaction to these drivers. There seems something like a trend towards acceptance and use of the concept of BCs as the lingua franca of the EA professional community around the globe. Most consulting firms and EA tool providers are talking more and more about BCs and their use in architecture modeling and transformation planning. The Open Group formally recognized the concept of BC in the TOGAF metamodel from version 9.2 (2018) and ArchiMate metamodel from version 3.0 (2016). BC is already one of the four elements of BIZBOK from the Business Architecture Guild.

Despite this public acclaim for the BC concept, its use has remained limited to business capability mapping and Capability-based Planning (CBP), failing to offer full lifecycle coverage of BC development and management through EA application in organizations.

Now it is time to think about a novel approach to EA based on the BC notion, which can be called Capability-based Enterprise Architecture (CBEA).

?

2.???? Concept

CBEA is an approach to design and develop enterprise architecture (both business and IT perspectives) around the BC concept. CBEA uses the BC concept to capture, model, plan, and govern an organization’s essential architecture during the application of common EA use cases, such as business-IT alignment, business process improvement/re-engineering, organization structure (re)design, strategy execution, business and digital transformation, etc. All architecture elements (meta-model entities) are captured and analyzed in connection with BCs, and all architecture development initiatives are traced back to the organization’s BCs. In the CBEA approach, BCs are regarded as a link between business strategy and EA, both in the process of architecture design and the EA management process. CBEA provides a unique, consistent, and overarching conceptual framework to state and solve a broad range of organizational problems.

CBEA is about thinking and doing EA through business capabilities lens.

?

3.???? Drivers

The main drivers of CBEA include:

3.1.???? Business-led EA

As a constant trend in the past four decades after the EA concept introduction by John Zachman, the application of EA has tended more and more toward business use cases, in contrast with initial IT-focused use cases in the early 90s. This trend has moved the EA focal point from the business-IT alignment theme in the “first school of EA” (borrowing from La Palme's terminology), to the business strategy execution theme in the “second school of EA”. Most organizations are now seeking specific business outcomes from their EA practice, rather than mere IT/IS planning benefits addressed by old-school EA frameworks. This business-orientation trend has expressed itself in the rise of business architecture-focused accounts of EA such as BIZBOK, or business design methods. It has also pushed more classical frameworks, like TOGAF, to enrich their business architecture metamodels and put stress on this aspect. (Compare, for example, TOGAF's answer to the “Why do I need an enterprise architecture?” question, in v8 and v9). Business-led EA requires a more business-centric view of the whole architecture and seeing it from the business owners' perspective.

??

3.2.???? Strategic architecture

Moving from an IT-focused EA towards a business-focused EA is augmented by a tendency to mainly use EA for addressing strategic concerns, rather than tactical and operational use cases, which was characteristic of early EA practice. (Strategy execution theme in La Palme’s second school of EA). Strategic architecture, as indicated in the TOGAF guideline for architecture partitioning, is determined by 1) broad organizational context, 2) long-term planning span, and 3) low level of detail models. Although TOGAF does not offer any specific guidance on how one can scope a strategic architecture planning project, it seems that capability-based planning is the right choice for this.

?

3.3.???? Integrated planning

While classical approaches to enterprise planning address different dimensions of business capabilities, i.e. people, process, and technology, through different streams across different business units, there is a strong demand for a holistic, integrated approach that would be capable of envisioning and planning these dimensions within a single conceptual framework.?

?

3.4.???? Architecture stability

Classical EA practices model and design the architecture based on elements like business units, business processes, products, etc. These elements are subject to change as the business is changing, at an ever-increasing pace. So, architects are seeking a more stable “unit of functionality” to serve in the planning and management of organizations’ architecture. BC emerges as the right candidate for such a solid foundation of architecture because the BC map of an organization changes only when the business model of the organization radically changes.

?

4.???? Structure

CBEA frames any organization in terms of its BCs. The main model is a top-level BC map, which could be further broken down into lower levels of granularity. Each BC is responsible for providing one or more business service(s) to external stakeholders (as external business services), or internal service consumers, i.e. other BCs or business actors. Orchestration of all business services is done through value streams to provide final value for stakeholders. Each BC utilizes a set of architectural building blocks or “assets”, such as business actors, business processes, and technology services, in a dedicated or shared manner. There could be a common infrastructure to provide shared services to all BCs.

?

The schematic view of the organization according to CBEA is as follows:

?

BCs are fundamental units of functionality of the enterprise, and business services act as the glue between BCs. As it is usual in architectural descriptions, many other viewpoints could serve to capture all aspects and perspectives of architecture and complete the whole picture, like value stream mapping and date models.

?

5. Roadmap

Although any organization needs its transformation roadmap based on business/technology priorities and overall strategic intent, a generic roadmap could be sketched according to CBEA. This general roadmap shall be tailored to any application instance.

?The generic CBEA roadmap consists of the following stages, which could be executed linearly, in parallel, or in a cyclic manner to fulfill the organization’s development requirements:

5.1.???? Initial Capability Modelling

The CBEA journey starts with BC mapping at the highest possible level of abstraction. The master BC map can be refined and split down to lower levels. It is usually sufficient to have a 2-3 levels BC map as a starting point for most CBEA scenarios. The BC map could be compiled by an analysis of business strategy, business models, organization structure, value streams, and/or reference models.?

?5.2.???? Capability-based Planning (CBP)

The first attempt to design the to-be architecture of the organization could be done in the form of a CBP cycle. In the first CBP cycle, the initial BC map is used to perform both a BC maturity assessment and a strategic impact analysis of BCs. The results are combined in a single ML-SI matrix and presented to strategic-level decision-makers to set the target BC maturity level goals. Then, the to-be maturity levels for BCs are translated into appropriate actions for improving the people, process, and technology dimensions of selected BCs. These actions form the organization’s overall development roadmap. (Read more here. )

?5.3.???? Capability Development Increments

Each BC development increment generally starts with modeling all as-is and to-be business services. The business service portfolio of any BC should be reviewed against business requirements and end-to-end integration considerations. Each business service has potentially a realizing business process, executed by one or more business actors. A detailed modeling and (re)design of business processes and organizational structure is usually needed to derive a detailed roadmap for improving BC maturity level. Also, it could be necessary to analyze and identify all required technology services to support business processes. These technology service requirements are used as input to IT architecture design process, to design physical applications and technology components providing required technology services.

?5.4.???? Enterprise Integration

Splitting the architecture into distinct BCs has many benefits for transformation planning, but should be balanced with a parallel stream of actions to find common architecture components and design the realizing assets to gain an appropriate level of integration across different BCs. Enterprise integration stream is a continual course of actions to assure that “all wheels work well together”.?

?5.5.???? Building and running EAM/EAG capability

No organization can benefit from EA values unless it establishes and uses an EA management and governance EAM/EAG capability. This is equally true when you follow the CBEA roadmap to develop your EA. The EAM/EAG capability will ensure that 1) all BC development and enterprise integration activities are in line with a pre-designed transformation roadmap to achieve the business vision, and 2) the target architecture and associated plan will remain valid and effective during the flow of both internal and environmental changes.

The following figure shows the generic roadmap of CBEA:

??

6. Summary

CBEA is a unified, business-led, and incremental approach to EA development which is formed around the concept of BC. CBEA splits the enterprise into distinct units of functionalities, interconnecting through business services. Then it incrementally designs, develops, and consolidates these units (BCs) into an overall architecture realizing the organization’s transformation vision. CBEA can be used consistently as a conceptual framework to gather all EA modeling and design techniques in a meaningful and purposive manner, to align the architecture with the strategic intent of the organization.