1

TDT4252
Modelling of Information Systems
Advanced Course

Sobah Abbas Petersen

Adjunct Associate Professor
[email protected]

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
2

Today’s lecture
• Introduction to Enterprise Architecture,
• Zachman’s EA Framework, TOGAF
• Based on slides from Spring 2010 by Harald Rønneberg.
• Based on:
A16: Roger Sessions,
A Comparison of the Top Four Enterprise-Architecture M
ethodologies, White Paper, ObjectWatch Inc. May 2007
.

Additional Information on Zachman’s Framework:

• http://test.zachmaninternational.com/index.php/the-zachman-framework
– The Open Group Architecture Framework (TOGAF) – The continuing Story, Chris Greenslade,
2002. (http://www.enterprise-architecture.info/Images/Documents/Togaf%20seminar.pdf)
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
3

Why Enterprise Architecture?

• Twenty years ago, a new field was born that
soon came to be known as enterprise
architecture. The field initially began to
address two problems:
– System complexity—Organizations were spending more and
more money building IT systems; and
– Poor business alignment—Organizations were finding it
more and more difficult to keep those increasingly expensive
IT systems aligned with business need.

The bottom line: more cost, less value .

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
4

Enterprise Architecture
• We will look at the most popular
Enterprise Architectural methodologies:
– The Zachman Framework for Enterprise.
– The Open Group Architectural Framework
(TOGAF).
– The Federal Enterprise Architecture (FEA).
– The Gartner Methodology.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
5

What is Enterprise Architecture?

• An enterprise?
– An organizational unit – from a
department to a whole corporation.

• An architecture?
– A formal description of a system, or a
detailed plan of the system at
component level to guide its
implementation.
– The structure of components, their
inter-relationships, and the principles
and guidelines governing their design
and evolution over time. TOGAF

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
6

What is Enterprise Architecture?

• A formal description of an
enterprise, a detailed map of the
enterprise at component level to
guide its changes. External Systems
ORIGO
”AS IS” Solution Overview
- Wet Supply Chain -

Material Movement
OD Orders SAP Credit Exposure
Credit
Warehouse (OPIMIS)
P&L Warehouse
VAR

• The structure of an enterprise’s

Materials Sales Orders
Business Partners Purchase Orders
Business Objects
Reports Report Data KVAR+
Report Data

Master Master
OCD Data Positions
Data
Exposure
RAMSES Volume
P&L
Quality SPORT RATS Positions
RAF Exposure

Pandion

components, their inter-

Brent/Dubai
Invoices
Stock Level Operations
Nominations Operational
Details Energy Server
Nominations
Voyage Info Price Info
O&S Deal Id Deal/Delivery Info
Deal/Delivery Info Trading Balance Other WSC systems
SIS 3 Vessel Info
Production Field
WebICE
Nominations Vestprosess Telex/Fax Info

relationships, and the principles

Voice-Logg
Offshore Contracts
User Info Free Format Telex
Report Data
Excel Reports
Tradenet
Message
PROSTY
Volume Manager
Quality
Deal Info Reuters
(Positions)
Price Info
Exports

and guidelines governing their

User Info
Cargo Position
Shipment and Deal link Management Etrade Hub
Partner Documents
Contracts
Allocation allocation Free Format Telex (Common Notification
Book) to be sent
Deal Info Captured deals
CRBA DCF

TOPS -
User TOPS Trading
Physical Deal
Role Web
Maintenance

design and evolution over time.

New Java based systems Notification

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
7

The Open Group

Enterprise Architecture is about understanding

all of the different components that go to make
up the enterprise and how those components
inter-relate.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
8

Wikipedia Spring 2007

Enterprise Architecture is the practice of applying a

comprehensive and rigorous method for describing a current
and/or future structure and behavior for an organisation's
processes, (information) systems, personnel and organizational
sub-units, so that they align with the organization's core goals
and strategic direction. Although often associated strictly with
information technology, it relates more broadly to the practice of
business optimisation in that it addresses business architecture,
performance management, organizational structure and process
architecture as well.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
9

IFEAD

Enterprise architecture is a complete expression of the

enterprise; a master plan which “acts as a collaboration
force” between aspects of business planning such as goals,
visions, strategies and governance principles; aspects of
business operations such as business terms, organization
structures, processes and data; aspects of automation
such as information systems and databases; and the
enabling technological infrastructure of the business such
as computers, operating systems and networks.

IFEAD is an independent research and information exchange organization working on the future state of Enterprise
Architecture.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
11

Gartner
• A planning discipline for the enterprise that
goes beyond technology choices:
– Driven by the strategic intent of the enterprise
– Holistic in breadth
– Designed to create a future-state “road map”
– Provides flexibility and adaptability for changing business,
information, and solution needs => change enabler
– A bridge between strategy and implementation

Strategy Architecture Implementation

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
12

EA Bridges Strategy and Implementation

Business architecture
Information architecture
Solution architecture
Technology architecture

Business Strategy Implementation

Business drivers Business processes
Business goals Application systems
Business policy Tech infrastructure
Trend analysis Organizational structure

The bridge between strategy & implementation

Lecture 14 - Enterprise Architecture:
TDT4252, Spring 2013
Zachman, TOGAF
13

The Enterprise View

 Why do this at the
ENTERPRISE level?
– To overcome religious
wars concerning
technology choices within
projects.
– To provide consistent
and disciplined use of
technology.
– To reduce stovepipe
solutions & reduce
integration complexity.

Source: Adaptive Corp.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
14

The Enterprise View

• An enterprise perspective identifies the big-picture
interrelationships & interdependencies to make
appropriate optimisation and suboptimisation
decisions
– Look at “the whole,” not the parts
– Look beyond narrow and restricted views
– Look for context from the top
The quality of all IT decisions is dependent on the
enterprise view

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
15

EA is a path, not a destination!

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
16

Why do I need an EA?

– The purpose of enterprise architecture is to optimise
across the enterprise the often fragmented legacy of
processes (both manual and automated) into an
integrated environment that is responsive to change
and supportive of the delivery of the business strategy.
– Thus the primary reason for developing an EA is to get
an overview (map) of the business’ processes,
systems, technology, structures and capabilities.
– I need an EA to provide a strategic context for the
evolution of the IT system in response to the constantly
changing needs of the business environment.
– I need an EA to achieve competitive advantage.
TOGAF

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
17

What is the value of EA?

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
18

The value of EA
You invest in EA in order to enable you to do something
you otherwise are unable to do.

The value of EA:

 Business - IT and business – business alignment

 Change enabler

 Improved agility to enable a real time enterprise

 Standardisation, reuse and common principles, terms

and work practices
 Integration and interoperability

 Structure, multiple perspectives and documentation

Zachman

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
19

Alignment
Common
understanding!

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
 Bridging the gap between Business
20

and IT
• Enhance the relationships
between IT and the business
• Reinforce IT understanding of
the business strategy
• Create a process for continuous
IT/business alignment.
• Enhance IT agility to support
business changes
• Create business value from IT
21

Value for the IT organization

– Deeper understanding of organisational strategic intent
– Correct IT investment allocation
– Realized economies of scale
– Elimination of redundancies
– Reduced IT delivery time due to reuse
– Higher-quality decision making at all levels
– An organization that works on the right things at the
– right time
– Selection/identification of correct technologies/functionality
required by the organisation
– An understanding of what we are doing and why and how
individual roles and responsibilities support
– Creation of an environment for enterprise success
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
22

EA Timeline

Sessions, 2007

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
23

EA – Key Concepts
• Stakeholders’ concerns – interests that are critical or
important to other stakeholders.
• Principles – a univocal understanding about what is
of fundamental importance for the organisation.
• Models – purposeful abstractions of reality.
• Views – difficult to make a univocal and
comprehensive set of models that can be understood
by all concerned, hence views.
• Frameworks – structure to select views.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
24

Example Case: MedAMore

• MedAMore is a chain of drug stores, which started as
a regional chain in 1960.
• IT system to run drug stores: MedAManage (MAM).

MAM

MAM/ MAM/ MAM/

Store Warehouse Home

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
25

Example case contd.

• By 2002, MedAMore had expanded into the other
parts of USA. The company started experiencing
some problems:
– MAM/Store required regional specialisation.
– Differences in routines in the different regional warehouses required
changes to the different MAM/Warehouse models.
– Difficulty in coordinating the file transfer approach and information
sharing across the different modules.
• Some of the challenges were:
– Difficult to change functions without affecting several million lines of
code.
– Debugging was difficult.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
26

Example case contd.

• Internal conflicts between the
technical and the business side.
– Business side saw IT as reducing business
agility.
– IT side saw the business side as making
impossible demands.
 Crisis!

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
27
Enter Enterprise Architecture!
MAM-EA

Cath, CEO

Bret, Business Manager Irma, CIO

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
28

Zachman’s Framework (1)

• Zachman's vision was that business value and agility
could best be realized by a holistic approach to
systems architecture that explicitly looked at every
important issue from every important perspective. His
multiperspective approach to architecting systems is
what Zachman originally described as an information
systems architectural framework and soon renamed
to be an enterprise-architecture framework.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
29

Zachman’s Framework (2)

• The Zachman Framework is an ontology for
describing the Enterprise.
• A logical structure for classifying and
organizing the descriptive representation of
an Enterprise.
• Neutral with regard to the processes or tools
used for producing the description.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
30

Zachman’s Framework (3)

• According to Sessions, the Zachman "Framework" is
actually a taxonomy for organizing architectural artifacts
(in other words, design documents, specifications, and
models) that takes into account both who the artifact
targets (for example, business owner and builder) and
what particular issue (for example, data and functionality)
is being addressed.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
31

Zachman’s EA Framework
TM
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA

List of Things Important

What FUNCTION

List of Processes the

How NETWORK Aspect Where PEOPLE Who When MOTIVATION Why

s
SCOPE List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat SCOPE
to the Business Business Performs the Business Operates Important to the Business to the Business
(CONTEXTUAL) (CONTEXTUAL)

Planner ENTITY = Class of Function = Class of Node = Major Business

People = Major Organizations Time = Major Business Event
Ends/Means=Major Bus. Goal/ Planner
Business Thing Business Process Location Critical Success Factor
e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE
ENTERPRISE System
MODEL MODEL
(CONCEPTUAL) (CONCEPTUAL)
Viewpoints

Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective
Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = W ork Product Cycle = Business Cycle Means = Business Strategy
e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System e.g. Human Interface e.g. Processing Structure e.g., Business Rule Model
SYSTEM
SYSTEM Architecture Architecture
MODEL
MODEL (LOGICAL)

View
(LOGICAL)

Node = I/S Function

Ent = Data Entity Proc .= Application Function (Processor, Storage, etc) People = Role Time = System Event End = Structural Assertion
Designer Reln = Data Relationship Cycle = Processing Cycle
Designer
I/O = User Views Link = Line Characteristics Work = Deliverable Means =Action Assertion
e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY
TECHNOLOGY
MODEL MODEL
(PHYSICAL) (PHYSICAL)

Node = Hardware/System
Builder Ent = Segment/Table/etc. Proc.= Computer Function Software People = User Time = Execute End = Condition
Reln = Pointer/Key/etc. I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Cycle = Component Cycle Means = Action

DETAILED e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED
REPRESEN- REPRESEN-
TATIONS TATIONS
(OUT-OF- (OUT-OF
CONTEXT) CONTEXT)

Sub-
Contractor Ent = Field Proc.= Language Stmt Node = Addresses People = Identity Time = Interrupt End = Sub-condition
Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step Contractor

FUNCTIONING FUNCTIONING
e.g. DATA e.g. FUNCTION e.g. NETW ORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE ENTERPRISE
21
John A. Zachman, Zachman International (810) 231-0531

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
32

Zachman’s Framework –Description (1)

• 2 perspectives:
– “Players in the game”
– Artefacts required by the different players
• Both of these perspectives on data are critical for
obtaining a holistic understanding of the enterprise.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
33

Zachman’s Framework –Description (2)

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

• Aspects:
– Data (what) – data needed for the enterprise to operate.
– Function (how) – concerned with the operation of the enterprise.
– Network (where) - concerned with the geographical distribution of
the enterprise’s activities.
– People (who) - concerned with the people who do the work,
allocation of work and the people-to-people relationships.
– Time (when) – to design the event-to-event relationships that
establish the performance criteria.
– Motivation (why) – the descriptive representations that depict the
motivation of the enterprise. It will typically focus on the objectives
and goals.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
34

Zachman’s Framework –Description (3)

Stakeholders

• Layers or views (players):

Scope – Scope: a "bubble chart" or Venn diagram, which depicts in gross
Contextual
Planner terms the size, shape, partial relationships, and basic purpose of
the final structure.
Enterprise
Conceptual – Enterprise or business model: the design of the business or the
Owner
architect’s drawing.
Systems – System model: translations of the drawings into detailed
Logical specifications. Corresponds to a systems model by a systems
Designer
analyst.
Technology – Technology model: the architect’s model translated to a builder’s
Physical
Builder model.
Detailed
– Detailed representations: detailed specifications given to
Contextual programmers.
Sub-
contractor – Functional enterprise: a system is implemented and made a part of
the enterprise.
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
35
3 suggestions to help
MedAMore
• Every architectural artefact should live on one and
only one cell.
• An architecture can be considered a complete
architecture only when every cell in that architecture
is complete.
• Cells in column should be related to each other.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
36
How can Zachman's grid help
MAM-EA?
• Ensure every stakeholder's perspective is
considered.
• Improve MAM-EA artifacts by sharpening each of
their focus points
• Ensure all business requirements can be traced
down to some technical implementation.
• Convince Bret that Irma's group is not implementing
useless functionality.
• Convince Irma that the business department is
including her in their planning.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
37

Zachman’s Framework
• Strengths:
– A comprehensive taxonomy to describe the enterprise.
• Weaknesses:
– Does not give us step-by-step process for creating a new
architecture.
– Doesn't even give us much help in deciding if the future
architecture we are creating is the best architecture possible.
– Does not give us an approach to show a need for a future
architecture.
• For MEM-EA – it does not give a complete solution,
e.g. does not describe a process for creating a new
architecture.
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
38

What is Enterprise Architecture?

• An enterprise?
– An organizational unit – from a
department to a whole corporation.

• An architecture?
– A formal description of a system, or a
detailed plan of the system at
component level to guide its
implementation.
– The structure of components, their
inter-relationships, and the principles
and guidelines governing their design
and evolution over time. TOGAF

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
39

Enterprise Architecture

• An architecture
– A formal description of a system, or
a detailed plan of the system at
component level to guide its
implementation.
– The structure of components, their
inter-relationships, and the
principles and guidelines governing
their design and evolution over time.

TOGAF

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
40

The Position of IT Architects

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
41

TOGAF – consists of
• An Architectural Development Method (ADM)
• Foundation Architecture
– A Technical Reference Model (TRM)
– A Standards Information Base (SIB)
– Building Blocks Information (BBIB)

• Resource Base contains advice on:

– Architecture views, IT Governance, Business scenarios,
Architecture patterns, etc.

Greenslade, 2000-2002

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
42

TOGAF

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
43

TOGAF – Framework or Process?

• TOGAF describes itself as a Framework. But the

most important part of it is the Architectural
Development Method (ADM):
– ADM is a recipe for creating architecture.

• TOGAF is an architectural process (Roger Sessions).

• It complements Zachman’s Framework:
– Zachman tell you how to categorise artifacts; TOGAF provides a
process for creating them.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
44

TOGAF’s Enterprise Architecture

Describes the Describes how Describes how the Describes the

processes the specific enterprise hardware and
business uses to applications are datastores are software
infrastructure that
meet its goals. designed and how organised and
supports applications
they interact with accessed.
and their interactions.
each other.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
45

TOGAF Enterprise Continuum (1)

•TOGAF views the Enterprise Architecture as a

continuum of architectures, ranging from the highly
generic to the highly specific.

•It views the process of creating a specific enterprise

architecture as moving from the generic to the specific.

•TOGAF’s ADM provides a process for driving this

movement from the generic to the specific.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
46

TOGAF Enterprise Continuum (2)

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
 TOGAF Enterprise Continuum
47

and ADM
Generic
• Foundation Architectures:
– Most generic, architectural principles that can be used by any IT
organisation.
• Common System Architectures:
– architectural principles that may be found in many types of
enterprises.
• Industry Architectures:
– architectural principles that are specific across many enterprises that
are in the same domain.
• Organisational Architectures:
– Architectures that are specific to a given enterprise.
Specific
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
 TRM – Technical Reference
48

Model
• Any TRM has two main components:
1. A taxonomy, which defines terminology, and provides
a coherent description of the components and
conceptual structure of an information system.
2. An associated TRM graphic, which provides a visual
representation of the taxonomy, as an aid to
understanding.
• The objective of the TOGAF TRM is to provide a
widely accepted core taxonomy, and an
appropriate visual representation of that
taxonomy.
Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013
Zachman, TOGAF
49

Architecture Development Cycle -

ADM

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
50

ADM - Framework and Principles

Framework
and Bret, Business Manager
Principles
Teri,
TOGAF
Consultant Irma, CIO

 Define architecture
principles that drive
technological architectures
and document those.
 Choose framework and
customise.
 Request for Architecture
Work

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
51

ADM - Architecture Vision

 Define the scope of the
architecture project
A  Define high level business
Architecture
Vision requirements

 Statement of architecture
work/architectural vision, to be
approved by Stakeholders

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
52

ADM – Business Architecture

Teri, Bret, Business Manager

TOGAF
Consultant
B Business
Architecture
The objective is to define and describe
the product and/or service strategy, and
the organizational, functional, process,
information, and geographic aspects of
the business environment.
 Detailed baseline and target
business architecture and full
analysis of the gaps between them.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
 ADM: Informations Systems
53

Architecture – Data & Applications

Teri, Irma, CIO

TOGAF
Consultant

The objective is to define the major types

and source of data necessary to support
C
Data the business. It is NOT about database
Architecture
Information design. The goal is to define the data
System
Management
Architecture entities relevant to the enterprise.

Applications
Architecture  Target information and application
architecture.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
54

ADM: Technical Architecture

Teri, Irma, CIO

TOGAF
Consultant

The objective is to define the technology

and technical services that will form the
basis of the following implementation work.

Management  Complete technical architecture: the

infrastructure necesary to support the
D proposed new architecture.
Technology
Architecture

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
55

ADM: Opportunities and Solutions

 The first phase directly concerned
with implementation
 How to close the gaps?

 Identify implementation projects

Focus on projects that will deliver short

Management term payoffs, e.g. the organisational
pain points such as difficulties in
completing regional /warehouse
specialisation and unreliability in data
E
Opportunities sharing.
and Solutions

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
56

ADM: Migration Planning

 Prioritize between implementation
projects

 i.e. project portfolio management

 Cost and benefit analysis
 Risk assessment
Management

F
Migration
Planning

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
57

ADM: Implementation Governance

 Architectural contract.
 Ensure compliance with the
defined architecture.
 Implementation
specifications – acceptance
criteria.
G
Implementation
Governance Management  Architectural specifications for the
implementation projects.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
58

ADM: Architectural Change Management

 Handle architecture change

requests
 Suggest new architecture
H Architecture
Change
projects
Management

Management

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
59

ADM: Requirements Management

 Handling new and changing
requirements from architecture
projects, IT projects, change
projects, operations, etc.

 Ready to start the phase again.

Requirements  One of the goals of the first cycle
Management
should be information transfer so that
Teri's consultancy services are
required less in the next cycle.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
60

TOGAF - benefits
+ TOGAF is flexible about the architecture that is
generated – ”architecture agnostic” or vendor neutral.
+ Comprehensive process, from business requirements
to applications to infrastructure.
• The final architecture may be good, bad or indifferent.
÷ TOGAF merely describes how to generate enterprise
architecture, not necessarily how to generate a good
one!

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
61

TOGAF and MED-EA

• The final architecture may be good or bad.

• It merely describes how to generate an architecture,

not necessarily a good one!
• A good architecture will depend on the experience of
the MedAMore staff and Teri, the TOGAF consultant.

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF
62

Next Lecture
• Continue Enterprise Architecture
– FEAF
– Gartner

Lecture 14 - Enterprise Architecture: TDT4252, Spring 2013

Zachman, TOGAF