• slider2

    Generalized Enterprise Function Framework  (GEFF)

  • slider3

    A3 KAM - Triple A(Architectural, Actionable and  Augmented) Knowledge Assets Management

  • slide1

    Enterprise Architecture 3.0 (EA3.0) - the third wave in Enterprise Architecture approaches

  • slider4

    ABODE™ business transformation methodology  founded on EA3.0

Plan-to-Capability - Development and Semantics

 

Introduction

In the whitepaper “Business Capabilities” TOGAF defines guidelines that should explain how to define business capabilities. In TOGAF the following formal Capability definition is used:

 

A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.

 

However, in the document instead of giving guidelines, explaining an approach, methodology, model, or techniques to derive at capabilities the document directly starts with naming capabilities. This naming is done in the confusingly same way as naming Business Service, Business Functions, etc. Also, the components used to define a Business Capability are limited to Roles, Processes, Information and Tools only. The results are not comparable to that what the title promises.

 

In this paper, I will explain how capabilities can be derived from strategic plans by using a model that was developed over the years and which now uses Archimate 3.0 for this translation. In other papers the complete model will be used to not only define capabilities, but also business functions, processes, services, resources, principles, etc. necessary to develop a successful capability model.

 

History

The translation of strategic plans into architectural components used in the strategic architecture domain (Archimate) is a complex task but necessary because it forms the foundation of the Enterprise Architecture. If this is not performed properly the different architecture domains, its components, models, principles, and business capabilities are, at the least, incomplete.

 

In 2007, as head of Architecture and IT Strategy of an airliner, I used a technique called Goals-Means modeling, based on the Business Motivation Model (short BMM, see Business Rules Group (BRG), Business Motivation Model, http://www.businessrulesgroup.org/ later adapted by OMG) with which the IT management team could derive the departmental goals from the enterprise goals. With this, the initial strategy for the IT department and the architecture team strategy was set up. Next, the different divisional strategies were integrated and the model was adjusted. I then translated it into an integrated capability model and derived the goals, capabilities, and actions for the whole IT department, and for the architecture team specifically.

 

 

This model can be transformed into an Archimate 3.0 model, although at the time with version 2 this was impossible. The Goal-Means model covers the left part of the below model. However, we used the Principles, Course-of-Action and Application Service, and more, as part of the Architecture Plan.

 

 

For the longer-term goals an investigation took place about what was necessary for the IT department to serve the organizational and divisional goals. Goals like business agility and flexibility, to operate and transform the organization based on different strategical scenarios for future opportunities like take-overs, joint-ventures, a European roll-out, multi or single hub operations scenarios, and a centralized or concentrated European organization scenario. From this we defined “foundational projects” to enable the architecture team and the IT department as a whole to support the business in the best way in a multi-year planning. For example introducing an SOA with ESB and, later, BPM and BAM facilities.

 

In 2016 Archimate (3.0) had evolved enough to translate the above mentioned approach into a motivation model. It now became possible to (partly[1]) translate the different strategical targets into short, middle, and longer-term goals of the organization as a whole and of the IT department as a service delivering capability. Next, it was also possible to set the goals and targets for the architecture and other teams within the IT department. The model was used to define the capabilities of the organization, departments and teams.

 

 The architecture team now could define the necessary components in coherence with each other including themes from the strategic plans and develop the support within the architecture teams for developing the enterprise architecture, perform impact analysis, advise management, support business case management, the design and delivery teams and information and functional management. Hence, the service delivery of the different architecture teams could be defined.

 

The (architecture) capability should deliver actions that had predefined goals to support the IT goals. For this, the capability needed IT resources (generic IT tools like an ESB, CMS, DMS, etc.) but also the financial and human resources, etc. could be distinguished. I also developed part of the model in such a way that the principles, the requirements, and the (ISO 25010) quality aspects for the results of the actions to be undertaken, could be defined top-down over the aspect architectures, especially the motivation aspect architecture, and then within each architecture domain specific per model. Based on the strategy a hierarchy of principles could now be set up at the strategic architecture domain.

 

Each specialization of the aggregated principles should at least support one or more quality characteristics and whenever possible define the requirements and constraints to establish that principle. This also meant that new requirements and quality characteristics could be derived base on the requirements and quality characteristics of the aggregated principles. In this way a tree of principles, quality characteristics, and requirements was established per aggregated principle that could be inherited by specializations of this principle.

 

It became possible to add these principles, requirements, and quality characteristics to the so-called Plan-to-Capability model. Architects could now deliver these based on an architectural capability model to derive the different components from the strategic plans. I used the model to define the architectural strategic plan and pointed out how each planned action would support the organizations strategy.

 

In 2017 I helped the architects of a larger municipality to use this model and analyze the “Digitalization Agenda”. The Capability component was “enriched” with Business Functions, Business Processes, Business Services, Resources and Products. We also reintroduced “resources[2]” as application components, application functions and application services.

 

Plan-to-Capability Model 

 

The above given Plan-to-Capability model[3] can be used for several different purposes. In this paper we will focus on the possibility to interpret strategic plans, to translate and fill different architectural components based on text parts of the plan especially concerning capabilities. In following papers we will address the other components.

 

Of course the model, especially the Capability components as given above, can be extended. For example the competencies of (human or non-human) resources define the results of the Business Process, and can only there, or in the Business Function, be defined. The problem is that Archimate doesn’t (yet) have a symbol for competencies and many other essential components.

 

Also, often the (main) Business Objects, called Enterprise Objects, and how the Product delivers Value from various viewpoints like Actor-Value, Product-Value, Process-Value, etc. is relevant for the Capability. As of yet, they have not been defined in the above model. I used to define requirements and ISO 25010 Quality characteristics, as constraints, to explain why Principles are necessary.

 

Besides that, the Service Delivery architecture approach, discussed in a later paper, can be used. In the Service Delivery model the Why and What of service delivery, starting with an external Actor, is modeled. In the above model a start for modelling the Service Delivery is given by defining the Business Actor. The value of this model for Enterprise and Business Architecture is high, but discussed later.

 

Semantics

The above model can be described semantically on a high-level as follows.

 

  • Capabilities deliver outcomes that serve the Goal of the architecture team, the IT department, the division, or the organization as a whole.
  • These Outcomes are guided by Constraints and Requirements, based on Principles and Courses of Actions.
  • Special or generic ICT resources can be essential components that serve Business Functions. These ICT resources can be combinations of Application Components, Application Functions, and Application Services.
  • The Capability itself, by definition, consists of Business Functions that form Business Processes that serve Business Services. Business Services are necessary to deliver the Product requested by a Business Actor. For the Business Actor the Business Services form complete sets of functionalities with a logical end before a next Business Service is performed.

 

 (c) Paul van Wely, Emc2 Holding BV

 

Paul van Wely is the founder of Enterprise Architects (www.enterprise-architects.com). He developed a methodology (ABODE™) based on a new approach of Enterprise Architecture (EA3.0™) and established a software company that develops tools for architecture, business planning and transition, a company that with these tools develops business solutions and business models.

 

 In coming papers he will give some insights on the above. When you are interested in downloading these and other papers please visit the website, download the papers or subscribe to the community.

 

[1] Archimate 3.0 is still missing several components necessary to support the strategy motivation, the architectural organization domain, the information domain and the IT domain as well as some aspect architectures (the columns) for addressing the Knowledge components, the Competencies and Requirements within each domain, etc.. This will be discussed in later papers.

 

[2] A term used otherwise in Archimate.

 

[3] In the model it was necessary to use the Constraint component instead of using a better definition name like quality aspect. Also, the relationships between Product, Business Service, Business Process and Business Function is often addressed otherwise. In later paper I will explain this from the viewpoints of service delivery and transition realization.