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)
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
TOGAF
6
What is Enterprise Architecture?
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
• 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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
10
EA – a collaboration force
Schekkerman -IFEAD
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
15
EA is a path, not a destination!
x
x
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
17
What is the value of EA?
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
19
Alignment
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
22
EA Timeline
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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).
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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!
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
27 Enter Enterprise Architecture!MAM-EA
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
29
Zachman’s Framework (2)
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
•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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
31
Zachman’s EA Framework
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
33
Zachman’s Framework –Description (2)
• 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
DataWhat
FunctionHow
NetworkWhere
PeopleWho
TimeWhen
MotivationWhy
34
Zachman’s Framework –Description (3)
• 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
40
The Position of IT Architects
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
Greenslade, 2000-2002
42
TOGAF
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: 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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
44
TOGAF’s Enterprise Architecture
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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)
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
•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)
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
TOGAF Enterprise Continuum and ADM
Generic
Specific
48 TOGAF – Components of Foundation Architecture
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
50
Architecture Development Cycle -ADM
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
51
ADM - Framework and Principles
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
Bret, Business Manager
52
ADM - Architecture Vision
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
Bret, Business Manager
54 ADM: Informations Systems Architecture – Data & Applications
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
FMigration Planning
Management
58
ADM: Implementation Governance
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
Handle architecture change requests
Suggest new architecture projectsH
Architecture Change
Management
Management
60
ADM: Requirements Management
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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!
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
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.
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF
63
Next Lecture
• Continue Enterprise Architecture– FEAF– Gartner
TDT4252, Spring 2013Lecture 14 - Enterprise Architecture: Zachman, TOGAF