TDT4252 Modelling of Information Systems Advanced · PDF file2 Today’s lecture • Introduction to Enterprise Architecture, • Zachman’s EA Framework, TOGAF • Based on slides

1

Sobah Abbas Petersen

Adjunct Associate [email protected]

TDT4252Modelling of Information Systems

Advanced Course

TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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 Methodologies, 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)


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.

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.


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

6

What is Enterprise Architecture?


• A formal description of an enterprise, a detailed map of the enterprise at component level to guide its changes.

• The structure of an enterprise’s components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

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.

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'sprocesses, (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.

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.


10

EA – a collaboration force

Schekkerman -IFEAD


OperationalCapabilities

TechnologyCapabilities

TechnologyStrategy

BusinessStrategy

BusinessConcepts

EnablingTechnologies

Enterprise StrategicAlignment

Enterprise BusinessImprovements

Having divided to conquer, we must reunite to rule

11

• 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

Gartner

ImplementationStrategy


Architecture

12

EA Bridges Strategy and Implementation

The bridge between strategy & implementation

Business architectureInformation architectureSolution architectureTechnology architecture

Business StrategyBusiness driversBusiness goalsBusiness policyTrend analysis

ImplementationBusiness processesApplication systemsTech infrastructureOrganizational structure


13

The Enterprise View

Source: Adaptive Corp.

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.


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


15

EA is a path, not a destination!

x

x


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


17

What is the value of EA?


18

The value of EAYou 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


19

Alignment


Common understanding!

20 Bridging the gap between Business 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


22

EA Timeline


Sessions, 2007

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.


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/ Store

MAM/Warehouse

MAM/ Home

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.


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!


27 Enter Enterprise Architecture!MAM-EA


Irma, CIO

Cath, CEO

Bret, Business Manager

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.


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.

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.


31

Zachman’s EA Framework


2 1e .g . D AT A

E N T E R P R IS E A R C H IT E C T U R E - A F R A M E W O R K

B u ilder

S C O P E(C O N T E X T U A L)

M O D E L(C O N C E P T U A L)

E N T E R P R IS E

D esigner

S Y S T E MM O D E L(LO G IC A L)

T E C H N O LO G YM O D E L(P H Y S IC A L)

D E T A ILE DR E P R E S E N - T AT IO N S(O U T -O F - C O N T E X T )

Sub-C on tra cto r

F U N C T IO N IN GE N T E R P R IS E

D AT A F U N C T IO N N E T W O R K

e.g . D a ta D e fin it ion

E n t = F ie ldR e ln = A d d ress

e .g . P h ys ica l D a ta M o d e l

E n t = S e g m e n t/Ta b le /e tc .R e ln = P o in te r /K e y /e tc .

e .g . L o g ica l D a ta M o de l

E n t = D a ta E n tityR e ln = D a ta R e la tio n sh ip

e .g . S e m a n tic M o d e l

E n t = B u s in ess E n tityR e ln = B u sin e ss R e la tio nsh ip

L is t o f T h in g s Im p o rta n tto th e B us in e ss

E N T IT Y = C la ss o fB u s ine ss Th ing

L is t o f P ro ce sse s th eB u s in e ss P e rfo rm s

F unc tion = C la ss o fB u s in e ss P roce ss

e .g . A p p lica tion A rch ite c tu re

I/O = U se r V ie w sP ro c .= A p p lica tio n F u n c tio n

e .g . S ys te m D e sig n

I/O = D a ta E le m e n ts /S e tsP ro c.= C om p u te r F u n c tio n

e .g . P ro g ra m

I/O = C o n tro l B lo ckP ro c .= L a n g u a ge S tm t

e .g . F U N C T IO N

e .g . B u s in e ss P ro ce ss M o d e l

P ro c. = B u s in e ss P ro ce ssI/O = B us in e ss R e so u rces

L is t o f Lo c atio n s in w h ich th e B us ine s s O p e ra tes

N o de = M a jor B u s ines sLo ca tio n

e .g . B us in e ss Lo g is tics S ys te m

N o d e = B u s in e ss L o ca tionL ink = B u s in ess L in ka g e

e .g . D is tr ib u te d S yste m

N o d e = I/S F u n c tio n(P ro ce sso r, S to ra g e , e tc )L in k = L in e C h ara c te r is t ic s

e .g . Tech n o log y A rch ite ctu re

N o d e = H a rd w are /S ys te mS o ftw a re

L ink = L in e S p ec if ic a tions

e .g . N e tw o rk A rch ite c tu re

N o d e = A d d re sse sL in k = P ro toco ls

e .g . N E T W O R K

A rch ite c tu re

P lanner

O w ner

B uilde r

E N T E R P R IS EM O D E L

(C O N C E P T U A L)

D esigner

S Y S T E MM O D E L

(LO G IC A L)

T E C H N O LO G YM O D E L

(P H Y S IC A L)

D E T A ILE DR E P R E S E N -

T AT IO N S (O U T -O F

C O N T E X T )

Sub-C on trac to r

F U N C T IO N IN G

M O T IV AT IO NT IM EP E O P LE

e .g . R u le S p e c if ica tio n

E nd = Su b-co n d itio nM e a n s = S te p

e .g . R u le D e s ig n

E n d = C on d itio nM e a ns = A c tio n

e .g ., B u s ine ss R u le M o d e l

E n d = S truc tura l A ss ertio nM e a n s = Ac tio n A sse r tio n

E n d = B u s ine ss O b je c tiveM ea n s = B u s in e ss S tra teg y

L is t o f B u s in e ss G oa ls /S tra t

E nds /M ea n s= M a jo r B u s . G o a l/C rit ica l S u cce ss F a cto r

L is t o f E ve n ts S ig n if ica n t

T im e = M a jo r B u s in es s E v en t

e .g . P ro ce ss ing S tru c tu re

C yc le = P ro ce ssin g C yc leT im e = S yste m E v en t

e .g . C o n tro l S tru c tu re

C ycle = C om p o n e n t C yc leT im e = E xe cu te

e .g . T im in g D e fin itio n

C yc le = M a ch in e C ycleT im e = In te rru p t

e .g . S C H ED U L E

e.g . M a s te r S ch e d u le

T im e = B us ine s s E ve n tC ycle = B u s in e ss C yc le

L is t o f O rg an iza tio ns

P eo p le = M a jo r O rga nizatio n s

e.g . W o rk F lo w M ode l

P e op le = O rga nizatio n U n itW o rk = W o rk P ro d u c t

e .g . H um a n In te rfa ce

P e op le = R o leW o rk = D e live ra b le

e .g . P re se n ta tion A rch itec ture

P e op le = U s erW o rk = S c ree n F orm ate .g . S e cu rity A rch ite ctu re

P e o ple = Id en tityW ork = J ob

e .g . O R G A N IZ AT IO N

P lanner

O w ner

to th e B u s ines sIm po rtan t to th e B us ine s s

W ha t H ow W here W ho W hen W hy

Joh n A . Z achm an , Z ach m an In te rn ation a l (810 ) 2 3 1 -05 31

S C O P E(C O N T E X T U A L)

A rch itec tu re

e .g . S T R AT E G YE N T E R P R IS E

e .g . B u sin e ss P la n

T M

View

Aspects

Viewpoints

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.


33


• 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.


DataWhat

FunctionHow

NetworkWhere

PeopleWho

TimeWhen

MotivationWhy

34


• Layers or views (players):– Scope: a "bubble chart" or Venn diagram, which depicts in gross

terms the size, shape, partial relationships, and basic purpose of the final structure.

– Enterprise or business model: the design of the business or the architect’s drawing.

– System model: translations of the drawings into detailed specifications. Corresponds to a systems model by a systems analyst.

– Technology model: the architect’s model translated to a builder’s model.

– Detailed representations: detailed specifications given to programmers.

– Functional enterprise: a system is implemented and made a part of the enterprise.


ScopeContextual

Planner

EnterpriseConceptual

Owner

SystemsLogical

Designer

TechnologyPhysicalBuilder

DetailedContextual

Sub-contractor

Stakeholders

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.


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.


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.


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.



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.


TOGAF


40

The Position of IT Architects


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

42

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.


44

TOGAF’s Enterprise Architecture


Describes theprocesses thebusiness uses to meet its goals.

Describes howspecificapplications aredesigned and howthey interact witheach other.

Describes how the enterprise datastores are organised and accessed.

Describes the hardware and software infrastructure that supports applications and their interactions.

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.

46

TOGAF Enterprise Continuum (2)


47

• 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.


TOGAF Enterprise Continuum and ADM

Generic

Specific

48 TOGAF – Components of Foundation Architecture


49 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.


50

Architecture Development Cycle -ADM


51

ADM - Framework and Principles


Define architecture principles that drive technological architectures and document those.

Choose framework and customise.

Request for Architecture Work

Framework and

Principles

Irma, CIO

Teri, TOGAF

Consultant


52

ADM - Architecture Vision


Define the scope of the architecture project

Define high level business requirements

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

A Architecture

Vision

53

ADM – Business Architecture


Detailed baseline and target business architecture and full analysis of the gaps between them.

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.

BBusiness

Architecture

Teri, TOGAF

Consultant


54 ADM: Informations Systems Architecture – Data & Applications


CInformation

System Architecture

Applications Architecture

Data Architecture

Management

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.

Teri, TOGAF

Consultant

Irma, CIO

Target information and application architecture.

55

ADM: Technical Architecture


DTechnology Architecture

Management

The objective is to define the technology and technical services that will form the basis of the following implementation work.

Teri, TOGAF

Consultant

Irma, CIO

Complete technical architecture: the infrastructure necesary to support the proposed new architecture.

56

ADM: Opportunities and Solutions


The first phase directly concerned with implementation

How to close the gaps?

Identify implementation projects

EOpportunities and Solutions

ManagementFocus on projects that will deliver short term payoffs, e.g. the organisational pain points such as difficulties in completing regional /warehouse specialisation and unreliability in data sharing.

57

Prioritize between implementation projects

i.e. project portfolio management Cost and benefit analysis Risk assessment

ADM: Migration Planning


FMigration Planning

Management

58

ADM: Implementation Governance


Architectural contract. Ensure compliance with the

defined architecture. Implementation

specifications – acceptance criteria.

GImplementation

Governance Management Architectural specifications for the implementation projects.

59

ADM: Architectural Change Management


Handle architecture change requests

Suggest new architecture projectsH

Architecture Change

Management

Management

60

ADM: Requirements Management


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

Requirements Management

Ready to start the phase again. One of the goals of the first cycle

should be information transfer so that Teri's consultancy services are required less in the next cycle.

61

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!


62

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.


63

Next Lecture

• Continue Enterprise Architecture– FEAF– Gartner
