CBEA Basic Metamodel

I introduced Capability-based Enterprise Architecture (CBEA) in an article published in June 2024. The heart of this approach is focusing on the business capability concept and arranging the whole EA descriptions around this concept. Here I will propose a basic metamodel containing core architecture elements and their relationships, to support the usual use cases of CBEA. The proposed metamodel is a “minimal” one, in the sense that it covers only fundamental elements used in most common use cases. It could be extended by adding other elements and relationships needed for additional scenarios.

The metamodel is developed in line with notations and syntax of ArchiMate? 3.2 Specification, to make it possible to implement it in any standard EA modeling environment. For the sake of conciseness, I will not define the elements of the metamodel here. All elements and relationships are always used in the sense of original meaning in the ArchiMate metamodel.

The following figure shows the overall CBEA Basic Metamodel:

The following rules apply to elements of CBEA Basic Metamodel:

1. Every organization has one or many GOALs.
2. Every GOAL may be realized by one or many COURSE OF ACTIONs.
3. Every COURSE OF ACTION is served by one or many BUSINESS CAPABILIES.

Rules (1), (2), and (3) form the basic structure of the strategic role of business capabilities, as fundamental “bricks” of the ability of an organization to execute a strategy to achieve its goals.

4. Every VALUE STREAM has one or many VALUE STREAM STAGEs.

5. Every VALUE STREAM STAGE is served by one or many BUSINESS CAPABILITIES.

Rules (4) and (5) show the behavioral role of business capabilities to perform a specific value delivery chain of actions.

6. Every ACTOR (business unit) is accountable for one or many BUSINESS CAPABILITIES.

7. Every ACTOR has one or many BUSINESS FUNCTIONs.

Rules (6) and (7) address the structural dimension of business capabilities. Different mappings between business capabilities and organization units enable different operating model realizations, resulting in organizational flexibility and sustainability.

8. Every ACTOR has one or many ROLEs in some BUSINESS PROCESS.

Rule (8) makes it possible to connect the structural dimension of business capabilities (people) to the behavioral dimension (process).

9. Every BUSINESS CAPABILITY provides one or many BUSINESS SERVICEs.

10. Every BUSINESS SERVICE is provided to one or many BUSINESS CAPABILITIES and/or ACTORs, through a BUSINESS INTERFACE.

Rules (9) and (10) allow the modeling of the external behavior of a business capability in terms of the value it provides to other business capabilities or business actors. Business services act as the “glue” between various business capabilities of the organization.

11. Every BUSINESS SERVICE is realized by one BUSINESS PROCESS.

12. Every BUSINESS PROCESS accesses one or many BUSINESS OBJECTs.

13. Every BUSINESS PROCESS is served by one or many APPLICATION SERVICEs, through one or many APPLICATION INTERFACEs.

Rule (13) relates the application layer of architecture to the business layer, through application services. Binding two layers by a service layer enables architects to analyze and design more flexible and robust architects, by hiding technology complexities from a business perspective.

14. Every APPLICATION SERVICE is realized by one APPLICATION COMPONENT.

15. Every APPLICATION COMPONENT accesses one or many DATA OBJECTs.

16. Every APPLICATION COMPONENT is served by one or many TECHNOLOGY SERVICEs.?

The whole metamodel could be decomposed into several “domains”, each containing homogenous elements capturing a specific aspect of the architecture. Possible domains of the metamodel are shown in the following figure:

The BUSINESS CAPABILITY element acts as a connector of different aspects and domains:

1. Strategy Domain: including GOAL and SOURSE OF ACTION elements, capturing the strategic direction of the organization.
2. Value Domain: mainly contains the VALUE STREAM elements, which are composed of several VALUE STREAM STAGEs, in turn. These elements capture the value delivery logic of the organization, from a high-level point of view.
3. Business Domain: including BUSINESS PROCESS, BUSINESS SERVICE, and BUSINESS INTERFACE, which capture the value delivery mechanism in more detail than Value Domain elements.
4. Application Domain: including APPLICATION COMPONENT, APPLICATION SERVICE, and APPLICATION INTERFACE. These elements address concerns about how technology supports an organization’s business processes and services.
5. Data Domain: including passive structural elements, BUSINESS OBJECT, and DATA OBJECT, that capture the data architecture of the organization.
6. Service Domain: including SERVICE elements in BUSINESS, APPLICATION, and TECHNOLOGY layers, framing the value delivery of each layer to the upper one, hiding the implementation mechanism of value provision. Service elements are vital in 1) architectural integration, and 2) encapsulation and hiding realization logic of business capabilities. Both of these features are required to make an organization's architecture flexible and sustainable.
7. Interface Domain: containing BUSINESS INTERFACE and APPLICATION INTERFACE elements to capture real-world touch points of any organization's behavior.

The CBEA Basic Metamodel could be extended by adding elements such as PRODUCT, EVENT, LOCATION, etc. to cover specific architecture stakeholders’ concerns.