# Business Capabilities Centric Enterprise Architecture

Thiago Barroero, Gianmario Motta, Giovanni Pignatelli

► To cite this version:

Thiago Barroero, Gianmario Motta, Giovanni Pignatelli. Business Capabilities Centric Enterprise Architecture. IFIP TC 5 International Conference on Enterprise Architecture, Integration and Interoperability (EAI2N) / Held as Part of World Computer Congress (WCC), Sep 2010, Brisbane, Australia. pp.32-43, 10.1007/978-3-642-15509-3_4. hal-01054821

HAL Id: hal-01054821

https://inria.hal.science/hal-01054821

Submitted on 8 Aug 2014

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Business Capabilities Centric Enterprise Architecture

Thiago Barroero¹, Gianmario Motta¹, Giovanni Pignatelli¹

¹ University of Pavia, Department of Computer Engineering and Systems Science, via Ferrata 1, 27100 Pavia, Italy {thiago.barroero, gianmario.motta, giovanni.pignatelli}@unipv.it

**Abstract.** In the field of Enterprise Architecture, The Open Group Architecture Framework (TOGAF) is a well known framework, that links Business Architecture, Data Architecture, Application Architecture, Technology. A key concept within Business Architecture domain is Business Capabilities, that are delivered by Business Component (BC). A BC is a business unit that encompasses a coherent set of activities, supported by assets including people, processes and technology. Current TOGAF version recognizes the BC requirements but misses how to bridge those requirements with a data, application and technology architecture. Defining the bridge is specifically the purpose of our extension called Business Capabilities Centric Enterprise Architecture (BCCE), where we adapt some TOGAF phases, extend the core TOGAF meta-model and add architectural contents. We have validated our approach on a telecommunication example taken from literature. A major benefit of the proposed extension is to link changes of business to data, application and technology architectures.

**Keywords:** Enterprise Architecture, TOGAF, Business Capabilities

# 1 Introduction

## 1.1 Enterprise Architecture and Business Capabilities modeling

Nowadays scenario of Enterprise Architecture (EA) testifies a plethora of frameworks [1] from which it is hard to determine which one is better than another, for they differ in goal and in approach. The point is that each framework has specific characteristics and has been developed for a specific purpose. Still, The Open Group Architecture Framework (TOGAF) is the result of best practice [7] and the second framework most used overall [2]. TOGAF is specifically conceived as cross-industry open standard for enterprise architecture. Across the board the principle that EA is critical to business survival and success, and is an indispensable means to achieve
competitive advantage through IT. Inspecting IBM CEO survey 2008 [3], it is plain that the enterprise of the future requires EA for responsiveness and innovation are achievable only if an integrated and responsive IT environment is supportive of the delivery of business strategy. In order to overcome today's imperatives of growth and profitability, firms must focus on responsiveness, innovation, differentiation and efficiency [3], and should embrace the concepts of Business Capabilities through *Componentization of Business* [4].

*Componentization* breaks down each enterprise capability into business component (BC). Each BC is an individual business model that encompasses a coherent set of activities, supported by assets including people, processes and technology. A component serves a unique purpose within the organization but could also, in principle, operate as an independent entity [5]. A BC is characterized by a distinctive high-level capability that it offers to the Enterprise. This possessed ability is used to achieve a specific purpose or outcome. In other words, BCs are the modular building blocks that compose an enterprise.

## 1.2 Business Capabilities Models

A Business Capability model includes the description of capabilities and connections, how services are provided, their performance metrics, the people responsible for the service, and the systems that provide support for them. In general, business component may be modeled in two very different ways [6] that lead to diverse patterns described in Table 1.

<table><caption>**Table 1** Modeling Business Capabilities Description</caption><thead><tr><th></th><th>Strategic Modeling</th><th>Functional Modeling</th></tr></thead><tbody><tr><th>Objective</th><td>To produce a model that enables the identification of business challenges and business opportunities.</td><td>To produce a model of each business component that enables its implementation, either on a business view (i.e. organizational structure, accountability, processes and activities, business services etc.) or on a IT view (i.e. design of systems, applications, software artifacts etc.).</td></tr><tr><th>Outcome</th><td>A business model, usually a paper or a tool-based model, that focuses on sensitive components.</td><td>A detailed design of all dimensions of each component</td></tr><tr><th>Primary Audience</th><td>Business executives</td><td>Business and IT managers</td></tr></tbody></table>

A BC is orthogonal to the overall domains of an EA. A generic EA divides the architecture in four domains [7], namely Business, Data, Application and Technology Architecture shortly summarized in Table 2.

<table><caption>**Table 2** Enterprise Architecture Domains</caption><thead><tr><th>Architecture Type</th><th>Description</th></tr></thead><tbody><tr><td>Business Architecture</td><td>The business strategy, governance, organization, and key business process.</td></tr></tbody></table>
<table><tr><td>Data Architecture</td><td>The structure of an organization's logical and physical data assets and data management resources</td></tr><tr><td>Application Architecture</td><td>A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization</td></tr><tr><td>Technology</td><td>The software and hardware capabilities required to support the deployment of business, data and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.</td></tr></table>

BC modeling is incorporated in methodologies, including those by IBM and Microsoft. Let us consider their profile and position our approach.

## IBM CBM Approach

IBM Component Business Modeling (CBM) [4][5][15] focuses on business change and transformation of enterprises. CBM identifies business challenges and business opportunities and analyzes the role of each BC in terms of specialization and differentiation. In other words, CBM enables to determine building blocks for the future business in different areas and across operational functions. The approach guides the architect in identifying gaps between current and future state showing requirements to be met (fit-gap analysis), but, alas, does not guide the analyst in defining how to bridge requirements with a data, application and technology architecture design.

## Microsoft Motion

In [7] [9] Homann and Tobey describe a Microsoft approach to “model a business architecture as a network of capabilities, and then transform the business architecture into a service-oriented architecture.” The Microsoft Motion methodology provides an approach to link a business modeling to an IT implementation related to Web Service technology. Motion is a top-down approach, from business to IT requirements. The methodology addresses architectural issues like capabilities view, people view, process view, technology view and Service Level Expectations (SLE), but does not describe how steps are performed, e.g. how components should be selected or decomposed, nor links BC to the information systems.

## Other Approaches

Business Capability Mapping and Analysis (BCMA) by Helix Commerce International Inc. [10] focuses on capabilities and its alignment with business processes. It is based on customers' needs and priorities. The approach may be considered as an EA Framework as it bridges the chasm between Strategy, Process, Architecture, and Technology and brings greater clarity to the as-is state and capabilities of a organization, and its alignment to the to-be vision of the business.

Capgemini reports an approach adopted to support insurance companies that uses a business component architecture [11]. The methodology divides the business into functions called components and analyzes each aspect of the business that impact on
the performance of a business component. The Business Component Architecture models the business architecture by identifying components and their relationship, it designs a target solution based on the component map in a manner that covers all functions that must be supported with no overlap and finally design and implement a insurance enterprise system to support the business functions.

Finally, enhanced Telecom Operation Map (eTOM) [12] is a detailed description of the business processes of a generic telecommunication company, decomposed to a deep level of detailed. If we observe the eTOM map decomposed down to the third level, we may consider those “processes” as components for they represent business functions.

## 1.3 Summary and positioning

After this short review, we position the BC models in terms of their orientation (functional or strategic), their target (industry, cross industry) as in Table.

<table><caption>Table 3 Comparative profile of business components models</caption><thead><tr><td>Model Name</td><td>Orientation</td><td>Target</td><td>EA Integration</td></tr></thead><tbody><tr><td>IBM - CBM</td><td>Strategic</td><td>Cross Industry</td><td>Missing</td></tr><tr><td>MS - Motion</td><td>Functional</td><td>Cross Industry</td><td>Missing</td></tr><tr><td>Helix - BCMA</td><td>Strategic</td><td>Cross Industry</td><td>????</td></tr><tr><td>Cap Gemini</td><td>Functional</td><td>Insurance</td><td>OK</td></tr><tr><td>eTOM</td><td>Functional</td><td>Telecom</td><td>OK</td></tr></tbody></table>

Apparently, a well-established and mature business capability centric approach that grants EA design, implementation and governs is still missing. The main purpose of this paper is to fill this gap. As a host methodology we have chosen TOGAF since [2]:

* Is supported by an open strong committee

* Is a proven method and result of long term practice

* Uses a standard taxonomy for business, information, and technology modeling.

* Has a business focus in the architecture development

* Is supported by many tools.

On the other side, Zachman is the most used framework, but it is a taxonomy rather than a methodology [2].

## 2 TOGAF Extension

“TOGAF provides the methods and tools for assisting in the acceptance, production, use and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.” [7] and includes several parts. The TOGAF structure includes a core and a certain number of extensions. Extensions add method steps, meta-model entities and artifacts.
BCCE is one of the possible TOGAF extensions. Specifically Business Capabilities Centric Extension (BCCE) introduces the BC concept in the TOGAF core structure and changes it in some parts as shown in Table 4.

<table><caption>Table 4 Impact of BCCE on TOGAF</caption><thead><tr><td>TOGAF Part</td><td>Comments</td><td>Impact of BCCE</td></tr></thead><tbody><tr><td>Part I Introduction<br>Part II Architecture<br>Development Model<br>(ADM)</td><td>Describes a process for deriving an organization-specific enterprise architecture that addresses business requirements</td><td>Additions to the method steps to include BC concepts</td></tr><tr><td>Part III ADM Guidelines<br>&amp; Techniques</td><td>Supports ADM</td><td><ul><li>Added the principle “Componentization of Business”</li><li>Added Architectural Artifacts</li></ul></td></tr><tr><td>Part IV Architecture<br>Content Framework</td><td>Provides a detailed model of architectural work products, including deliverables, artifacts within deliverables</td><td>Changes to the core meta-model entities</td></tr><tr><td>Part V Enterprise<br>Continuum</td><td>A model for structuring a virtual repository and provides methods for classifying architecture and solution artifacts.</td><td>----------------</td></tr><tr><td>Part VI Architectural<br>Reference Models</td><td>TOGAF provides two reference models for inclusion in an Enterprise Continuum</td><td>----------------</td></tr><tr><td>Part VII Architectural<br>Capability Framework</td><td>A set of resources, guidelines, templates and background information</td><td>----------------</td></tr></tbody></table>

## 2.3 Changes in TOGAF Part II - Architecture Development Model (ADM)

The main changes in Part II - Architecture Development Model include

* Integration of the Componentization of Business principle as a constraints of the Enterprise Architecture structure

* Description of the Architecture Vision in terms of business capabilities through Business Component Map Diagram and Business Component Collaboration Diagram;

* Introduces in Capability Assessment the strategic value added by BC.

## 2.1 Changes in TOGAF Part III - ADM Guidelines & Techniques

The first change is the Componentization of Business as a new principle for Enterprise Architecture (Table 5).
<table><caption>Table 5. The principle of Componentization of Business.</caption><thead><tr><th>Name of principle</th><th>Componentization of Business</th></tr></thead><tbody><tr><td>Statement</td><td>Well-defined business units called Business Components (BC) compose the Business Architecture. Each BC encompasses a distinctive set of capabilities, activities and resources, and interacts with other components through services. Each BC has to be considered as a "centre of services".</td></tr><tr><td>Rationale</td><td>Componentization of business delivers a modular enterprise architecture that potentially is more responsive to business changes.</td></tr><tr><td>Implications</td><td><ul><li>Componentization of business brings a revolutionary change to enterprise organization for it divides the business into separated business units.</li><li>Componentization places a big constraint on business inter-component communication, because every exchange of value or information should be conducted through business services.</li><li>Componentization generates an environment where every unit of an enterprise acts like a producer of services; thus, every part could be managed as a single independent organization itself.</li></ul>The whole organization should be fully componentized in order to benefit from componentization.</td></tr></tbody></table>

Part III also contains new architectural artifacts that are required by method steps described in Part II. Figure 1 shows BCCE added artifacts and describes their respective content.

<figure><img src="image_2.png" /><figcaption>Figure 1 TOGAF viewpoints taxonomy of BCCE</figcaption></figure>

<table><caption>Table 6 BCCE Diagrams and Matrices Description</caption><thead><tr><th>Entity</th><th>Description</th></tr></thead></table>
<table><thead><tr><td>Entity</td><td>Description</td></tr></thead><tbody><tr><td>Business Component Map Diagram</td><td>A business component map diagram provides an overview of the enterprise as a whole illustrating high-level capabilities of the enterprise.</td></tr><tr><td>Business Component Collaboration Diagram</td><td>A business component collaboration diagram provides a static description of the interaction between components on a specific business scenario. It shows main business services exchanged by components.</td></tr><tr><td>Business Component Sequence Diagram</td><td>A business component sequence diagram provides a time sequence high-level workflow for the specific business scenario. It provides information on timing and dependencies of business services</td></tr><tr><td>Process Flow Diagram</td><td>A process flow diagram describes the workflow on a level of detail that shows activities, business rules and information flow.</td></tr><tr><td>Business Service Consumption/Production Matrix</td><td>The matrix shows which business component produces business services and which one consumes it.</td></tr><tr><td>Business Component/ Business Process Matrix</td><td>The matrix shows which business component is involved in which business process.</td></tr><tr><td>Business Service Dependencies Matrix</td><td>The matrix shows the dependencies between business services.</td></tr><tr><td>Business Component/ Information Matrix</td><td>This matrix shows for each component what source of information is required.</td></tr><tr><td>Business Service/Data Entity Lifecycle Matrix</td><td>This matrix shows the data lifecycle (CRUD) used by business services.</td></tr></tbody></table>

## 2.2 Changes in TOGAF Part IV - Architecture Content Framework

We have extended the TOGAF core meta-model by introducing or redefining concepts of the BC approach. Figure 2 shows the changes to core TOGAF meta-model and Table 7 describes them. The foundations of our contents extensions are available in [13] [14] [15].
<figure><img src="image_3.png" /><figcaption>Figure 2 Business Capabilities Centric Extension (BCCE): Changes to Metamodel</figcaption></figure>

<table><caption>Table 7 BCCE Changes to TOGAF meta-model description.</caption><thead><tr><td>Entity</td><td>Description</td><td>Change Type</td><td>Notes</td></tr></thead><tbody><tr><td>Business Component</td><td>A business component encompasses a coherent set of activities, supported by assets including people, processes and technology. It interacts with other business components through business services.</td><td>New</td><td></td></tr><tr><td>Capability</td><td>A capability is the “power or the ability to do something”. It is an idealized conceptual structure that describes what a BC can do to create value for customers. It is accessible through business services and identifies what is required to accomplish a business objective.</td><td>Modified</td><td>Each capability can be associated to one and only one BC</td></tr><tr><td>Business Service</td><td>A business service is an interface through which other components requires or provides a capability. It is standardized and hides its implementation from other components.</td><td>Modified</td><td>BCs can exchange value only trough business services.</td></tr><tr><td>Activity</td><td>An activity is an atomic operation performed within a BC and belongs exclusively to a single component. It represents an operation performed to provide low-level capability.</td><td>Modified</td><td>Each Activity can be associated to one and only one BC</td></tr></tbody></table>
<table><thead><tr><td>Entity</td><td>Description</td><td>Change Type</td><td>Notes</td></tr></thead><tbody><tr><td>Business Process</td><td>A business process represents the procedures required to provide a capability, i.e. the governance required to orchestrate business services, activities, resources and technology.</td><td>Modified</td><td>Business Process is a composition of Business Services</td></tr><tr><td>Data Entity</td><td>A data entity is a major source of data that must be understandable, consistent, complete and stable. It is used by and activity through an information system service.</td><td>Modified</td><td>Data Entity can be handled only by Business Services and Information Systems Services.</td></tr><tr><td>Information System Service</td><td>An information system service represents an IT functionality implemented as a service that may encompass a set of activities or even represent a fully automated business service.</td><td>Modified</td><td>Each system function can be implemented only by Information System Services</td></tr></tbody></table>

## 3 Validation

Let's consider a telecommunication organization that wishes to capitalize the emerging of new opportunities such as DSL demand in his country. Due to processes inefficiency and the complexity of a DSL offer, the intervention requires a re-design of business processes and organization in order to govern and manage demand planning, network planning and order management. The case is taken from NGOSS Framework for it is a best practice on the Telecommunication industry adopted in the world by major Telco companies.

In order to assess enterprise capabilities we built a Business Component Map diagram based on eTOM level 3 processes. In Figure 3 we identified the direct and indirect impacted components in order to deliver a DSL service. The map quickly shows what components of the enterprise are required for the desired service and become a requirement for further modeling. For each business component a catalog of sub-capabilities is created to identify what ability should have each BC. Table 8 shows a catalog of capabilities for the Resource Provisioning BC aligned to the BC goals.

<table><caption>**Table 8** Resource Provisioning BC capabilities decomposition.</caption><tr><td>Goal</td><td colspan="3">Guarantee that resource orders are issued correctly and complete.</td></tr><tr><td>Capability</td><td colspan="3">Ability to issue correct and complete resource orders.</td></tr><tr><td>Ability to initiate a resource order assessing the information contained on a service order.</td><td>State</td><td>Specified</td></tr><tr><td>Ability issue resource orders that require a feasibility assessment, new provisioning activities, change to a previous resource order, or require the deletion/recovery of previously delivered resource orders.</td><td>State</td><td>Specified</td></tr><tr><td>Ability to manage specific or unusual requirements.</td><td>State</td><td>Specified</td></tr></table>
Then, we defined a business scenario for each process that composes a DSL Service, namely DSL Fulfillment, DSL Assurance and DSL Billing. For each one of them we designed a Business Component Collaboration diagram to identify main business services exchanged between components. Figure 4 shows the Collaboration Diagram referred to a DSL Fulfillment sub-process, i.e. DSL Pre-sales sub process. Those viewpoints together with the dynamic collaboration viewpoint addressed with UML Sequence Diagrams represent a high-level vision of the desired behavior and structure of our target enterprise architecture.

Hereafter we start a functional modeling of each component. For each Business Component Collaboration View, a process flow is drawn in order to identify activities and information flows and to validate business services.

<figure><img src="image_4.png" /><figcaption>**Figure 3** Business Component Map Diagram for a telecommunication enterprise</figcaption></figure>

When the business architecture phase is over, an analysis of main source of data was conducted. For each business service we identified how data entity was manipulated building the Business Service / Data entity Lifecycle Matrix showing CRUD (Create, Read, Update, Delete) relations. Furthermore, we identified source of data for each activity described during the process flow analysis.
Finally, we identified system services by analyzing data manipulation. Our goal was not to provide a system design but describe system as group of low-level capabilities that manage data of the data architecture and support activities on business architecture. At last, we related application components to technology components.

<figure><img src="image_5.png" /><figcaption>Figure 4 Business Component Collaboration Diagram. DSL Fulfillment. Pre-sales sub-process.</figcaption></figure>

## 4 Conclusions

We have illustrated the integration of a Business Component approach into the TOGAF framework. This integration implies multiple potential benefits.

First it links business strategy and IT strategy by a very convincing model. For Business Component approach is a very popular method among enterprise consultants to identify a modularization of the enterprise in the perspectives of business development, sourcing and out-sourcing.

Second the link between the business component concept and related information architecture is clear and easy to understand. In fact from a business strategic viewpoint Business Component is a Business Unit and from IT viewpoint it is a cluster that receives and delivers services.

Third Business Component allows by its very nature a modularization of IT architecture, that potentially enhancing its responsiveness to sudden business and environmental changes. Moreover the alignment of IT to Business comes almost as a byproduct of mating Business Component into Information Architecture.
Next steps include a formal field validation and a subsequent step its formal integration in the TOGAF framework body.

Business Component Approach is a strategic modeling procedure that is taking place over last years. It focuses mainly on decision-making steps for it defines scopes, required capabilities and strategic evaluations. We used TOGAF 9 to fill the gap between the outcome of the business component approach and an EA framework. Next step would require a detailed description of EA with a service oriented architecture supporting business component approach.

## References

1. J. Schekkerman, Institute for Enterprise Architecture Developments (IFEAD). *Trends in Enterprise Architecture*. Reports of the Thirds Measurement, Edition 1.0, Suikerpeergaarde 4, 3824BC Amersfoort, The Netherlands. Dec 2005

2. D Minoli. Enterprise Architecture A to Z. Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. Auerbach Publications. Taylor & Francis Group. ISBN 978-0-8493-8517-9 (Hardcover). 2008

3. IBM Global CEO Study. The Enterprise of the Future. Executive Summary. GBE03044-uSEn-01, 2008

4. L. Cherbakov et al. Impact of Service Orientation at the Business Level. IBM Systems Journal, Vol. 44, Number 4, 2005.

5. G. Pohle, P. Korsten, S. Ramamurthy, S. Foecking. The Specialized Enterprise. A Fundamental Redesign Of Firms And Industries. IBM Business Consulting Services. 2005.

6. P. Herzum, O. Sims. Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. Wiley Press, Hoboken, NJ. 2000.

7. The Open Group. TOGAF Version 9. The Open Group Architecture Framework. ISBN 978-90-8753-230-7. Document Number G091. Published by The Open Group, 2009.

8. U. Homann, J. Tobey. Building Distributed Applications. From Capabilities to Services: Moving from a Business Architecture to an IT Implementation. MSDN Library. 2006

9. U. Homann. Building Distributed Applications. A Business-Oriented Foundation for Service Orientation. MSDN Library. 2006

10. Helix. *Business Capabilities Mapping and Analysis (BCMA)*. Helix Commerce International Inc., 2006

11. R. Linan. *The Smart Insurance Enterprise System (SIES)*. Capgemini Financial Services. Sep 2007

12. Enhanced Telecom Operations Map (eTOM). The Business Process Framework. For the Information and Communication Industry. Release 6.0. TeleManagement Forum. 2005

13. J. Ackermann, K. Turowski. Specification of Customizable Business Components. Euromicro.pp.391, 29th Euromicro Conference (EUROMICRO'03), 2003

14. D. W. McDavid. A Standard for Business Architecture Description. IBM Systems Journal, Vol 38 Number 1, 1999.

15. M. Ernest, J.M. Nisavic. Adding Value to the IT organization with the Component Business Model. IBM System Journal, vol 46, no 3, 2007

16. G. Pohle, P. Korsten, S. Ramamurthy, S. Foecking. The Specialized Enterprise. A Fundamental Redesign Of Firms And Industries. IBM Business Consulting Services. 2005.