See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/319218916

Enterprise Architecture: A Maturity Model Based on TOGAF ADM

Conference Paper · July 2017

DOI: 10.1109/CBI.2017.38

CITATIONS READS

7 3,982

2 authors:

Diogo Proença José Borbinha

Inesc-ID University of Lisbon
33 PUBLICATIONS   112 CITATIONS    193 PUBLICATIONS   919 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Digital Preservation for Timeless Business Processes and Services (TIMBUS) View project

SHAMAN (Sustaining Heritage Access through Multivalent Archiving), View project

All content following this page was uploaded by Diogo Proença on 04 December 2018.

The user has requested enhancement of the downloaded file.

 Enterprise Architecture
A Maturity Model Based on TOGAF ADM
Authors Name/s per 1st Affiliation (Author)
line 1 (of Affiliation): dept. name of organization
line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired
Abstract— Ensuring the alignment between IT and business
can be a difficult challenge. That is the reason why the Enterprise
Architecture domain exists, to provide guidance on how to better
align Business and IT. There are several methods in existence
that guide an organization in developing its Enterprise
Architecture. However, putting these methods in practice can
become a huge project. The purpose of this paper is to develop a
maturity model for Enterprise Architecture in organizations as a
governance instrument to analyze and evaluate the current state
of affairs, as well as, identify possible areas for improvement. In
this way, maturity models facilitate the evolutionary
reengineering of all functions related with the lifecycle of an
Enterprise Architecture as they allow benchmarking assessment
and roadmap planning to be performed. The development of this
maturity model is based on design science research grounded in
current literature. By collecting the critical success factors of
Enterprise Architecture and evaluating the existent maturity
models for this domain the conclusion is that there is no maturity
model that fully considers all these critical factors. The maturity
model proposed in this paper is evaluated through a multi-step
perspective that is used to confirm that the maturity model
makes a useful and novel contribution to the enterprise
architecture domain by taking in consideration the best practice
and critical success factors of the domain.
Keywords— Enterprise Architecture, Maturity Model,
Measurement, Performance, Design.
I. INTRODUCTION
The process of business and IT alignment can be described as
the application of Information Technology (IT) in an
“appropriate and timely way, in harmony with business
strategies, goals and needs” [1]. However, maintaining the
alignment is not an easy task. Organizations inhabit unstable
environments, at the competitive, collaborative, and
cooperative levels, which might directly and indirectly affect
their information systems, imposing new requirements [2].
Consequently, many organizations invest in technology over
the years, as business faces new needs, which despite its
power to “transform and whole industries and markets”, can
have frustrating results [1]. Between the several aspects that
can influence alignment between business and IT, “IT
understands the business” and “IT does not understand
business" have been listed respectively as enabler and
inhibitor for the alignment [3], which clearly points to
Authors Name/s per 2nd Affiliation (Author)
line 1 (of Affiliation): dept. name of organization
line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired
communication as a major factor. Enterprise architecture (EA)
tries to harness the benefits of using architectures to attack the
business-IT alignment problem. Lankhorst defines EA as “a
coherent whole of principles, methods, and models that are
used in the design and realization of an enterprise’s
organizational structure, business processes, information
systems, and infrastructure" [4], with a “focus on alleviating
the infamous business-information technology alignment
problem” [4]. EA practice involves the creation of models
describing an enterprise, including business and IT elements,
so that it can realize management requirements and be
maintained over the period of its useful life [5]. EA practice
also involves the use of EA frameworks that guide the
architecture work, providing an underlying structure for
architecture descriptions.
Current EA literature shows a focus on refining existing
methods. One shortcoming is the attention towards the arising
challenges of applying EA concepts to specific organizational
environments. There are still no common adequate
instruments for assessing the current state and identifying
opportunities for improvement. Thus, organizations are often
unsure about where to start in improving their EA
management procedures.
The objective of this paper is to develop an artifact (the
maturity model) by using a research approach to address the
practical problem described previously and contribute to the
body of knowledge at the same time. Therefore, Design
Science Research (DSR) was chosen as it combines both
perspectives, the practical and scientific dimensions. The
maturity model focuses on the EA body of knowledge to
define EA maturity levels. In this paper, we focus on the
following two research questions (RQs):
[RQ1] Can existing maturity models holistically assess the
critical success factors of EA in organizations?
[RQ2] How could a maturity model specific to EA be
designed, which targets the challenges of EA lifecycle
management across different types of organizations and
industries?
To address these research questions, the paper is structured in
six sections. First, fundamental terms and concepts will be
detailed and will be followed by the outline of the research
methodology in section III. Further on, section IV presents the
findings from a literature review. Section V elaborates the
main insights of the iterative maturity model development and
the maturity model itself. Next, the evaluation of the maturity
model is presented in section VI. Lastly, this paper presents
conclusions from this works and details research limitations.
II. FOUNDATION
To ensure a common understanding, we explain in this section
the key terms and concepts, such as, “maturity model”, and
“Enterprise Architecture”.
A Maturity Model is a technique that has been proved to be
valuable in measuring different aspects of a process or an
organization. It represents a path towards increasingly
organized and systematic way of doing business in
organizations. A Maturity Model consists of several “maturity
levels”, often five, from the lowest to the highest, Initial,
Managed, Defined, Quantitatively Managed and Optimizing
(however, the number of levels can vary, depending on the
domain and the concerns motivating the model). This
technique provides organizations: (1) A measuring for
auditing and benchmarking; (2) A measuring of progress
assessment against objectives; (3) An understanding of
strengths, weaknesses and opportunities (which can support
decision making concerning strategy and project portfolio
management).
MMs history goes back to 1973 [6], and had its maximum
visibility with the Software Engineering Institute Capability
Maturity Model Integration (CMMI) [7] and the ISO 15504
[8]. Both these key references were born in the Software
Engineering domain, culminating decades of development and
refinement of the corresponding models. Moreover, there is
certification for these two references as they are considered as
the de facto assessment techniques to be used when
benchmarking organizations for their software engineering
process implementation and maturity. As such, for the results
to be comparable, there is a detailed maturity assessment
method behind each of these MMs. These methods define in
detail how an assessment should be planned, conducted, the
maturity levels calculated and how the results must be
presented to the organization. These methods make each
assessment repeatable and comparable with results from other
organizations, allowing for benchmarking.
EA is “The architecture of an enterprise. As such, it concerns
those properties of an enterprise that are necessary and
sufficient to meet its essential requirements.” [9] It is a holistic
approach to systems architecture [10] with the purposes of
modeling the role of information systems and technology in
the organization, aligning enterprise-wide concepts and
information systems with business processes and information.
It supports planning for sustainable change and provides self-
awareness to the organization [11]. In that sense, it aims to
provide a complete coverage of the organization. It has
become a very popular approach to the development of
information systems aligned with business strategies [12].
The term “enterprise architecture” has been used to depict a
process for creating architectures for the enterprise, a
framework for classifying architecture artifacts, or both. In [4],
the author defines EA as a coherent whole of principles,
methods, and models that are used in the holistic design and
realization of an enterprise’s organizational structure, business
processes, information systems and infrastructure. Another
definition refers to EA frameworks as a way for defining what
products the architecture must deliver and how those products
must be constructed [13]. It can also be defined as a “complete
expression of the enterprise”, or a “master plan”, which aligns
aspects of business planning, business operation, aspects of
automation, and the technological infrastructure, which
enables all the other aspects, capturing a vision of the “entire
organization” [14].
There are various best practice guidance frameworks for EA,
some of the most known are TOGAF [11] and the Zachman
Framework [10].
Depending on the needs and challenges raised by specific
domains and organizations, EA approaches can be used for
several purposes. In [15], seven key applications for EA are
identified, which are (1) Situation description, (2) Strategic
Direction, (3) Gap Analysis, (4) Tactical Planning, (5)
Operational Planning, (6) Selection of partial solutions and (7)
Solution Architecture.
The Open Group Architecture Framework (TOGAF) [11] is a
high-profile EA, providing methods and tools to support
architecture development. It comprises seven modules that can
be partly used independently of each other. The core of
TOGAF is the Architecture Development Method (ADM) and
the Architecture Content Framework.
The ADM is a cyclical process divided in nine phases, as
shown in Figure 1. After a preliminary phase in which the
context, relevant guidelines, standards and the architecture
process goal are identified, the main process begins with the
elaboration of an architecture vision and the principles that
should guide the architecture. This provides the basis for
developing the business architecture, information systems
architecture, and technology architecture.
On this basis, solutions are developed, and migration and
implementation are planned and governed. Finally,
Architecture Change Management ensures that the
architecture continues to be fit for purpose. The ADM can be
adapted for various purposes, and in more complex situations,
the architecture can be scoped and partitioned so that several
architectures can be developed and later integrated using an
instance of the ADM to develop each one of them.

Figure 1. TOGAF Architecture Development Method (ADM) [11]
III. RESEARCH METHODOLOGY
To address the RQs raised in this paper, we opted to use a
Design Science Research (DSR) paradigm as described in
[16]. DSR can be described by “a designer answering
questions relevant to human problems via the creation of
innovative artifacts, thereby contributing new knowledge to
the body of scientific evidence. The designed artifacts are both
useful and fundamental in understanding that problem” [38] In
this method, research focuses on designing solutions to be
applied to solve a problem, as opposed to the more descriptive
paradigm followed in social and natural sciences. The process
includes six steps: (1) problem identification and motivation;
(2) definition of the solution objectives (3) design and
development of the solution artefact; (4) demonstration; (5)
evaluation; and (6) communication.
The development of maturity models in the IT and EA
domains is not new and has been quite popular in recent years.
As an example, in [17], the authors have identified more than
100 maturity models, and in [18] even more are identified.
However, one major issue can be identified in most these
maturity models, which is the lack of disclosure of the
development process used to develop them. This leads to a
weakness in this research area, which is the lack of
contributions regarding how to develop these models. Despite
this fact, we have identified some development methods and
procedures for maturity models, such as, the general design
principles from Roglinger et al. [19], the DSR perspective on
maturity models by Mettler [20], the development guidelines
from Maier et al. [21], and the procedure model based on DSR
from Becker et al. [22], which are quite popular among
scholars based on their respective citation counts. To develop
the maturity models presented in this paper we decided to
apply the development procedure of Becker et al. [22] as it is
based on DSR and as result it offers a sound methodological
foundation, which is suitable for application in the research
approach. This development procedure gives a stringent and
consistent approach to the DSR guidelines of Hevner et al.
[23].
As depicted in the procedure model in Figure 2 the first steps
focus on the problem identification. In this step the research
problem is identified and detailed, the practical relevance of
the problem is specified and the value of the artifact is
justified. This step is followed by the comparison with
existing maturity models. This second step is based on the
problem identification of the first step and analysis of existing
maturity model in the EA domain, which leads to the
identification of weaknesses in these models. We conducted a
literature analysis, which was based on an extensive online
search to find existing maturity models focused on the EA
domain. Thus, the analysis of the maturity models was
performed according to their functionality, as well as, their
capability to address the baseline CSF.
The next step deals with the determination of the research
strategy outlined in this section of the paper. This is followed
by the iterative maturity model development. In this step, we
used model adoption techniques, such as, configuration,
instantiation, aggregation, specialization and analogy [24] to
incorporate the TOGAF ADM in the maturity model. This
allowed us to create a rigorous maturity model regarding both
the structure and content. In the last step, evaluation, we
combined the steps of Becker et al. [22], conception of
transfer and evaluation, implementation of transfer media, and
evaluation, into step 5. All steps will be conducted, but to
match the structure of this paper we made this change.
IV. ANALYSIS
To provide a consistent and precise problem definition, we
conducted a literature analysis. The aim of this analysis was to
identify current challenges, areas where future action is
required, and success factors related with the lifecycle
management of an EA. This analysis is therefore based on
current literature in the EA domain including research papers,
reports and white papers from both the Academia and
practitioners.
Based on the extended analysis of literature, we identified a
set of several success factors (CSF) for an EA implementation.
In evaluating each CSF, we relied on the theoretical
framework of Rockart [25] [26], which considers CSF as a
“limited number of areas in which results, if they are
satisfactory, will ensure competitive performance for the
organization”. In a second step, we condensed and verified the
CSF, which we derived from the literature analysis on EA
lifecycle management.
An EA should enable effective communication and provide a
common language for the enterprise. It should provide a
business-driven approach by proving a linkage between
business and IT. It should also strive for commitment from the
top management throughout the whole lifecycle. It should use
Figure 2. Procedure model of the research approach (adopted
from Becker et al. [22])
a sound management strategy and strive for tool support by
using structured, well-defined and documented methods such
as, processes, guidelines, best practices and standards. An EA
development method directs the creation of EA models and
other artifacts, which in turn provide a valuable help in the
communication of the architecture to the relevant
stakeholders. Management and organizational aspects of the
architecture should be dealt by governance principles, which
define “how an organization makes decisions, sets priorities,
allocates resources, designates accountability, and manages its
architectural processes” [27]. The design and implementation
of EA should be conducted through projects and as result
project management has a central role in the success of an EA
implementation. As part of EA Governance there should also
be assessments and evaluation of EA with a well-defined
purpose, process and assessment criteria. EA should be a key
influencer in the IT Investment and Acquisition. Architectural
decisions should be aligned with the IT Governance strategy
As part of any EA implementation there should be a team of
skilled architects, top management, business partners and
different stakeholder groups who have the necessary training
to engage in the design and implementation of an EA. Finally,
for an EA design and implementation project to be successful
the organizational culture must be taken into consideration
striving for an adequate organizational and cultural fit. Based
on Ylimaki [28][29], Perkins [30] and Al-kharusi et al. [31]
we derived the eleven CSF for EA maturity models, which can
be summarized as follows:
[CSF01] Communication and Common Language
[CSF02] Business-driven Approach
[CSF03] Commitment
[CSF04] Development Methodology and Tool Support
[CSF05] EA Models and Artifacts
[CSF06] EA Governance
[CSF07] Project and Program Management
[CSF08] Assessment and evaluation
[CSF09] IT Investment and Acquisition Strategies
[CSF10] Skilled Team, Training and Education
[CSF11] Organizational Culture
These CSF were used as a reference baseline to assess the
relevance of a set of maturity models. Based on the results of
our literature review within the EA design and implementation
domain, we identified numerous papers dealing with maturity
models. In a first step, we selected maturity models that were
related to the topic areas of EA based on the analysis of the
abstracts. Prior to the in-depth assessment a few maturity
models have been excluded, due to their different
methodological approaches, Finally, the remaining maturity
models were analyzed according to the degree to which they
cover and fit to the previously defined reference baseline.
Each maturity model was ranked for every CSF per the degree
of matching from 1 (very low) to 5 (very high). In the
overview, we concluded that only six maturity models scored
an aggregate of at least 24 points per the defined CSF
reference baseline.
 NASCIO EA Maturity Model [32];
 US DoC ACMM Framework (Version 1.2) [33];
 Extended EA Maturity Model (EEAMM) [34];
 OpenGroup Architecture Capability Maturity Model
(OG ACMM) [35];
 GAO Organizational Transformation – A Framework
for assessing and improving EA Management
(Version 2.0) [36];
 Architecture Maturity Matrix (AMM) [37].
Table 1 presents the assessment results of the above as most
significant identified maturity model in details. Based on this
set an average total score of 25,5 was achieved (maximum
score 55).
V. SYNTHESIS
In accordance to the maturity model development procedure
of Becker et al. [22] a new maturity model should be
developed, if no existing or the advancement of an existing
one can address the identified problem. So, based on the
findings of our literature analysis there is no maturity model
which acceptably fulfills the entire CSF reference baseline.
Therefore, we decided to develop a new maturity model.
The newly developed maturity model, presented in Table 2,
adopts established structural elements, domains and functions
of the best practice of maturity models analyzed in section 4
and is based in TOGAF ADM, which most of the analyzed
maturity models point for further guidance. These artifacts
were then extended and adjusted to fit the purpose of assessing
the maturity of an EA using the guidance from TOGAF ADM.
As outlined within our research methodology, we applied an
iterative process for the development of this maturity model.
In total, we needed three iterations, which are described in the
following:
First Iteration: As a first step, we identified the basic
characteristics and structure of the model. As a starting point,
we proposed five maturity levels – Initial, Managed, Defined,
Quantitatively Managed, Optimizing – as this approach is
evident in several reputable maturity models, such as, the
CMMI [7]. In this initial iteration, we focused in just some
phases of the TOGAF ADM namely the Preliminary Phase
and the Architecture Vision. For each criterion of the maturity
Table 1. CSF reference matrix fit assessment
model we modeled what is the manifestation of that criterion
at the different maturity levels.
Second Iteration: The aim of the second iteration was to build
on the success of the results of the first iteration. Thus, the
maturity model was extended to contemplate all the phases of
the TOGAF ADM. As result the phases of the TOGAF ADM
are now seen as dimensions of the maturity model. We also
restructured these phases criteria as in the ADM there is one
phase named Requirements Management, which is connected
to all the other phases. As such there are criteria of this phase
that must be used to assess all the other phases. We continued
with the approach of the first iteration and modeled each of the
criteria at each maturity level. We then conducted a trial
assessment using the maturity model, which revealed some
issues that will be solved in the third iteration.
Third Iteration: After the trial assessment using the maturity
model one relevant issue was identified. The trial revealed that
there was a difficulty in understanding the differences in each
possible answer for the assessment questions. As an example,
participants could understand what a “documented procedure”
is but it was difficult for them to understand what is a “defined
procedure” or even an “ad-hoc assessed procedure”. This led
to a revision of the assessment questionnaire and an overhaul
of the maturity model to accommodate the changes to the
assessment questionnaire. The maturity levels definition
remained the same, however there are major changes in the
overall structure of the criteria. Now instead of modelling each
criterion at each maturity level we opted by identifying
capabilities for each maturity level and dimension, which
resulted in an easily understandable maturity model that is
presented in Table 2. We also realized that by following this
approach there were almost no criteria that could be drawn
from TOGAF ADM for maturity level 4 and 5. We turned our
attention to the guidance from CMMI, which details a set of
process areas for maturity levels 4 and 5 very relevant to
assessing the maturity of an EA. The criteria from CMMI is
used to assess the maturity levels 4 and 5 for all the
dimensions and is detailed under “General”.
In addition to the already discussed, maturity levels 1–5, we
added level 0, which means that the organization is not
executing any EA function or task at all. Therefore, level 0 is
not explicitly mentioned within the EA maturity model.
Finally, this leads to the following maturity levels:
 Level 0 – Non-existent EA;
 Level 1 – Initial EA;
 Level 2 – Managed EA;

Maturity Model CSF01 CSF02 CSF03 CSF04 CSF05 CSF06 CSF07 CSF08 CSF09 CSF10 CSF11 
NASCIO 3 1 4 3 3 2 2 3 1 1 1 24
DoC ACMM 3 3 4 3 1 3 1 2 3 1 1 25
EEAMM 1 2 4 3 3 3 3 1 3 1 1 25
OG ACMM 1 3 4 4 2 4 2 3 1 4 2 30
GAO 1 3 5 3 3 4 3 3 1 3 1 30
AMM 1 3 4 4 3 1 2 2 3 2 1 26
Average 1 3 4 3 3 3 2 2,5 2 1,5 1 25,5
  Level 3 – Defined EA;
 Level 4 – Quantitatively Managed EA;
 Level 5 – Optimizing EA.
To move from level 0 to level 1, the organization needs to be
aware that EA is needed as a relevant function of the
organization. Furthermore, basic EA tasks are performed with
the aim of ensuring Business-IT alignment across the
organization.
At maturity level 2 EA meets its goals. However, there is no
standardization of procedures for each phase, which can lead
to two people doing different tasks to achieve the same goal
and in turn can result in the inability to repeat tasks that were
previously performed. Moreover, at this maturity level there is
no assignment of responsibilities.
Then at maturity level 3, the organization has a standardized
list of procedures for each phase with responsibilities assigned
for these procedures. There are also tools and methods that
support the lifecycle management of the EA, which are agreed
upon and become a standard across the organization.
Procedures at this maturity level are well defined and include
its purpose, inputs, entry criteria, activities, roles, verification
steps, outputs and exit criteria. There is also an understanding
of the interrelationships between the various phases of the
ADM.
At maturity level 4 the organization establishes quantitative
objectives for quality and performance of all functions related
with EA. Specific measures of performance are collected and
are analyzed using statistical and other quantitative
techniques. There are also performance baselines and models
that help in setting quality objectives. A key difference
between maturity levels 3 and 4 is the predictability of
performance as predictions are based on the statistical analysis
of fine-grain information.
Finally, at Maturity Level 5 the organization continually
improves its EA functions based on quantitative analysis of
the business objectives and performance baselines. It uses
quantitative techniques to understand variations in procedures
and the causes of outcomes. It also focuses on continually
improving performance using incremental and innovative
procedures. Additionally, the quality and performance
objectives are established and continuously revised to reflect
changing business objective and the organization’s
performance. A key difference between maturity level 4 and 5
is the focus on improving and managing the organization
performance, which at this level is concerned in analyzing
performance using data collected from multiple projects. This
data helps identify gaps and weak points in performance that
are then used to generate a measurable improvement.
To improve from level X to level X+1, the organization must
comply with all the criteria from level X, which makes this
maturity model follow a “stages” approach. What an
organization can expect from progressing through the maturity
levels is that their EA lifecycle management practice will
become increasingly managed, defined and optimized. This in
turn results in a better alignment between the Business and IT
functions. In Table 2 “ML” stands for “Maturity Level”.
Table 2. EA Maturity Model
Dimension: Architecture Capability
ADM Phase: Preliminary
The preparation and initiation activities are not performed. There
ML1 is no definition of principles and no organization-specific
architecture framework.
At maturity level 2, the organization:
-Identifies the core, soft and extended enterprise units, as well as,
ML2 the communities and governance involved.
- Selects the appropriate architecture tools to support the
architecture function.
In addition to Maturity Level 2, the organization:
- Defines a framework for architecture governance.
- Defines and Establishes an Enterprise Architecture Team and
Organization.
ML3
- Identifies and establishes the Architecture principles, which are
the set of principles that relate to architecture work.
- Determines what tailoring of TOGAF and other selected
architecture frameworks is required.
ADM Phase: A - Architecture Vision
The architecture scope is not defined, the stakeholders are not
ML1 identified, there is no architecture vision and no approvals are
obtained.
At maturity level 2, the organization:
- Identifies the key stakeholders and their concerns or objectives,
and describe the key business requirements to be addressed in the
architecture project.
ML2 - Identifies and evaluates the collection of capabilities within the
organization.
- Evaluates and qualifies the organization readiness to undertake
change.
- Identifies the risks associated with the architecture vision.
In addition to Maturity Level 2, the organization:
- Conducts the necessary procedures to secure recognition of the
architecture project, the endorsement of corporate management,
and the support and commitment of the necessary line
management.
- Identifies the business goals and business drivers, as well as, the
constraints that must be dealt with.
- Defines what is inside the scope of the baseline and target
ML3 architecture
- Reviews the principles under which the architecture will be
developed.
- Develops an architecture vision that covers the extent of the
scope identified for the architecture project, at a high level.
- Defines the value propositions and KPIs for the target
architecture to be developed within the project.
- Defines the work products to be produced, as well as, deadlines
for each of these work products.
Dimension: Architecture Development
ADM Phase: B, C, D – Business, Information Systems and Technology
Architecture
There is no Architecture developed that supports the Architecture
ML1
Vision
At maturity level 2, the organization:
- Identifies the catalogues that capture inventories of the core
assets of the business.
- Identifies the required matrices that show the core relationships
between related model entities.
- Identifies the required diagrams that present the business, data,
application and technology architecture information from deferent
ML2 viewpoints according to the requirements of stakeholders.
- Formalizes the business, data, application and technology
requirements for implementing the target architecture.
- Develops a Baseline Description of the current business, data,
application and technology Architecture to the extent necessary to
support the target business architecture.
- Identifies and resolves any wide impacts or implications in the
Architecture Landscape.
ML3 In addition to Maturity Level 2, the organization:
 - Selects relevant business, data, application and technology
architecture resources and viewpoints, as well as, appropriate
tools and techniques.
- For each viewpoint, selects the models needed to support the
specific view required, using the selected tool or method.
- Develops a target description for the business, data, application
and technology architecture to be developed, to the extent
necessary to support the Architecture vision.
- Verifies the business, data, application and technology
architecture models for internal consistency and accuracy by
identifying gaps between the baseline and target business
architecture.
- Defines a business, data, application and technology roadmap to
prioritize activities over the following phases.
- Reviews if the proposed business, data, application and
technology architecture is capable of supporting the subsequent
work by checking the original motivation for the architecture
project and the statement of architecture work against the
proposed architecture.
- Finalizes the business, data, application and technology
architecture after conducting a formal stakeholder review by
documenting all the final requirements, mappings and work
products.
- Documents the architecture definition and also reviews the
resulting document with relevant stakeholders and incorporates
feedback.
Dimension: Transition Planning
ADM Phase: E – Opportunities & Solutions
The delivery approaches, such as, projects, programs or portfolios
ML1 are not identified, which results in the organization not being able
to deliver the target architecture identified in the previous phases.
At maturity level 2, the organization:
- Identifies any business drivers that would constrain the
implementation sequence.
- Consolidates the interoperability requirements identified in
previous phases.
- Refines the initial dependencies, ensuring that any constraints on
the Implementation and Migration Plans are identified.
ML2
- Reviews the findings of the Business Transformation Readiness
Assessment previously conducted in Phase A and determine their
impact on the Architecture Roadmap and the Implementation and
Migration Strategy.
- Creates an overall Implementation and Migration Strategy that
will guide the implementation of the Target Architecture, and
structure any Transition Architectures.
In addition to Maturity Level 2, the organization:
- Determines how the enterprise architecture can be best
implemented to take advantage of the organization’s business
culture. This should include the creation of an Implementation
Factor Assessment and Deduction matrix.
- Consolidates and integrates the gap analysis results from the
Business, Information Systems, and Technology Architectures
(created in Phases B to D) and assess their implications with
respect to potential solutions and inter-dependencies.
- Assesses the requirements, gaps, solutions, and factors to
identify a minimal set of requirements whose integration into
work packages would lead to a more efficient and effective
ML3
implementation of the Target Architecture across the business
functions that are participating in the architecture.
- Assesses the missing business capabilities identified in the
Architecture Vision and Target Architecture and logically group
the various activities into work packages.
- Identifies one or more Transition Architectures where the scope
of change to implement the Target Architecture requires an
incremental approach.
- Consolidates the work packages and Transition Architectures
into the Architecture Roadmap, which describes a timeline of the
progression from the Baseline Architecture to the Target
Architecture.
ADM Phase: F – Migration Planning
ML1 The Implementation and Migration Plan is not coordinated with
the organizations change management and implementation
approach. The business value and cost of work packages and
Transition Architectures is not understood by stakeholders.
At maturity level 2, the organization:
- Establishes and assigns business values to all of the work
packages.
ML2 - Determines the required resources and times for each project
and their increments and provides the initial cost estimates.
- Transitions governance from the development of the architecture
to the realization of the architecture.
In addition to Maturity Level 2, the organization:
- Coordinates the Implementation and Migration Plan with the
management frameworks within the organization.
- Prioritizes the projects by ascertaining their business value
ML3 against the cost of delivering them.
- Updates the Architecture Roadmap including any Transition
Architectures and confirms the architecture definition in case the
implementation approach shifted.
- Generates the completed Implementation and Migration Plan.
Dimension: Architecture Governance
ADM Phase: G – Implementation Governance
There is no oversight of the implementation of the target
ML1 architecture, the deployment resources and priorities are not
identified, and compliance reviews are not performed.
At maturity level 2, the organization:
- Identifies system development methods required for solutions
development and ensures that the systems development method
enables feedback to the architecture team on designs.
ML2
- Carries out the deployment projects; and publishes new Baseline
Architectures to the Architecture Repository and update other
impacted repositories, such as operational configuration
management stores.
In addition to Maturity Level 2, the organization:
- Confirms the Scope and Priorities for Deployment with
Development Management.
- Guides the Development of Solutions Deployment.
ML3 - Reviews ongoing implementation governance and architecture
compliance for each building block; conducts post-development
reviews; and closes the development part of deployment projects.
- Conducts post-implementation reviews; and publishes reviews
and close projects.
ADM Phase: H – Architecture Change Management
The procedures that manage change to the target architecture are
ML1 not established, there are no risk management procedures and
monitoring tools in place.
At maturity level 2, the organization:
- Manages the governance process and framework for the
ML2
architecture.
- Activates the architecture process to implement change.
In addition to Maturity Level 2, the organization:
- Influences business projects to exploit the EA for value
ML3 realization (outcomes).
- Manages EA risks and provides recommendations for IT
strategy.
In addition to Maturity Level 3, the organization:
- Ensures that monitoring tools are deployed and applied.
ML4 - Provides analysis for architecture change management.
- Makes recommendations on change requirements to meet
performance targets and development of position to act.
Dimension: Architecture Requirements Management
Requirements management is not sustained and does not operate
for all ADM phases, the architecture requirements are not
ML1 identified and managed during the execution of the ADM. The
relevant architecture requirements are not available for use at
each phase of the ADM.
At maturity level 2, the organization:
- Identifies the changed requirements and records the priorities.
- Updates the Requirements Repository with information relating
ML2
to the changes requested, including stakeholder views affected.
- Identifies and documents requirements using business scenarios,
or an analogous technique.
 - Identifies changed requirements.
- Determines whether to implement change, or defer to later
ADM cycle; if decision is to implement, assesses timescale for
change management implementation.
In addition to Maturity Level 2, the organization:
- Ensures that all key participants agree on the detailed
description of the requirements, and commit to execute them
accordingly.
- Monitors the baselined requirements.
- Assesses and revises gap analysis performed during Phases B
ML3
through D, which identify the gaps between Baseline and Target
Architectures.
- Assesses impact of changed requirements on the current (active)
phase.
- Assesses impact of changed requirements on the previous
phases.
- Issues at every phase of the ADM cycle a requirements impact
statement.
In addition to Maturity Level 3, the organization:
- Ensures that new or changing requirements that are derived from
ML4
Architecture Change Management (Phase H) are managed
accordingly.
Dimension: General
For all dimensions, in addition to Maturity Level 3, the
organization:
- Establishes the objectives for quality and process performance
and negotiates at an appropriate level of detail to permit an
overall evaluation of the objectives and risks at the process level.
- Selects measures and analytic techniques to be used in
ML4 quantitative management.
- Analyses selected measures to characterize the performance of
the organizations’ processes.
- Establishes and compares process performance baselines to the
organization’s quality and process performance objectives to
determine if the quality and process performance objectives are
being achieved.
For all dimensions, in addition to Maturity Level 4, the
organization:
- Identifies potential areas for improvement that could contribute
to meeting business objectives.
- Selects and implements improvements for deployment
throughout the organization based on an evaluation of costs,
benefits, and other factors.
ML5
- Evaluates the effects of deployed improvements on quality and
process performance using statistical and other quantitative
techniques.
- Systematically determines the root causes of selected and
analyzed outcomes.
- Implements and evaluates selected action proposals developed
in causal analysis.
The Maturity Model is structured in a set of dimensions. These
dimensions aggregate phases which work together towards a
common purpose and is inspired by the iteration cycles of the
ADM [11]. The first dimension is the Architecture Capability
that has the phases that “support the creation and evolution of
the required Architecture Capability” [11] includes the
Preliminary Phase and Phase A. The second is the
Architecture Development, that has the phases that “allow the
creation of the architecture content” [11] includes phases B, C
and D. The third is the transition planning that include phases
that “support the creation of formal change roadmaps” [11]
includes phases E and F. The fourth dimension is Architecture
Governance that includes the Phases that “support governance
of change activity” [11] includes Phases G and H. The fifth
dimension includes only the “Requirements Management”
phase, a special phase, which goal is to manage the
architecture requirements across the ADM. This is a special
phase as phases A to H interact with this phase and that is the
reason for this phase to be in the center of the ADM in Figure
1. This led to a distinction between assessment criteria. There
are specific criteria for requirements management that phases
A to H must take into consideration to be compliant with the
ADM. This means that the maturity assessment results for
these phases will take into consideration the results for these
criteria to calculate the maturity level for each of these phases.
Finally, there are also specific criteria used to assess the
maturity level of the requirements management phases and is
not taken in consideration when assessing the other ADM
phases. The TOGAF ADM details the development process
for an EA and does not go into the specific details on how to
quantitatively manage and optimize this process. As result,
there is no guidance that could be used for maturity levels 4
and 5. This lead us to gather guidance for these maturity levels
from the SEI CMMI [7], which defines in generic terms what
is a process at maturity level 4 and 5. We adapted this
guidance and created criteria to assess an EA at these higher
maturity levels, detailed in Table 2 under the “General”
dimension, for all the phases of the ADM.
Additionally, in Table 2, phases B, C and D of the ADM are
combined into a single phase to ease the understanding of the
Maturity Model. However, these three phases are assessed
independently. This means that the Maturity Model can assess
the maturity of phase B, phase C and phase D separately.
Moreover, we have decomposed the phase C into two sub-
phases, to allow for the assessment of the maturity of the Data
Architecture and of the Application Architecture separately,
resulting in a fine-grain assessment of the overall EA. As can
be seen, Phases B, and D encompass the same overall steps to
develop the business, information systems and technologies
architecture respectively.
VI. EVALUATION
The evaluation step is a substantial element of DSR. Thereby
it is necessary to show the “utility, quality, and efficacy of a
design artifact” [38] To conform to these requirements we
followed a multi-perspective evaluation approach consisting
of two stages (1) Checking CSF Compliance; (2) Check
TOGAF ADM Coverage. The first step focuses on checking if
the ADM, considers each CSF. The second focuses on
whether the maturity model takes into consideration all the
phases and steps of the ADM. In this case, according to T.
Mettler [20], the subject of evaluation is the design product,
the time-frame is Ex-ante, and the evaluation method is
artificial. The EA Maturity Model takes into consideration all
the phases of the TOGAF ADM and as result covers all the
guidance in the TOGAF ADM that in turn makes it compliant
with all the CSF detailed in Section IV for the reasons detailed
further on this section for each of the CSF. Depicted in Table
3 are the ADM phases covered by the maturity model, as well
as, an assessment of the fit of each CSF using the same scale
used for comparing the existing EA maturity models in section
IV. Using the same scale used in section IV, the maturity
model proposed in this paper reach a score of 44 and has an
average of 4 for the CSF fit meaning there is a high degree of
alignment between the CSF and the maturity model.
The CSF01 focus on the communication and common
language aspects of the EA. This is an aspect that is taken into
consideration in the ADM in various phases. Since the
preliminary phase communication between the EA team and
relevant stakeholders is established. Common language is also
one of the main goals when developing an EA per the ADM.
For example, in phase A there should be a common definition
of all the principles.
CSF02 focus on a business-driven approach to the lifecycle
management of an EA. The whole ADM focus on constantly
checking if the architecture is relevant for the business, and
focus on constantly obtaining approval for several aspects of
the architecture from the relevant business stakeholders.
CSF03 focus on commitment, as stated previously the ADM
constantly checks for commitment from the relevant
stakeholders of the organization across all the phases of ADM.
CSF04 focus on the development methodology and tool
support. The ADM itself is a development method for an EA
and defines a set of steps and guidance to develop a relevant
EA. Throughout the ADM there are several steps, which
purpose is to identify if the organization selects relevant
resources and viewpoints, as well as, appropriate tools and
techniques that can be used to support the design and
implementation of the EA, as for example in phases B to D.
CSF05 emphases on the EA models and artifacts. As example
when developing the different architectures in phases B to D
there are steps where the organization must identify the
required diagrams that present the architecture information
from deferent viewpoints per the requirements of stakeholders.
There are also steps where the organization must select
relevant reference models to support the design and
implementation of the EA.
CSF06 focuses on the EA Governance. In the ADM, there is a
whole phase where implementation governance of the EA is
considered (Phase G). This phase aim is to establish
architecture governance functions for the EA. Then the Phase
H ensures that the EA Governance function is correctly
executed and monitored. CSF07 focuses on the project and
program management. The ADM provides guidance on how to
implement an architecture project, which aim is to improve on
the baseline architecture towards the defined target
architecture. This architecture project is developed in phase A
and used throughout the ADM. CSF08 focuses on assessment
and evaluation. The ADM takes into consideration assessment
and evaluation since phase A where a business capability
evaluation must be performed. Then during the following
phases there are several aspects that are assessed and
evaluated, as an example, during all the phases of ADM and
regarding the requirements management phase there must be a
changed requirements assessment and impact assessment.
CSF09 focuses on the IT investment and acquisition strategies.
The ADM considers investment strategies in the architecture
change management phase where the change implementation
process takes into consideration investments needed to
implement changes in the baseline architecture.
CSF10 focuses on the skilled team, training and evaluation.
Since the preliminary phase the ADM states that the
organization defines and establishes an EA Team with the
relevant skills and training necessary for the architecture
project. This aspect is also considered in phase G.
Finally, CSF11 focuses on the organizational culture. The
organizational culture is considered throughout the ADM, for
example when the organizational context is defined and the
architecture tools are selected in the preliminary phase, and
when the key corporate change attributes are determined in
phase E.
VII. CONCLUSION
The aim of this paper is the development of a maturity model
for EA. The latter can serve as a governance instrument that
could be used by an organization to analyze and evaluate the
current strengths and weaknesses of EA lifecycle
management. However, the model is not restricted to
analytical purposes only. It can also be used to derive a
roadmap towards an evolutionary improvement of EA
lifecycle management regarding its capabilities and its
effectiveness and efficiency. The first part of the paper
elaborates the CSF, which were used as a reference baseline to
investigate whether existing maturity models are capable of
holistically assessing an EA [RQ1]. The findings revealed that
existing maturity models cover the entire reference baseline
insufficiently, since they only selectively address the CSF.
Hence, no existing maturity model can solve the identified
problem. Finally, we decided to design a new maturity model
in consistency to the defined research strategy. In the second
part of the paper, we described the development of a maturity

Table 3. EA Maturity Model ADM Coverage and CSF matrix fit

ADM Phase Covered CSF01 CSF02 CSF03 CSF04 CSF05 CSF06 CSF07 CSF08 CSF09 CSF10 CSF11
Preliminary Yes X X X X X X X X X
A Yes X X X X X X X X X
B Yes X X X X X X X X X X X
C Yes X X X X X X X X X X X
D Yes X X X X X X X X X X X
E Yes X X X X X
F Yes X X X X X X X X X
G Yes X X X X X X X X X X X
H Yes X X X X X X X
Requirements
Yes X X X X X
Management
Fit Score per CSF 4 4 3 3 4 4 5 5 3 4 5
model for EA lifecycle management based on TOGAF ADM,
including the model itself as well as its evaluation to address
the second research question: “How could a maturity model
specific to EA be designed that targets the challenges of EA
lifecycle management across different types of organizations
and industries” [RQ2]. The developed model is based on
existing maturity model structures and inherits concepts and
methods of the EA domain. Our aim during the development
of the Maturity Model was to provide a consumable research
result. Logically, the applied research approach comes along
with certain limitations. First, the maturity model was
designed and evaluated with the focus to assess and evaluate
EA lifecycle management procedures that follow the TOGAF
ADM, the most recognized EA Development Method by the
EA community. To extend the research component, we
suggest evaluating (and refining) the maturity model within
different industry sectors to gather an insight of what EA
methods and procedures different industries are using and how
far in the maturity scale they are. This would lead to a more
generic EA maturity model and would enable cross-industry
benchmarking.
REFERENCES
[1] J. Luftman, "Assessing business-IT alignment maturity,"
Communications of the Association for Information Systems, vol. 4,
2000.
[2] J. Scott, I. Vessey, "Managing risks in enterprise systems
implementations," Commun. ACM, vol. 45, pp. 74-81, 2002.
[3] J. Luftman, "Enablers and inhibitors of business-IT alignment,"
Communications of the Association for Information Systems, vol. 1,
1999.
[4] M. Lankhorst, Enterprise Architecture at Work: Modeling,
Communication, and Analysis. Springer, 2005.
[5] J. Zachman, "Enterprise architecture: The issue of the century,"
Database Programming and Design, vol. 10, pp. 44-53, 1997.
[6] R. Nolan, "Managing the Computer Resource: A Stage Hypothesis",
Communications of the ACM, vol. 16, pp. 399-405, 1973.
[7] D. Ahern, A. Clouse, R. Turner, “CMMI Destilled: A Pratical
Introduction to Integrated Process Improvement, Third Edition,” Addson
Wesley Professional, 2008.
[8] ISO/IEC 15504:2004, “Information technology - Process assessment,”
International Organization for Standardization and International
Electrotechnical Commission Std. 2004.
[9] D. Greefhorst, E. Proper, Architecture Principles. Springer-Verlag
Berlin Heidelberg, 2011.
[10] J. Zachman. A framework for information systems architecture. IBM
Systems Journal, 12(6):276–292, 1987.
[11] The Open Group. TOGAF Version 9. Van Haren Publishing, 2009.
[12] J. Ross, P. Weill, D. Robertson, Enterprise Architecture as Strategy:
Creating a Foundation for Business Execution, Harvard Business
Review Press, 256pp, ISBN:978-1591398394, August, 2006.
[13] M. Mayer, E. Rechtin, The Art of Systems Architecting. CRC Press,
472pp, ISBN:978-1420079135, 2nd edition, January 2009.
[14] J. Schekkerman, How to Survive in the Jungle of Enterprise Architecture
Frameworks: Creating or Choosing an Enterprise Architecture
Framework, Trafford Publishing, 2006.
[15] M. Op’t Land, E. Proper, M. Waage, J. Cloo, C. Steghuis, Enterprise
Architecture - Creating Value by Informed Governance, Springer-Verlag
Berlin Heidelberg (The Enterprise Engineering Series), 2009.
[16] K. Peffers, T. Tuunanen, M. Rothenberger, S. Chatterjee, “A design
science research methodology for information systems research,”
Journal of Management Information Systems, vol. 24, pp. 45–77, 2008.
View publication stats
[17] T. Mettler, P. Rohner, R. Winter, "Towards a Classification of Maturity
Models in Information Systems," In A. D'Atri, M. De Marco, A. M.
Braccini and F. Cabiddu: Management of the Interconnected World,
Physica-Verlag, Heidelberg, 2010.
[18] J. Poeppelbuss, B. Niehaves, A. Simons, J. Becker, "Maturity Models in
Information Systems Research: Literature Search and Analysis,"
Communications of the Association for Information Systems, vol. 29,
2011.
[19] M. Röglinger, J. Pöppelbuß, “What makes a useful maturity model? A
framework for general design principles for maturity models and its
demonstration in business process management,” In proceedings of the
19th European Conference on Information Systems, Helsinki, Finland,
June. 2011.
[20] T. Mettler, “A design science research perspective on maturity models in
information systems,” St. Gallen: Institute of Information Management,
Universtiy of St. Gallen. 2009.
[21] A. Maier, J. Moultrie, P. Clarkson, “Assessing Organizational
Capabilities: Reviewing and Guiding the Development of Maturity
Grids,” In IEEE transactions on engineering management, vol. 59, no. 1.
2012.
[22] J. Becker, R. Knackstedt, J. Pöppelbuβ, “Developing maturity models
for IT management: A procedure model and its application,” Business
and Information Systems Engineering, Vol. 3, pp 213-222. 2009.
[23] A. Hevner, S. Ram, S. March, J. Park, "Design Science in Information
Systems Research," MISQ, vol. 28, pp. 75-105, 2004.
[24] J. Vom Brocke, "Design Principles for Reference Modeling-Reusing
Information Models by Means of Aggregation, Specialization,
Instantiation, and Analogy," In P. Fettke and P. Loos: Reference
modeling for business systems analysis, Idea Group Inc., Hershey, 2007.
[25] C. Bullen, J. Rockart, "A primer on critical success factors," Center for
Information System Research, Sloan School of Management,
Massachussets Institute of Technology, City, 1981.
[26] J. Rockart, "Chief executives define their own data needs," Harvard
Business Review, vol. 57, 1979.
[27] D. Baker, M. Janiszewski, 7 Essential Elements of EA, Fawcette
Technical Publications (FTP), 2006.
[28] T. Ylimaki, "Towards Critical Success Factors For Enterprise
Architecture," AISA Project Report, University of Jyvaskyla, 2006.
[29] T. Ylimaki, "Potential Critial Success Factors for Enterprise
Architetcure," Journal of Enterprise Architetcure, vol. 2, pp. 29-40,
2006.
[30] A. Perkins, "Critical Success Factors for Enterprise Architetcure
Engineering," Visible Solution, Technical Report, 2003.
[31] H. Al-Kharusi, S. Miskon, M. Bahari, "Factors Influencing The
Engagement Between Enterprise Architects And Stakeholders In
Enterprise Architecture Development," In Proceedings of the Pacific
Asia Conference in Information Systems (PACIS 2016), 2016.
[32] NASCIO, NASCIO Enterprise Architecture Maturity Model, National
Association of State Chief Information Officers, 2003.
[33] United States Department of Commerce, Enterprise Architecture
Capability Maturity Model, Version 1.2, 2007.
[34] Institute For Enterprise Architecture Developments, Extended Enterprise
Architecture Maturity Model - Support Guide, Version 2.0, 2006.
[35] The Open Group, "When Was Your Last Enterprise Architecture
Maturity Assessment," 2012. [Online] Available:
https://blog.opengroup.org/2012/03/02/when-was-your-last-enterprise-
architecture-maturity-assessment/
[36] United States Goverment Accounbtability Office, Organizational
Transformation - A Framework for Assessing and Improving Enterprise
Architetcure, Version 2.0, 2010.
[37] M. Steenbergen, M. Berg, S. Brinkkemper, "A Balanced Approach to
Devloping the Enterprise Architetcure Practice," In Proceedings of
ICEIS 2007, pp. 240-253, 2008.
[38] A. Hevner, S. Chatterjee, “Design Research in Information Systems:
Theory and Practice,” Springer, Heidelberg, 2010.