TOGAF, Enterprise Architecture

1. 1

2. 2

3. Where it All Begins
3

4. The Problem
Every enterprise already has an architecture
EA addressed problems
• Increasing IT system complexity
• Poor business alignment
The Business Need
• Implementation methodologies (i.e. RUP)
Relative importance of response to a business need
• Enterprise Architecture Focus
Identification, specification and prioritization of business needs
4

5. What is Enterprise Architecture ?
IBM Systems Journal, article "A Framework for Information Systems
Architecture”, John Zachman, 1987. originally described as an
information systems architectural framework, soon renamed to
enterprise-architecture framework.
Definition: Formal description of the structure and operation of an
organization. The motivation behind EA is to determine how the whole
organization can effectively achieve its current/future objectives.
“The cost involved and the success of
the business that depends increasingly
on its information systems require a
disciplined approach to the
management of those systems.”
J.A. Zachman
5

6. It’s a Metaphor
• Complex System = costs for maintenance
• Large City
• Simplicity is out of question!
• City planners
• Architects
• Success not guaranteed
• Cottage
• Simplicity!
• Architect?
6

7. What is Architecture Framework?
An architecture framework is methodology and tool that:
Guides the development or organization specific architecture
Embodies best practices and common wisdom
Assists the evaluation of architectures
Ensures that every domain is adequately
reviewed and documented
Provides generic categorization
of architecture artifacts.
Presents a set of standards,
design concepts, models, services
7

8. THE BIG FOUR
90% of EA implementations apply
Zachman Framework
The Open Group Architecture Framework (TOGAF)
Federal Enterprise Architecture (FEA)
Gartner Methodology
8

9. Zachman Framework for EA
9

10. v.9
TOGAF v.9
Architecture Content Framework (ACF)
provides structural model for architectural
content.
Architecture Development Method (ADM)
The TOGAF core - describes a method
for developing an EA
Iterative, over the whole process, between
phases, and within phases
Populates Architecture Repository
10

11. EA Architecture Domains
Business architecture Application/systems architecture
Data/information architecture Information Technology (IT)
architecture
Information architecture Data architecture
?
Business architecture
?
?
?
Application architecture Technical architecture
?
11

12. TOGAF ACF
Architectural work product categories:
Deliverables
Artifacts
Building blocks
Architecture
Solution
Content Metamodel
definition of all types of building blocks in EA and their relations.
12

13. TOGAF ADM
Preliminary phase
Review the organizational context for EA execution
Present and setup the process for stakeholders
Ensure commitment to the success of everyone involved
Phase A
In: Request for work – business need, budget, personel
Out: architectural vision - appropriate stakeholders have been
identified and their issues have been addressed
Phase B
detailed description of the baseline and target business objectives, and
gap descriptions of the business architecture
Phase C
Target Information and Applications Architecture
13

14. TOGAF ADM (Continued)
Phase D
Complete the technical architecture—the infrastructure necessary to
support the proposed new architecture
Phase E
Evaluate the various implementation possibilities, identifies the major
implementation projects that might be undertaken (the projects that
convinced the org. to start EA implementation)
Phase F
Prioritize projects on cost and risk
Phase G
Architectural specification for implementation of projects
Phase H
Modify change management process with new artifacts
Go to Phase A
14

15. Where TOGAF meets RUP
• TOGAF is NOT RUP alternative
• The two frameworks have different
purposes
• RUP
• technology architecture driven.
• Business requirements -> software
• TOGAF
• business architecture driven
• Technology -> realize business
vision
15

16. Methodology Rating
Criteria Rating (1 – very poor, 4 – very good)
ZACHMAN17 TOGAF31 FEA31 GARTNER29
Taxonomy completeness* 4 2 2 1
Process completeness* 1 4 2 3
Reference-model guidance 1 3 4 1
Practice guidance* 1 2 2 4
Maturity model 1 1 3 2
Business focus* 1 2 1 4
Governance guidance 1 2 3 3
Partitioning guidance 1 2 4 3
Prescriptive catalog 1 2 4 2
Vendor neutrality* 2 4 3 1
Information availability* 2 4 2 1
Time to value* 1 3 1 4

17. To Avoid Misunderstanding
• EA is not rocket science
• EA brings the business and the technology sides together
• EA is a path and not destination
• EA is a valuable tool that guides the change
• A framework does not make architectural design an automated
process
17

18. How will EA Change Your Business?
EA purpose is to create environment that is responsive to
change and supportive of the delivery of the business
strategy.
Use common sense / common language
Be systematic
Avoiding misunderstandings
Know WHAT you do before you start
Know WHY you are doing it
Learn from best practices
Talk to business users in business terms
Record what, where, when, how, who and why
18

19. Enterprise Architecture Benefits
Efficient IT operation:
Lower software development and maintenance costs
Increased portability of applications
Improved ability to address critical enterprise-wide issues (i.e. security)
Easier system management
Easier upgrade and exchange of systems
Reduced risk for future investment:
Reduced complexity in IT infrastructure
Flexibility to make, buy, or out-source IT solutions
Reduced risk overall in new investment
Return of investment
Greater ability to respond to new demands
Greater business value from IT operations
Greater ability to implement new technologies
Faster, simpler and cheaper delivery to market
19

20. To TOGAF or Not?
What TOGAF does What TOGAF does NOT
provides framework and guidelines make decision (Business and IT
architects do)
guides building EA necessarily guide building good EA
provides guidelines for I/O provide detailed templates
allows phases to be skipped, done put the EA process in strict limits
incompletely or reordered
20

21. DEMO
21

22. 22

23. IT Architecture
Clearly define the structure of AS-IS state
Be derived from BUSINESS requirements
React to change according to the enterprise market
Be understood and receive support in the enterprise
Set out the strategy for future purchases
Specify migration strategies
Reduce number and complexity of interfaces between components
23