TDT4252 Modelling of Information Systems Advanced Course: Sobah Abbas Petersen

1
TDT4252
Modelling of Information Systems
Advanced Course
Sobah Abbas Petersen

Adjunct Associate Professor
sap@idi.ntnu.no
Lecture 15 – Enterprise TDT4252, Spring 2011

Architecture
2
This Lecture
• Enterprise Architectures continued.
– TOGAF
– Gartner
– Based on lecture slides from Spring 2010, by Harald Rønneberg.
• Based on:
– A15: Roger Sessions,
A Comparison of the Top Four Enterprise-Architecture Methodologies, Wh
ite Paper, ObjectWatch Inc. May 2007
.
• Additional reading:
– The Open Group Architecture Framework (TOGAF) – The continuing
Story, Chris Greenslade, 2002. (http://www.enterprise-
architecture.info/Images/Documents/Togaf%20seminar.pdf)
Architecture
3
What is Enterprise Architecture –

recap

Architecture
4
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 - Introduction to TDT4252, Spring 2011
Enterprise Architecture
5
Alignment
Common
understanding!

6
Zachman’s EA Framework - recap

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 Ends/Means=Major Bus. Goal/ Planner
Business Thing Business Process People = Major Organizations Time = Major Business Event Critical Success Factor
Location
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 = Work 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. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY
ENTERPRISE ENTERPRISE
21
John A. Zachman, Zachman International (810) 231-0531

7
TOGAF
• The Open Group Architecture Framework
• The Open Group Forums – cooperation between
vendors and users, where a variety of common interests
are explored, one of which is architecture.
• Earlier versions of TOGAF available since 1995.
• Current version is 9.

Architecture
8
• 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
9
The Position of IT Architects

Architecture
10
The Position of IT Architects

Architecture
11
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

Architecture
12
TOGAF

Architecture
13
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.

Architecture
14
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.

Architecture
15
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.

Architecture
16
TOGAF Enterprise Continuum (2)

Architecture
17
TOGAF Enterprise Continuum

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
Architecture
TOGAF – Components of Foundation
18
Architecture

Architecture
19
TOGAF – Foundation Architecture

• The TOGAF Foundation Architecture is an architecture
of generic services and functions that provides a
foundation on which more specific architectures and
architectural components can be built.
• This Foundation Architecture is embodied within the
Technical Reference Model (TRM), which provides a
model and taxonomy of generic platform services.
• The TRM is universally applicable and, therefore, can
be used to build any system architecture.

Architecture
20
TRM – Technical Reference 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.

Architecture
21
TRM – High level view

The high-level TRM seeks to emphasize two
major common architectural objectives:
Application Portability, via the Application
Platform Interface — identifying the set of
services that are to be made available in a
standard way to applications via the platform.
Interoperability, via the Communications
Infrastructure Interface — identifying the set
of Communications Infrastructure services
that are to be leveraged in a standard way by
the platform.
Both of these goals are essential to enable

integration within the enterprise and trusted
interoperability on a global scale between
enterprises.

Architecture
22
Architecture Development Cycle -

ADM

Architecture
23
ADM - Framework and Principles

Framework
and
Principles
 Define architecture
principles that drive
technological architectures
and document those.
 Choose framework and
customise.

Architecture
24
ADM - Architecture Vision

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

Architecture
25
ADM – Business Architecture

The objective is to define and
describe the product and/or service
strategy, and the organizational,
functional, process, information, and
B geographic aspects of the business
Business
Architectur environment.
e
 Select viewpoints
 Describe TO-BE
 Describe AS-IS
 Analyse gaps between TO-BE
and AS-IS

Architecture
26
ADM: Informations Systems

Architecture - Data
The objective is to define the major types
and source of data necessary to support
the business. It is NOT about database
design. The goal is to define the data
entities relevant to the enterprise.
Data
C
Information
Architecture  Describe TO-BE
System
Managem
Architecture  Describe AS-IS
ent  Analyze gaps between TO-BE
Applications
Architecture and AS-IS

Architecture
27
ADM: Informations Systems
Architecture - Applications
The objective is to define the major kinds of
application necessary to process the data
and support the business. The goal is to
define what kind of applications are
relevant to the enterprise, and what they
need to do.
Data
Architecture
C  Describe TO-BE
Information
System
Architecture  Describe AS-IS
Managem
ent  Analyse gaps between
Applicat
Applications
Architecture
ions TO-BE and AS-IS
Architec
ture

Architecture
28
ADM: Technical Architecture

The objective is to define the technology
and technical services that will form the
basis of the following implementation work.
 Describe TO-BE
 Describe AS-IS
 Analyse gaps between TO-BE
Management
and AS-IS
D
Technology
Architecture

Architecture
29
ADM: Opportunities and Solutions

 The first phase directly concerned
with implementation
 How to close the gaps?
 Identify implementation projects
Management
E
Opportunities
and Solutions

Architecture
30
ADM: Migration Planning

 Prioritize between implementation
projects
 i.e. project portfolio management

 Cost and benefit analysis
 Risk assessment
Management
F
Migration
Planning

Architecture
31
ADM: Implementation Governance
 Architectural contract.
 Ensure compliance with the
defined architecture.
 Implementation
specifications – acceptance
criteria.
G
Implementation
Governance Management

Architecture
32
ADM: Architectural Change Management
 Handle architecture change

requests
 Suggest new architecture
H projects
Architecture
Change
Management
Management

Architecture
33
ADM: Requirements Management

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

Architecture
34
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!

Architecture
35
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

Architecture
36
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

37
From Strategy to Implementation

• Planning and Strategy
Enterprise
– Focused on integration of business Planning
and IT planning and Strategy
• Enterprise Architecture
– Goal is to provide the road map for
the enterprise
• Program Management Enterprise Enterprise
– Primary agent for implementing Program Architecture
enterprise transformation Management

Architecture
38
Gartner
• The Gartner EA methodology is a ”practice” – Sessions.
• It is an ongoing process of creating, maintaining, and
especially, leveraging an enterprise architecture that
gives the enterprise its vitality.

Architecture
39
Gartner
• EA is about creating a
Business Business
common understanding. Owners Owners
• Bringing together 3 Common
constituents: business owners, understanding
information specialists and
technology imolementers.
• If we can unify these behind a Business
common vision that drives the Owners
business value  success!

Architecture
40
Gartner x
• Enterprise Architecture must start where an

organisation is going, not where it is x
 focussed on destination.
• Recommends that an organisation begins by telling the
story of where its strategic direction is heading and
what the business drivers are to which it’s responding.
 Goal: everybody understands and shares a single
vision.
• As soon as an organisation has a single vision, the
implications on the business, technical, information and
solution architectures can be considered.

Architecture
41
Gartner Enterprise Architecture Method

The two major facets of the Gartner EA method are:
• Gartner Enterprise Architecture Process Model
Business Strategy
Environmental Trends
Architecting
Effort
Architecture Effort
Develop Develop Develop
Organize Architecture Requirements Principles Models
Future State Architecture
Closing
Governing & Managing the Gap
Organize
Current State Architecture

Documenting
• Gartner Enterprise Architecture Framework

Architecture
42
Gartner’s 4 Architectural Viewpoints

Three primary viewpoints:
– Business Architecture
– Information Architecture
– Technology Architecture
One meta-architecture
viewpoint
– Solution Architecture
Solution Architecture
Framework
– A framework for creating
Solution Architectures

Architecture
43

Business Architecture
– Defines and describes the current- and future- state models of business activities
(processes, assets and organization structure)
Information Architecture
– Defines and describes the current- and future- state models of the information value
chain, key information artifacts (concepts), information flows
Technology Architecture
– Defines and describes the current- and future- state models of the infrastructure and
technology platforms required for the solution architecture and which enables rapid
engineering, solutions development and technical innovation
– Combining and reconciling (integration) the loosely coupled and often conflicting
viewpoints of the primary stakeholders into a unified architecture
– Having divided to conquer, we must reunite to rule
– SA is a consistent architectural description of a specific enterprise solution
– An intersection of viewpoints

Architecture
44
Gartner Enterprise Architecture

Process Model
Business Strategy
Architecting
Effort

Architecture Effort
Requirements Principles Models

Organize Architecture
Closing
Organize

Documenting
Architecture
45
Principles
– Successful organizations establish guiding principles to support
consistent decision making, drive consistent behavior and drive cultural
changes.
– There is no perfect set of principles.
– Institutionalisation of principles, the process, is the difficult part.
– Principles are an extremely important component of governance and EA.

Architecture
46
From Forces to Enterprise Architecture
External ss e
e
Forces s i n tur
c
Bu ite
rch
A tion
rm a
Info ecture
it
Business Arch
Strategy Tec
Arch hnical
itec
ture
Arch
Solu ture
Internal
itec
tion
Forces

Architecture
47
Organise Architecture Effort

Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
48
Organise Architecture Effort - Activities
• State the goals

• Scoping
• Buy-in and commitment
• Stakeholder analysis
• Set time box
• Establish EA team

Architecture
49
Develop Requirements
Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
50
CRV - from strategy to business

requirements
Environmental
Trends
Enterprise
Business
Strategies
Business Business Information Business

Change Information Technology Solutions
Requirements Requirements Requirements Requirements
CRV = Common Requirements Vision

Architecture
51
What is CRV?
• A process for capturing, discussing and documenting a shared
common view of the strategic requirements driving the
enterprise:
 Position on the impact of Environmental
environmental trends to the enterprise Trends
 Set of enterprise business strategies Enterprise

Business
 Set of common strategic Strategies
requirements derived from

Business Business Information Business
enterprise business strategies Change Information Technology Solutions
Requirements Requirements Requirements Requirements
The CRV document is an articulation of what will drive the

enterprise’s future state

Architecture
52
CRV Best Practices

• Obtain as much business participation as early as
possible
• Remember that wording is very important
• Provide support with graphics
• Avoid excessive details
• Start with a “straw man” document
• Time-box the development effort

Architecture
53
CRV process - from trends to business

strategy
External
Forces
Business
Strategy
Internal
Forces

Architecture
54
CRV Challenges
• Business participation
• Integration with established strategy processes
• Level of details
• Wording

Architecture
55
Develop Principles
Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
56
Principles
– Successful organizations establish guiding principles to support
consistent decision making, drive consistent behavior and drive cultural
changes.
– There is no perfect set of principles.
– Institutionalisation of principles, the process, is the difficult part.
– Principles are an extremely important component of governance and EA.

Architecture
57
Develop Models
Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
58

Business Architecture
– Defines and describes the current- and future- state models of business activities
(processes, assets and organization structure)
Information Architecture
– Defines and describes the current- and future- state models of the information value
chain, key information artifacts (concepts), information flows
Technology Architecture
– Defines and describes the current- and future- state models of the infrastructure and
technology platforms required for the solution architecture and which enables rapid
engineering, solutions development and technical innovation
– Combining and reconciling (integration) the loosely coupled and often conflicting
viewpoints of the primary stakeholders into a unified architecture
– Having divided to conquer, we must reunite to rule
– SA is a consistent architectural description of a specific enterprise solution
– An intersection of viewpoints

Architecture
59
Four Levels of Abstraction

EBA EIA ETA ESA
Remember:
Business context
• Just enough models
just in time
• Avoid paralysis by
Conceptual analysis
• Future state before
current state
Logical
Implementation

Architecture
60
Current state and the gap

Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
61
Governing and Managing

Business Strategy
Architecting
Effort

Architecture Effort

Closing
Organize

Documenting
Architecture
62
Governing and Managing
Governing – key words:

– Governing EA artifact creation and changes – architecture review
board
– EA contract
– EA compliance or waiver
Managing – key words:
– Managing the EA program itself
– Management of the EA repository and its contents
– EA consulting to project team

Architecture
63
Gartner- benefits
+ Process completeness – the methodology fully guides
you through a step-by-step process for creatign EA.
+ Practical guidance.
+ Business focus.
+ Provides a methodology that can support governance.
÷ Does not provide a complete taxonomy.
÷ Not much information available about it.

Architecture
64
Summary
• Today, we have looked at the following Enterprise
Architecture Methodologies:
– TOGAF
– Gartner

Architecture
65
Next Lecture
• Monday 28 March 2011, 12-13hrs and 15-17hrs.
• Topic: SOAML, by Babak Farshchian

Architecture

TDT4252 Modelling of Information Systems Advanced Course: Sobah Abbas Petersen

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TDT4252 Modelling of Information Systems Advanced Course: Sobah Abbas Petersen

Uploaded by

Copyright:

Available Formats

1

Sobah Abbas Petersen

Lecture 15 – Enterprise TDT4252, Spring 2011

What is Enterprise Architecture –

Lecture 15 – Enterprise TDT4252, Spring 2011

EA Bridges Strategy and Implementation

Business Strategy Implementation

The bridge between strategy & implementation

Lecture 14 - Introduction to TDT4252, Spring 2011

Zachman’s EA Framework - recap

List of Things Important

List of Processes the

Node = I/S Function

Lecture 14 - Introduction to TDT4252, Spring 2011

Lecture 15 – Enterprise TDT4252, Spring 2011

The Position of IT Architects

Lecture 15 – Enterprise TDT4252, Spring 2011

The Position of IT Architects

Lecture 15 – Enterprise TDT4252, Spring 2011

• Resource Base contains advice on:

Lecture 15 – Enterprise TDT4252, Spring 2011

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF – Framework or Process?

• TOGAF describes itself as a Framework. But the most

• TOGAF is an architectural process (Roger Sessions).

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF’s Enterprise Architecture

Describes the Describes how Describes how the Describes the

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF Enterprise Continuum (1)

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF Enterprise Continuum (2)

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF Enterprise Continuum

Lecture 15 – Enterprise TDT4252, Spring 2011

TOGAF – Foundation Architecture

Lecture 15 – Enterprise TDT4252, Spring 2011

TRM – Technical Reference Model

• Any TRM has two main components:

Lecture 15 – Enterprise TDT4252, Spring 2011

TRM – High level view

Both of these goals are essential to enable

Lecture 15 – Enterprise TDT4252, Spring 2011

Architecture Development Cycle -

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM - Framework and Principles

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM - Architecture Vision

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM – Business Architecture

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM: Informations Systems

Lecture 15 – Enterprise TDT4252, Spring 2011

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM: Technical Architecture

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM: Opportunities and Solutions

 Identify implementation projects

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM: Migration Planning

 i.e. project portfolio management

Lecture 15 – Enterprise TDT4252, Spring 2011

ADM: Implementation Governance