Five essential services of an EAM capability

As more organizations shift from a project-based approach to enterprise architecture and doing ad-hoc EA planning projects to establishing and utilizing EA management (EAM) capability, it turns out more and more how important is to have a comprehensive and clear reference model of EAM capability. There are many such references in EAM literature, for example, “The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability” (2018), COBIT short description of APO02 management objective “Managed Enterprise Architecture” (2019), and EAM guide in IVI IT-CMF Framework (2016). Although all of these references might be inspirational to some extent, none of them are as clear as needed for practical uses.

Following is a list of 5 essential services which every EAM capability should deliver to make the organization capable of revealing and utilizing EA full value. Each service is elaborated in terms of sub-services which could be directly mapped onto practical processes and procedures.

1.    EA Repository Management

The core functionality of the EAM capability is to gather, record, organize, and retrieve data about EA elements (business motivation and strategy, organization and processes, application services and components, etc.) by means of an EA repository. Related sub-services are:

1.1 Create and maintain EA tool and repository

An EA repository managed by an EA tool is crucial to EAM capability. Creating and maintaining these two components is the main mission of any EAM team.

1.2 Configuration management of EA content

Since EA repository content is under constant change and update due to changes in the organization’s architecture, and these updates might be originated by different stakeholders, certain configuration management procedures should be established in order to assure about consistency and accuracy of the content. For example, check-in/check-out procedures to keep the updates effective, or making baselines after a series of inter-related updates, etc.

1.3 Extract and publish EA models

In general, EAM is responsible for providing the EA stakeholders with the required views and models. Doing this job in a right and timely manner is vital in EAM communication and stakeholder management.

2.    EA Integration Management

EA repository content is an accumulation of the organization’s self-consciousness embodied in the form of EA elements data and models. This content should be gathered and integrated from different sources, e.g., EA planning projects, business design activities, business process management, data management, solution development projects, and so on. Formal uniformity and semantic integrity of different parts of EA content is a vital factor of its quality and usefulness for EAM use cases. In order to keep the EA content consistent following integration services should be delivered by EAM:

2.1 Design and maintain EA repository completion roadmap

No EA repository could be completed at once (if a “complete” repository makes any sense at all!). Any organization needs a customized roadmap to incrementally complete EA repository content. This roadmap may include successive EA planning projects, solution development projects, business process modeling, and other modeling activities.

2.2 Create and maintain EA blueprints

As-is, to-be, and transition architecture blueprints are landmarks to direct and guide architecture change activities. Most EA blueprints are delivered by EA planning projects, but other EAM activities could also result in a make or change in EA blueprints.

2.3 Quality control and acceptance of EA models

Models and blueprints generated by different projects and activities should be checked against quality measures before accepting and merging into EA repository.

2.4 Architecture compliance reviews and controls

Architecture compliance reviews, usually performed by Architecture Review Boards (ARB), are the main mechanism to implement EA governance. EAM capability is responsible to plan ARB meetings, provide input material for these meetings, document the result, and follow-up decisions. Additional process controls, other than ARB, could be designed and implemented to assure compliance of all architecture changes with blueprints and standards.

3.    EA Requirements Management

EA requirements are the main sources to define EA change cycles. Every EA cycle should be defined and justified against a well-defined set of EA requirements, including certain change or “fail” scenarios. EA requirements management service is delivered by the following sub-services:

3.1 Identify, gather, and maintain EA requirements

The set of EA requirements is an integral part of the EA repository. Therefore EAM capability should incorporate a clear and comprehensive “Requirement Catalog”, representing all change motivations and gaps between as-is and to-be architectures.

3.2 Analyze and prioritize EA requirements

EA requirements should be analyzed and prioritized against business strategy, impact on current architecture, available resources, and other organizational limitations.

3.3 Define EA cycles

Any EA cycle starts with a problem definition originating from business or IT strategy, or other change motivations. EAM is responsible for setting the vision and scoping of EA cycles in the organizations. High-priority EA requirements are used to define new EA cycles.  

3.4 Manage architecture debts

Architecture debts are gaps between planned or actual architecture building blocks and to-be architecture blueprints and standards. Architecture debts are created as the result of changing the business/IT requirements faster than the architecture itself. The compromised and accepted noncompliance also creates architecture debt. Although a certain level of architecture debt is unavoidable for most organizations, EAM must monitor and care for the acceptable level of architecture debt. EA cycles should be defined in case of over-tolerated levels of architecture debt, in order to reduce the total debts to an acceptable level.

4.    EA Knowledge Management

Regarding EAM as a knowledge management process, EAM capability should deliver certain services to fulfill its stakeholders’ knowledge needs. EA knowledge management sub-services include:

4.1 Define and maintain EA framework and standards

Designing a customized EA meta-model and selecting related standards are parts of the preparatory phase of EAM capability establishment in any organization (Preliminary phase in TOGAF ADM). But it is not a one-time job as it may be induced by ADM. The EA meta-model and standards need to be reviewed and updated in a continual manner.

4.2 EA training

General training about EA concepts, value, and processes are services of an EAM capability. Continuous training is a part of the EA communication program and is essential to gain stakeholders’ commitment.

4.3 EA consulting

Not all EA tasks in the organizations are done by EAM people. Project managers, product managers, business analysts, and other parties in the organization may need assistance and guidance to make or use EA artifacts or make architectural decisions.

5.    EA Capability Management

Last but not least, there should be services serving the EAM itself, as a business capability. EAM capability maturity should be monitored and measured constantly and arranged to be improved by designing and re-design EAM people, process, and technology aspects. Related sub-services include:

5.1 Measure and improve EAM capability maturity

Like any other business capability, EAM capability maturity should be continuously monitored, measured, and improved in a systematic way and according to an agreed maturity model.

5.2 Design EAM competency model

The competency models, AKA skill frameworks, are used to find, recruit, train, allocate, and promote the right people with the right skills in organization positions. The EAM capability should serve itself with design and maintain an EA competency model, based on EAM scope and use-cases.

5.3 Design and improve EAM organization and processes

The EAM organization and processes should be designed, implemented, evaluated, and constantly improved. In organizations where these tasks are done by a centralized or shared service, the EAM capability is responsible to feed its own requirements.