A Maturity Model based Roadmap for Implementing TOGAF

A Maturity Model based Roadmap for Implementing
TOGAF
R.W. Gosselt
University of Twente
Deldenerstraat 37-I, 7551AB Hengelo
The Netherlands
r.w.gosselt@student.utwente.nl
ABSTRACT
Almost two third of the enterprise projects result in failure. The
fact that the supporting architecture frameworks are overly
complex is one of the main reasons for this. In this paper we try
to reduce the initial complexity of adopting The Open Group
Architecture Framework (TOGAF), the de facto standard, by
prioritizing and tailoring its implementation based on insights
from architecture maturity models. This should make the initial
dive into the world of enterprise architecture and TOGAF
specifically less daunting.
Keywords
Enterprise Architecture, Maturity models, Maturity assessment,
TOGAF, Architecture Development Method, NASCIO.
1. INTRODUCTION
One of the challenges facing enterprises today is how to cope
with the rapid changes in the business environment and IT
technology [25]. As an enterprise grows in size and complexity,
several factors impede its abilities to solve the problems it
faces. The point is rapidly reached where the factors that come
into play in structuring and conducting the business of the
enterprise become too numerous and complex to manage [9].
As information systems and technologies grow in complexity
and scope, the need for a coherent and comprehensive modeling
approach becomes of paramount importance [13].
In the last decades the subject of Enterprise Architecture has
raised a lot of interest [7]. It helps control complexity, create
cohesion and provides a future proof solution.[27] The top
benefits reported are improved systems integration, improved
IT governance, higher chance the development team follows
common technology, improved business efficiency and
increased data integrity [5].
The growing interest in enterprise architecture has led to the
development of many frameworks to support the creation of
enterprise architecture. The Open Group Architecture
Framework ( TOGAF)[29] is such a framework and it has
become the de facto standard for development and deployment
of enterprise architecture[2]. According to Shaw [24], more
than 66% of enterprise architecture initiatives fail. This was a
conservative estimate he derived from a Rotterdam University
survey done in 2008. Before this survey, in 2007 the Gartner
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
17 th Twente Student Conference on IT, June 25 th , 2012, Enschede, The
Netherlands.
Copyright 2012, University of Twente, Faculty of Electrical Engineering,
Mathematics and Computer Science.
group had predicted that 40% of all the EA programs would
terminate by 2010 because of failures. Although exact data for
TOGAF projects is not available it is reasonable to assume that
TOGAF projects cope with comparable failure rate.
There is a plethora of reasons why these projects fail. The Open
Group recognizes a lack of experience, lack of understanding of
the artifacts and excessive time pressure as one of the main
reasons [32]. According to Gartner [4], a wrong architecture
leader, insufficient stakeholder understanding & support, too
much focus on IT, the EA team doing all the work, lack of
integration between the business units, lack of impact
measurement and lack of communication are the key reasons.
According to Sunderan most architecture projects are overly
ambitious and complex [28] which leads to delayed results and
running out of budget. This is confirmed by Sessions [23], who
reports that the main characteristic shared by each of the
Enterprise Architecture Frameworks is complexity. All of the
frameworks are highly complex. Murch [15] states, “to let IT
infrastructures and architectures become increasingly complex
with no action is unacceptable and irresponsible. If we simply
throw more skilled programmers and others at this problem,
chaos will be the order of the day. Until IT vendors and users
alike solve the problem of complexity, the same problems will
be repeated and will continue to plague the industry.”
It is easy to see that complexity is a big issue in TOGAF
implementations. TOGAF is a heavy methodology that requires
quite some architecture skills and sophistication. One could say
that a complete implementation of the TOGAF method is only
possible for organizations which have the highest EA maturity
level. Less mature organizations don’t have the ‘infrastructure’
to fully implement TOGAF. For organizations new to the
enterprise architecture practice adopting TOGAF could be a
daunting task.
This paper uses the six levels of architecture maturity proposed
by NASCIO to prioritize and tailor the adoption of TOGAF as
the organizations maturity progresses. To do this we first create
a good understanding of enterprise architecture and its role in
the organization. This is described in section 2.1. In section
2.2we analyze the TOGAF method and provide an overview of
its key elements. Section 2.3 contains a description of maturity
models and an overview of the relevant elements of NASCIO
for our research. In section 3 the results of our mapping of
TOGAF elements to the NASCIO stages are described. An
overview of these results is presented in the table in appendix
B. On the left hand side are the TOGAF elements, on the right
the maturity stage at which they should be introduced within the
architecture program. On the right-hand-side we also mapped
each TOGAF element to the NASCIO category which provides
a description in relation to the TOGAF element.

2. RELATED WORK
2.1 Enterprise Architecture
Enterprise architecture (EA) has the purpose to optimize, across
the enterprise, the often fragmented legacy of processes (both
manual and automated) into an integrated environment, that is
responsive to change and supports the achievement of the
business strategy[29]. EA can be used by organizations to
perform strategic planning and develop “blueprints” of their
future-state. EA is also used as a management tool to ensure
planning and activities are aligned with the strategic goals of
the organization, and to identify opportunities for collaboration
and reuse of resources across an organization[25].
An architecture may be viewed as a set of rules, guidelines and
patterns for describing the architecture of systems.[18] The ISO
42010 standard [8] describes architecture as the fundamental
organization of a system embodied in its components, their
relationships to each other, and to the environment, and the
principles guiding its design and evolution.
The Open Group [29] defines ”enterprise” as any collection of
organizations that has a common set of goals. For example, an
enterprise could be a government agency, a whole corporation,
a division of a corporation, a single department, or a chain of
geographically distant organizations linked together by
common ownership. The term “enterprise” in the context of
“enterprise architecture” can be used to denote both an entire
enterprise —encompassing all of its information and technology
services, processes, and infrastructure —and a specific domain
within the enterprise. In both cases, the architecture crosses
multiple systems, and multiple functional groups within the
enterprise.
Most enterprise architecture frameworks (EAFs) provide a
definition of enterprise architecture. These definitions share
commonalities that EA is about a set of models including their
components and how these components integrate and work
together to achieve a specific goal [14]. It is important to
understand that Enterprise Architecture is not limited to IT, but
is a company wide effort [21].
According to Lankhorst et al.[12] enterprise architecture (i)
offers a holistic perspective of the current and future operations,
and on the actions that should be taken to achieve the
company’s goals. It is (ii) an important asset in positioning new
developments within the context of the existing processes, IT
systems, and other assets of an organization, and it helps in
identifying necessary changes. Thus, good architectural practice
helps a company innovate and change by providing both
stability and flexibility. The insights provided by an enterprise
architecture are needed on the one hand in determining the
needs and priorities for change from a business perspective, and
on the other hand in assessing how the company may benefit
from technological innovations. And EA is a (iii) valuable asset
in the complex and diverse world of business-IT alignment. The
business-IT alignment is based on a well-known strategic
alignment model of Henderson and Venkatraman[6] which
distinguishes between the aspects of business strategy and
organizational infrastructure on the one hand, and IT strategy
and IT infrastructure on the other hand.
Lankhorst et al. [12] positioned enterprise architecture within
the context of the enterprise. This is visualized in the form of a
pyramid show in Figure 1. At the top of this pyramid, we see
the mission of the enterprise: why does it exist The vision
states its ‘image of the future’ and the values the enterprise
holds. Next there is its strategy, which states the route the
enterprise will take in achieving this mission and vision. This is
translated into concrete goals that give direction and provide the
milestones in executing the strategy. Translating those goals
into concrete changes to the daily operations of the company is
where enterprise architecture comes into play. It offers a
holistic perspective of the current and future operations, and on
the actions that should be taken to achieve the company’s goals.
Figure 1. Enterprise architecture positioned within the
organizations context (Lankhorst et. al.)
Architecture has three value creating potentials: innovativeness,
responsiveness and economies of scale [11]. Organizations with
highly capable infrastructure will have greater tendency to
innovate with information technology. Higher levels of IT
infrastructure capabilities will be more responsive at adapting
their information systems to accommodate changing business
conditions. The development cost and time of business
application systems will generally be lower for firms with more
capable IT infrastructures.
2.2 Enterprise architecture frameworks
With the growing use of EA, architects have an increasing need
for instruments to manage, to define, realize and communicate
demands on the architecture [10]. An enterprise architecture
framework (EAF) provides such an instrument. Enterprise
architecture frameworks are commonly used to develop a single
cohesive model that encompasses all aspects of a business in
support of business and IT initiatives. A well-developed EA
optimizes business processes by eliminating redundancy,
contradictions and identifying gaps [17]. EAFs help
organizations to build target-conformant enterprise architecture
that is flexible, adaptable and efficient [25]. The four most used
Enterprise Architecture Frameworks are the Zachman
Framework, The Open Group Architecture Framework
(TOGAF), Federal Architecture Framework (FEA) and the
Gartner Methodology.
2.2.1 TOGAF
TOGAF is growingly considered to be the de facto standard
way of working for the development and deployment of modern
IT systems in enterprises [2]. TOGAF is freely available to
members and non-members and has gained a market
penetration of 50% according to its own figures [19].
Ohren[18], made some efforts of characterizing available EAFs.
From his architecture framework ontology can be concluded
that TOGAF distinguishes itself by the development of an
architecture repository to support the organization of re-usable
architectures. TOGAF is not wholly specific with respect to
generated documents; in fact, it provides very little in the way
of prescriptive document templates—merely guidelines for
inputs and outputs [20].
In a comparison of the before mentioned four 'frameworks'
Sessions [22] states that TOGAF, although self-described as a

framework, it is actually more accurately defined as a process.
He comes to this conclusion because the Architecture
Development Method is the most visible and important part of
the TOGAF framework, which is a process for creating the
architecture artifacts.
Figure 2. Phases in the TOGAF Architecture Development
Method
The Architectural Development Method (ADM) is a detailed,
step-by-step method on how to build, maintain, and implement
an enterprise architecture. It consists out of 8 different steps in
the design cycle. See figure 2. These phases are an indication
however, because TOGAF is flexible with respect to the phases.
As the specification itself says: One of the tasks before applying
the ADM is to review its components for applicability, and then
tailor them as appropriate to the circumstances of the individual
enterprise. This activity might well produce an "enterprisespecific"
ADM [29]. TOGAF allows phases to be done
incompletely, skipped, combined, reordered, or reshaped to fit
the needs of the situation [22].
Appendix B contains an overview off the most important
elements of the TOGAF method. Next we will describe these
elements to get a better understanding of what they are.
Architecture development Method (ADM) , the development
process, is the most visual element of TOGAF. The ADM
provides a tested and repeatable process for developing
architectures. The ADM includes establishing an architecture
framework, developing architecture content, transitioning, and
governing the realization of architectures. All of these activities
are carried out within an iterative cycle of continuous
architecture definition and realization that allows organizations
to transform their enterprises in a controlled manner in response
to business goals and opportunities.
The Architecture Board oversees the implementation of the
governance strategy. This body should be representative of all
the key stakeholders in the architecture.
Architecture Compliance Assessment. Once an architecture has
been defined, it is necessary to govern that architecture through
implementation to ensure that the original Architecture Vision
is appropriately realized and that any implementation lessons
are fed back into the architecture process. Period compliance
reviews of implementation projects provide a mechanism to
review project progress and ensure that the design and
implementation is proceeding in-line with the strategic and
architectural objectives.
Architecture Contracts are the joint agreements between
development partners and sponsors on the deliverables, quality,
and fitness-for-purpose of an architecture.
The Architecture Governance Framework supports the
architecture governance by assisting the identification of
effective processes and organizational structures, so that the
business responsibilities associated with architecture
governance can be clarified, communicated, and managed
effectively Architecture governance is the practice and
orientation by which enterprise architectures and other
architectures are managed and controlled at an enterprise-wide
level. It includes systems to control over the creation and
monitoring of all architectural components and activities.
Ensuring compliance with internal and external standards and
regulations and ensuring accountability to the stakeholders.
Phase G of the TOGAF ADM is dedicated to the
implementation governance.
The Architecture skills framework provides a set of roles, skills,
and experience norms for staff undertaking enterprise
architecture work.
The Architectural content framework provides a structural
model for architectural content that allows the major work
products that an architect creates to be consistently defined,
structured, and presented.
Architecture Building Blocks (ABBs) typically describe required
capability and shape the specification of Solution Building
Blocks (SBBs). For example, a customer services capability
may be required within an enterprise, supported by many SBBs,
such as processes, data, and application software. Solution
Building Blocks (SBBs) represent components that will be used
to implement the required capability. For example, a network is
a building block that can be described through complementary
artifacts and then put to use to realize solutions for the
enterprise.
The Architecture Definition Document is the deliverable
container for the core architectural artifacts created during a
project and for important related information. The Architecture
Definition Document spans all architecture domains (business,
data, application, and technology) and also examines all
relevant states of the architecture (baseline, transition, and
target). The Architecture Definition Document provides a
qualitative view of the solution and aims to communicate the
intent of the architect.
A Transition Architecture shows the enterprise at an
architecturally significant state between the Baseline and Target
Architectures. Transition Architectures are used to describe
transitional Target Architectures necessary for effective
realization of the Target Architecture.
Architecture Patterns are a technique for putting building
blocks into context. Patterns can be used to describe a re-usable
solution to a problem. Building blocks are what you use.
Patterns can tell you how you use them, when, why, and what
trade-offs you have to make in doing so.

Architecture Principles are a qualitative statement of intent that
should be met by the architecture. They have at least a
supporting rationale and a measure of importance. Principles
are general rules and guidelines, intended to be enduring and
seldom amended, that inform and support the way in which an
organization sets about fulfilling its mission. We differentiate
Business, Data, Application and Technology principles.
The Architecture Repository acts as a holding area for all
architecture-related projects within the enterprise. The
repository allows projects to manage their deliverables, locate
re-usable assets, and publish outputs to stakeholders and other
interested parties. Part of the repository is the Reference library
which provides guidelines, templates, patterns, and other forms
of reference material that can be leveraged in order to accelerate
the creation of new architectures for the enterprise. Another
important aspect of the repository is the Standards information
base which captures the standards to which new architectures
must comply. They may include industry standards, selected
products and services from suppliers, or shared services already
deployed within the organization.
The Architecture Metamodel describes the organizationally
tailored application of an architecture framework, including a
method for architecture development and a metamodel for
architecture content.
The Architecture Requirements Specification provides a
quantitative view of the solution, stating measurable criteria that
must be met during the implementation of the architecture.
The Architecture Roadmap lists individual work packages that
will realize the Target Architecture and lays them out on a
timeline to show progression from the Baseline Architecture to
the Target Architecture. The Architecture Roadmap is
incrementally developed throughout Phases E and F, and
informed by readily identifiable roadmap components from
Phase B, C, and D within the ADM.
The Architecture Vision is created early on in the ADM cycle. It
provides a summary of the changes to the enterprise that will
accrue from successful deployment of the Target Architecture.
The purpose of the Architecture Vision is to provide key
stakeholders with a formally agreed outcome.
Business principles, business goals, and business drivers
provide context for architecture work, by describing the needs
and ways of working employed by the enterprise. Many factors
that lie outside the consideration of architecture discipline may
nevertheless have significant implications for the way that
architecture is developed.
Capability assessments are used to identify the abilities that an
organization possesses. Capabilities are typically expressed in
general and high-level terms and typically require a
combination of organization, people, processes, and technology
to achieve. We differentiate a business capability assessment,
IT capability assessment, architecture maturity assessment and
a Business transformation readiness assessment. The latter
provides insight in the readiness of the organization to accept
change. Identifying readiness issues and then dealing with them
in the Implementation and Migration Plans is vital for a
successful architecture transformation in Phases E and F.
A Change Request is a document containing a call for an
adjustment of the architecture; it may be submitted in order to
kick-start a further cycle of architecture work.
The development of a Communications Plan allows for
effective communication, of targeted information to the right
stakeholders at the right time through the right channels, to be
carried out within a planned and managed process.
The Enterprise Continuum is a categorization mechanism useful
for classifying architecture artifacts (Architecture continuum)
and solution artifacts (Solutions continuum), both internal and
external to the Architecture Repository, as they evolve from
generic Foundation Architectures to Organization-Specific
Architectures.
The Implementation and Migration Plan provides a schedule of
the projects that will realize the Target Architecture. The
Implementation and Migration Plan includes executable
projects grouped into managed portfolios and programs. A key
element of the Implementation and Migration Plan is the
Implementation and Migration Strategy which provides
strategic implementation direction and an implementation
sequencing approach.
The Implementation Governance Model ensures that a project
transitioning into implementation also smoothly transitions into
appropriate architecture governance. It does so by defining
specific processes, organizations, roles, responsibilities, and
measures on a project-by-project basis.
Interoperability requirements define the degree to which the
information, business processes and services are to be shared.
As part of the change management phase Monitoring Tools are
deployed that monitor for technology and business changes that
impact the baseline architecture. They could eventually lead to
change requests.
The Organizational model contains the scope of organizations
impacted, budget requirements, roles and responsibilities (for
architecture teams) and a governance and support strategy.
A Request for architecture work is a document that is sent from
the sponsoring organization to the architecture organization to
trigger the start of an architecture development cycle. Requests
for Architecture Work can be created as an output of the
Preliminary Phase, a result of approved architecture Change
Requests, or terms of reference for architecture work
originating from migration planning.
A Requirements Impact Assessment assesses the current
architecture requirements and specification to identify changes
that should be made and the implications of those changes.
Risk management. There will always be risk with any
architecture/business transformation effort. It is important to
identify, classify (assessment), and mitigate these risks before
starting so that they can be tracked (monitoring) throughout the
transformation effort. It is within the governance framework
that the risks have to be accepted and then managed.
Stakeholder Management is an important discipline that
successful architecture practitioners can use to win support
from others. Stakeholder management helps ensure stakeholders
support and their input improves the quality of the models
produced. Stakeholders are people who have key roles in, or
concerns about, the system. Different stakeholders with
different roles in the system will have different concerns.
Stakeholders can be individuals, teams, or organizations (or
classes thereof). Concerns are the key interests that are crucially
important to the stakeholders in the system, and determine the
acceptability of the system.
The Statement of Architecture Work defines the scope and
approach that will be used to complete an architecture
development cycle. The Statement of Architecture Work is
typically the document against which successful execution of
the architecture project will be measured and may form the
basis for a contractual agreement between the supplier and
consumer of architecture services.

Tailored architecture framework. Before TOGAF can be
effectively used within an architecture project the TOGAF
model needs to be tailored for integration into the enterprise and
also tailored for the specific architecture project. This tailoring
will include integration with project and process management
frameworks, customization of terminology, development of
presentational styles, selection, configuration, and deployment
of architecture tools, etc. The formality and detail of any
frameworks adopted should also align with the organizational
context, such as culture, stakeholders, commercial models for
enterprise architecture, and the existing level of Architecture
Capability.
The Technical reference model (TRM) is a taxonomy that
categorizes a set of technology areas and their relationships at a
conceptual level. It establishes a common structure and
vocabulary for describing technology components.
Solution development & deployment. During Phase G
(Implementation & Migration) the actual solution is
implemented and deployed. This is not a direct output of the
architecture development process. But because of its
importance it is also listed as an element of TOGAF.
2.3 Maturity models
Maturity models date back to the early seventies. In contrast to
popular believe the first application of a staged maturity model
to IT was not by CMM/SEI, but rather by Richard L. Nolan,
who, in 1973 published the stages of growth model for IT
organizations. The Capability Maturity Model (CMM) was
originally developed as a tool for objectively assessing the
ability of government contractors' processes to perform a
contracted software project. The CMM is based on the process
maturity framework first described in the 1989 book Managing
the Software Process by Watts Humphrey. It was later
published in a report in 1993 (Technical Report CMU/SEI-93-
TR-024 ESC-TR-93-177 February 1993, Capability Maturity
Model for Software, Version 1.1) and as a book by the same
authors in 1995.
The CMM model proved useful to many organizations, but its
application in software development has sometimes been
problematic. Applying multiple models that are not integrated
within and across an organization could be costly in training,
appraisals, and improvement activities. The Capability Maturity
Model Integration (CMMI) project was formed to sort out the
problem of using multiple CMMs.[31] For software
development processes, the CMM has been superseded by
CMMI, though the CMM continues to be a general theoretical
process capability model used in the public domain. CMMI was
developed by the CMMI project, which aimed to improve the
usability of maturity models by integrating many different
models into one framework. The project consisted of members
of industry, government and the Carnegie Mellon Software
Engineering Institute (SEI).
Maturity models can be categorized in one of two types of
maturity models [26]. (i) Staged models: These models
distinguish five levels of maturity. For each level a number of
focus areas are defined specific to that level. These focus areas
have to be implemented satisfactorily for the organization to
achieve that particular level. (ii) Continuous models: These
models also distinguish five general maturity levels and a
number of focus areas. The difference with the first kind of
models is that the focus areas are not attributed to a level, but
within each focus area the 5 levels are distinguished.
2.4 Enterprise architecture maturity models
With the emergence of enterprise architecture also a lot of
maturity models specifically tailored for enterprise architecture
were developed.[1,3,16,26]
According to NASCIO an essential part of enterprise
architecture development is for the organizations to assess their
current situation, and then set goals for the future. Identifying
the maturity of EA Architecture program components formally
allows the organization to benchmark the status of current
programs and begin the process of improving their
effectiveness, or kick off a new program.[16]
Architecture Capability Maturity Models (ACMMs) provide an
effective and proven method for an organization to gradually
gain control over and improve its architecture change processes.
By describing process improvement practices and a framework
to measure that improvement. A maturity model is not only
suitable as an assessment tool of the current state of the
architecture. It could also be used as a roadmap of steps to take
to improve the enterprise architecture [30].
2.5 NASCIO
One of the most used models is the National Association of
State Chief Information Officers ( NASCIO) Enterprise
architecture maturity model [14,29]. It is also proposed by
TOGAF to perform Enterprise architecture maturity
assessments.
The model is based on the Capability Maturity Model
developed by the Software Engineering Institute (SEI).
NASCIO describes the intent of the model as: “to supply a tool
that can be used to benchmark the effectiveness of an Enterprise
Architecture program. It also illustrates the natural progression
of benefits that a supported and managed architecture program
will contribute to an organization as it matures.”
NASCIO organizes its maturity descriptions by 8 different
categories:
Architecture Planning ensures the program is managed to
assure the goals for implementation are realistic and achievable
and the program is kept within scope.
Architecture Framework consists of the processes, templates
and forms used by those documenting the operations and
standards of the organization.
Architecture Blueprint refers to the completed documents that
are prepared using the Architecture Framework processes,
templates and forms. The Blueprint refers to the documented
products and standards, together with their detail,
classifications, impact statements, and migration strategies.
Communication is the element that ensures standards and
processes are established and readily available to team members
for reference and use. As an organization changes and
programs evolve the continued communication ensures the EA
program remains vital and operates optimally.
Compliance must be reviewed periodically to be sure the
business and IT programs and services are operating effectively.
Integration addresses the ability of the various entities (internal
or external to the organization) to coordinate their efforts to the
greatest benefit of the organization. This is a key factor, as
great efficiencies are gained by identifying similar functions or
operations, both inside and outside of an organization.
Involvement must be part of an EA Program. Without the
support of managers and employees who are expected to utilize
and follow the defined process, the program is sure to fail.

The maturity model is a staged model which differentiates 6
stages of maturity, from no program (immature) to a
continuously improved program (mature). We will give a short
description of each of these stages. Appendix A contains a more
in-depth description of the (for our research relevant) elements
in each of the 6 stages. Or consult the NASCIO maturity model
document for a more detailed description for each of the
different stages[16].
Level 0: No program. At this level there is not a documented
architectural framework in place at this level of maturity.
While solutions are developed and implemented, this is done
with no recognized standards or base practices. The
organization is completely reliant on the knowledge of
independent contributors.
Level 1: Informal program. The base architecture framework
and standards have been defined and are typically performed
informally. There is general consensus that these steps should
be performed, however they may not be tracked and followed.
Organizations with an Enterprise Architecture framework at this
level are still dependent on the knowledge of individual
contributors.
Level 2: Repeatable program. The base architecture and
standards have been identified and are being tracked and
verified. At this point in the program processes are repeatable
and reusable templates are starting to be developed. The need
for product and compliance components to conform to the
standards and requirements has been agreed upon, and metrics
are used to track process area performance.
Level 3: Well-defined program. The enterprise architecture
framework is well defined; using approved standard and/or
customized versions of the templates. Processes are
documented across the organization. Performance metrics are
being tracked and monitored in relationship to other general
practices and process areas.
Level 4: Managed program. At this point performance metrics
are collected, analyzed and acted upon. The metrics are used to
predict performance and provide better understanding of the
processes and capabilities.
Level 5: Continuously improved program. The processes are
mature; targets have been set for effectiveness and efficiency
based on business and technical goals. There are ongoing
refinements and improvements based on the understanding of
the impact changes have to these processes.
3. USE OF TOGAF IN EACH LEVEL
With every level of architecture maturity more elements of
TOGAF should be adopted in the EA process. In this chapter
we will describe these elements for each of the maturity levels.
Because a higher maturity builds on lower levels only the
elements introduced in that maturity level are specified.
An overview of the mapping of the NASCIO elements to the
TOGAF elements can be found in Appendix A. An overview of
the TOGAF elements in each of the maturity levels can be
found in Appendix B. That table also contains a mapping of the
TOGAF elements on the different categories distinguished by
NASCIO in its maturity model.
3.1 Level 0: No program
At this maturity stage TOGAF has not yet entered the reality of
the organization. The awareness and even most elementary use
of an enterprise architecture framework would put the
organization in a higher maturity level.
3.2 Level 1: Informal program
According to NASCIO the architecture activities and the
architecture process are informal and unstructured at this stage
of maturity. There is no defined process and the success of the
architecture activities depends on the efforts of individual
contributors. These contributors can use aspects of the ADM in
isolation. For the development of a baseline and target
architecture they could use the architecture vision phase of the
ADM as guide. According to the TOGAF document the goal of
the architecture vision phase is develop a high-level aspirational
vision of the capabilities and business value to be delivered as a
result of the proposed enterprise architecture. As part of the
vision phase it provides a step by step plan to deliver a lowlevel
(0.1 version) business, application and technology
architecture. These steps don’t rely on the existence or
knowledge of other TOGAF elements and could therefore well
be used in isolation. The deliverable can be seen as an immature
or draft (v0.1) architecture definition document.
One of the biggest reasons for EA failure is a lack of focus on
the business aspects early on in the architecture life cycle[4,24].
It is therefore important to focus on business architecture as
well as the IT architectures and involve the business practice in
the process. NASCIO describes the informal documentation of
business drivers in this maturity stage. The business principles,
goals and drivers element of TOGAF could be beneficial in
guiding this documentation.
One of the first things you want to do in developing an
enterprise architecture is demonstrating success[23]. This helps
you build momentum and establish credibility early on. It is
therefore important to develop and deploy solutions early on.
In this level of architecture maturity there is very little
communication about the architecture and its documents.
3.3 Level 2: Repeatable program
At this maturity level the need for governance has been
identified. TOGAF supports this by means of an Architecture
Governance Framework. The forming of committees has
started, but this is not a very formal process. The development
of clear roles and responsibilities is supported by the
stakeholder management process and documented as part of
the organizational model.
In this level of maturity the organization should have decided
on the use of an architecture methodology ( ADM) and start
tailoring the architecture framework. The tailoring of the
framework has become important because a lot of elements of
TOGAF get introduced to the architecture process in this
maturity level leading to an increase in complexity. The
(tailored) Architecture program is documented within the
architecture metamodel which is part of the architecture
repository.
The customized Architecture development Method forms the
bases for EA program plan that should be developed. The
architecture principles, which are defined in addition to the
business principles, are also an input to the identification of EA
tasks. The Migration & Implementation Plan and
Architecture Roadmap are key deliverables regarding
planning. In this maturity level focus is on the resource
requirements and business value of the individual projects.
The organization is beginning to reuse methods for capturing
critical EA information. This could be supported by a fixed set
of artifacts, which are documented in the content metamodel.
The technical reference model provides taxonomy for
describing technology components. The growing need for
storage and dissemination of architecture documents can be
filled by the architecture repository. The architecture

definition document is used to contain the core architectural
artifacts created and now also contain transition architectures.
The architecture principles together with the Architecture
Vision are key elements used in the identification of strategic
info.
The organization has begun to develop a compliance process to
ensure that projects and enhancements are consistent with EA
standards. TOGAF provides architecture compliance
assessment to support this process.
The need for Enterprise Architecture is being communicated to
Senior Management and EA awareness activities are beginning
to emerge or be developed. The organization also begins to
develop plans for EA educational sessions and materials to
increase the awareness and understanding of the EA concepts
and processes . All communications efforts are planned through
the Communications plan element of TOGAF. Although EA
awareness is one of the key success factors for enterprise
architecture there are no direct references to it in the TOGAF
documentation. EA awareness and involvement are however
improved by a well-executed communications plan and readily
available architecture documentation.
3.4 Level 3: Well-defined program
Most of the TOGAF elements used in the previous maturity
level will be developed more extensively in this level. For
instance the Implementation and migration planning is extended
by focusing on the timeline and financial requirements of the
different projects.
The governance committees get a more formal nature. An
architecture board could be formed and the Architecture
skills framework could be useful to support the definition of
well-defined governance committees.
The organization starts using templates to capture information
consistently. These templates are located within the reference
library. The use of an Standards information base assists in
the classification of existing technology standards in a
consistent way. Architecture Patterns help to identify
combinations of Architecture Building blocks and/or Solution
Building Blocks (ABBs/SBBs) that have been proven to
deliver effective solutions in the past. The Enterprise
continuum acts as a categorization mechanism for all the
architectural and solution artifacts.
The EA Compliance process is followed consistently
throughout the enterprise. If there is a variance to the
requirements or architecture definition document a change
request may be created to kick-start a new development cycle.
When a new cycle is necessary a request for work is created.
Interoperability requirements could be used to improve the
integration between the EA Program and strategic planning and
budgeting processes by describing the way information and
services are shared.
3.5 Level 4: Managed program
The main difference between organizations in this maturity
level and the previous one is the extent to which metrics are
used to measure progress and effectiveness. For instance the
organization captures metrics to measure the progress against
the established EA plans. The Architecture requirements
specification provides quantitative statements that outline what
a project must do in order to comply with the architecture. It is
typically a major component of the architecture contracts. The
statement of architecture work is another document in which
quantitative measurements are defined. They are used to
measure whether the project is successfully executed.
Requirements impact assessments can be used to identify the
need for updates to architecture documentation and/or
classifications. Corrective action plans are put in place when
deficiencies in templates and/or procedures are identified.
The risks and issues that may threaten the success of the
enterprise architecture practice and its ability to meet its vision,
goals and objectives is assessed. This helps the organization to
improve the effectiveness of the architecture program.
Although a government framework is already in place, specific
processes, organizations, roles, responsibilities, and measures
may need to be defined on a project-by-project basis. The
Implementation Governance Model could be used to support
this.
3.6 Level 5: Continuously improved
program
Requirements Impact Assessment assesses the current
architecture requirements and specification to identify changes
that should be made and the implications of those changes.
Based on these implications the architecture is updated.
Monitoring tools are deployed to watch for new technology
and business trends that will improve the business.
4. CONCLUSION
The maturity models provide some indication for what TOGAF
elements to focus on early in the enterprise architecture
maturity and which elements to postpone, until a higher
maturity is reached. It could offer a kind of roadmap on top of
the step-by-step plan offered by the architecture development
method (ADM), which is the most visual and most important
part of TOGAF. Besides offering a good step-by-step process it
also introduces a lot of processes, deliverables & methods to
use within or on top of it. The maturity based roadmap could
help identify the elements that are relevant for the organization
at hand, offering guidance for the architects in selecting what
elements to focus on. The more modular specification document
introduced by the Open Group with version 9.1 makes this
focus on single elements easier. This helps avoid the architect
getting overwhelmed by information and also making the
architecture process less complex.
Although our research could offer benefits in theory this should
be proven in practice. Due to the limited time offered to the
bachelor thesis project we don’t provide a validation of the
proposed mapping in practice.
4.1 Future work
The most important restriction of our research is a lack of
validation to see whether our results comply with actual use of
TOGAF. It would, in general, be interesting to see what
elements of TOGAF have been adopted in the real world and
how successful these architecture projects have been. And to be
more specific, how the adopted elements relate to the
architecture maturity of the organizations.
Within the specification document they make notion that a
future versions of TOGAF may include a maturity model to
measure adoption of TOGAF itself. This paper could be used as
a starting point for such a maturity model. This model should
assess whether the relevant elements of TOGAF have been
adopted in the given maturity stage.
5. REFERENCES
1. Department of Commerce. Enterprise Architecture
Capability Maturity Model - Version: 1.2. 2007.
2. Dietz, J.L.G. and Hoogervorst, J.A.P. A Critical
Investigation of TOGAF - Based on the Enterprise
Engineering Theory and Practice. In A. Albani, J. Dietz

and J. Verelst, eds., Advances in Enterprise Engineering V.
Springer-Verlag Berlin, Berlin, 2011, 76–90.
3. GAO. A Framework for Assessing and Improving
Enterprise Architecture Management (Version 1.1). .
4. Gartner. Ten Enterprise Architecture Pitfalls Identified.
http://www.gartner.com/it/page.jspid=1159617.
5. Gokhale, A. Increasing Effectiveness Of The Zachman
Framework Using The Balanced Scorecard. (2010).
6. Henderson, J.C. and Venkatraman, N. Strategic alignment:
leveraging information technology for transforming
organizations. IBM Systems Journal 32, (1993), 4–16.
7. Iacob, M.-E., Franken, H., and Berg, H. van den. Handbook
enterprise architecture : method, language and tools.
BiZZdesign, Enschede, 2007.
8. IEEE. IEEE Std 1471-2000: IEEE Recommended Practice
for Architectural Description of Software-Intensive
Systems. IEEE, (2000).
9. Iyer, B. and Gottlieb, R. The Four-Domain Architecture: An
approach to support enterprise architecture design. IBM
Systems Journal 43, 3 (2004), 587–597.
10. Jonkers, H., Lankhorst, M.M., ter Doest, H.W.., Arbab, F.,
Bosma, H., and Wieringa, R.J. Enterprise architecture:
Management tool and blueprint for the organisation.
Information Systems Frontiers 8, 2 (2006), 63–66.
11. Kayworth, T.R., Chatterjee, D., and Sambamurthy, V.
Theoretical justification for IT infrastructure investments.
Advanced topics in information resources management 1, ,
73–90.
12. Lankhorst, M. Enterprise architecture at work: Modelling,
communication and analysis. Springer-Verlag New York
Inc, 2009.
13. Leist, S. and Zellner, G. Evaluation of current architecture
frameworks. Proceedings of the 2006 ACM symposium on
Applied computing, (2006), 1546–1553.
14. Meyer, M., Helfert, M., and O’Brien, C. An Analysis of
Enterprise Architecture Maturity Frameworks. In J. Grabis,
M. Kirikova, W. Aalst, et al., eds., Perspectives in Business
Informatics Research. Springer Berlin Heidelberg, 2011,
167–177.
15. Murch, R. Managing Complexity in IT, Part 1: The
Problem. In 2004.
16. NASCIO. NASCIO Enterprise Architecture Maturity Model
Version 1.3. 2003.
17. Oda, S., Fu, H., and Zhu, Y. Enterprise Information Security
Architecture A Review of Frameworks, Methodology, and
Case Studies. 2009 2ND IEEE INTERNATIONAL
CONFERENCE ON COMPUTER SCIENCE AND, (2009),
333–337.
18. Ohren, O. An ontological approach to characterising
enterprise architecture frameworks. Knowledge Sharing in
the Integrated Enterprise: Interoperability 183, (2005),
131–141.
19. Opengroup. Newsletter - Togaf 9 survey results. 2009.
https://opengroup.org/tech/arch_newsletter/nl_aug09.pdf.
20. Perks, C. and Beveridge, T. Guide to Enterprise IT
Architecture. Springer-Verlag New York, Inc., 2001.
21. Ross, J.W., Weill, P., and Robertson, D. Enterprise
architecture as strategy: creating a foundation for business
execution. Harvard Business Press, 2006.
22. Sessions, R. A Comparison of the Top Four Enterprise-
Architecture Methodologies. 2007.
http://msdn.microsoft.com/en-us/library/bb466232.aspx.
23. Sessions, R. A Better Path to Enterprise Architectures.
http://msdn.microsoft.com/enus/library/aa479371(d=printer).aspx.
24. Shaw, B. Enterprise Architecture – Will Yours Fail Too.
http://www.itprojecttemplates.com/WP_EA_Will_Yours_Fa
il.htm.
25. Song, H. and Song, Y.-T. Enterprise architecture
institutionalization and assessment. Proceedings - 9th
IEEE/ACIS International Conference on Computer and
Information Science, ICIS 2010, (2010), 870–875.
26. van Steenbergen, M., van den Berg, M., and Brinkkemper,
S. A Balanced Approach to Developing the Enterprise
Architecture Practice. ENTERPRISE INFORMATION
SYSTEMS-BOOKS 12, (2008), 240–253.
27. Steenbergen, M. van. Maturity and effectiveness of
enterprise architecture. (2011).
28. Sunduran, S. Five Keys to a Successful Enterprise
Architecture Program -- Enterprise Systems.
http://esj.com/Articles/2010/01/19/Enterprise-
Architecture.aspxPage=3&p=1.
29. The Open Group. The Open Group Architecture Framework
(TOGAF), version 9. Van Haren Publishing, Zaltbommel,
2009.
30. Vermoolen, J. Een volwassenheidsgroeimodel voor
Enterprise Architectuur - Hulpmiddel voor
organisatiegerichte IT. .
31. Wikipedia contributors. Capability Maturity Model.
Wikipedia, the free encyclopedia, 2012.
http://en.wikipedia.org/w/index.phptitle=Capability_Matur
ity_Model&oldid=490134655.
32. World-Class Enterprise Architecture. Whitepaper, The Open
Group, (2010).

APPENDIX A NASCIO ELEMENTS MAPPED TO TOGAF
NASCIO elements
TOGAF elements
0: No EA program
1: Informal program
Informal EA activities by individual contributors
Informal and incosistent business drivers
2: Repeatable program
Identified need for governance
Begin development of clear roles & responsibilities
Begin development of an architecture vision
Identify EA tasks and resource requirements
Develop a EA plan
Decide on a methodology
EA program is documented
Identification of strategic info
Technology standards identified
Ensure project compliance with standards
EA repository for storage and dissemination needed
Need for communication to Senior management
3: Well defined program
Architecture committees are defined and their authority are aligned
Templates are used for consistent information capturing
Consistent classification of existing standards
Formal EA compliance process as part of EA lifecycle processes
EA program is integrated with strategic planning and budget
4: Managed program
Measure architecture progress against EA plan
Documentation and classification of products and compliance
Capture metrics to improve effectiveness
5: Continuously improved program
Proactively review architecture program
Monitoring of new business & technology trends
Architecture vision (phase)
Architecture definition document
Architecture Development Method
Business Principles, Goals and Drivers
Architecture governance framework
Organizational model
Stakeholder management process
Architecture vision
Architecture principles
Architecture roadmap
Migration & implementation plan
Architecture development method
Tailoring of the architecture framework
Architecture & content metamodel
Architecture vision
Technical reference model
Architecture compliance assessment
Architecture repository
Communications plan
Architecture board
Architecture skills framework
Reference library
Standards information base
Architecture patterns
Architecture building & solutions blocks
Enterprise continuum
Change requests & request for arch. Work
Interoperability requirements
Architecture requirements specification
Architecture contracts
Statement of architecture work
Requirements impact assessment
Risk management
Requirements impact assessment
Monitoring tools

APPENDIX B TOGAF ELEMENTS IN EACH MATURITY LEVEL