Enterprise Architecture

Lecture 1. Lecture notes

Contents

1. The Purpose of Enterprise Architecture ........................................................................... 2

2. The standards history ...................................................................................................... 3
3. Introsuction to Zachman and Togaf ................................................................................. 6
References ........................................................................................................................ 10

1
 Enterprise Architecture

1. The Purpose of Enterprise Architecture

This is the first module, in which we are going to cover the basics and key definition of
Enterprise Architecture field of study.
In order to get the feeling about the importance of Enterprise Architecture as a
discipline, let us consider how complex the modern managerial tasks are. Let us consider a
reorganizational project of a manufacturing enterprise. Imagine you have to implement a
number of changes in the structure of business. Normally, the starting point would be a
technological process. You have to change the baseline of company processes. This will be
followed by reengineering of business processes, which means changing how the processes
are run, sometimes changing the owner and key resources. Business processes
reengineering is normally linked to redesign of organizational structure of the company, the
departments functionality and information flows. The processes performance can be also
digitized with implementation of information systems. We might have to implement new
software or change the existing. Software changes might also lead to switching database
management systems or even infrastructure changes in terms of hardware. This “chain”
leads to two main questions: what else and how to control complexity?
By complexity we mean fundamental organization of a system and organizational
components (including departments, people, software, hardware and other). Internal and
external relationships. Basic principles of the organizations to guide the design. All these
points summarize the complexity of any organizational projects, which might be linked to
information technology or not.
And here we come to the question why to use Enterprise Architecture. There must be
a structure and a process in place to provide a blueprint – translation from a business idea
of change to the technical steps and components. Enterprise Architecture (EA) is playing
this role by looking at the problem from multiple angles of enterprise perspectives,
interfacing and connecting the dots for multiple stakeholders in the game.
If we consider Enterprise Architecture as a tool for business analysis and development,
we shall recognize that it provides a holistic view of the enterprise. This means that EA as a
tool will help to avoid local optimization within individual domains. Though there are even
more internal and external factors, which require complex approach.
The key internal factor to use Enterprise Architecture is the need of Business and IT
alignment. Those, who are experienced in software projects, would probably admit that
sometimes software is implemented just to be implemented. This is crucial for successful
digitalization. IT have to solve business tasks. IT strategy has to fit Business strategy. Top-
management has to support this idea on strategic level and execution level. Organizational

2
 Enterprise Architecture

structure and business processes have to be integrated with IT infrastructure to create a

pure digital enterprise [1]. The figure 1 represents the linkage described previously.

Figure 1 – The Business and IT alignment

Moving on to external factors, it can be admitted that these factors are not obvious.
Sometimes regulatory framework requires clear possessing of company development goals
and strategy in order to be competitive. Companies would struggle without a specific tool in
the described environment.
2. The standards history

Now when we understand Why Enterprise Architecture can be needed let us move
back and try to understand how it evolved. All this came from information systems
implementation and the question of its planning. Complex software cannot be implemented
straight forward. This is quite obvious. The idea of deliberate information systems planning
is far from new. Early planning approaches proposed various considerations on how to
design corporate information systems based on an organizational strategy, data flows
between departments, suppliers and orders, critical success factors, management

3
 Enterprise Architecture

information requirements. One of the first concepts, called Business Systems Planning
(BSP) methodology, was initiated by IBM in the 1960s. At first, it was for IBM internal use
only; later it was made available to customers. Its focus on data and especially on processes
was an entirely new way business to view the firm and to build; this process approach has
since been strategic methodology [2]. The first edition of BSP, which you can see in the
figure 2, resembled many important aspects of modern EA approaches. We start from
business processes definition (skipping steps 1-3 which are initiation). We analyze current
information technology and work with stakeholders. We move further to recommendations
development. And quite soon you will see that modern approaches have the same basics.

Figure 2 – Business System Planning

Further BSP evolved into the early Enterprise Architecture approaches, which were
proposed by Spewak and Hill. They actually paid more attention to technical aspects of EA,
but already started describing current and future states and preparing implementation plan.
Later on the modern approaches appeared and one of the most widespread is TOGAF. The
standard focuses on baseline and target architecture, covering different domains and being
iterative in nature. This means that its ultimate goal is to plan and manage corporate
development in business and technology domains.
TOGAF was initiated in the early 1990s as methodology for the development of
technical architecture, and has been developed by The Open Group into an extensive
enterprise architecture framework. In 1995, the first version of TOGAF (TOGAF 1.0) was
presented. This version was mainly based on the Technical Architecture Framework for
Information Management (TAFIM), developed since the late 1980s by the US Department
of Defense [3]. The steps of EA evolution are presented on table1.

4
 Enterprise Architecture

Table 1 - The EA evolution

Aspect BSP Early EA Modern EA

Time 1960s–1980s 1980s–1990s 1990s–present

Definitive BSP (1975) Spewak and Hill (1992) TOGAF (2011)

source

Domains Organization, processes, Business, data, Business, data,

data, and information applications, and applications, and
systems technology technology

Modeling Relationship matrices, info Lists, relationship Catalogs, matrices, and

rmation systems networks, matrices, and diagrams diagrams
and flowcharts

Methodology Describe current and desir
ed states, prepare an
action plan, and implement
it
Describe current and
future states, prepare an
implementation plan, and
implement it
Describe baseline and
target states, prepare a
transition plan, implement
the plan, and repeat the
process

Difference N/A Pays more attention to tec Iterative in nature

from the hnical aspects
predecessor

TOGAF, which we use today has actually appeared in 2011, while the very first mention
of Enterprise Architecture notation was in 1987 by John Zachman. So, before we move on
lets us summarize: 1960s - BSP emergence; 1980-1990s - the first EA works appear; 2010s
- the modern EA.
In the 1980s John Zachman had been involved at IBM in the development of business
system planning (BSP), a method for analyzing, defining and designing an information
architecture of organizations. In 1982 Zachman had already concluded that these analyses
could reach far beyond automating systems design and managing data into the realms of
strategic business planning and management science in general. It may be employed in the
(in that time considered more esoteric) areas of enterprise architecture, data-driven systems
design, data classification criteria, and more [4].

5
 Enterprise Architecture

The Zachman Framework appears to define Architecture as a set of primitive models.

Zachman defines 7 rules for using his framework:
1. Do not add rows or columns to the Framework.
2. Each column has a simple generic model.
3. Each cell model specializes its column’s generic model.
4. No meta concept can be classified into more than one cell.
5. Do not create diagonal relationships between cells.
6. Do not change the names of the rows or columns.
7. The logic is generic, recursive [5].
It is important to keep in mind that The Zachman Framework that you see today is NOT
a new Framework- it is a new Framework graphic.
The timeline of standards creation is presented on figure 3.

Figure 3 – The standards behind

3. Introduction to Zachman and TOGAF

Zachman EA is one of the first representations of EA. Originally it is called Zachman

Taxonomy. It provides a formal and structured way of viewing and defining an enterprise.
The ontology is a two dimensional classification schema. In columns we have: What, How,
When, Who, Where, and Why. In rows we have digitalization level. In cells we have different
types of models, which reflect this two dimensions. For example, for the contextual level we
have lists: business goals for “why”, processes for “how” and so on. The models are just
examples. They are not regulated strictly, but have to reflect the enterprise structure.

6
 Enterprise Architecture

TOGAF as an approach to realize TOGAF-type-architecture and Zachman as a

framework to get ideas for what models and diagrams to make or look for, is a good fit. In
practice there is often not enough time available to create all the Zachman models and
diagrams, a selection of the most important ones must be made.
John Zachman's Framework is way of categorizing and associate varies aspects of the
IT environment of an organization with each other. While TOGAF is overall process to plan,
organize, and deliver an Enterprise Architecture (EA) to the organization that will enhance
its ability to support the purpose of the organization. You can first define your EA with a
Zachman's Framework and then implement it with TOGAF.
Both TOGAF and the Zachman framework are enterprise architecture frameworks, not
web application frameworks. The comparison of TOGAF and Zachman is presented in the
table 2.

Table 2 - The TOGAF and Zachman comparison

Framework Description What it does When to use

TOGAF Leading EA development Creates an outline for As a guide for clear-cut

tool for step-by-step rapid and iterative architecture
architecture architecture development implementation and
implementation governance

Zachman Set of management rules Defines relationships To describe independent

presented in a form of a between different element without losing the
36-cell table perspectives and rules holistic view of a system

Figure 10 – Export of model in Archi

An enterprise application framework describes a set of architectural views that allow

us to graphically and textually display the flow of information or materials through an
organization. Taken together, all these views can allow decision makers to understand the
organization as a whole, which should shorten the time it takes for them to determine
strategic courses. Colloquially, we refer to the collected views as “an Architecture.” The
Zachman framework clearly describes using row-and-column matrices the architectural
products that are to be provided. Completely implemented, a Zachman architecture is a
comprehensive document that describes everything an organization does in exhaustive
detail. Zachman Enterprise Architecture Ontology – Offers a matrix for architecture artifacts
that are significant to the management of the Enterprise, as well as to the development, and
to multiple stakeholders – The rows of the grid represent different “player perspectives”

7
 Enterprise Architecture

(owner, designer, etc.) – The columns represent “technical perspectives” (What/Data,

How/Process, etc.).
Initially Zachman’s EA Framework looked more like a taxonomy providing good
places and names.
TOGAF, on the other hand, describes an Architecture Development Methodology
without clearly describing the artifacts that are to be developed using the methodology. The
Open Group Architecture Framework (TOGAF) - Focuses on Enterprise Continuum with
Architecture Development Method (ADM).
Now here is TOGAF standard structure. This is one of the modern representations of
EA. Here we have got 2 baseline elements: EA structure on the left and Architecture
Development Method or ADM on the right. EA structure has 5 levels. The top one is
Business Architecture, which defines requirements and drives Information Architecture. This
Information Architecture has to be supported by software, which is Information Systems
Architecture. These defines the data requires and further the specific software and
hardware. ADM supports analysis of current state of architecture and its development with
a number of steps, which are all interrelated with requirements management. We will cover
TOGAF standard in more details throughout the whole course. Now we need to emphasize
its important differences from Zachman (table 3).

Table 3 - Zachman framework

Data Function Network People Time Motivation
(What?) (How?) (Where?) (Who?) (When?) (Why?)

Objectives / List of things List of List of List of List of List of

Scope important to processes the locations organizational business business
the business business where the units events / goals /
performs business cycles strategies
operates

Business Entity Business Logistics Organization Business Business plan

Model relationship process network chart, with master
diagram model (nodes and roles; skill schedule
(Semantic (physical data links) sets; security
model) flow diagram) issues.

Information Physical Data Essential Distributed Human Dependency Business rule

System model Data flow system interface diagram(proc model
Model diagram; architecture architecture essing
application structure)
architecture

8
 Enterprise Architecture

Technology Data System System User "Control flow" Business rule

Model architecture; design: architecture interface; diagram design
map to legacy structure (hardware, security (control
data chart, software design structure)
pseudo-code types)

Detailed Data design, Detailed Network Screens, Timing Rule

Representati physical Program architecture security definitions specification
on storage Design architecture in program
design logic

Function Converted Executable Communicati Trained Business Enforced

System data programs ons facilities people events rules

The most important element of TOGAF is ADM and the design structure (figure 4).
TOGAF is originally designed to manage company development, it helps to model the
enterprise in dynamics. And this aspect is one of the most important characteristic of any
tool in today’s rapidly changing world [6].

Figure 4 - TOGAF Standard, Version 9.2

9
 Enterprise Architecture

References

1. De Haes, S., & Van Grembergen, W. (2015). Enterprise Governance of IT,

Alignment and Value. In Enterprise Governance of Information Technology (pp. 1-
10). Springer, Cham
2. Albert L. Lederer. Joseph M. Katz Graduate School of. Business. University of
Pittsburgh. Pittsburgh, PA 15260 . (IBM, 1975; Lederer and Putnam, 1986)
3. Marc Lankhorst (2013) Enterprise Architecture at Work: Modelling, Communication
and Analysis p. 23
4. Business Systems Planning and Business Information Control Study: A
comparisment. In: IBM Systems Journal, vol 21, no 3, 1982. p. 31-53.
5. Sowa, J.F. & J.A. Zachman, 1992, and Inmon, W.H, J.A. Zachman, & J.G. Geiger,
1997. University of Omaha
6. The TOGAF® Standard, Version 9.2 Overview (1995-2019) Retrieved from:
https://www.opengroup.org/togaf

10