Togaf 9 introduction
- 1. TOGAF 9 Vinod Wilson – Architect – Crestron Electronics
- 3. ADM AND THE TOGAF CROP CIRCLE DIAGRAM
- 4. From baseline to target architecture
- 5. Transition architectures and increments (states)
- 6. Gap analysis • Which elements are new (organizations, applications, infrastructures)? • Which elements have been deleted? • Which elements have been modified? • Which elements remain unchanged?
- 7. Impact evaluation • An enterprise is often a complex organization with multiple branches. Consequently, the modification of one part of its architecture may potentially affect other components situated outside the scope of the implemented changes.
- 8. The concept of capability • Capability designates the ability of an organization to provide a given product or service. Capability manifests itself through a series of factors that contribute to the realization of these products or services at the required level of quality. These factors can vary widely in type: for example, • personnel training, • availability of an expert in a field, • surface area of premises, • power of IT servers, and so on.
- 9. Capability • “The ability of an organization, person, process, application, IT service or other configuration item to carry out an activity.”
- 10. Architecture and description of architecture 1. “A formal description of a system, or a detailed plan of the system at component level, to guide its implementation.” 2. “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”
- 11. Domains and phases • Business architecture, which covers strategy, goals, business processes, functions, and organization. • Data architecture, dedicated to the organization and management of information. • Application architecture, which presents applications, software components, and their interactions. • Technology architecture, which describes the techniques and components deployed, as well as networks and the physical infrastructure upon which the applications and data sources run.
- 13. Architecture repository • Naturally, enterprises need to conserve, diffuse, and reuse the EA information that constitutes one of their key assets. • This is the role of the architecture repository, which includes descriptions from each of the four domains, as well as a whole host of knowledge, guiding principles, and techniques linked to enterprise architecture.
- 14. Architecture and solution • Architecture - designates a description, and more precisely a logical view • Solution - represents a technical reality • ABB(Architecture Building Block) - The logical specification of an element • SBB(Solution Building Block) – Physical specification of an element
- 15. GOALS, CONSTRAINTS, AND REQUIREMENTS Strategic Objectives or Goals • Describe general orientation Operational Objectives • Formalize the goals in terms of measurable results at a given date Drivers • Motivates decisions regarding architectural change Requirements • Specify what will be concretely implemented to reach the stated goal Constraints • Which are external that influence the system
- 16. Role of the enterprise architect • The role of an enterprise architect is not to define objectives (strategic or operational) for an organization • He/She will formalize them within a structured context, and will use this formalization to better link decisions and architectural elements
- 17. STAKEHOLDERS AND THE HUMAN FACTOR • Stakeholder management • Transformation Readiness Assessment • Efficiency of communication through the concept of viewpoints
- 18. Managing stakeholders • Who defines goals? • Who gains and who loses from this change? • Who controls the transformation process? • Who designs new systems? • Who will make the decisions? • Who procures IT systems and who decides what to buy? • Who controls resources? • Who has or controls the necessary specialist skills? • Who influences the project?
- 19. Degrees of Stakeholder involvement
- 20. Transformation Readiness Assessment • A clear presentation of the impacts of changes made, notably on an organizational level • A concrete view of the expected business benefits, in the form of “business cases” • An objective assessment of the enterprise’s IT, business, and financial aptitudes, with no overestimation of its real capacities • An executive management team recognized as being able to defend the project in the long term • High-quality communication, which aims to promote a common understanding of the stakes and the solutions to implement
- 21. Views and viewpoints • If a message is to be successfully understood, the most important aspect to consider is that its content and form must be tailored to the intended recipient. • Viewpoints - A viewpoint designates the most appropriate perspective for a given participant, and is materialized by a certain number of views of the architecture, in the form of diagrams, documents, or other elements • It is imperative that views and viewpoints be defined for each stakeholder before beginning work on the four architecture domains (business, data, application, and technology)
- 22. Governance • To slow down the centrifugal forces and retain a certain level of overall consistency, it is essential that an appropriate organization be established • This organization, called the “architecture board,” is responsible for the following goals: to guarantee that common rules are respected, and to ensure that implementation projects are supported. In its capacity as a steering and control committee, the architecture board also takes care of managing the architecture repository.
- 23. Architecture principles • They establish a set of rules and recommendations, which encourage the harmonization of choices and practices. • Architecture principles properties • Stability: Principles are stable by nature. They are only rarely modified compared with the frequency of developments. • General scope: A principle applies to the entire enterprise, and does not depend on the transformation carried out. • Comprehensibility: A principle is interpreted clearly by all stakeholders. • Coherence: With regard to the set of principles. Two principles cannot be contradictory.
- 24. Summarized view of Architecture transformation project
- 25. TOGAF and DODAF • DODAF viewpoints are structured as follows: • All Viewpoint (AV) • Capability Viewpoint (CV) • Data and Information Viewpoint (DIV) • Operational Viewpoint (OV) • Project Viewpoint (PV) • Services Viewpoint (SvcV) • Standards Viewpoint (StdV) • Systems Viewpoint (SV)
- 26. TOGAF Viewpoints • As in TOGAF, each viewpoint is broken down into a collection of views, each designed to represent a part of the architecture Operational Viewpoint OV-1 High Level Operational Concept Graphic OV-2 Operational Node Connectivity Description OV-3 Operational Information Exchange Matrix OV-4 Organizational Relationships Chart OV-5 Operational Activity Model OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event-Trace Description OV-7 Logical Data Model
- 27. Enterprise architecture process maturity levels •No enterprise architecture program. No enterprise architecture to speak of.Level 0: None •Informal enterprise architecture process underway Level 1: Initial •Enterprise architecture process is under development.Level 2: Under Development •Defined enterprise architecture including detailed written procedures and TRM.Level 3: Defined •Managed and measured enterprise architecture process.Level 4: Managed •Continuous improvement of enterprise architecture process.Level 5: Optimizing
- 28. Thank You