Detailed Analysis of Enterprise Architecture Layers and Applications

This report provides a comprehensive overview of the layers of Enterprise Architecture, emphasizing the importance of a layered approach to manage the complexity of relationships between different elements and stakeholder viewpoints. It details the Business Architecture, Data Architecture, Application Architecture, and Technology Architecture, explaining their roles and interdependencies. The report highlights key applications of enterprise architecture, including problem investigation, strategic direction, gap analysis, tactical and operational planning, and solution architecture. It also provides a background on the evolution of Enterprise Architecture, referencing the contributions of John Zachman and others. The report discusses the Zachman Framework and its origins, as well as the key applications of Enterprise Architecture, emphasizing its role in enabling informed decision-making and ensuring compliance at various levels of specificity. The report also examines the historical context of Enterprise Architecture and highlights key figures and their contributions, emphasizing the importance of Enterprise Architecture in the contemporary business environment.

Intro
Layers of an Enterprise Architecture
To cope with the complexity of the relations between all the elements of an
Enterprise Architecture and the different views and viewpoints of the stakeholders
to address, it is common to use a layering scheme (Fig. 2.1).
As stated in the definition given by The Opengroup for the term «Architecture
Domains» the layering in (TOGAF) is done as follows:
Business Architecture: As TOGAF states
«In summary, the Business Architecture describes the product and/or service strategy, and
the organizational, functional, process, information, and geographic aspects of the business
environment.»
This architecture is extremely important, as all the other architectures rely on it.
The exact extent to which business-related activities to define this layer will
effectively be driven and managed by an Enterprise Architecture program depends
on the business environment. For example, in our environment the Enterprise
Architecture team had the lead for the definition of an information model and
business glossary, but not for the business process architecture itself.
Data Architecture: This architecture deals with all necessary aspects of data
management, how applications, services, and business functions utilize enterprise
data, how the relationship among data objects are to be modeled, how the transformation
of data is to be done, etc. TOGAF provides the following definition:
«A description of the structure and interaction of the enterprise’s major types and sources
of data, logical data assets, physical data assets, and data management resources.»
Business Architecture
Data & Application Architecture
Technology Architecture
Fig. 2.1 Layers of an enterprise architecture
12 2 Theory
Application Architecture: This layer provides all necessary information for the
management of the application landscape, how business functions will be realized
in terms of applications.
Maybe to use
In addition to the above requirements on enterprise architecture as a means, based
on the discussions in this chapter, we also identify seven key applications for enterprise
architecture:
1. Investigate problems/shortcomings in a preexisting situation, including the creation
of a shared (among stakeholders) understanding of the existing situation;
2. Express (and motivate) the future direction of an enterprise, as well as investigate
(and evaluate) different alternatives. This also involves the creation of a shared
(among stakeholders) conceptualisation of the (possible) future directions, and
shared agreement for the selected alternative;
3. Identify key problems, challenges, issues, impediments, chances, etc., as well
as make well-motivated design decisions that enable a move from the existing
situation into the desired strategic direction;
4. Provide boundaries and identify plateaus (intermediary steps) for the transformation
of the enterprise toward the articulated strategic direction. In this context,
enterprise architecture is used as a planning tool, making the realization of a
strategy more tangible;
5. Give a clear context and direction for a portfolio of projects working toward the
realization of the first plateau as defined at the tactical planning level;
6. Select one or more standard solutions and/or packages that are to become part

of the solution and/or decide to outsource an entire business process/service to
another enterprise;
7. Create the high level design of an actual step in the enterprise transformation as
it will be realized (and implemented) in the context of a specific project.
3.3 Key Applications for Enterprise Architecture
Based on the needs and challenges of enterprises as discussed in the previous chapter
(in particular, Sect. 2.6), we identify seven key applications for enterprise architecture
as a means. In combination, these applications provide an instrument to make
informed decisions as well as to ensure compliance of the transformation to these
decisions, at several levels of specificity:
– Situation description—Use enterprise architecture as a means for goal/cause
analysis to investigate problems/shortcomings in an existing situation. This also involves the
creation of a shared (among stakeholders) understanding of the existing
situation.
– Strategic direction—Use enterprise architecture to express (and motivate) the
future direction of an enterprise, as well as investigate (and evaluate) different alternatives.
This also involves the creation of a shared (among stakeholders) conceptualization
of the (possible) future directions, and shared agreement for the
selected alternative.
– Gap analysis—Use enterprise architecture to identify key problems, challenges,
issues, impediments, chances, threats, etc., as well as make well-motivated design
decisions that enable a move from the existing situation into the desired strategic
direction.
– Tactical planning—Use enterprise architecture to provide boundaries and identify
plateaus (intermediary steps) for the transformation of the enterprise toward
the articulated strategic direction. In this context, enterprise architecture is used
as a planning tool, making the realization of a strategy more tangible.
– Operational planning—Use enterprise architecture to give a clear context and
direction for a portfolio of projects working toward the realization of the first
plateau as defined at the tactical planning level.
– Selection of partial solutions—Use enterprise architecture as a means to select
one or more standard solutions and/or packages that are to become part of the
solution and/or decide to outsource an entire business process/service to another
enterprise.
– Solution architecture—Use enterprise architecture to create the high level design
of an actual step in the enterprise transformation as it will be realized (and
implemented) in the context of a specific project.
In Fig. 3.7, we have illustrated these seven application areas. Each of these seven
application areas will yield different enterprise architectures, which are clearly
interdependent.
By ensuring compliance among these architectures, governance, and
informed decision-making, from the strategic level to the operational level is enabled.
Background
Enterprise Architecture is still fairly young. It began getting traction in the mid to late 1980s
after John Zachman published an article describing a framework for information systems
architectures in the IBM Systems Journal. Zachman said he lived to regret initially calling his

framework “A Framework for Information Systems Architecture,” instead of “Enterprise
Architecture” because the framework actually has nothing to do with information systems.
Rather, he said, it was “A Framework for Enterprise Architecture.” But at the time of
publication, the idea of Enterprise Architecture was such a foreign concept, Zachman said,
that people didn’t understand what it was. Even so, the origins of his ontological framework
were already almost 20 years old by the time he first published them.
In the late 1960s, Zachman was working as an account executive in the Marketing Division
of IBM. His account responsibility was working with the Atlantic Richfield Company (better
known as ARCO). In 1969, ARCO had just been newly formed out of the merger of three
separate companies, Atlantic Refining out of Philadelphia and Richfield in California, which
merged and then bought Sinclair Oil in New York in 1969.
By separating these two independent variables, management could change organizational
responsibilities without affecting or changing existing systems or the organization. Many
years later, Jim Champy and Mike Hammer popularized this notion in their widely read 1991
book, “Reengineering the Corporation,” Zachman said.
Source 8
In the early ‘80’s, there was little interest in the idea of Enterprise Engineering or Enterprise
Modeling and the use of formalisms and models was generally limited to some aspects of
application development within the Information Systems community. The subject of
architecture was acknowledged at that time, however, there was little definition to support
the concept. This lack of definition precipitated the initial investigation that ultimately resulted
in the “Framework for Information Systems Architecture” (later referred to as The Zachman
Framework). Although from the outset, it was clear that it should have been referred to as
the “Framework for Enterprise Architecture,” that enlarged perspective could only now begin
to be generally understood as a result of the relatively recent and increased, world-wide
focus on Enterprise Engineering
Source 7
In my 1998 article, "Enterprise Architecture: The Issue of the Century," I argued that the
Enterprise that can accommodate the concepts of Enterprise Architecture will have the
opportunity to stay in the game ... and the Enterprise that cannot accommodate the concepts
of Enterprise Architecture is not going to be in the game. I might observe that a lot of
Enterprises have been falling out of the game of late.
Source 6
In 1998, the ZIFA Forum was held in August at the Camelback Inn in Scottsdale, Arizona. If
anything, that year's program was even more enthusiastically received than previous years,
although my program strategy was completely different from the past.
Tom Bruce -- who was at the Bank of America when he wrote Designing QualityDatabases
Using IDEF1X Information Modeling, a seminal work on Column 1 (data)models. The basic
idea of the book is that if you want the end result to representwhat the 'Owners' have in
mind, each model has to accurately reflect the intent ofthe next higher row model. In his
presentation, Tom also was making some incrediblyinteresting observations about designing
the data models to accommodate downstreamEnterprise change.

Melissa Cook -- who is at Hewlett Packard and wrote Building Enterprise
InformationArchitectures, a book on Rows 1 (Scope) and a high-level sliver of Row 2
(Modelsof the Business) for Columns 1 (Data), 2 (Process) and 3 (Location). This isa very
easy-to-read book on using classification theory to establish architecturalboundaries for all
ensuing implementations. It contains one of the clearestdiscussions I have ever read on
why architecture is so critical for the Column 3(Network) design. In 1998, Melissa was
recounting her experience in implementingher ideas at HP.
Don Hodge -- from the Bank of America, currently building a very large set ofRow 2 models
(Models of the Business). He was very interesting, not only becausehe represents an
'implementing Enterprise,' but also because the model they are buildingis very large
(something over 5,000 objects at present) and also, he is using a modelingtool supplied by
NCR called METIS, to capture and manipulate the model.
Tom Hokel -- from Framework Software, who built an 'Artifact Management' tool,specifically
using the Framework as the basis for classifying and accessing any kindof artifact. You can
associate a document, a model, a standard, an application,or whatever with a Cell or set of
Cells and then retrieve it later through the Framework. Click on the Cell, find the artifact,
launch the application where it is stored,and present it through the Framework Cell. This
tool is receiving wide acceptanceand, specifically, it is being heavily used in the U.S. Air
Force, Health InformationResources System.
Judi Reeder and Howard Jachter -- of Knowledge Partners and Lucent
Technologies(respectively) who are building a set of Row 2 models (Models of the Business)
forLucent Technologies. This is another 'implementing Enterprise' experience wherethey are
building very large models to serve as a basis for bounding all ensuing'systems'
implementations and accumulating a 'meta-data' repository to serve as acontrol point for all
I.T. decision making. This was very interesting in thatit is a kind of 'prototype' effort at
Lucent to accumulate knowledge on architecturesand architectural practices for subsequent
deployment broadly in the corporation.
Ron Buck -- of the South Bay Group who, as CEO of IVI Publishing, produced allof the
publications for the Mayo Clinic, including the very innovative "PrimePractice: CD-ROM
Series for Primary Care Practitioners." This continuingeducation program for physicians is a
model of Column 4, Presentation Architectureconcepts that employs the practices of the
publishing industry in designing 'userinterfaces.' Ron described even more interesting
execution of these ideas inseveral Knowledge Management projects on which he is currently
working.
Tom DeMarco -- who wrote Structured Analysis and System Specification (publishedby
Yourdon Press in 1978), a seminal piece of work on Process models, Column 2, Rows4 and
5. He could attend only by video and had some very interesting observationson architecture
and reusability. He also observed that 'Architecture' is sucha powerful concept that when it

is employed publicly (as a product in the marketplace),the government launches anti-trust
actions to break up the implementers because theyhave so much dominance -- for example,
IBM and its System 360 architecture, AT&Tand its telephone network architecture, Microsoft
and its operating system architecture.
Paula Pahos -- who, along with Prakash Rao of Metadata Management Corporation,is the
author of a Repository product, "Design Bank." If there isone technology dependency for
making 'Architecture' a reality, it is a database forstoring architectural models -- a
Repository. Design Bank was designed fromthe bottom up as a model manager and uses
the Framework to organize the metamodelso that you can access the Repository contents
through the Framework. Anotherinteresting feature of this presentation was the observation
that Design Bank hasbeen successfully implemented by the U.S. Air Force Air Mobility
Command -- a huge,global, decentralized organization.
John Hall -- of Model Systems, a UK-based Architecture-consulting firm. He wasthe principle
author of SSADM, a development methodology widely used in Europe. As part of SSADM,
Entity Life History Analysis has been modernized to become 'Event-DrivenBehavior of
Entities' which models the behavior of entities based on business events(Column 5) and
transforms the behavior models into process specifications. John's presentation integrated
very rigorously-defined theoretical structures witha depth of practical implementation
experience that can only come from decades ofhands-on work.
Leo Genders -- of the Ohio Bureau of Workers' Compensation, who have adopted atop-
down, Enterprise Architecture approach. Leo was one of the 'implementingEnterprise'
speakers, and he was eloquent in describing their history and currentstate of affairs. The
'legacy' was eating them alive, and everything takestoo long and costs too much. It was
deja vu all over again! Hewas describing any and every I/S shop you have ever seen. They
have tried everything: all the new technologies, outsourcing, packages, consultants, and the
problem onlykeeps getting worse. As a kind of last resort, they turned to Enterprise
Architectureand are experiencing some early-on, unanticipated benefits. It is
strengtheningI/S and beginning to restore their credibility with the management/user
communities.
Ron Ross -- of Business Rule Solutions wrote the seminal work, The BusinessRule Book:
Classifying, Defining and Modeling Rules (published by the DatabaseResearch Group). This
book describes a notation for Column 6, Row 3, 'BusinessRules.' I know of no one who has
spent as much time exploring the issues ofBusiness Rules as Ron Ross. He continues to
drive the state of the art by definingapproaches for identifying and formalizing the Business
Rules as derivatives of theobjectives and strategies of the Enterprise (Column 6, Row 2).
Although hedidn't explicitly mention this, I happen to know this new work on the derivationof
rules currently is being done as an actual implementation in a large financialindustry
organization.
Jonathan Geiger -- who is the principle author of Data Warehousing and theZachman
Framework. Although Bill Inmon and I authored chapters of thisbook (I wrote the one on

'Knowledge Management'), the book was basically a descriptionof Jon Geiger's Data
Warehousing implementation methodology, which he used whileresponsible for Data
Warehouse at Florida Power and Light. I continuously havepeople come up and tell me
what a great book this is ... "the best Data Warehousebook (they) have ever read." I am
somewhat reluctant to take too muchcredit because Jon was the one who did the lion's
share of the work!
In 1987, John Zachman introduced the first and best-known enterprise architecture
framework (Zachman 1987), although back then it was called
‘Framework for Information Systems Architecture’. The framework as it
applies to enterprises is simply a logical structure for classifying and organising
the descriptive representations of an enterprise that are significant
to the management of the enterprise as well as to the development of the
enterprise’s systems
Overview of EA definitions
Enterprise architecture (EA) is often projected as a multipurpose medicine that cures an
enterprise of all pains and problems. EA comes in different flavors—sometimes a marketing
gimmick in management
talks, sometimes a means to boast about knowledge of some framework or other, and
sometimes
an academic research topic. As a consequence, there seems to be a mystical mist
surrounding the field
of EA. (source 1. Chp1)
EA is a hygiene factor for the IT landscape. (source 1. Chp1)pg 5
Architecture - The fundamental organization of a system, embodied in its components, their
relationships to each other and the environment, and the principles governing its design and
evolution. (source 1 chpt 2) Architecture is essentially meant to establish the structural
foundation, behavioral characteristics, and principles that guide the creation, evolution, and
operation of a system in the long run . (source 1 chpt 2)
The Definition of Architecture
Architecture is the representation of the structure and behavior of a system and its
constituent parts, plus a set of principles that guide the system’s long-term evolution (source
1 chpt 2)
March and Simon (1958) define enterprises as complex systems comprising individuals or
groups that coordinate actions in pursuit of common goals. (source 1 chpt 2)
Enterprise architecture (EA), then, is loosely defined as the architecture of a system where
the system is the whole enterprise (source 1 chpt 2)
ARCHITECTURE IN THE CONTEXT OF BUSINESS-IT MANAGEMENT IN AN
ENTERPRISE
What Is Enterprise Architecture?
Enterprise architecture (EA) is the representation of the structure and behavior of an
enterprise’s IT landscape in relation to its business environment. It reflects the current and
future use of IT in the enterprise and provides a roadmap to reach a future state. EA offers:
• An insight into the current utilization of IT in business operations,
• A vision for the future utilization of IT in business operations, and

• A roadmap for the evolution of the IT landscape from the current state to a future state,
along with the transient
states in between. (source 1 chpt 2)
An EA framework is a set of assumptions, concepts, values, and practices that constitutes a
way of
looking at enterprise reality via views on (architectural) models. It offers a fundamental
structure, serving
as a scaffold for developing, maintaining, and using EA. Source 1 chpt 4
source 2 chapt 2
Enterprise: The highest level (typically) of description of an organization that
typically covers all missions and functions. An enterprise will often span multiple
organizations.
Architecture: 1. A formal description of a system, or a detailed plan of the
system at component level, to guide its implementation (ISO/IEC 42010 2007).
2. The structure of components, their interrelationships, and the principles and
guidelines governing their design and evolution over time.
Architecture Framework: A conceptual structure used to develop, implement,
and sustain an architecture.
Architecture Domain: The architectural area being considered. There are four
architecture domains within TOGAF: business, data, application, and technology.
Patterns: A technique for putting building blocks into context; for example, to
describe a reusable solution to a problem. Building blocks are what you use:
patterns can tell you how you use them, when, why, and what tradeoffs you have to
make in doing so.
In this book, we deal with a simplification of the real world to address the concerns
of different stakeholders. We therefore use the following definitions as well:
Model: A representation of a subject of interest. A model provides a smaller
scale, simplified, and/or abstract representation of the subject matter. A model is
constructed as a «means to an end». In the context of Enterprise Architecture, the
subject matter is the entire enterprise or a part of it and the end is the ability to
10 2 Theory
construct «views» that address the concerns of particular stakeholders; i.e., their
«viewpoints» in relation to the subject matter.
View: The representation of a related set of concerns. A view is what is seen
from a viewpoint. An architecture view may be represented by a model to demonstrate
to stakeholders their areas of interest in the architecture. A view does not
have to be visual or graphical in nature.
Viewpoint: A definition of the perspective from which a view is taken. It is a
specification of the conventions for constructing and using a view (often by means
of an appropriate schema or template). A view is what you see; a viewpoint is
where you are looking from – the vantage point or perspective that determines
what you see.
As most of these kinds of disciplines have roots in a very technological environment
(e.g., information technology), the Enterprise Architecture has gained
maturity by taking more and more the views and viewpoints of the business and its
strategies.1 Nowadays, every definition of Enterprise Architecture encompasses all
the levels, beginning at the business architecture down to the technology.
Source 3 chpt 1

Architecture is the fundamental organisation of a system embodied
in its components, their relationships to each other, and to the environment,
and the principle guiding its design and evolution.
Stakeholder: an individual, team, or organisation (or classes
thereof) with interests in, or concerns relative to, a system.
Enterprise: any collection of organisations that has a common set
of goals and/or a single bottom line.
Enterprise architecture: a coherent whole of principles, methods,
and models that are used in the design and realisation of an enterprise’s
organisational structure, business processes, information systems,
and infrastructure.
Source 4 chpt 2
Given that the main purpose of an enterprise architecture is to align the design of an
enterprise to its strategy, the essential meaning of an enterprise architecture is that it
provides a normative restriction of design freedom toward transformation projects
and programs (or put more positively: a reduction of design stress). This was already
illustrated in Fig. 2.5 (page 18).
As discussed before, one might counter the point that the meaning of an enterprise
architecture is a normative restriction of design freedom by saying that it
should also provide guidance to programs and projects.
Finally, as a summary we will now provide a definition of enterprise architecture
which summarizes our understanding of the concept of enterprise architecture. However,
before doing so, we first define the general concept of architecture in general.
ARCHITECTURE Those properties of an artifact that are necessary and sufficient to
meet its essential requirements. This definition also shows the clear distinction between a
design and an architecture.
While the design provides a full elaboration of ‘the design’ of an artifact such that it leaves
no room for undesired results in the implementation, the architecture focuses on how the
essential requirements will be met.
The definition of architecture, allows us to summarize our understanding of enterprise
architecture as ENTERPRISE-ARCHITECTURE The architecture of an enterprise. As such,
it concerns those properties of an enterprise that are necessary and sufficient to meet its
essential
requirements.
Fehskens defines architecture as “those properties of a thing
and its environment that are necessary and sufficient for it to be fit for purpose for
its mission”. In his view, architecture should focus on what is essential, on “the stuff
that matters”.
Source 5 chpt 3
3.4.1 Definitions of Enterprise Architecture
Before providing our definition of enterprise architecture, we start with a discussion
of some of the existing definitions of IT/information/enterprise architecture:
• The Institute of Electrical and Electronics Engineers (IEEE) defines architecture
as: “An architecture is 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 [60].”

• The Open Group’s Architectural Framework (TOGAF) defines architecture as:
“Architecture has two meanings depending upon its contextual usage: (1) A formal
description of a system, or a detailed plan of the system at component level
to guide its implementation; (2) The structure of components, their interrelationships,
and the principles and guidelines governing their design and evolution
over time [139].”
• The Clinger–Cohen Act’s definition of IT architecture is: “The term “information
technology architecture,” with respect to an executive agency, means an integrated
framework for evolving or maintaining existing information technology
and acquiring new information technology to achieve the agency’s strategic goals
and information resources management goals [142].”
• The Netherlands Architecture Forum (NAF), defines architecture conceptually as
“a normative restriction of design freedom” and operationally as “a set of design
principles [154].” As a background to this definition, NAF writes: “In general,
the design freedom of designers is undesirable large. The idea of architecture is
to take advantage of this. Therefore, architecture is defined as normative restriction
of design freedom. This idea of consciously applying normative restriction
of design freedom is the really new thing. It makes architecture a prescriptive
notion; any descriptive interpretation is cogently rejected.”
• The ArchiMate Foundation defines enterprise architecture to be “A coherent
whole of principles, methods, and models that are used in the design and realization
of an enterprise’s organizational structure, business processes, information
systems, and infrastructure [78].”
• The current architecture definition of Capgemini is: “An architecture is a set of
principles, rules, standards, and guidelines, expressing and visualizing a vision
and implementing concepts, containing a mixture of style, engineering, and construction
principles.”
• A recent definition from the Gartner Group is: “Enterprise architecture (EA) is
the process of translating business vision and strategy into effective enterprise
change by creating, communicating, and improving the key principles and models
that describe the enterprise’s future state and enable its evolution.”
The variety in these definitions does seem to indicate that the field of enterprise
architecture is still in its infancy. At the same time, however, the wide spread attention
of enterprise architecture does indicate that enterprises do feel a profound need
to steer their development (including their business and IT portfolio), and that they
are looking toward enterprise architecture as a means to fill this need.
Key concepts of EA
Source 4 chpt 2
2.5.3 The Elements of an Enterprise Architecture
As discussed by Op ’t Land et al. (2008), key concepts in the field of enterprise architecture
include concerns, architecture principles, models, views and frameworks.
An enterprise has many stakeholders, and the future development of the enterprise
is likely to impact on the interests of these stakeholders. A stakeholder typically
is an individual, a team, or an organization (or classes thereof) with interest
in, or concerns relative to, a system (such as an enterprise).
Concerns are interests pertaining to the system’s development, its operation or any other
aspect that is critical or otherwise important to one or more stakeholders. In making
decisions about an enterprise’s future directions, stakeholders want to obtain insight into the
impact these directions will have on their concerns, and understand the risks involved in
current and future initiatives. Even more, since present day enterprises are complex

social systems of interrelated processes, people and technology, stakeholders are
keen on finding a way to harness this complexity when judging the impact on their
concerns.
According to TOGAF, architecture principles are general rules and guidelines,
intended to be enduring and seldom amended, which inform and support the way
in which an organization sets about fulfilling its mission. Op ’t Land et al. (2008)
position architecture principles as a way to capture an univocal understanding about
what is of fundamental importance to the enterprise. Given the central position of
architecture principles in this book, the ensuing chapters will provide a more elaborate
discussion on the nature and definition of architecture principles. The IEEE
(2000) definition of architecture: 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 also explicitly refers to the role of principles in guiding the
design and evolution of systems.
Models are generally understood to be purposeful abstractions of (some relevant
part of) reality (Falkenberg et al. 1998). Models can be used to represent systems,
and actually can be regarded as systems themselves. For example, Apostel (1960)
defines a model as a system representing another system: “any subject using a system
A that is neither directly nor indirectly interacting with a system B, to obtain
information about the system B, is using A as a model for B”. In colloquial use, in
the context of enterprise architecture, the term model is equated to some diagram.
This colloquialism can be explained as most models used in process modeling and
software development are graphical models. Models, however, do not necessarily
have to be graphical. In the context of enterprise architecture, a multitude of models
are used that describe different aspects:
• Different levels of realization: from conceptual via logical to physical.
• Different aspects of transformation: from contextual (why) via design (where to)
to the actual transformations (how).
• Different aspects of enterprises: from goals via services, products and processes
to IT.
• Different levels of aggregation: from enterprise level to the level of specific (partial)
processes or applications.
It is in these models where we will find the components, their relationships to each
other, and to the environment as referred to by the IEEE (2000) definition of architecture.
Gundars Osvalds and
Annapolis Junction 2001
Model—An Architecture Model contains data, process, hardware, personnel, performance,
organization, and interface descriptions that define the system. The model may use any
format that is appropriate to the documentation of the mission.
Contains what defines a system in terms of data captured into the system, processes
followed to implement the system and making use of the system, hardware components,
operational performance, organization and interface description and peoples using the
system. Model used can be any validated method on the document of processes and
missions of the enterprise.
A view is a representation of (a part of) a system from the perspective of a related
set of concerns (IEEE 2000). Different views based upon the stakeholders
concerns are an important communication means to obtain the cooperation of the

stakeholders. Views are typically derived from models. While models focus more on
completeness in coverage and detail, views focus more on tuning the content
toward the concerns of stakeholders. To provide architects with some structure to select
views, architecture frameworks have been introduced. These frameworks intend to aid
architects by providing an ontology, which uses different abstraction levels to map all kinds
of information needed.
View—An Architecture View is one or more abstractions of the stakeholder perspectives. A
view may be from the point of the owner, user, developer, designer and implementer. These
views may contain Physical, Logical, Conceptual and Contextual representations
Architecture frameworks position architecture results and enable diverse
communication (stakeholders, detail). Often tools and best practices are included in
the framework to support the work needed.
GundarsOsvaldsandAnnapolisJunction2001
Architecture Framework—An Architecture Frame-work provides guidance for the description
of the information system via the use of views and models. “The Framework, as it applies to
enterprises, is a logical structure for classifying and organizing the descriptive
representations of an enterprise that are significant to the management of the enterprise as
well as to the development of the enterprise’s sys-tems." (Zachman, 1998).
2.6 Stakeholders and Their Concerns
To understand the patterns presented in this book we first identify the stakeholders
and describe their concerns. In terms of Enterprise Architecture development we
are talking about the different architectural viewpoints. This gives us the possibility
to find the suitable language (architectural descriptions) to meet their
expectations. For each stakeholder we describe first his role and then list his
possible concerns and how we intend to respond to them in a suitable language in
terms of EAPs. The stakeholders will of course use modeling or visualization
techniques other than EAPs. By defining how we intend to respond to the diverse
concerns with the patterns presented in this book, we are also gathering requirements
on what kind of information the EAPs should provide and motivate their
use. We mostly deal with four types of stakeholders:
1. Stakeholders whose concerns address the consistency of the overall architecture
or the strategic direction to follow in accordance with the business goals. In the
context of this book this stakeholder corresponds to the Enterprise Architect.
2. Stakeholders that are mainly involved during an ICT project to build or change
a system. These are the Project Sponsor, the Solution Architects, Business
Analysts, and Project Leaders.
3. Stakeholders that are charged with strategic planning, decision making. Very often,
this is aChief InformationOfficer (CIO) or another personwhois involved in defining
the strategy of how ICT should be used to best support meeting the business goals.
2.5 Reusability 17
4. Stakeholders that are responsible for the controlling of how efficient ICT is used
in an enterprise. This is typically an internal auditor or a controller. By comparing
EAPs to the actual ICT landscape he gains an impression of how well

ICT is aligned to strategic goals.
Methods to create an EA
Source 3 chapt 2
2.2.1 Enterprise Architecture Methods
TOGAF
Source 3 chapt 2
− The TOGAF Architecture Development Method (ADM) (see Sect.
2.2.4), developed by The Open Group, provides a detailed and well described
phasing for developing an IT architecture. The current version
of TOGAF (The Open Group 2009a) provides a framework and development
method for developing enterprise architectures.
 The Open Group Architectural Framework (TOGAF)—Although called
a framework, is actually more accurately defined as a process
The Open Group Architectural Framework, or TOGAF, is one of the most common framework
structures in business today.
TOGAF accounts for over 80 percent of the entire business framework structure.
It contains all the needed pieces for a powerful framework. It has a common vocabulary to use,
recommended standards and compliance methods, suggested software and tools, and even a
method to define best practices.
Created and owned by The Open Group, TOGAF is as much an engine as a framework.
It holds the steps and keys to creating independent architecture. This method of creation is the
Architectural Development Method or ADM.
TOGAF is often viewed as more an overarching process. The details and methods contained
within TOGAF help guide businesses through any step of business organization.
The Open Group Architecture Framework (TOGAF, The Open Group 2003) is an attempt to
standardize the second type of frameworks. It is largely based on the EA work undertaken in the
government of the United States, but also other EA efforts have been incorporated to this
comprehensive EA knowledge base. At the heart of the often domain specific, “rich” type of
frameworks, there is also a basic set of views. The four architectures, business, information,
applications and technologies are the major architectural views that can be found in the second type
of frameworks. Besides, these frameworks often outline the process for EA management. The
architecture development method, ADM is the EA process description in TOGAF
The four architectures, business, information, applications and technologies are the major
architectural views that can be found