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

29 12,600

2 authors:

Diogo Proença José Borbinha

Inesc-ID University of Lisbon
34 PUBLICATIONS 478 CITATIONS 201 PUBLICATIONS 1,633 CITATIONS

SEE PROFILE SEE PROFILE

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) Authors Name/s per 2nd Affiliation (Author)
line 1 (of Affiliation): dept. name of organization line 1 (of Affiliation): dept. name of organization
line 2-name of organization, acronyms acceptable line 2-name of organization, acronyms acceptable
line 3-City, Country line 3-City, Country
line 4-e-mail address if desired line 4-e-mail address if desired

Abstract— Ensuring the alignment between IT and business communication as a major factor. Enterprise architecture (EA)
can be a difficult challenge. That is the reason why the Enterprise tries to harness the benefits of using architectures to attack the
Architecture domain exists, to provide guidance on how to better business-IT alignment problem. Lankhorst defines EA as “a
align Business and IT. There are several methods in existence coherent whole of principles, methods, and models that are
that guide an organization in developing its Enterprise
used in the design and realization of an enterprise’s
Architecture. However, putting these methods in practice can
become a huge project. The purpose of this paper is to develop a organizational structure, business processes, information
maturity model for Enterprise Architecture in organizations as a systems, and infrastructure" [4], with a “focus on alleviating
governance instrument to analyze and evaluate the current state the infamous business-information technology alignment
of affairs, as well as, identify possible areas for improvement. In problem” [4]. EA practice involves the creation of models
this way, maturity models facilitate the evolutionary describing an enterprise, including business and IT elements,
reengineering of all functions related with the lifecycle of an so that it can realize management requirements and be
Enterprise Architecture as they allow benchmarking assessment maintained over the period of its useful life [5]. EA practice
and roadmap planning to be performed. The development of this also involves the use of EA frameworks that guide the
maturity model is based on design science research grounded in
architecture work, providing an underlying structure for
current literature. By collecting the critical success factors of
Enterprise Architecture and evaluating the existent maturity architecture descriptions.
models for this domain the conclusion is that there is no maturity
model that fully considers all these critical factors. The maturity Current EA literature shows a focus on refining existing
model proposed in this paper is evaluated through a multi-step methods. One shortcoming is the attention towards the arising
perspective that is used to confirm that the maturity model challenges of applying EA concepts to specific organizational
makes a useful and novel contribution to the enterprise environments. There are still no common adequate
architecture domain by taking in consideration the best practice instruments for assessing the current state and identifying
and critical success factors of the domain. opportunities for improvement. Thus, organizations are often
Keywords— Enterprise Architecture, Maturity Model,
unsure about where to start in improving their EA
Measurement, Performance, Design. management procedures.

The objective of this paper is to develop an artifact (the

I. INTRODUCTION
maturity model) by using a research approach to address the
The process of business and IT alignment can be described as practical problem described previously and contribute to the
the application of Information Technology (IT) in an body of knowledge at the same time. Therefore, Design
“appropriate and timely way, in harmony with business Science Research (DSR) was chosen as it combines both
strategies, goals and needs” [1]. However, maintaining the perspectives, the practical and scientific dimensions. The
alignment is not an easy task. Organizations inhabit unstable maturity model focuses on the EA body of knowledge to
environments, at the competitive, collaborative, and define EA maturity levels. In this paper, we focus on the
cooperative levels, which might directly and indirectly affect following two research questions (RQs):
their information systems, imposing new requirements [2].
Consequently, many organizations invest in technology over [RQ1] Can existing maturity models holistically assess the
the years, as business faces new needs, which despite its critical success factors of EA in organizations?
power to “transform and whole industries and markets”, can
have frustrating results [1]. Between the several aspects that [RQ2] How could a maturity model specific to EA be
can influence alignment between business and IT, “IT designed, which targets the challenges of EA lifecycle
understands the business” and “IT does not understand management across different types of organizations and
business" have been listed respectively as enabler and industries?
inhibitor for the alignment [3], which clearly points to
To address these research questions, the paper is structured in information systems with business processes and information.
six sections. First, fundamental terms and concepts will be It supports planning for sustainable change and provides self-
detailed and will be followed by the outline of the research awareness to the organization [11]. In that sense, it aims to
methodology in section III. Further on, section IV presents the provide a complete coverage of the organization. It has
findings from a literature review. Section V elaborates the become a very popular approach to the development of
main insights of the iterative maturity model development and information systems aligned with business strategies [12].
the maturity model itself. Next, the evaluation of the maturity The term “enterprise architecture” has been used to depict a
model is presented in section VI. Lastly, this paper presents process for creating architectures for the enterprise, a
conclusions from this works and details research limitations. framework for classifying architecture artifacts, or both. In [4],
the author defines EA as a coherent whole of principles,
II. FOUNDATION methods, and models that are used in the holistic design and
To ensure a common understanding, we explain in this section realization of an enterprise’s organizational structure, business
the key terms and concepts, such as, “maturity model”, and processes, information systems and infrastructure. Another
“Enterprise Architecture”. definition refers to EA frameworks as a way for defining what
products the architecture must deliver and how those products
A Maturity Model is a technique that has been proved to be must be constructed [13]. It can also be defined as a “complete
valuable in measuring different aspects of a process or an expression of the enterprise”, or a “master plan”, which aligns
organization. It represents a path towards increasingly aspects of business planning, business operation, aspects of
organized and systematic way of doing business in automation, and the technological infrastructure, which
organizations. A Maturity Model consists of several “maturity enables all the other aspects, capturing a vision of the “entire
levels”, often five, from the lowest to the highest, Initial, organization” [14].
Managed, Defined, Quantitatively Managed and Optimizing There are various best practice guidance frameworks for EA,
(however, the number of levels can vary, depending on the some of the most known are TOGAF [11] and the Zachman
domain and the concerns motivating the model). This Framework [10].
technique provides organizations: (1) A measuring for Depending on the needs and challenges raised by specific
auditing and benchmarking; (2) A measuring of progress domains and organizations, EA approaches can be used for
assessment against objectives; (3) An understanding of several purposes. In [15], seven key applications for EA are
strengths, weaknesses and opportunities (which can support identified, which are (1) Situation description, (2) Strategic
decision making concerning strategy and project portfolio Direction, (3) Gap Analysis, (4) Tactical Planning, (5)
management). Operational Planning, (6) Selection of partial solutions and (7)
MMs history goes back to 1973 [6], and had its maximum Solution Architecture.
visibility with the Software Engineering Institute Capability The Open Group Architecture Framework (TOGAF) [11] is a
Maturity Model Integration (CMMI) [7] and the ISO 15504 high-profile EA, providing methods and tools to support
[8]. Both these key references were born in the Software architecture development. It comprises seven modules that can
Engineering domain, culminating decades of development and be partly used independently of each other. The core of
refinement of the corresponding models. Moreover, there is TOGAF is the Architecture Development Method (ADM) and
certification for these two references as they are considered as the Architecture Content Framework.
the de facto assessment techniques to be used when The ADM is a cyclical process divided in nine phases, as
benchmarking organizations for their software engineering shown in Figure 1. After a preliminary phase in which the
process implementation and maturity. As such, for the results context, relevant guidelines, standards and the architecture
to be comparable, there is a detailed maturity assessment process goal are identified, the main process begins with the
method behind each of these MMs. These methods define in elaboration of an architecture vision and the principles that
detail how an assessment should be planned, conducted, the should guide the architecture. This provides the basis for
maturity levels calculated and how the results must be developing the business architecture, information systems
presented to the organization. These methods make each architecture, and technology architecture.
assessment repeatable and comparable with results from other On this basis, solutions are developed, and migration and
organizations, allowing for benchmarking. implementation are planned and governed. Finally,
Architecture Change Management ensures that the
EA is “The architecture of an enterprise. As such, it concerns architecture continues to be fit for purpose. The ADM can be
those properties of an enterprise that are necessary and adapted for various purposes, and in more complex situations,
sufficient to meet its essential requirements.” [9] It is a holistic the architecture can be scoped and partitioned so that several
approach to systems architecture [10] with the purposes of architectures can be developed and later integrated using an
modeling the role of information systems and technology in instance of the ADM to develop each one of them.
the organization, aligning enterprise-wide concepts and
 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
Figure 1. TOGAF Architecture Development Method (ADM) [11] used model adoption techniques, such as, configuration,
instantiation, aggregation, specialization and analogy [24] to
III. RESEARCH METHODOLOGY incorporate the TOGAF ADM in the maturity model. This
allowed us to create a rigorous maturity model regarding both
To address the RQs raised in this paper, we opted to use a the structure and content. In the last step, evaluation, we
Design Science Research (DSR) paradigm as described in combined the steps of Becker et al. [22], conception of
[16]. DSR can be described by “a designer answering transfer and evaluation, implementation of transfer media, and
questions relevant to human problems via the creation of evaluation, into step 5. All steps will be conducted, but to
innovative artifacts, thereby contributing new knowledge to match the structure of this paper we made this change.
the body of scientific evidence. The designed artifacts are both
useful and fundamental in understanding that problem” [38] In IV. ANALYSIS
this method, research focuses on designing solutions to be To provide a consistent and precise problem definition, we
applied to solve a problem, as opposed to the more descriptive conducted a literature analysis. The aim of this analysis was to
paradigm followed in social and natural sciences. The process identify current challenges, areas where future action is
includes six steps: (1) problem identification and motivation; required, and success factors related with the lifecycle
(2) definition of the solution objectives (3) design and management of an EA. This analysis is therefore based on
development of the solution artefact; (4) demonstration; (5) current literature in the EA domain including research papers,
evaluation; and (6) communication. reports and white papers from both the Academia and
The development of maturity models in the IT and EA practitioners.
domains is not new and has been quite popular in recent years.
As an example, in [17], the authors have identified more than Based on the extended analysis of literature, we identified a
100 maturity models, and in [18] even more are identified. set of several success factors (CSF) for an EA implementation.
However, one major issue can be identified in most these In evaluating each CSF, we relied on the theoretical
maturity models, which is the lack of disclosure of the framework of Rockart [25] [26], which considers CSF as a
development process used to develop them. This leads to a “limited number of areas in which results, if they are
weakness in this research area, which is the lack of satisfactory, will ensure competitive performance for the
contributions regarding how to develop these models. Despite organization”. In a second step, we condensed and verified the
this fact, we have identified some development methods and
procedures for maturity models, such as, the general design
CSF, which we derived from the literature analysis on EA a sound management strategy and strive for tool support by
lifecycle management. using structured, well-defined and documented methods such
An EA should enable effective communication and provide a as, processes, guidelines, best practices and standards. An EA
common language for the enterprise. It should provide a development method directs the creation of EA models and
business-driven approach by proving a linkage between other artifacts, which in turn provide a valuable help in the
business and IT. It should also strive for commitment from the communication of the architecture to the relevant
top management throughout the whole lifecycle. It should use 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
Figure 2. Procedure model of the research approach (adopted models were analyzed according to the degree to which they
from Becker et al. [22]) 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 model we modeled what is the manifestation of that criterion
overview, we concluded that only six maturity models scored at the different maturity levels.
an aggregate of at least 24 points per the defined CSF
reference baseline. Second Iteration: The aim of the second iteration was to build
 NASCIO EA Maturity Model [32]; on the success of the results of the first iteration. Thus, the
 US DoC ACMM Framework (Version 1.2) [33]; maturity model was extended to contemplate all the phases of
 Extended EA Maturity Model (EEAMM) [34]; the TOGAF ADM. As result the phases of the TOGAF ADM
are now seen as dimensions of the maturity model. We also
 OpenGroup Architecture Capability Maturity Model
restructured these phases criteria as in the ADM there is one
(OG ACMM) [35];
phase named Requirements Management, which is connected
 GAO Organizational Transformation – A Framework to all the other phases. As such there are criteria of this phase
for assessing and improving EA Management that must be used to assess all the other phases. We continued
(Version 2.0) [36]; with the approach of the first iteration and modeled each of the
 Architecture Maturity Matrix (AMM) [37]. criteria at each maturity level. We then conducted a trial
Table 1 presents the assessment results of the above as most assessment using the maturity model, which revealed some
significant identified maturity model in details. Based on this issues that will be solved in the third iteration.
set an average total score of 25,5 was achieved (maximum
score 55). Third Iteration: After the trial assessment using the maturity
model one relevant issue was identified. The trial revealed that
V. SYNTHESIS there was a difficulty in understanding the differences in each
In accordance to the maturity model development procedure possible answer for the assessment questions. As an example,
of Becker et al. [22] a new maturity model should be participants could understand what a “documented procedure”
developed, if no existing or the advancement of an existing is but it was difficult for them to understand what is a “defined
one can address the identified problem. So, based on the procedure” or even an “ad-hoc assessed procedure”. This led
findings of our literature analysis there is no maturity model to a revision of the assessment questionnaire and an overhaul
which acceptably fulfills the entire CSF reference baseline. of the maturity model to accommodate the changes to the
Therefore, we decided to develop a new maturity model. assessment questionnaire. The maturity levels definition
remained the same, however there are major changes in the
The newly developed maturity model, presented in Table 2, overall structure of the criteria. Now instead of modelling each
adopts established structural elements, domains and functions criterion at each maturity level we opted by identifying
of the best practice of maturity models analyzed in section 4 capabilities for each maturity level and dimension, which
and is based in TOGAF ADM, which most of the analyzed resulted in an easily understandable maturity model that is
maturity models point for further guidance. These artifacts presented in Table 2. We also realized that by following this
were then extended and adjusted to fit the purpose of assessing approach there were almost no criteria that could be drawn
the maturity of an EA using the guidance from TOGAF ADM. from TOGAF ADM for maturity level 4 and 5. We turned our
As outlined within our research methodology, we applied an attention to the guidance from CMMI, which details a set of
iterative process for the development of this maturity model. process areas for maturity levels 4 and 5 very relevant to
In total, we needed three iterations, which are described in the assessing the maturity of an EA. The criteria from CMMI is
following: used to assess the maturity levels 4 and 5 for all the
dimensions and is detailed under “General”.
First Iteration: As a first step, we identified the basic In addition to the already discussed, maturity levels 1–5, we
characteristics and structure of the model. As a starting point, added level 0, which means that the organization is not
we proposed five maturity levels – Initial, Managed, Defined, executing any EA function or task at all. Therefore, level 0 is
Quantitatively Managed, Optimizing – as this approach is not explicitly mentioned within the EA maturity model.
evident in several reputable maturity models, such as, the Finally, this leads to the following maturity levels:
CMMI [7]. In this initial iteration, we focused in just some  Level 0 – Non-existent EA;
phases of the TOGAF ADM namely the Preliminary Phase  Level 1 – Initial EA;
and the Architecture Vision. For each criterion of the maturity
 Level 2 – Managed EA;
Table 1. CSF reference matrix fit assessment

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; Table 2. EA Maturity Model
 Level 4 – Quantitatively Managed EA;
Dimension: Architecture Capability
 Level 5 – Optimizing EA. ADM Phase: Preliminary
The preparation and initiation activities are not performed. There
To move from level 0 to level 1, the organization needs to be ML1 is no definition of principles and no organization-specific
architecture framework.
aware that EA is needed as a relevant function of the At maturity level 2, the organization:
organization. Furthermore, basic EA tasks are performed with -Identifies the core, soft and extended enterprise units, as well as,
the aim of ensuring Business-IT alignment across the ML2 the communities and governance involved.
organization. - Selects the appropriate architecture tools to support the
architecture function.
At maturity level 2 EA meets its goals. However, there is no In addition to Maturity Level 2, the organization:
standardization of procedures for each phase, which can lead - Defines a framework for architecture governance.
to two people doing different tasks to achieve the same goal - Defines and Establishes an Enterprise Architecture Team and
and in turn can result in the inability to repeat tasks that were Organization.
ML3
- Identifies and establishes the Architecture principles, which are
previously performed. Moreover, at this maturity level there is the set of principles that relate to architecture work.
no assignment of responsibilities. - Determines what tailoring of TOGAF and other selected
Then at maturity level 3, the organization has a standardized architecture frameworks is required.
list of procedures for each phase with responsibilities assigned ADM Phase: A - Architecture Vision
for these procedures. There are also tools and methods that The architecture scope is not defined, the stakeholders are not
ML1 identified, there is no architecture vision and no approvals are
support the lifecycle management of the EA, which are agreed obtained.
upon and become a standard across the organization. At maturity level 2, the organization:
Procedures at this maturity level are well defined and include - Identifies the key stakeholders and their concerns or objectives,
its purpose, inputs, entry criteria, activities, roles, verification and describe the key business requirements to be addressed in the
architecture project.
steps, outputs and exit criteria. There is also an understanding ML2 - Identifies and evaluates the collection of capabilities within the
of the interrelationships between the various phases of the organization.
ADM. - Evaluates and qualifies the organization readiness to undertake
At maturity level 4 the organization establishes quantitative change.
- Identifies the risks associated with the architecture vision.
objectives for quality and performance of all functions related In addition to Maturity Level 2, the organization:
with EA. Specific measures of performance are collected and - Conducts the necessary procedures to secure recognition of the
are analyzed using statistical and other quantitative architecture project, the endorsement of corporate management,
techniques. There are also performance baselines and models and the support and commitment of the necessary line
management.
that help in setting quality objectives. A key difference - Identifies the business goals and business drivers, as well as, the
between maturity levels 3 and 4 is the predictability of constraints that must be dealt with.
performance as predictions are based on the statistical analysis - Defines what is inside the scope of the baseline and target
of fine-grain information. ML3 architecture
- Reviews the principles under which the architecture will be
Finally, at Maturity Level 5 the organization continually developed.
improves its EA functions based on quantitative analysis of - Develops an architecture vision that covers the extent of the
the business objectives and performance baselines. It uses scope identified for the architecture project, at a high level.
quantitative techniques to understand variations in procedures - Defines the value propositions and KPIs for the target
architecture to be developed within the project.
and the causes of outcomes. It also focuses on continually - Defines the work products to be produced, as well as, deadlines
improving performance using incremental and innovative for each of these work products.
procedures. Additionally, the quality and performance Dimension: Architecture Development
objectives are established and continuously revised to reflect ADM Phase: B, C, D – Business, Information Systems and Technology
changing business objective and the organization’s Architecture
There is no Architecture developed that supports the Architecture
performance. A key difference between maturity level 4 and 5 ML1
Vision
is the focus on improving and managing the organization At maturity level 2, the organization:
performance, which at this level is concerned in analyzing - Identifies the catalogues that capture inventories of the core
performance using data collected from multiple projects. This assets of the business.
- Identifies the required matrices that show the core relationships
data helps identify gaps and weak points in performance that between related model entities.
are then used to generate a measurable improvement. - Identifies the required diagrams that present the business, data,
To improve from level X to level X+1, the organization must application and technology architecture information from deferent
comply with all the criteria from level X, which makes this ML2 viewpoints according to the requirements of stakeholders.
- Formalizes the business, data, application and technology
maturity model follow a “stages” approach. What an requirements for implementing the target architecture.
organization can expect from progressing through the maturity - Develops a Baseline Description of the current business, data,
levels is that their EA lifecycle management practice will application and technology Architecture to the extent necessary to
become increasingly managed, defined and optimized. This in support the target business architecture.
- Identifies and resolves any wide impacts or implications in the
turn results in a better alignment between the Business and IT Architecture Landscape.
functions. In Table 2 “ML” stands for “Maturity Level”. ML3 In addition to Maturity Level 2, the organization:
 - Selects relevant business, data, application and technology the organizations change management and implementation
architecture resources and viewpoints, as well as, appropriate approach. The business value and cost of work packages and
tools and techniques. Transition Architectures is not understood by stakeholders.
- For each viewpoint, selects the models needed to support the At maturity level 2, the organization:
specific view required, using the selected tool or method. - Establishes and assigns business values to all of the work
- Develops a target description for the business, data, application packages.
and technology architecture to be developed, to the extent ML2 - Determines the required resources and times for each project
necessary to support the Architecture vision. and their increments and provides the initial cost estimates.
- Verifies the business, data, application and technology - Transitions governance from the development of the architecture
architecture models for internal consistency and accuracy by to the realization of the architecture.
identifying gaps between the baseline and target business In addition to Maturity Level 2, the organization:
architecture. - Coordinates the Implementation and Migration Plan with the
- Defines a business, data, application and technology roadmap to management frameworks within the organization.
prioritize activities over the following phases. - Prioritizes the projects by ascertaining their business value
- Reviews if the proposed business, data, application and ML3 against the cost of delivering them.
technology architecture is capable of supporting the subsequent - Updates the Architecture Roadmap including any Transition
work by checking the original motivation for the architecture Architectures and confirms the architecture definition in case the
project and the statement of architecture work against the implementation approach shifted.
proposed architecture. - Generates the completed Implementation and Migration Plan.
- Finalizes the business, data, application and technology Dimension: Architecture Governance
architecture after conducting a formal stakeholder review by ADM Phase: G – Implementation Governance
documenting all the final requirements, mappings and work There is no oversight of the implementation of the target
products. ML1 architecture, the deployment resources and priorities are not
- Documents the architecture definition and also reviews the identified, and compliance reviews are not performed.
resulting document with relevant stakeholders and incorporates At maturity level 2, the organization:
feedback. - Identifies system development methods required for solutions
Dimension: Transition Planning development and ensures that the systems development method
ADM Phase: E – Opportunities & Solutions enables feedback to the architecture team on designs.
The delivery approaches, such as, projects, programs or portfolios ML2
- Carries out the deployment projects; and publishes new Baseline
ML1 are not identified, which results in the organization not being able Architectures to the Architecture Repository and update other
to deliver the target architecture identified in the previous phases. impacted repositories, such as operational configuration
At maturity level 2, the organization: management stores.
- Identifies any business drivers that would constrain the In addition to Maturity Level 2, the organization:
implementation sequence. - Confirms the Scope and Priorities for Deployment with
- Consolidates the interoperability requirements identified in Development Management.
previous phases. - Guides the Development of Solutions Deployment.
- Refines the initial dependencies, ensuring that any constraints on ML3 - Reviews ongoing implementation governance and architecture
the Implementation and Migration Plans are identified. compliance for each building block; conducts post-development
ML2
- Reviews the findings of the Business Transformation Readiness reviews; and closes the development part of deployment projects.
Assessment previously conducted in Phase A and determine their - Conducts post-implementation reviews; and publishes reviews
impact on the Architecture Roadmap and the Implementation and and close projects.
Migration Strategy. ADM Phase: H – Architecture Change Management
- Creates an overall Implementation and Migration Strategy that The procedures that manage change to the target architecture are
will guide the implementation of the Target Architecture, and ML1 not established, there are no risk management procedures and
structure any Transition Architectures. monitoring tools in place.
In addition to Maturity Level 2, the organization: At maturity level 2, the organization:
- Determines how the enterprise architecture can be best - Manages the governance process and framework for the
implemented to take advantage of the organization’s business ML2
architecture.
culture. This should include the creation of an Implementation - Activates the architecture process to implement change.
Factor Assessment and Deduction matrix. In addition to Maturity Level 2, the organization:
- Consolidates and integrates the gap analysis results from the - Influences business projects to exploit the EA for value
Business, Information Systems, and Technology Architectures ML3 realization (outcomes).
(created in Phases B to D) and assess their implications with - Manages EA risks and provides recommendations for IT
respect to potential solutions and inter-dependencies. strategy.
- Assesses the requirements, gaps, solutions, and factors to In addition to Maturity Level 3, the organization:
identify a minimal set of requirements whose integration into - Ensures that monitoring tools are deployed and applied.
work packages would lead to a more efficient and effective ML4 - Provides analysis for architecture change management.
ML3
implementation of the Target Architecture across the business - Makes recommendations on change requirements to meet
functions that are participating in the architecture. performance targets and development of position to act.
- Assesses the missing business capabilities identified in the
Dimension: Architecture Requirements Management
Architecture Vision and Target Architecture and logically group
Requirements management is not sustained and does not operate
the various activities into work packages.
for all ADM phases, the architecture requirements are not
- Identifies one or more Transition Architectures where the scope
ML1 identified and managed during the execution of the ADM. The
of change to implement the Target Architecture requires an
relevant architecture requirements are not available for use at
incremental approach.
each phase of the ADM.
- Consolidates the work packages and Transition Architectures
At maturity level 2, the organization:
into the Architecture Roadmap, which describes a timeline of the
- Identifies the changed requirements and records the priorities.
progression from the Baseline Architecture to the Target
- Updates the Requirements Repository with information relating
Architecture. ML2
to the changes requested, including stakeholder views affected.
ADM Phase: F – Migration Planning
- Identifies and documents requirements using business scenarios,
ML1 The Implementation and Migration Plan is not coordinated with or an analogous technique.
 - Identifies changed requirements. architecture requirements across the ADM. This is a special
- Determines whether to implement change, or defer to later phase as phases A to H interact with this phase and that is the
ADM cycle; if decision is to implement, assesses timescale for
change management implementation. reason for this phase to be in the center of the ADM in Figure
In addition to Maturity Level 2, the organization: 1. This led to a distinction between assessment criteria. There
- Ensures that all key participants agree on the detailed are specific criteria for requirements management that phases
description of the requirements, and commit to execute them A to H must take into consideration to be compliant with the
accordingly.
- Monitors the baselined requirements. ADM. This means that the maturity assessment results for
- Assesses and revises gap analysis performed during Phases B these phases will take into consideration the results for these
ML3
through D, which identify the gaps between Baseline and Target criteria to calculate the maturity level for each of these phases.
Architectures. Finally, there are also specific criteria used to assess the
- Assesses impact of changed requirements on the current (active)
phase. maturity level of the requirements management phases and is
- Assesses impact of changed requirements on the previous not taken in consideration when assessing the other ADM
phases. phases. The TOGAF ADM details the development process
- Issues at every phase of the ADM cycle a requirements impact for an EA and does not go into the specific details on how to
statement.
In addition to Maturity Level 3, the organization:
quantitatively manage and optimize this process. As result,
- Ensures that new or changing requirements that are derived from there is no guidance that could be used for maturity levels 4
ML4
Architecture Change Management (Phase H) are managed and 5. This lead us to gather guidance for these maturity levels
accordingly. from the SEI CMMI [7], which defines in generic terms what
Dimension: General
is a process at maturity level 4 and 5. We adapted this
For all dimensions, in addition to Maturity Level 3, the
organization: guidance and created criteria to assess an EA at these higher
- Establishes the objectives for quality and process performance maturity levels, detailed in Table 2 under the “General”
and negotiates at an appropriate level of detail to permit an dimension, for all the phases of the ADM.
overall evaluation of the objectives and risks at the process level. Additionally, in Table 2, phases B, C and D of the ADM are
- Selects measures and analytic techniques to be used in
ML4 quantitative management. combined into a single phase to ease the understanding of the
- Analyses selected measures to characterize the performance of Maturity Model. However, these three phases are assessed
the organizations’ processes. independently. This means that the Maturity Model can assess
- Establishes and compares process performance baselines to the the maturity of phase B, phase C and phase D separately.
organization’s quality and process performance objectives to
determine if the quality and process performance objectives are Moreover, we have decomposed the phase C into two sub-
being achieved. phases, to allow for the assessment of the maturity of the Data
For all dimensions, in addition to Maturity Level 4, the Architecture and of the Application Architecture separately,
organization: resulting in a fine-grain assessment of the overall EA. As can
- Identifies potential areas for improvement that could contribute
to meeting business objectives. be seen, Phases B, and D encompass the same overall steps to
- Selects and implements improvements for deployment develop the business, information systems and technologies
throughout the organization based on an evaluation of costs, architecture respectively.
benefits, and other factors.
ML5
- Evaluates the effects of deployed improvements on quality and VI. EVALUATION
process performance using statistical and other quantitative
techniques. The evaluation step is a substantial element of DSR. Thereby
- Systematically determines the root causes of selected and it is necessary to show the “utility, quality, and efficacy of a
analyzed outcomes. design artifact” [38] To conform to these requirements we
- Implements and evaluates selected action proposals developed
in causal analysis. followed a multi-perspective evaluation approach consisting
of two stages (1) Checking CSF Compliance; (2) Check
The Maturity Model is structured in a set of dimensions. These TOGAF ADM Coverage. The first step focuses on checking if
dimensions aggregate phases which work together towards a the ADM, considers each CSF. The second focuses on
common purpose and is inspired by the iteration cycles of the whether the maturity model takes into consideration all the
ADM [11]. The first dimension is the Architecture Capability phases and steps of the ADM. In this case, according to T.
that has the phases that “support the creation and evolution of Mettler [20], the subject of evaluation is the design product,
the required Architecture Capability” [11] includes the the time-frame is Ex-ante, and the evaluation method is
Preliminary Phase and Phase A. The second is the artificial. The EA Maturity Model takes into consideration all
Architecture Development, that has the phases that “allow the the phases of the TOGAF ADM and as result covers all the
creation of the architecture content” [11] includes phases B, C guidance in the TOGAF ADM that in turn makes it compliant
and D. The third is the transition planning that include phases with all the CSF detailed in Section IV for the reasons detailed
that “support the creation of formal change roadmaps” [11] further on this section for each of the CSF. Depicted in Table
includes phases E and F. The fourth dimension is Architecture 3 are the ADM phases covered by the maturity model, as well
Governance that includes the Phases that “support governance as, an assessment of the fit of each CSF using the same scale
of change activity” [11] includes Phases G and H. The fifth used for comparing the existing EA maturity models in section
dimension includes only the “Requirements Management” IV. Using the same scale used in section IV, the maturity
phase, a special phase, which goal is to manage the 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 and used throughout the ADM. CSF08 focuses on assessment
alignment between the CSF and the maturity model. and evaluation. The ADM takes into consideration assessment
The CSF01 focus on the communication and common and evaluation since phase A where a business capability
language aspects of the EA. This is an aspect that is taken into evaluation must be performed. Then during the following
consideration in the ADM in various phases. Since the phases there are several aspects that are assessed and
preliminary phase communication between the EA team and evaluated, as an example, during all the phases of ADM and
relevant stakeholders is established. Common language is also regarding the requirements management phase there must be a
one of the main goals when developing an EA per the ADM. changed requirements assessment and impact assessment.
For example, in phase A there should be a common definition CSF09 focuses on the IT investment and acquisition strategies.
of all the principles. The ADM considers investment strategies in the architecture
CSF02 focus on a business-driven approach to the lifecycle change management phase where the change implementation
management of an EA. The whole ADM focus on constantly process takes into consideration investments needed to
checking if the architecture is relevant for the business, and implement changes in the baseline architecture.
focus on constantly obtaining approval for several aspects of CSF10 focuses on the skilled team, training and evaluation.
the architecture from the relevant business stakeholders. Since the preliminary phase the ADM states that the
CSF03 focus on commitment, as stated previously the ADM organization defines and establishes an EA Team with the
constantly checks for commitment from the relevant relevant skills and training necessary for the architecture
stakeholders of the organization across all the phases of ADM. project. This aspect is also considered in phase G.
CSF04 focus on the development methodology and tool Finally, CSF11 focuses on the organizational culture. The
support. The ADM itself is a development method for an EA organizational culture is considered throughout the ADM, for
and defines a set of steps and guidance to develop a relevant example when the organizational context is defined and the
EA. Throughout the ADM there are several steps, which architecture tools are selected in the preliminary phase, and
purpose is to identify if the organization selects relevant when the key corporate change attributes are determined in
resources and viewpoints, as well as, appropriate tools and phase E.
techniques that can be used to support the design and
implementation of the EA, as for example in phases B to D. VII. CONCLUSION
CSF05 emphases on the EA models and artifacts. As example The aim of this paper is the development of a maturity model
when developing the different architectures in phases B to D for EA. The latter can serve as a governance instrument that
there are steps where the organization must identify the could be used by an organization to analyze and evaluate the
required diagrams that present the architecture information current strengths and weaknesses of EA lifecycle
from deferent viewpoints per the requirements of stakeholders. management. However, the model is not restricted to
There are also steps where the organization must select analytical purposes only. It can also be used to derive a
relevant reference models to support the design and roadmap towards an evolutionary improvement of EA
implementation of the EA. lifecycle management regarding its capabilities and its
CSF06 focuses on the EA Governance. In the ADM, there is a effectiveness and efficiency. The first part of the paper
whole phase where implementation governance of the EA is elaborates the CSF, which were used as a reference baseline to
considered (Phase G). This phase aim is to establish investigate whether existing maturity models are capable of
architecture governance functions for the EA. Then the Phase holistically assessing an EA [RQ1]. The findings revealed that
H ensures that the EA Governance function is correctly existing maturity models cover the entire reference baseline
executed and monitored. CSF07 focuses on the project and insufficiently, since they only selectively address the CSF.
program management. The ADM provides guidance on how to Hence, no existing maturity model can solve the identified
implement an architecture project, which aim is to improve on problem. Finally, we decided to design a new maturity model
the baseline architecture towards the defined target in consistency to the defined research strategy. In the second
architecture. This architecture project is developed in phase A 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, [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.
including the model itself as well as its evaluation to address Braccini and F. Cabiddu: Management of the Interconnected World,
the second research question: “How could a maturity model Physica-Verlag, Heidelberg, 2010.
specific to EA be designed that targets the challenges of EA [18] J. Poeppelbuss, B. Niehaves, A. Simons, J. Becker, "Maturity Models in
lifecycle management across different types of organizations Information Systems Research: Literature Search and Analysis,"
and industries” [RQ2]. The developed model is based on Communications of the Association for Information Systems, vol. 29,
2011.
existing maturity model structures and inherits concepts and
[19] M. Röglinger, J. Pöppelbuß, “What makes a useful maturity model? A
methods of the EA domain. Our aim during the development framework for general design principles for maturity models and its
of the Maturity Model was to provide a consumable research demonstration in business process management,” In proceedings of the
result. Logically, the applied research approach comes along 19th European Conference on Information Systems, Helsinki, Finland,
with certain limitations. First, the maturity model was June. 2011.
designed and evaluated with the focus to assess and evaluate [20] T. Mettler, “A design science research perspective on maturity models in
information systems,” St. Gallen: Institute of Information Management,
EA lifecycle management procedures that follow the TOGAF Universtiy of St. Gallen. 2009.
ADM, the most recognized EA Development Method by the [21] A. Maier, J. Moultrie, P. Clarkson, “Assessing Organizational
EA community. To extend the research component, we Capabilities: Reviewing and Guiding the Development of Maturity
suggest evaluating (and refining) the maturity model within Grids,” In IEEE transactions on engineering management, vol. 59, no. 1.
2012.
different industry sectors to gather an insight of what EA
[22] J. Becker, R. Knackstedt, J. Pöppelbuβ, “Developing maturity models
methods and procedures different industries are using and how for IT management: A procedure model and its application,” Business
far in the maturity scale they are. This would lead to a more and Information Systems Engineering, Vol. 3, pp 213-222. 2009.
generic EA maturity model and would enable cross-industry [23] A. Hevner, S. Ram, S. March, J. Park, "Design Science in Information
benchmarking. Systems Research," MISQ, vol. 28, pp. 75-105, 2004.
[24] J. Vom Brocke, "Design Principles for Reference Modeling-Reusing
REFERENCES Information Models by Means of Aggregation, Specialization,
Instantiation, and Analogy," In P. Fettke and P. Loos: Reference
[1] J. Luftman, "Assessing business-IT alignment maturity,"
modeling for business systems analysis, Idea Group Inc., Hershey, 2007.
Communications of the Association for Information Systems, vol. 4,
2000. [25] C. Bullen, J. Rockart, "A primer on critical success factors," Center for
Information System Research, Sloan School of Management,
[2] J. Scott, I. Vessey, "Managing risks in enterprise systems
Massachussets Institute of Technology, City, 1981.
implementations," Commun. ACM, vol. 45, pp. 74-81, 2002.
[26] J. Rockart, "Chief executives define their own data needs," Harvard
[3] J. Luftman, "Enablers and inhibitors of business-IT alignment,"
Business Review, vol. 57, 1979.
Communications of the Association for Information Systems, vol. 1,
1999. [27] D. Baker, M. Janiszewski, 7 Essential Elements of EA, Fawcette
Technical Publications (FTP), 2006.
[4] M. Lankhorst, Enterprise Architecture at Work: Modeling,
Communication, and Analysis. Springer, 2005. [28] T. Ylimaki, "Towards Critical Success Factors For Enterprise
Architecture," AISA Project Report, University of Jyvaskyla, 2006.
[5] J. Zachman, "Enterprise architecture: The issue of the century,"
Database Programming and Design, vol. 10, pp. 44-53, 1997. [29] T. Ylimaki, "Potential Critial Success Factors for Enterprise
Architetcure," Journal of Enterprise Architetcure, vol. 2, pp. 29-40,
[6] R. Nolan, "Managing the Computer Resource: A Stage Hypothesis",
2006.
Communications of the ACM, vol. 16, pp. 399-405, 1973.
[30] A. Perkins, "Critical Success Factors for Enterprise Architetcure
[7] D. Ahern, A. Clouse, R. Turner, “CMMI Destilled: A Pratical
Engineering," Visible Solution, Technical Report, 2003.
Introduction to Integrated Process Improvement, Third Edition,” Addson
Wesley Professional, 2008. [31] H. Al-Kharusi, S. Miskon, M. Bahari, "Factors Influencing The
Engagement Between Enterprise Architects And Stakeholders In
[8] ISO/IEC 15504:2004, “Information technology - Process assessment,”
Enterprise Architecture Development," In Proceedings of the Pacific
International Organization for Standardization and International
Asia Conference in Information Systems (PACIS 2016), 2016.
Electrotechnical Commission Std. 2004.
[32] NASCIO, NASCIO Enterprise Architecture Maturity Model, National
[9] D. Greefhorst, E. Proper, Architecture Principles. Springer-Verlag
Association of State Chief Information Officers, 2003.
Berlin Heidelberg, 2011.
[33] United States Department of Commerce, Enterprise Architecture
[10] J. Zachman. A framework for information systems architecture. IBM
Capability Maturity Model, Version 1.2, 2007.
Systems Journal, 12(6):276–292, 1987.
[34] Institute For Enterprise Architecture Developments, Extended Enterprise
[11] The Open Group. TOGAF Version 9. Van Haren Publishing, 2009.
Architecture Maturity Model - Support Guide, Version 2.0, 2006.
[12] J. Ross, P. Weill, D. Robertson, Enterprise Architecture as Strategy:
[35] The Open Group, "When Was Your Last Enterprise Architecture
Creating a Foundation for Business Execution, Harvard Business
Maturity Assessment," 2012. [Online] Available:
Review Press, 256pp, ISBN:978-1591398394, August, 2006.
https://blog.opengroup.org/2012/03/02/when-was-your-last-enterprise-
[13] M. Mayer, E. Rechtin, The Art of Systems Architecting. CRC Press, architecture-maturity-assessment/
472pp, ISBN:978-1420079135, 2nd edition, January 2009.
[36] United States Goverment Accounbtability Office, Organizational
[14] J. Schekkerman, How to Survive in the Jungle of Enterprise Architecture Transformation - A Framework for Assessing and Improving Enterprise
Frameworks: Creating or Choosing an Enterprise Architecture Architetcure, Version 2.0, 2010.
Framework, Trafford Publishing, 2006.
[37] M. Steenbergen, M. Berg, S. Brinkkemper, "A Balanced Approach to
[15] M. Op’t Land, E. Proper, M. Waage, J. Cloo, C. Steghuis, Enterprise Devloping the Enterprise Architetcure Practice," In Proceedings of
Architecture - Creating Value by Informed Governance, Springer-Verlag ICEIS 2007, pp. 240-253, 2008.
Berlin Heidelberg (The Enterprise Engineering Series), 2009.
[38] A. Hevner, S. Chatterjee, “Design Research in Information Systems:
[16] K. Peffers, T. Tuunanen, M. Rothenberger, S. Chatterjee, “A design Theory and Practice,” Springer, Heidelberg, 2010.
science research methodology for information systems research,”
Journal of Management Information Systems, vol. 24, pp. 45–77, 2008.

View publication stats