isaca belgium architecture frameworks
DESCRIPTION
Isaca Belgium RoundTable 2011-01-29 Architecture frameworksTRANSCRIPT
ISACA BENEW YEAR EVENT 2011
JL ALLARD & ERIC MICHIELS
ArchitectureS
2
Architectures
29/01/2011ISACA Belgium, New Year Event 2011
Objectives Introduce architecture Introduce the 3 main models Motivate to start using them
when needed with the appropriate energy
3
Agenda
IntroductionEnterprise Information Architecture Model
(Zachman)Enterprise Security Architecture Model
(SABSA)Coffee pauseEnterprise IT Architecture Model
(TOGAF)Q&A
29/01/2011ISACA Belgium, New Year Event 2011
4
Introduction
Is this architecture?
Do not take the result of an activity for the activity itself
29/01/2011ISACA Belgium, New Year Event 2011
5
Introduction
Reason for architecture Seven thousand years of human history would
establish that the key to complexity and change is Architecture.
Architecture is a REPRESENTATION of the need The models
The models are recommended to make sure that what you build will respond to the complete need
Only the real context will indicate if you need to complete and document the full model Some ‘upper’ steps can be simplified, not by-passed!
29/01/2011ISACA Belgium, New Year Event 2011
6
Agenda
IntroductionEnterprise Information Architecture Model
(Zachman)Enterprise Security Architecture Model
(SABSA)Coffee pauseEnterprise IT Architecture Model
(TOGAF)Q&A
29/01/2011ISACA Belgium, New Year Event 2011
7
EIA Zachman
29/01/2011ISACA Belgium, New Year Event 2011
8
EIA - Zachman
29/01/2011ISACA Belgium, New Year Event 2011
The thinking part
The realization part
9
EIA1
Vertical dimension What: the inventory of information How: the [information] process(es) Where: the network, relationships, exchanges Who: the organization When: the timing Why: the motivation
Unlimited model (cyclinder)
29/01/2011ISACA Belgium, New Year Event 2011
10
EIA1
Contextual Level Scope, strategist & planner perspective The context that establishes the universe of discourse,
the inner and outer limits, the list of relevant constituents that must be accounted for in the descriptive representations (models) for the remaining Perspectives.
ENTERPRISE ARCHITECTURE OBJECTIVES, Gross Sizing, Scope
DESIGN ARTIFACTS BUBBLE CHARTS, Gross Sizing, Shape, Spatial
Relationships
29/01/2011ISACA Belgium, New Year Event 2011
11
EIA - Contextual
Examples A bank A school A lawyer firm A media A church (& Cie)
Use different information, processes, networks, organizations, motivations, timings
29/01/2011ISACA Belgium, New Year Event 2011
12
EIA – Practical Example
29/01/2011ISACA Belgium, New Year Event 2011
How to build confidence across EU in the identity management of natural persons? Initial idea
compare procedures based on BE vision + risk assessment
Try to define a ‘generic’ process Describe BE implementation Build a questionnaire
Describe concrete implementation Identify risk
Compare and decide
13
EIA –My experience
29/01/2011ISACA Belgium, New Year Event 2011
The ‘big picture’ What: 4 fundamental documents Who: actors -
Public: administration Private: Individuals, public ‘users’
Where: 2 locations and 3 communication channels Local & Central Administrations, Between persons & administrations, between administrations
How: 4 processes – When: permanent or ah-hoc Why: gain trust and prevent fraud & identity theft
Took about one hour to identify and 4 to document.
14
EIA2
Conceptual Level The Business, Executive & Owner perspective The recipient (customer) view of the end product, (e.g.
airplane, house, Enterprise, etc.). These descriptive representations reflect the usage characteristics of the end product, what the Owner(s) are going to do with the end product, or how they will use it once they get it in their possession. This is a view of what the Owner can think about relative to the use of the end product.
ENTERPRISE ARCHITECTURE MODEL OF THE BUSINESS, Enterprise as Seen by the
"Owner“ DESIGN ARTIFACTS
ARCHITECT'S DRAWINGS, Building as Seen by the Owner
29/01/2011ISACA Belgium, New Year Event 2011
15
EIA - Conceptual
Exemples Stadion - all sports have their own ‘design’:
Soccer, Football, Baseball, Athletics, Tennis, Basket ball, etc.
The ‘number’ of attendees The ‘money’ & technology available The city where it’ll take place (it must & will fit) The surrounding landscape
29/01/2011ISACA Belgium, New Year Event 2011
16
EIA - Conceptual
29/01/2011ISACA Belgium, New Year Event 2011
Church – all religions have their specificities Segregation priests/people; men/women The number of attendees The ‘money’ & technology available The city and landscape where it’ll take place (it must &
will fit)
17
EIA2 – Practical Example
29/01/2011ISACA Belgium, New Year Event 2011
Processes Process1: 3 activities Process2: 3 activities Process3: 4 activities Process4: 2 activities
Documents New information and documents
Actors: complete list + witness (& conditions)
Channels: 1 more + characteristics
Motivations: more detailed
Time needed: 5 days & discussions to draw.
18
The result?
Site survey in 8 countriesReport
Summary, SWOTWhy not deeper?
National cultures are different Similar concepts differentey implemented
Logical level (see next) too detailedWhat effect?
Support by European CommissionWhat next?
Exploit results Propose acceptable solutions
29/01/2011ISACA Belgium, New Year Event 2011
19
ISACA Belgium, New Year Event 2011
EIA3
Logical level The System, Architect, Designer, Engineer perspective The intermediary between what is desirable (Row 2) and what is
physically and technically possible (Row 4). … reflects the laws of nature, the system, or logical constraints for the design of the product. The logical view of the end product.
For Enterprises, this is the logical representation of the Enterprise which forms the basis for the white collar system, the recordkeeping system, of the Enterprise as well as the basis for the design of the blue collar system, the material manipulation system for manipulating the tangible aspects of the Enterprise.
ENTERPRISE ARCHITECTURE MODEL OF THE "SYSTEMS“, (the "Systematic Model"), Enterprise as
Seen by the "Designer“ DESIGN ARTIFACTS
ARCHITECT'S PLANS, Building as Seen by the Designer
29/01/2011
19
20
EIA3 - Logical
Exemples A house
Urbanism & technology requirements Harmonization with the landscape Roads and facilities (Electricity, Gas, Water, Drains) Garage or not Office or not? How many floors?
Drawings (both Conceptual and Logical)
29/01/2011ISACA Belgium, New Year Event 2011
21
EAI
Lower levels The most complex & tricky The most known and used No need for examples
29/01/2011ISACA Belgium, New Year Event 2011
22
EIA4
29/01/2011ISACA Belgium, New Year Event 2011
Technology, Engineer, Builder, Physical perspective The manufacturing Engineer, the General Contractor,
the employer of some technical capacity for producing the end product. These descriptive representations reflect the physical constraints of applying the technology in the construction of the product.
Contractor’s plan / Technology model drawings as constrained by Nature and Available
Technology (Building as Seen by the Builder)
INFRASTRUCTURE
23
EIA5
29/01/2011ISACA Belgium, New Year Event 2011
The Detailed representation Technician, Component, Subcontractor, Out-of-Context
perspective Detailed description that disassociates the parts or pieces of the
complex object for manufacturing purposes. This is the area of the configuration of the needs and means to respond to demands.Plays a part in the transformation from the media of the design (paper and ink or e-) of the product to the media of the end product itself (documents, voice, image, computers & networks).For Enterprises, these are the product specifications relating the technology constraints of Row 4 to the vendor products in which the technology constraints are materialized.
SHOP PLANS Descriptions of Parts/Pieces
24
EIA6
29/01/2011ISACA Belgium, New Year Event 2011
The ‘Functioning Enterprise’ The Worker, Operations perspective The physical manifestation of the end product itself.
The end result of the Architectural process. Although, technically, Row 6 is not Architecture
because it is not a representation (it is the actual thing), it is useful to incorporate it into the Framework graphic as it completes the Architectural picture.
The end object is to ensure that Row 6 represents what the Owners have in mind for the Enterprise at Row 2. The realization of the Concept
25
Agenda
IntroductionEnterprise Information Architecture Model
(Zachman)Enterprise Security Architecture Model
(SABSA)Coffee pauseEnterprise IT Architecture Model
(TOGAF)Q&A
29/01/2011ISACA Belgium, New Year Event 2011
26
ESA - SABSA
Sherwood Applied Business Security ArchitectureBorn 1995
Sarting point : ISO 7498-2 (open system interconnection), the 3 lower layers
Readjusted based on EIA Zachman (1999)Focus:
Enterprise Security Architecture Enterprise Security Service Management
With attributesAn © open-use model & methodology
From Business requirements to controls Ensures traceability across the model
29/01/2011ISACA Belgium, New Year Event 2011
27
ESA - Relations
29/01/2011ISACA Belgium, New Year Event 2011
Zachman SABSA
The Business View Contextual Security Architecture
The Architect’s View Conceptual Security Architecture
The Designer’s View Logical Security Architecture
The Builder’s View Physical Security Architecture
The Tradesman’s View Component Security Architecture
The Facilities Manager’s View Operational Security Architecture
28
ESA
29/01/2011ISACA Belgium, New Year Event 2011
Management
Governance
Technical
29
ESA matrix
29/01/2011ISACA Belgium, New Year Event 2011
30
ESA for Security Service Mgt
29/01/2011ISACA Belgium, New Year Event 2011
The content of the ‘transversalOperational layer
31
ESA – Development process
29/01/2011ISACA Belgium, New Year Event 2011
Natural break for signed approval
Don’t go straight to
select & implement solution!
Life-cycle:- Strategy & Concept- Design- Implement- Manage & measure
32
ESA - Business Attributes
29/01/2011ISACA Belgium, New Year Event 2011
ManagementOperationalRisk ManagemetLegal/regulatoryTechnical strategyBusiness strategyUser
Accessible, accurate, consistent, current, duty segregated, educated & aware, informed, motivated, reliable, supported, timely, usable
Information = missing? And the information attributes?
33
ESA – my view
Contextual What: What should be protected (key information & activities) Why: What’s at stake? Need for Security? Feared Events How: Security principles and standards to apply Who: Involvement of C-Suite, backbone of Security organization Where: Most important places to protect and central place for security
management/governance; network with externals When: Delays, target dates, calendars
Conceptual: What: List of information processes and inventory of information Why: Risks to business objectives (short, mean, long term) How: General Security Policy Who: Key security actors & place in the organization +
communication channels Where: SGeneric security rules for the involved domains When: Recovery & Backup, generic action plan
29/01/2011ISACA Belgium, New Year Event 2011
34
ESA – unique selling points
29/01/2011ISACA Belgium, New Year Event 2011
Business Driven Enabling Business Usability
Holistic Approach Adding Value Inter-operability
Fit-for-Purpose Empowering Customers Supportability
Measurable Protecting Relationships Integration
Return on Investment Leveraging Trust Low Cost Development
Risk-based Cost / Benefit Assurance Scalability of Platforms
Managing Complexity Governance Scalability of Cost
Providing a Roadmap Compliance Scalability of Security
Simplicity & Clarity Fast Time to Market Re-usability
Lower Cost of Ownership Lower Operations Costs Lower Administration Cost
35
Enterprise Architecture
Zachman and SABSA offer Detailed guide Education Certification
www.zachmanframeworkassociates.com/ Wikipedia paper : correspondance with other
architecture modelswww.sabsa-institute.org/www.sabsa.org
29/01/2011ISACA Belgium, New Year Event 2011
36
Roles of architecture
Managing complexityProviding a framework & road mapSimplicity & clarity through layering &
modularisationBusiness focus beyond the technical domain
29/01/2011ISACA Belgium, New Year Event 2011
37
Benefits of Architecture (1)
29/01/2011ISACA Belgium, New Year Event 2011
Architecture delivers modular, re-usable technical infrastructure, effective operational and management processes, and meets a broad spectrum of business requirements for systems, including:
Usability The solution must be appropriate to the technical competence of the intended users and ergonomically acceptable to those users
Inter-Operability
The solution must provide for the long-term requirements for inter-operability between communicating information systems and applications
Integration The solution must integrate with the wide range of computer applications and platforms for which it might be required in the long term.
Supportability The solution must be capable of being supported in the environment within which it has been designed to be used.
Low Cost Development
The solution should be of modular design and hence capable of being integrated into a development programme at minimal cost.
Fast Time to Market
The solution should be capable of being integrated into a development programme with minimal delay.
38
Benefits of Architecture (2)
29/01/2011ISACA Belgium, New Year Event 2011
Scalability of Platforms The solution should fit with the range of computing platforms with which it might be required to integrate.
Scalability of Cost The entry-level cost should be appropriate to the range of business applications for which the solution is intended.
Scalability of Security Level
The solution should support the range of cryptographic and other techniques that will be needed to implement the required range of security strengths.
Re-Usability The solution should be re-usable in a wide variety of similar situations to get the best return on the investment in its acquisition and development.
Lower Operations and Administration Costs
The cost impact on systems operations should be minimised and the solution should provide an efficient means for administration to optimise the costs of this activity
39
Agenda
IntroductionEnterprise Information Architecture Model
(Zachman)Enterprise Security Architecture Model
(SABSA)Coffee pauseEnterprise IT Architecture Model
(TOGAF)Q&A
29/01/2011ISACA Belgium, New Year Event 2011
40
Agenda
IntroductionEnterprise Information Architecture Model
(Zachman)Enterprise Security Architecture Model
(SABSA)Coffee pauseEnterprise IT Architecture Model
(TOGAF)Q&A
29/01/2011ISACA Belgium, New Year Event 2011
41
TOGAF
The Open Group Architecture FrameworkTopics in this section
o Enterprise Architectureo The Open Group and Architectureo TOGAF in a “Nutshell”o TOGAF Relationship with other Frameworkso TOGAF Relevance
ObjectivesAt the end of my section, ask yourself:
“Should I learn/read more about TOGAF?”“Should I adopt TOGAF concepts”
“How to introduce TOGAF concepts in my context?”
29/01/2011ISACA Belgium, New Year Event 2011
42Enterprise Strategy
Fire and hope!
Enterprise Architecture
Business Operating Environmentand IT Infrastructure
TransitionPlanning
Group IT Architecture Definition
Infrastructure Design & Planning
Establish IT Competency Centre
End User Infrastructure Upgrade
Inter-company WAN (imple.)
Outsource New Core systems
Outsource Helpdesk and Desktop
Outsource network
Outsourcing Initiatives
Competency Centre Initiatives
Electronic Service Delivery
Data Warehouse
Customer Service Centre
Recognise and report problem
Diagnose problem
Escalate problem
Analyse problem
Log Problem
Close problem
Update customer
Resolve problem
Bypass and/or fix
Config. Management
Operations Management
Change Management
Call management
Operations management
Update customer
Perf and Capacity management
WAN infrastructureIntranet/Mail infrastructure
Customer ServiceData Warehouse
Graphical IS
B.U.B.U.
Document Management
Systems Management
Middleware
NETWORK
Planning/Design Initiatives
Infrastructure Initiatives
OtherBusiness Unit SystemsKiosksTelemetry systemsetc
Initiatives focused on migrating to the new delivery environment
Planning/DesignInfrastructureOutsourcing
Initiatives focused on implementing the vision
Planning/designIT Competency centre
Key Group Decision Points
ArchitectureGovernance
BusinessArchitecture
IT Architecture
AEICorporate
YankeeGroup
SaturnGroup
YarnDivision
KnitsDivision
SenecaPlant
RaleighPlant
CashManagement
Shipping
Accounting
ComponentDesign
Yarn Buying
Order Entry
ComponentScheduling
YarnDyeing
Inventory
AssortmentPlanning
ComponentKnitting
Tagging & Packing
Business Structure
Business Locations
Pro
gra
m
focu
sE
nte
rpri
se w
ide f
ocu
s
Strategy
Planning
Designand
Delivery
Change Programs
Soln Outline Macro DesignMicro Design Devt, etc.
Programme ArchitectureGroup IT Architecture Definition
Infrastructure Design & Planning
Establish IT Competency Centre
End User Infrastructure Upgrade
Inter-company WAN (imple.)
Outsource New Core systems
Outsource Helpdesk and Desktop
Outsource network
Outsourcing Initiatives
Competency Centre Initiatives
Electronic Service Delivery
Data Warehouse
Customer Service Centre
Recognise and report problem
Diagnose problemEscalate problemAnalyse problemLog Problem
Close problemUpdate customer Resolve problem
Bypass and/or fixConfig. Management
Operations ManagementChange Management
Call managementOperations management
Update customer
Perf and Capacity management
WAN infrastructureIntranet/Mail infrastructureCustomer ServiceData Warehouse
Graphical IS
B.U. B.U. Document Management
Systems ManagementMiddleware
N E T W O R K
Planning/Design Initiatives
Infrastructure Initiatives
OtherB u sin ess U n it
S ys tem s
K io sks
Te lem etry sys tem s
etc
Initiatives focused on migrating to the new delivery environment
P lann ing /D es ign
In fras truc tu re
O u tsou rc ing
Initiatives focused on implementing the vision
P lann ing /des ign
IT C om pe tency cen tre
Key Group Decision Points
Soln Outline Macro DesignMicro Design Devt, etc.
Programme ArchitectureGroup IT Architecture Definition
Infrastructure Design & Planning
Establish IT Competency Centre
End User Infrastructure Upgrade
Inter-company WAN (imple.)
Outsource New Core systems
Outsource Helpdesk and Desktop
Outsource network
Outsourcing Initiatives
Competency Centre Initiatives
Electronic Service Delivery
Data Warehouse
Customer Service Centre
Recognise and report problem
Diagnose problemEscalate problemAnalyse problemLog Problem
Close problemUpdate customer Resolve problem
Bypass and/or fixConfig. Management
Operations ManagementChange Management
Call managementOperations management
Update customer
Perf and Capacity management
WAN infrastructureIntranet/Mail infrastructureCustomer ServiceData Warehouse
Graphical IS
B.U. B.U. Document Management
Systems ManagementMiddleware
N E T W O R K
Planning/Design Initiatives
Infrastructure Initiatives
OtherB u sin ess U n it
S ys tem s
K io sks
Te lem etry sys tem s
etc
Initiatives focused on migrating to the new delivery environment
P lann ing /D es ign
In fras truc tu re
O u tsou rc ing
Initiatives focused on implementing the vision
P lann ing /des ign
IT C om pe tency cen tre
Key Group Decision Points
Enterprise Architecture = “the city plan”
System Design= “the buildings”
Strategy = “the city’s purpose & goals”Technology
AvailabilityBusiness
OpportunityBus Strategy IT Strategy
“Enterprise Planning and Strategy”
An IBM View on Enterprise Architecture (EA)
29/01/2011ISACA Belgium, New Year Event 2011
43
EA According to IBM
Enterprise Architecture (EA) provides the business with IT capabilities for:o Managing the life cycle and value of current systems o Adding new systems and their infrastructure
As an integral part of the strategic planning process, the EA is the linkage between the business strategy, IT strategy and IT implementation
EA guides investment, cost reduction and design decisions to support the goal of optimizing return on IT investments (ROI)
EA specifies processes, standards, interfaces and common services for the deployment and management of IT assets that support business objectives
Enterprise Architecture defines an environment in which infrastructure and solutions can be built for both known and unforeseen future requirements
IBM believes that an Enterprise Architecture provides the vital linkages between “strategy” and “implementation” to support a
customers goal for aligning business and IT
29/01/2011ISACA Belgium, New Year Event 2011
44
The Open Group
Vision of Boundary-less Information Flow – with EA as a critical element for making the vision a reality, the TOGAF ADM provides an important toolset
“Making Standards Work” – extensive experience and track record in facilitating consensus to develop standards and operating a premier certification service
The Open Group works with customers, suppliers, consortia, and other standards bodies to
Capture, understand, address current and emerging requirements, establish policies, share best practices
Facilitate interoperability, develop consensus, evolve and integrate specifications & open source technologies
Offer a comprehensive set of services to enhance the operational efficiency of consortia Operate the industry’s premier certification service
Motif DCE (Open DCE)
AQRM
MILSForums
Architecture Platform Security
Identity Management Enterprise Management
Real Time and Embedded Systems
Core Technology Methods & Best Practices
SOA-WG
Certifications• UNIX• LDAP• WAP• S/MIME• ITAC / ITSC• NASPL
LDAP / CCI
http://www.opengroup.org/sanfrancisco2008/
Architecture Practitioner Conferences
29/01/2011ISACA Belgium, New Year Event 2011
45
TOGAF is …..
An Enterprise Architecture FrameworkA generic framework for developing architectures to meet different
business needsNot a “one-size-fits-all” architectureDescriptive and not proscriptive (where possible)
One of the most accepted and “most popular” Enterprise Architecture frameworks
Vendor independentDeveloped and evolved by members of The Open Group
Architecture Forum Often used “in tandem with” other methods
Zachmann FrameworkRUPDODAF / MODAF
There is an increasing market demand for TOGAF Certified Architects
TOGAF Case Studies: Open Group web sitehttp://www.opengroup.org/architecture/togaf8-doc/arch/chap35.html
29/01/2011ISACA Belgium, New Year Event 2011
46
1994: Requirement 1995: TOGAF Version 1 1996: TOGAF Version 2 1997: TOGAF Version 3 1998: TOGAF Version 4 1999: TOGAF Version 5 2000: TOGAF Version 6 2001: TOGAF Version 7 2002: TOGAF Version 8 2003: TOGAF Version
8.1 2006: TOGAF Version
8.1.1 2009: TOGAF Version 9
TOGAF, the “de facto” Enterprise Architecture
standard
29/01/2011ISACA Belgium, New Year Event 2011
47
What does TOGAF Version 9 contain?
• Central to TOGAF is the Architecture Development Method (ADM) – a step by step approach to develop an EA
• The method is supported by a number of Guidelines and Techniques
• The Architecture Content Framework is a structured metamodel for architectural artifacts, ABBs, deliverables
• This produces content to be stored in the repository which is classified according to the Enterprise Continuum
• The repository is initially populated with the TOGAF Reference Models
• The Architecture Content Framework discusses the roles and responsibilities required to stablish and operate an architecture practice
29/01/2011ISACA Belgium, New Year Event 2011
48
The ArchitectureDevelopment Method
The core of TOGAFA proven way of developing
an architectureSpecifically designed to
address business requirements
An iterative methodA set of architecture views to
ensure that a complex set of requirements are adequately addressed
The ADM supports the concept of iteration at three levels: Cycling around the ADM Iterating between phases Cycling around a single phase
29/01/2011ISACA Belgium, New Year Event 2011
49
ADM Phases Overview
TOGAF Document Categorization Modelo A model to structure release
management of the TOGAF specification itself
Content of the TOGAF specification is categorizedo TOGAF Core: fundamental
concepts that form the essence of TOGAF
o TOGAF Mandated: normative parts of TOGAF. Elements considered central to its usage, without which the framework would not be TOGAF
o TOGAF Recommended: a pool of resources referenced in TOGAF as ways in which Core and Mandated processes can be accomplished
o TOGAF Supporting: additional resources not referenced in the other three categories
29/01/2011ISACA Belgium, New Year Event 2011
50
Deliverables, Artifacts and Building Blocks
Deliverables Formal products Contractually specified Outputs from a project A deliverable can
contain many artifacts Building blocks
Components that can be combined with other building blocks to deliver architectures and solutions
Can be defined at various levels of detail
ABBs: describe required capability shaping the …
SBBs: represent the components to be used to implement the required capability
Artifacts Fine grained products describing an architecture from
a specific viewpoint Examples: use-cases, architectural requirements,
network diagrams, etc. Classified as:
Catalogs (lists of things) Matrices (showing relationships between things) Diagrams (pictures of things)
Artifacts make up the content of the Architecture Repository
29/01/2011ISACA Belgium, New Year Event 2011
51
The Enterprise Continuum
Sets the broader context for the Architect Explains how generic solutions can be leveraged and specialized in
order to support requirements of an individual organization Provides a view of the Architecture Repository that shows the
evolution of the related architectures from GENERIC to SPECIFIC, from ABSTRACT TO CONCRETE, from LOGICAL to PHYSICAL
29/01/2011ISACA Belgium, New Year Event 2011
52
Architecture Repository
Supports Enterprise Continuum
Stores different classes of Architectural Output at different levels of abstraction
These outputs are created by the ADM
29/01/2011ISACA Belgium, New Year Event 2011
53
Interaction between TOGAF and other Management Frameworks
Two key elements of EA Framework
Definition of deliverables
Description of method for production
Popularity of TOGAF:Can be used in conjunction with any of other popular frameworks (ITIL, CMMI, COBIT, PRINCE2, PMBOK, MSP, ...)
Framework-agnostic: fill in the framework you already have
29/01/2011ISACA Belgium, New Year Event 2011
54
Synergy between Frameworks
Zachman Framework
Federal Enterprise Architecture Framework
TOGAF ADMArchitecture Development Method
Other Frameworks
Support orGuidance
There is no “one size fits all” framework “TOGAF ADM is strong in process aspect” “Zachman is strong in the area of EA Models” “FEAF is performance based” “DODAF focuses on Composite Models”
Often, organizations adopt several frameworks and methodologies and integrate that with their own solutions delivery practice
29/01/2011ISACA Belgium, New Year Event 2011
55
Where TOGAF meets RUP
TOGAF is not an alternative to RUP Although many models and subjects are held
in common between the two frameworks They have different drivers and purposes
RUP is technology architecture-driven TOGAF is business architecture-driven In RUP, business requirements are gathered
to design and deliver a software-based system
In TOGAF technology is seen as a way to realize a business vision
The purpose of RUP as a Software Development Life Cycle (SDLC) methodology is to support timely and effective applications delivery
TOGAF's purpose is to support enterprise architecture implementation and maintenanceArticle by Vitalie Temnencohttp://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html
BA, ISA, TA handed over to implementation teams
Artifact Flow between
TOGAF and RUP
29/01/2011ISACA Belgium, New Year Event 2011
56
TOGAF in Eclipse Process Framework
EPF and TOGAF (Armstrong Process Group)• http://www.aprocessgroup.com/news/apg_atpl_launch.asp• http://www.aprocessgroup.com/togaf/published/index.htm
29/01/2011ISACA Belgium, New Year Event 2011
57
ArchiMate as EA Modeling Langauge
This results in this language framework:1. The Business layer offers products
and services to external customers, which are realised in the organization by business processes (performed by business actors or roles)
2. The Application layer supports the business layer with application services which are realised by (software) application components
3. The Technology layer offers infrastructural services (e.g., processing, storage and communication services) needed to run applications, realised by computer and communication devices and system software
Due to the heterogeneity of the methods and techniques used to document the architectures, it is very difficult to determine how the different architectural domains are interrelated
For optimal communication between domain architects, needed to align designs in the different domains, a clear picture of the domain interdependencies is indispensable
Conclusion: a language for modelling Enterprise Architectures should focus on inter-domain relations
29/01/2011ISACA Belgium, New Year Event 2011
58
ArchiMate and TOGAF ADM
TOGAF’s scope is broader and in particular addresses more of the high-level strategic issues and the lower-level engineering aspects of system development ArchiMate is limited to the Enterprise Architecture
level of abstraction and refers to other techniques both for strategies, principles and objectives, and for more detailed, implementation-oriented aspects
Although there is no one-to-one mapping between ArchiMate viewpoints and TOGAF there is a fair amount of correspondence, but there are also some mis-matches
TOGAF views are confined to a single architectural layer ArchiMate viewpoints that deal with the relationships between architectural layers,
such as the product and application usage viewpoints This is where ArchiMate could nicely complement TOGAF
29/01/2011ISACA Belgium, New Year Event 2011
59
Yes
No
Yes
TOGAF 8 Certified?
StepwiseDevelopment? TOGAF 9
Certified
TOGAF 9 Foundation
TOGAF 8-9 Advanced Bridge Exam
TOGAF 9 Part 2 Exam
No
TOGAF 9 Part 1 Exam
SampleSample
TOGAF 9Combined Part 1 & Part 2 Exam
TOGAF Adoption by Professionals
100 %
80 %
60 %
40 %
20 %
0 %
TOGAF Demand TrendThe chart provides the 3-month moving total beginning in 2004 of permanent IT jobs citing TOGAF within the UK as a proportion of the total demand within the Processes & Methodologies category.
TOGAF Certification Path
29/01/2011ISACA Belgium, New Year Event 2011
60
Conclusions around TOGAF
Adoption and use of TOGAF An effective, industry standard framework and method for
Enterprise Architecture Vendor, tool, and technology neutral Complementary to, not competing with, other frameworks
Participation in the Architecture Forum Worldwide forum for Architecture practitioners Network with peers and industry experts Allows to contribute to, and leverage “work in progress” Help further development of Enterprise Architecture as a
discipline and a profession
A growing number of vendors support TOGAF with methods, tools, education and certification
29/01/2011ISACA Belgium, New Year Event 2011
61
Thank You for Your Attention
Eric MichielsOpen Group Distinguished Chief ArchitectTOGAF 9 Certified [email protected]
29/01/2011ISACA Belgium, New Year Event 2011