The Open Group Architecture Framework (TOGAF) TOGAF The Continuing Story Presented by Chris Greenslade cjtg@frietuna.com TOGAF The Continuing Story 1 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions TOGAF The Continuing Story 2 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions TOGAF The Continuing Story 3 of 102
The Open Group Forums The heart of cooperation between vendors and users Common interests explored and resources pooled Active Loss Prevention Architecture Directory interoperability Enterprise management Messaging Mobile management Platform Quality of service Real-time and embedded systems Security and ecommerce TOGAF The Continuing Story 4 of 102
Architecture Forum The mission of the Forum s members is to: Advance the cause of IT Architecture - in order to Improve the quality of information systems To move IT Architecture from a cottage industry to a profession Original (and continuing) focus: (TOGAF) Industry consensus framework and method for IT architecture Tool- and technology-neutral Extended focus Architecture Tools Certification TOGAF The Continuing Story 5 of 102
Forum Membership BMC Software Inc. (US) Booz Allen & Hamilton (US) Boeing Corporation (US) Brandeis University (US) CC and C Solutions ((Aus) Centre For Open Systems (Aus) ChiSurf (Hong Kong) Computacentre (UK) Computas (Nor) Computer Associates (US) Conclusive Logic (US) Department of Defense / DISA (US) Department of Works and Pensions (UK) Desktop Management Task Force (US) Fujitsu (Japan) Frietuna Consultants (UK) Hewlett-Packard (US) Hitachi (Japan) IBM (US) Innenministerium NordRhein-Westfalen (Ger) Jet Propulsion Labs (US) Lockheed Martin (US) Ministry of Defence (UK) Mitre Corporation (US) Monash University (Australia) Motorola (US) NASA Goddard Space Flight Center (US) National Computerization Agency (Korea) NATO C3 Agency (Bel) NEC (Japan) NeTraverse, Inc. (US) Nexor, Inc. (US) TOGAF The Continuing Story 6 of 102
Forum Membership Open GIS Consortium, Inc. (US) PASS Network Consulting (Ger) Popkin Software & Systems, Inc (US) POSC (US) Predictive Systems AG (Ger) ReGIS (Japan) QA Consulting (UK) SCO (US) Sun Microsystems (US) Teamcall (Bel) The Terasoft Group (US) Tivoli (US) Toyota InfoTechnology Center (Japan) TRON Association (Japan) University of Plymouth (UK) University of Reading (UK) Veriserve Corporation (US) Visa International (US) Weblayers, Inc. (US) Westpac Banking Corporation (Australia) TOGAF The Continuing Story 7 of 102
Who s Who Director Chair Vice Chairs John Spencer The Open Group Chris Greenslade Frietuna Computer Consultants (UK) Barry Smith The MITRE Corporation (USA) Ian McCall IBM Global Services (UK) Vish Viswanathan CC & C Solutions (Australia) TOGAF The Continuing Story 8 of 102
The Story So Far (1) The direction of TOGAF s evolution has been driven by The Open Group s membership over a period of 8 years An annual publication cycle 1994: Requirement statement developed Proof of need 1995: X/Open Architecture Framework - version 1 Proof of concept 1996: TOGAF - version 2 Proof of application 1997: TOGAF - version 3 Relevance to practical architectures TOGAF The Continuing Story 9 of 102
The Story So Far (2) 1998: TOGAF - version 4 TOGAF in context - the Enterprise Continuum Web structured documentation - ease of use 1999: TOGAF - version 5 Re-organized around extended ADM Business scenarios to help define requirements Addition of ADML 2000: TOGAF - version 6 Integration of Building Block work Integration of other initiatives, US DoD, IEEE 1471, IEEE 1003.23 TOGAF The Continuing Story 10 of 102
Current situation Current 2001: TOGAF - version 7 New sections on Architecture Patterns, Architecture Principles, Architecture Compliance Reviews Significant additional material on Business Scenarios Comparisons of TOGAF with other frameworks Further integration of IEEE Std 1471-2000 into TOGAF Metis model of the TOGAF ADM Positioning of TOGAF relative to enterprise architecture 2002: TOGAF version 8 - Enterprise edition Work in in progress TOGAF The Continuing Story 11 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF What is an IT Architecture What are the business benefits What is an IT Architecture Framework What is the role of the IT Architect The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions TOGAF The Continuing Story 12 of 102
What is an IT Architecture? ANSI/IEEE Standard 1471-2000 Conceptually an IT Architecture is The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. Practically it is represented in Architectural Descriptions from the viewpoints of the Stakeholders TOGAF The Continuing Story 13 of 102
Some more ANSI/IEEE definitions Architect: the person, team, or organisation responsible for systems architecture Architecting: the activities of defining, documenting, maintaining, improving and certifying proper implementation of an architecture. Architectural description a collection of products to document an architecture. TOGAF The Continuing Story 14 of 102
An IT Architecture is not optional Every enterprise already has an IT Architecture Some are designed and some just happen But it s there and it affects the efficiency of the enterprise TOGAF The Continuing Story 15 of 102
What should an IT Architecture do? A well-designed and effective IT Architecture will: Clearly define the structure of the existing system Set out the strategy for future purchases Specify migration strategies Reduce the number and complexity of the interfaces between the components, improving the ease of: Application portability Component upgrade Component exchange Component development and maintenance TOGAF The Continuing Story 16 of 102
What should an IT Architecture do? (cont.) Be derived from business requirements React to change at a rate dictated by the speed of change in the enterprise s markets Be understood and supported by senior management. Business requirements Current systems Technology trends IT Architecture Standards Component selection Investment decisions TOGAF The Continuing Story 17 of 102
What are the business benefits? Greater ability to respond to new demands Greater business value from IT operations Greater ability to introduce new technology Faster, simpler and cheaper procurement Faster time-to-market Can a business succeed without a documented business plan? Can IT IT succeed without a documented architecture? TOGAF The Continuing Story 18 of 102
In addition Pace set by public agencies and large vendors More enforcement of acquisition regulations Clinger-Cohen Act (US Information Technology Management Reform Act 1996) EU Directives on the Award of Public Contracts Contracting Authority needs procedures for ensuring vendor independent expression of needs Tendering contractors need procedures for ensuring common format for response TOGAF The Continuing Story 19 of 102
What is an Enterprise Architecture? Types of architecture: Business architecture Data/information architecture Application (systems) architecture Information technology (IT) architecture All these are related An An IT IT Architecture is is the technical foundation of of an an effective IT IT strategy TOGAF The Continuing Story 20 of 102
The Zachman Framework What? How? Where? Who? When? Why? Data Function Network People Time Motivation Planner s Viewpoint Contextual Owner s Viewpoint Conceptual Designer s Viewpoint Logical Builder s Viewpoint Physical Sub-contractor s Viewpoint Out-of-context Functioning Enterprise Scope Enterprise Models Systems Models Technology Models Detailed Representations Actual Systems TOGAF The Continuing Story 21 of 102
What is an Architecture Framework? Architecture design is a complex process An Architecture framework is a tool for: Designing a broad range of a architectures Assisting the evaluation of different architectures Selecting and building the right architecture for an organization It embodies best practice and acknowledged wisdom It presents a set of services, standards, design concepts, components and configurations It guides the development of specific architectures TOGAF The Continuing Story 22 of 102
What is an Architecture Framework? Use of a framework leads to: The use of common principles, assumptions and terminology The development of information systems with better integration and interoperability, especially with respect to issues that affect the whole enterprise WARNING! A framework does not make architectural design an automatic process It is a valuable aid to experienced and knowledgeable IT Architects TOGAF The Continuing Story 23 of 102
The position of IT Architects We know solutions to every problem? What s your problem? How do I know what I want, when I don t know what you can do for me IT Archi tect TOGAF The Continuing Story 24 of 102
The position of IT Architects Technical Management Business Management IT IT Architects System Designers & Developers TOGAF The Continuing Story 25 of 102
Architecture We are NOT talking about rocket science We ARE talking about: Using common sense Being systematic Avoiding misunderstandings Knowing what we are doing before we start Knowing why we are doing it Learning from the best practice of others Treating the user as a partner Talking to business users in business terms Recording what, where, when, how, who and WHY Using common sense TOGAF The Continuing Story 26 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Architecture Development Method (ADM) The Foundation Architecture Other aspects of TOGAF The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions TOGAF The Continuing Story 27 of 102
TOGAF consists of An Architecture Development Method (ADM) Foundation Architecture A Technical Reference Model (TRM) A Standards Information Base (SIB) Building Blocks Information Base (BBIB) Resource Base contains advice on: Architecture views Business scenarios IT Governance Architecture patterns ADL Case studies TABB Architecture principles Architecture contracts... TOGAF The Continuing Story 28 of 102
More about TOGAF Foundation Architecture Target Architectures Architecture Development Method Technical Reference Model (services) Standards Information Base (standards) Building Block Information Base (future) Business Requirements TOGAF The Continuing Story 29 of 102
Architecture Development Method Start with a foundation architecture Follow the phases of the ADM Results in an organization-specific architecture more reusable building block assets in the Enterprise Continuum Each iteration becomes easier and has more reusable building blocks to use A Initiation & framework G Architecture maintenance F Implementation Requirements B Baseline description C Target architecture E D Migration Opportunities options & solutions TOGAF The Continuing Story 30 of 102
TOGAF The Continuing Story 31 of 102
The TOGAF ADM A - Initiation and Framework Establish or revalidate architecture principles Use business scenarios Understand how scenarios map to IT Define relevant business requirements Build consensus with business partners Plan and get commitment to IT Governance G Architecture maintenance F Implementation E Migration planning A Initiation & framework Requirements D Opportunities & solutions B Baseline description C Target architecture TOGAF The Continuing Story 32 of 102
Architecture Principles The principles for developing Architectures not for any particular architecture Define the underlying general rules and guidelines Architecture principles to guide all future work on all future architectures Are applied for the use and deployment of all IT resources and assets Form the basis for making future IT decisions Clearly relate back to the business objectives and key architecture drivers TOGAF The Continuing Story 33 of 102
Documented Architecture Principles Involves Obtaining a consensus Demonstrating commitment Documenting clearly Publishing and promoting Mandating TOGAF The Continuing Story 34 of 102
Developing Architecture Principles They should include a statement, the rational and the implications They are developed by the Chief Architect and key business stakeholders They must be appropriate policies and procedures They must ensure alignment of IT strategies with business principles strategies and visions A good set of principles will be understandable, robust, complete, consistent and stable Everything should be done to minimize violations whether deliberate or accidental TOGAF The Continuing Story 35 of 102
Example Architecture Principles From TOGAF documentation Boeing Primacy of Principles Thou shalt not Business Continuity idle the factory Common Use Applications floor Data is an Asset Data is protected from unauthorized use and disclosure Technology Independence Mark Forman US Office of Management and Budget Component of 5-part President s Management Agenda Market-based, Result-oriented, Citizen-centered Simplify and Unite TOGAF The Continuing Story 36 of 102
Business scenarios A complete description of the business problem in business and architectural terms Text, diagrams and models It ensures: The architecture is based on a complete set of requirements The business value of solving the problem is clear The relevance of potential solutions is clear Aids the buy-in by business stakeholders Clarifies communication with vendors Is used and validated in all Phases TOGAF The Continuing Story 37 of 102
Business scenarios A Business Scenario describes A business process - an application or set of applications enabled by the proposed solution The business and technology environment The people and computing components (called actors ) who execute it The desired outcome of proper execution A good Business Scenario Is representative of a significant market Enables the supply side to understand the value to the buy side of a developed solution Is also SMART TOGAF The Continuing Story 38 of 102
A SMART business scenario Specific - defines what needs to be done in the business Measurable - clear metrics for success Actionable - it clearly segments the problem and provides the basis for determining elements and plans for the solution Realistic - the problem can be solved within the bounds of physical reality, time and cost constraints Time-bound - there is a clear understanding of when the solution opportunity expires TOGAF The Continuing Story 39 of 102
7 Steps to building a business scenario 1 - Identify, document and rank the problem driving the scenario 2 - Identify business and technical environment where situation is occurring, and document in scenario models 3 - Identify and document desired objectives - the results of handling the problems successfully - get SMART 4 - Identify human actors, their roles, their place in the business model 5 - Identify computer actors (computing elements), their roles, their place in the technology model 6 - Identify and document roles, responsibilities, measures of success per actor 7 - Check for fitness for purpose and refine only if necessary 1 - Problem 2 - Environment 3 - Objectives 4 - Human Actors 5 - Computer Actors 6 - Roles & Responsibilities 7 - Refine TOGAF The Continuing Story 40 of 102
Business Scenario phases 1 - Problem Gather Analyze Review 2 - Environment 3 - Objectives 4 - Human Actors 5 - Computer Actors 6 - Roles & Responsibilities Refine if necessary Refine if necessary Refine if necessary TOGAF The Continuing Story 41 of 102
IT governance Established to ensure senior management retain control of IT operation Established to ensure senior management is seen to assume responsibility for IT operation Two important elements A cross-organization Architecture Board An IT architecture compliance strategy IT Governance Institute Control OBjectives for Information and related Technology (COBIT) http://www.itgi.org/ TOGAF The Continuing Story 42 of 102
The TOGAF ADM B - Baseline Description Inventory of re-usable IT building blocks Build description of current system Functional view Platforms in place Complete yet fit for purpose Multiple views G Architecture maintenance F Implementation E Migration planning A Initiation & framework Requirements B Baseline description D Opportunities & solutions C Target architecture TOGAF The Continuing Story 43 of 102
Architecture views - definitions Adapted from IEEE 1471 Recommended Practice for Architectural Description SYSTEM: a collection of components organized to accomplish a specific function or set of functions ARCHITECTURE: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution ARCHITECTURAL DESCRIPTION: a collection of products to document an architecture. Architecture views are the key products in TOGAF TOGAF The Continuing Story 44 of 102
Architecture views - definitions SYSTEM STAKEHOLDER: an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. VIEW: a representation of a whole system from the perspective of a related set of concerns. VIEWPOINT: a schema of the information in a view IEEE 1471 defines this as: "A viewpoint acts as a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.") TOGAF The Continuing Story 45 of 102
Architecture view Description of the architecture from the viewpoint of a specific stakeholder The main mechanism of communication between the architect and the stakeholder Used to ensure accuracy of understanding of the current system Used to ensure the architecture meets the need of each stakeholder TOGAF s list of views is only a recommendation TOGAF The Continuing Story 46 of 102
Recommended architecture views Business architecture views To address the concerns of users Technical architecture views Engineering views To address the concerns of System and Software Engineers Operations views To address the concerns of Operators, Administrators and Managers Acquirers views To address the concerns of Acquirers TOGAF The Continuing Story 47 of 102
Business Architecture Views Business Architecture Views People - human resource aspects Process - user processes involved Function - functions to support the processes Business information -its flow in support of the processes Usability - of the system and its environment Performance - of the system and its environment TOGAF The Continuing Story 48 of 102
Engineering views Security view Software engineering view Data view System engineering view Communications engineering view TOGAF The Continuing Story 49 of 102
Operations views Security view Software view Data view Computing/Hardware view Communications view TOGAF The Continuing Story 50 of 102
Acquirer s views Building blocks cost view Standards view TOGAF The Continuing Story 51 of 102
The TOGAF ADM C - Target Architecture Identify target architecture Multiple views All needed services G Architecture maintenance A Initiation & framework B Baseline description F Implementation Requirements C Target architecture E Migration planning D Opportunities & solutions TOGAF The Continuing Story 52 of 102
C - Target Architecture (Sub-process Steps) B 1 Create baseline 2 Consider views 3 Create architectural model 6 Determine criteria 4 Select services 5 Confirm Bus. Objs. 7a Define architecture 7b Identify Architectural Building Blocks 8 Conduct gap analysis D TOGAF The Continuing Story 53 of 102
Step 1 - Create baseline Describe current system in terms of TOGAF and re-usable building blocks Inputs As for whole Phase Outputs is TOGAF description of current system in the form of Technical Architecture 0.1 Model - Version 0.1 Constraints Architecture Principles Requirements Traceability key question list for evaluating merits criteria for selection of service portfolio B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 54 of 102
Step 2 - Consider architectural views Ensure all requirements from all stakeholders are covered functional, management, development, views Input Technical Architecture 0.1 Outputs Technical Architecture 0.2 Target Architecture model from each view Constraints imposed by each view Rationale for each decision B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 55 of 102
Step 3 - Create an architectural model Create an architecture model of building blocks Input Technical Architecture 0.2 Outputs Technical Architecture 0.3 Architecture model of building blocks High-level description of target architecture Modifications to architecture continuum Extensions Amendments B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 56 of 102
Step 4 - Select services Select services portfolio for each building block Inputs Technical Architecture 0.3 TOGAF TRM Standards Information Base Outputs Technical Architecture 0.4 Description of the service portfolios required Modifications to architecture continuum Extensions Amendments B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 57 of 102
Step 5 - Confirm business goal are met Get buy-in and insure everything is on the right track Inputs Technical Architecture 0.4 Business Architecture 2 Outputs Technical Architecture 0.5 List of objectives and how the emerging architecture meets them Answers to Key Questions List B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 58 of 102
Step 6 - Determine selection criteria Determine criteria for specification selection for populating the architecture Inputs Technical Architecture 0.5 Standards Information Base Outputs Technical Architecture 0.6 Criteria for selecting specifications that will make up fully populated final architecture Criteria for selecting portfolios of specifications B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 59 of 102
Step 7- Complete defining the architecture Fully specify the target architecture Inputs Technical Architecture 0.6 Outputs Technical Architecture 0.7 Fully defined (by service) list of standards All the building blocks Architecture specification (by building blocks) Requirements traceability Mapping of the architecture in the architecture continuum B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 60 of 102
Step 8 - Conduct a gap analysis Understand the gaps in the architecture between the architecture and reality Inputs Technical Architecture 0.7 Outputs Technical Architecture 1 Gap report B 1 create baseline 2 consider views 3 create arch model 6 determine criteria 4 select services 5 confirm bus objs 7a define architecture 7b identify ABBs 8 conduct gap analysis D TOGAF The Continuing Story 61 of 102
Gap matrix Target Current Video conferencing services Enhanced telephony services Mailing list services ELIMINATED SERVICES Broadcast services Intentionally eliminated Video conferencing services Included Enhanced telephony services Potential match Shared screen services Unintentionally excluded REVISE NEW GAP Enhancement to be developed GAP To be procured TOGAF The Continuing Story 62 of 102
The TOGAF ADM G Architecture A framework B description F Implementation Requirements C architecture E Migration options D & solutions TOGAF The Continuing Story 63 of 102
Impact analysis Phase D - Project list Name, description and objectives of each project Phase E - Time oriented migration plan Benefits of migration [including mapping to business requirements] Estimated costs of migration options Criteria measures of effectiveness of projects Risks and issues TOGAF The Continuing Story 64 of 102
The TOGAF ADM D - Opportunities and Solutions Brainstorming sessions on technical requirements from a functional perspective co-existence and interoperability requirements Architecture assessment and gap analysis Project identification and classification Output Impact Analysis - Project list G Architecture maintenance F Implementation E Migration planning A Initiation & framework Requirements D Opportunities & solutions B Baseline description C Target architecture 65 of 102
The TOGAF ADM E - Migration Planning Project prioritization Migration brainstorm session Dependencies, costs and benefits assessment of the various migration projects Risk assessment Roadmap (time-lined) generation Output Impact Analysis - Migration Plan G Architecture maintenance F Implementation E Migration plannimg A Initiation & framework Requirements D Opportunities & solutions B Baseline description C Target architecture TOGAF The Continuing Story 66 of 102
Questions to ask (1) What are the dependencies of this project on other activities? What products are needed? What components must be developed? Does the organization have the resources needed to develop such components? What standards are the products or components built on? When will they be available? TOGAF The Continuing Story 67 of 102
Questions to ask (2) Will the products stand the test of time because of the technology because of the viability of the supplier? What is the cost of retraining the users? What is the likely cultural impact on the user community, and how can it be controlled? What is the total cost of the migration, and what benefits will it deliver? Is the funding available? Is the migration viable? TOGAF The Continuing Story 68 of 102
The TOGAF ADM F - Implementation Project recommendation formulation, for each separate implementation project Document in Impact Analysis: scope of individual projects strategic requirements change requests rules for conformance time-line Document Architecture Contract obtain signature from all developing organizations and sponsoring organization G Architecture maintenance F Implementation E Migration planning A Initiation & framework Requirements D Opportunities & solutions B Baseline description C Target architecture TOGAF The Continuing Story
Architecture Contract Signed statement of intent from the developing organization to follow the architecture Introduction Background The nature of the agreement Scope Strategic requirements Conformance requirements Architecture adopters Time window TOGAF The Continuing Story 70 of 102
The TOGAF ADM G - Architecture Maintenance Input Request for Architecture Work (new cycle) New technology reports Output Request for Architecture Work (new cycle) Technical architecture updates G Architecture maintenance F Implementation A Initiation & framework Requirements B Baseline description C Target architecture E Migration planning D Opportunities & solutions TOGAF The Continuing Story
Key steps in this phase Key steps in this phase include: Ongoing monitoring of technology changes Ongoing monitoring of business changes Assessment of changes and development of position to act Meeting of governing council to decide on handling changes (technology and business) TOGAF The Continuing Story 72 of 102
The TOGAF ADM - the whole cycle A Initiation & G Architecture maintenance B Baseline F Implementation Requirements C Target E Migration options D Opportunities TOGAF The Continuing Story 73 of 102
Request for Architecture Work obtained from the sponsoring/funding organization supplied by the architecture organization of the business Product Information supplied by the Information Technology organization of the business, or supplying partners supplied by the technology watchdog organization 74 of 102
Major output list - ADM A to G Statement of Architecture Work Technical Architecture Impact Analysis Ancillary documents for gaining consensus Business scenarios Business process domain views Project impact assessments TOGAF The Continuing Story 75
More about TOGAF Foundation Architecture Target Architectures Architecture Development Method Technical Reference Model (services) Standards Information Base (standards) Building Block Information Base (future) Business Requirements 76 of 102
Technical Reference Model Infrastructure Applications Application Program Interface Application Platform Communications Infrastructure Interface Communication Infrastructure TOGAF The Continuing Story 77 of 102
Services and Qualities API Infrastructure Applications Business Application Application Platform Services Software Engineering Security Sys & Net Management International Operations User Interface Location & Directory Transaction Processing Operating System Services Data Interchange Data Management Graphics & Image Service Qualities CII Network Services Communication Infrastructure TOGAF The Continuing Story 78 of 102
Standards Information Base (SIB) A complete and up to date database of open industry standards with links to conformant products With user guide Search or full listing Define particular services Define properties of components Keeps the architecture up to date with the latest IT industry consensus TOGAF The Continuing Story 79
TOGAF - its key benefits (1) Vendor-Neutral Comprehensive process - from business requirements to applications to infrastructure The result of 8 years of global development Support for Quick-Start learning curves Mentoring and consultancy Training courses available TOGAF based services for Architecture audit etc. TOGAF The Continuing Story 80 of 102
Refined and honed checklists at all levels - from business requirements to physical components The Standards Information Base Maintained, current and comprehensive The Building Block Information Base is being developed TABB is being planned as an open source architecture tool TOGAF available today http://www.opengroup.org/architecture/togaf/ TOGAF is on free-license for own use Third-party users are expected to join the Forum Any member can participate in shaping TOGAF s evolution TOGAF The Continuing Story 81 of 102
TOGAF The Continuing Story The Architecture Forum The Next TOGAF for Enterprise Architectures The enhancements to the ADM Boundaryless Information How this maps onto the Zachman Other activities of the Forum Future directions TOGAF The Continuing Story 82 of 102
WARNING! Everything about TOGAF 8 is provisional, subject to The Open Group s review process 83 of 102
What is our current motivation? Changes that will influence the future take-up of Architecture More extended enterprises More co-operative IT operations Tighter IT budgets Global competition More frantic skills chase Increase in litigation Failure can be terminal TOGAF The Continuing Story 84 of 102
What is our current motivation? Pace set by public agencies and large vendors More enforcement of acquisition regulations Clinger-Cohen Act (US Information Technology Management Reform Act 1996) EU Directives on the Award of Public Contracts Contracting Authority needs procedures for ensuring: Completeness of given business requirements Vendor independent expression of needs Same information to all TOGAF The Continuing Story 85 of 102
What is the Enterprise Edition? An Enterprise Architecture is the technical foundation of an effective IT strategy Types of architecture: Business architecture Information System Architectures Data or information architecture Application architecture Technology architecture All these are related TOGAF 8 TOGAF 7 TOGAF The Continuing Story 86 of 102
Schedule for TOGAF 8 09 Sep Start company review 07 Oct End company review 17-18 Oct Change Request review meeting 01 Nov Recommendations posted for ballot 04-15 Nov Ballot of recommendations 18-22 Nov Address unresolved issues 02 Dec 'Sanity check' draft review 09 Dec Board approval to publish 13 Dec TOGAF Version 8 published TOGAF 8 TOGAF The Continuing Story 87 of 102
The Enhanced ADM Preliminary Framework & Principles G Architecture Change Management A Architecture Vision B Business Architecture G Implementation Governance Requirements Management C C Information Information System System Architectures Architectures F Migration Planning E Opportunites & Solutions D Technology Architecture TOGAF The Continuing Story 88 of 102
Preliminary steps Getting the buy-in The most difficult stage The most important stage Establishing the Architecture Framework Customizing, configuring and selecting options suitable for the organization Integrating the framework with existing procedures Preserving tried, trusted, or mandated procedures Monitored pilot project Built-in leeway to allow for familiarization and fine-tuning TOGAF The Continuing Story 89 of 102
Establishing the Architecture Framework Providing a foundation for the framework by establishing: Architecture principles to guide all future work on all future architectures IT Governance Architecture compliance procedures Customizing the framework to suit the environment Choosing the tools Creating a repository for Building Blocks (BBIB?) TOGAF The Continuing Story 90 of 102
The Zachman Framework What? How? Where? Who? When? Why? Data Function Network People Time Motivation Planner s Viewpoint Contextual Owner s Viewpoint Conceptual Designer s Viewpoint Logical Builder s Viewpoint Physical Sub-contractor s Viewpoint Out-of-context Functioning Enterprise Validated Validated Approved statement Validated Architecture principles of architecture principles work principles principles Business Business Correlation of Organization organization Business goals functions and function structureroles and Data model Business baseline version 1 Framework Business Data objectives model managem t Gap analysis results processes definition managem t Business view Business architecture version 1 Business processes view services Common application Data dissemination Technology services Technical view baseline 1 Application Data Application architecture user version 0.2 Target data Target architecture application architecture information lifecycle interop. Data Applications lifecycle interoperability Technology location view information viewtechnical Data architecture view security architecture view version version 0.3 1 view Technology architecture version 0.1 Refined Business Business principles principles goals goals & drivers drivers Constraints Technical on requirements technology architecture Technology architecture version 0.4 Gap analysis results Scope Enterprise Models Systems Models Technology Models Detailed Representations Actual Systems TOGAF The Continuing Story 91 of 102
Possible transition policy TOGAF 7 will be frozen and retained as the version for Technology Architectures TOGAF 8 will be the first release of the Enterprise Edition There will be work to be completed for the Business, Data and Application Architectures The Technology Architecture will not be as strong as TOGAF 7 due to changes to integrate with the other Architectures Future releases will complete, strengthen and work harden the Enterprise Edition TOGAF 7 will be withdrawn when the Technology subset of the Enterprise Edition is as complete as TOGAF 7 TOGAF The Continuing Story 92 of 102
III-RM Graphic Integrated Information Infrastructure Reference Model TOGAF The Continuing Story 93 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Completing the Architectural capability Architecture practitioners Architecture tools Future directions TOGAF The Continuing Story 94 of 102
The Architecture Forum Striving to achieve a total, practical Architecture solution TOGAF Architect Certification A good Architecture framework Tools Certification Knowledgeable and professional practitioners Support tools at all levels TOGAF The Continuing Story 95 of 102
Separate issues of architect certification 1) Defining the role of Architect(s) in developing information services 2) Identifying the skills, knowledge and experience necessary to fulfil that role 3) Identifying techniques for validating each of (2) 4) Recommend Certification Programs based on a combination of (3) 5) Accrediting Certification Programs to achieve a level global standard How far? Informative Advisory Commercial TOGAF The Continuing Story 96
Role players Recommends Certification to Certifies the Architects of Standards body Certification Authority Accreditation Authority Certification Provider Architecture Practice User Specifies procedures & standards Accredits Certification Program of Evaluates Architects of Provides Architectural Services to TOGAF The Continuing Story 97 of 102
Stakeholder categories Education & Training Professional Bodies and Associations IT industry Enterprise Users Legislators Recruitment Organizations 28 Stakeholders identified TOGAF The Continuing Story 98 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions TOGAF The Continuing Story 99 of 102
What are our future directions? Evolution of TOGAF Enterprise Edition Bring to maturity Enhance to align with OMG s MDA Enhance to include mobility features Enhance to support Quality of Service Possible alignment with Zachman Framework Enhance to include industry TRMs Promote, support, advise and get it all into use. Develop the distributed BBIB Establishment of IT Architect Certification Protection of TOGAF with Certification TOGAF The Continuing Story100 of 102
TOGAF Certification To protect the value of TOGAF Architecture tools to ensure that the ADM is supported consistently by different architecture tools Training courses to ensure that the course syllabus includes coverage of the necessary elements of the ADM Architects to ensure that professional services are delivered by architects who up to date knowledge Professional services to ensure that organizations who offer such services abide by an approved code of practice and use properly trained architects TOGAF The Continuing Story101 of 102
TOGAF The Continuing Story The Architecture Forum Our motivation for developing TOGAF The Current TOGAF for Technical Architectures The Next TOGAF for Enterprise Architectures Other activities of the Forum Future directions Any questions? TOGAF The Continuing Story102 of 102