TOGAF 9 Training: Foundation

Transcription

1 TOGAF 9 Training: Foundation Part I: Basic Concepts Document version control information Document Name Document Status Document Owner Part I: Basic Concepts Final IT Management Group TOGAF Lead Trainer Approved Approved by Version number IT Management Group Quality Manager V /

2 Level 1 TOGAF 9 Foundation Learning Units Basic Concepts Core Concepts General Definitions Introduction to the ADM Enterprise Continuum and Tools ADM Phases (Level 1) ADM Guidelines and Techniques Architecture Governance (Level 1) Architecture Views, Viewpoints and Stakeholders Building Blocks ADM Deliverables (Level 1) TOGAF Reference Models (Level 1) TOGAF Certification Program

3 Level 2 TOGAF 9 Certified Learning Units Level 1 Units + Preliminary Phase Architecture Governance (Level 2) Business Scenarios Technique Phase A: Architecture Vision Architecture Content Framework Stakeholder Management TOGAF Content Metamodel Architecture Implementation Support Techniques Phase B: Business Architecture Phase C: Information Systems Architectures Data Architecture Phase C: Information Systems Architectures Application Architecture TOGAF Foundation Architecture: The Technical Reference Model (Level 2) The Integrated Information Infrastructure Reference Model (Level 2) Phase D: Technology Architecture Migration Planning Techniques Phase E: Opportunities and Solutions Phase F: Migration Planning Phase G: Implementation Governance Phase H: Architecture Change Management ADM Architecture Requirements Management Architecture Partitioning The Architecture Repository Guidelines for Adapting the ADM: Iteration and Levels Guidelines for Adapting the ADM: Security Guidelines for Adapting the ADM: SOA Architecture Maturity Models Architecture Skills Framework

4 Certification

5 What is TOGAF? The Open Group Architecture Framework TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization Introduction TOGAF KLP /

6 TOGAF : Meaning of architecture A formal description of a system, or a detailed plan of the system at component level to guide its implementation. The structure of of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. TOGAF embraces but does not strictly adhere to ISO/IEC 42010: 2007 terminology 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. Introduction Architecture KLP /

7 TOGAF : Architecture Framework Characteristics of an Architecture Framework Foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. 7 /

8 Enterprise and Enterprise Architecture An Enterprise is any collection of organizations that has a common set of goals, for example: Government agency Whole corporation Division of a corporation Single department Enterprise architecture encompassing all of its information and technology services, processes, and infrastructure The architecture crosses multiple systems, and multiple functional groups within the enterprise. 8 /

9 Benefits of Enterprise Architecture More effective and efficient business operations: Lower business operation costs More agile organization Business capabilities shared across the organization Lower change management costs More flexible workforce Improved business productivity More effective and efficient Digital Transformation and IT operations: Extending effective reach of the enterprise through digital capability Bringing all components of the enterprise into a harmonized environment Lower software development, support, and maintenance costs Increased portability of applications Improved interoperability and easier system and network management Improved ability to address critical enterprise-wide issues like security Easier upgrade and exchange of system components Better return on existing investment, reduced risk for future investment: Reduced complexity in the business and IT Maximum return on investment in existing business and IT infrastructure The flexibility to make, buy, or out-source business and IT solutions Reduced risk overall in new investments and their cost of ownership Faster, simpler, and cheaper procurement: Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence The ability to procure heterogeneous, multi-vendor open systems The ability to secure more economic capabilities 9 /

10 Structure of TOGAF PART I (Introduction) This part provides a high-level introduction to the key concepts of Enterprise Architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout this standard. PART II (Architecture Development Method) This part is the core of the TOGAF framework. It describes the TOGAF Architecture Development Method (ADM) - a step-bystep approach to developing an Enterprise Architecture. PART III (ADM Guidelines & Techniques) This part contains a collection of guidelines and techniques available for use in applying the TOGAF approach and the TOGAF ADM. Additional guidelines and techniques are available in the TOGAF Library. PART IV (Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables. PART V (Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise. PART VI (Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise. Introduction Structure of TOGAF KLP 1.1-1, /

11 Structure of TOGAF Library Library resources are organized into four sections: Section 1. Foundation Documents Section 2. Generic Guidance and Techniques Section 3. Industry-Specific Guidance and Techniques Section 4. Organization-Specific Guidance and Techniques

12 TOGAF : Architectures domains Business Architecture: business strategy, governance, organization, and key business processes Data Architecture: logical and physical data assets and data management resources Application Architecture: individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization Technology Architecture: logical software and hardware capabilities Introduction Architecture KLP /

13 Architecture Development Method TOGAF Architecture Development Method (ADM) describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF. 13 /

14 Architecture Development Method Architecture Capability Preliminary: Establish the Architecture Capability Architecture Motivation A: Develop the Architecture Vision and obtain approval Architecture Development B: Develop the Business Architecture C: Develop the Data and Application Architectures D: Develop the Technology Architecture Transition Planning E: Create an initial version of the Architecture Roadmap F: Implementation and Migration Plan Architecture Realization G: Ensure conformance with the Target Architecture Architecture Maintenance H: Ensure that the Architecture meets current requirements 14 /

15 Architecture Capability Preliminary The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles. Output: Organization Model for the Enterprise Tailored Architecture Framework Initial Architecture Repository Restatement of, or reference to, business principles, business goals, and business drivers Request for Architecture Work (optional) Architecture Governance Framework 15 /

16 Architecture Motivation Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development. Main Outputs: Approved Statement of Architecture Work Refined sta tements of business principles, business goals, and business drivers Architecture principles Capability Assessment Tailored Architecture Framework Architecture Vision Draft Architecture Definition Document Communications Plan Additional content populating the Architecture Repository 16 /

17 Architecture Development The steps which are defined in Phase B,C, and D are exactly the same. Phase B: Business Architecture Describes the development of a Business Architecture to support the agreed Architecture Vision. Phase C: Information Systems Architectures Describes the development of Information Systems Architectures to support the agreed Architecture Vision. Phase D: Technology Architecture Describes the development of the Technology Architecture to support the agreed Architecture Vision. Main Outputs: Architecture Definition Document Architecture Requirements Specification Architecture Roadmap 17 /

18 Architecture Development A version numbering convention is used within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions. A. Architecture Vision B. Business Architecture C Information System Architecture D Technology Architecture /

19 Transition Planning Phase E: Opportunities & Solutions describes the process of identifying deliver y vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases. Phase F: Migration Planning addresses migration planning; that is, how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan. Main Outputs: Transition Architectures Implementation recommendations Implementation and Migration Plan Re-Usable Architecture Building Blocks Requests for Architecture Work Implementation Governance Model Change Requests for the Architecture Capability arising from lessons learned 19 /

20 Transition Planning A version numbering convention is used within the ADM to illustrate the evolution of Implementation and Migration Planing. E: Opportunities & Solutions 0.1 F: Migration Planning /

21 Architecture Realization Phase G: Implementation Governance Provides an architectural oversight of the implementation. Main Outputs: Architecture Contract Compliance Assessments Change Requests Architecture-compliant solutions deployed 21 /

22 Architecture Maintenance Phase H: Architecture Change Management Establishing procedures for managing change to the new architecture. Main Outputs: Architecture updates (for maintenance changes) Changes to architecture framework and principles (for maintenance changes) New Request for Architecture Work, to move to another cycle (for major changes) Statement of Architecture Work Architecture Contract Compliance Assessments 22 /

23 Requirements Management Requirements Management As indicated by the Requirements Management circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process Main Outputs: Requirements Impact Assessment Updated Architecture Requirements Specification 23 /

24 ADM Guidelines and Techniques ADM Guidelines describes scenarios, process styles and specialist architecture how the Architecture Development Method (ADM) process can be adapted. ADM Techniques describes specific tasks within the ADM. 24 /

25 ADM Guidelines & Techniques ADM Guidelines ADM Techniques Applying Iteration to the ADM Applying the ADM across the Architecture Landscape Architecture Principle Stakeholder Management Architecture Patterns Gap Analysis Migration Planning Techniques Business Transformation Readiness Assessment Interoperability Requirements Risk Management Capability-Based Planning 25 /

26 Architecture Content Framework The Architecture Content Framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented. 26 /

27 Basic Architectural Concepts System: Collection of components organized to accomplish a specific function or set of functions Architecture of a system: system s fundamental organization embodied in its components their relationships to each other and to the environment and the principles guiding its design and evolution 27

28 Basic Architectural Concepts Architecture description: Collection of artifacts that document an architecture Stakeholders: People who have key roles in, or concerns about, the system Different stakeholders with different roles in the system will have different concerns Stakeholders can be individuals, teams, or organizations 28

29 Basic Architectural Concepts Concerns: Key interests that are crucially important to the stakeholders in the system Determine the acceptability of the system Architecture View: A representation of a system from the perspective of a related set of concerns. 29

30 Basic Architectural Concepts Viewpoint: Defines the perspective from which a view is taken Defines how to construct and use a view (by means of an appropriate schema or template) 30

31 Basic Architectural Concepts An architecture view is what you see A viewpoint is where you are looking from - the vantage point or perspective that determines what you see Viewpoints are generic, and can be stored in libraries for re-use. An architecture view is always specific to the architecture for which it is created. Every architecture view has an associated viewpoint that describes it, at least implicitly. 31

32 Content Metamodel 32 /

33 Core Content Metamodel 33 /

34 Content Metamodel Concepts Core Metamodel concepts Core and Extension Content. Core Metamodel Entities Catalog, Matrix, and Diagram Concept This core and extension concept is intended as a move towards supporting formal method extension approaches within TOGAF, such as the method plug-in concept. 34 /

35 Deliverables, Artifacts and Building Blocks Deliverable a work product that is contractually specified Artifact a granular architectural work product Building Block represents a (potentially reusable) component: Architecture Building Block Solution Building Block 35 /

36 Building Block - Definition A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions. Architecture Building Blocks (ABB) Capture architecture requirements; e.g., business, data, application, and technology requirements Direct and guide the development of SBBs Solution Building Blocks (SBB) Define what products and components will implement the functionality Define the implementation Fulfill business requirements Are product or vendor-aware 36 /

37 Building Blocks Building blocks have generic characteristics as follows: A building block is a package of functionality defined to meet the business needs across an organization. A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity) A building block has a defined boundary and is generally recognizable as "a thing" by domain experts. A building block may interoperate with other, inter-dependent, building blocks. A good building block has the following characteristics: It considers implementation and usage, and evolves to exploit technology and standards. It may be assembled from other building blocks. It may be a subassembly of other building blocks. Ideally a building block is re-usable and replaceable, and well specified. 37 /

38 Building Blocks

39 Building Blocks - Principles Use only building blocks that are relevant to the business problem Building blocks may have complex relationships to one another. Building blocks should conform to standards relevant to; their type; the principles of the enterprise; the standards of the enterprise. 39 /

40 Building Block - Characteristics A building block is a package of functionality defined to meet the business needs across an organization. A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity) A building block has a defined boundary and is generally recognizable as "a thing" by domain experts. A building block may interoperate with other, inter-dependent, building blocks. A good building block has the following characteristics: It considers implementation and usage, and evolves to exploit technology and standards. It may be assembled from other building blocks. It may be a subassembly of other building blocks. Ideally a building block is re-usable and replaceable, and well specified.

41 Building Block Design Consider three classes of building blocks: Re-usable building blocks (legacy items) Building blocks to be subject of development (new applications) Building blocks to be subject of purchase (COTS applications) Use desired level of integration to bind or combine functions into building blocks. 41 /

42 Patterns And Building Blocks Patterns are a way of putting building blocks into context Building blocks are what you use; patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so Patterns help architect identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past, and may provide the basis for effective solutions in the future 42 /

43 Artifact a Basic Concept 43 /

44 What is an artifact? Granular architectural work product that describes an aspect of the architecture Views of the building blocks relevant to the architecture 44 /

45 Artifacts types Artifacts are generally classified as catalogs, matrices and diagrams. Catalogs lists of things Location 1 Actor 1 Actor 2 Location 2 Actor 2 Actor 3 Matrices showing relationships between things Diagrams pictures of things 45 /

46 Artifacts by ADM Phase 46 /

47 Architecture Deliverables Architecture Building Blocks Architecture Contract Architecture Definition Document Architecture Principles Architecture Repository Architecture Requirements Architecture Roadmap Architecture Vision Business Principles, Business Goals, and Business Drivers Capability Assessment Change Request Communications Plan Compliance Assessment Implementation and Migration Plan Implementation Governance Model Organizational Model for Enterprise Request for Architecture Work Requirements Impact Assessment Solution Building Blocks Statement of Architecture Work Tailored Architecture Framework 47 /

48 Enterprise Continuum and Tools The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. The Enterprise Continuum describes how architectures can be partitioned and organized within a repository. 48 /

49 Architecture Repository Architecture Repository can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. 49 /

50 Enterprise Continuum The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization- Specific Architectures 50 /

51 Enterprise Continuum in detail Introduction Enterprise Continuum and Tools 51 /

52 Architecture Capability Framework 52 /

53 Architecture Capability Framework Consist of: Establishing an Architecture Capability Architecture Board Architecture Compliance Architecture Contracts Architecture Governance Architecture Maturity Models Architecture Skills Framework Introduction Architecture Capability Framework 53 /

54 Capability as an Operational Entity A successful enterprise architecture practice must sit on a firm operational footing. an enterprise architecture practice must be run like any other operational unit within a business Financial Management Performance Management Service Management Risk Management Resource Management Communications and Stakeholder Management Quality Management Supplier Management Configuration Management Environment Management 54 /

55 Related Management Frameworks 55 /

56 TOGAF with other Frameworks 56 /

57 Establishing And Maintaining An Enterprise Architecture Capability In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures roles, responsibilities skills processes 57

58 Establishing And Maintaining An Enterprise Architecture Capability

59 Architecture Development Method Architecture Capability Preliminary: Establish the Architecture Capability Architecture Motivation A: Develop the Architecture Vision and obtain approval Architecture Development B: Develop the Business Architecture C: Develop the Data and Application Architectures D: Develop the Technology Architecture Transition Planning E: Create an initial version of the Architecture Roadmap F: Implementation and Migration Plan Architecture Realization G: Ensure conformance with the Target Architecture Architecture Maintenance H: Ensure that the Architecture meets current requirements Introduction Architecture Development Method 59 /

60 Typical Steps in Phase B,C,D Select Reference Models, Viewpoints, and Tools Develop Baseline Business Architecture Description Develop Target Business Architecture Description Perform Gap Analysis Define Candidate Roadmap Components Resolve Impacts Across the Architecture Landscape Conduct Formal Stakeholder Review Finalize the Business Architecture Create the Architecture Definition Document

61 Architecture Development A version numbering convention is used within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions. A. Architecture Vision B. Business Architecture C Information System Architecture D Technology Architecture /

62 ADM, Enterprise Continuum, and Architecture Repository 62 /

63 ADM Guidelines and Techniques ADM Guidelines describes scenarios, process styles and specialist architecture how the Architecture Development Method (ADM) process can be adapted. ADM Techniques describes specific tasks within the ADM. 63 /

64 ADM Guidelines & Techniques ADM Guidelines ADM Techniques Applying Iteration to the ADM Applying the ADM across the Architecture Landscape Architecture Principle Stakeholder Management Architecture Patterns Gap Analysis Migration Planning Techniques Business Transformation Readiness Assessment Interoperability Requirements Risk Management Capability-Based Planning 64 /

65 Key Points ADM The breadth of coverage of the enterprise to be defined The level of detail to be defined The extent of the time period aimed at, including the number and extent of any intermediate time periods The architectural assets to be leveraged, including: o Assets created in previous iterations of the ADM cycle within the enterprise o Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.) These decisions should be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

66 Reasons to tailor the ADM The order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise The order of phases may also be defined by the architecture principles and business principles of an enterprise TOGAF is to be integrated with another enterprise framework

67 Governance Framework (Conceptual Structure) (Organizational Structure) 67 /

68 Governance Framework 68 /

69 The major information areas managed by a governance repository Reference Data (collateral from the organization's own repositories/enterprise Continuum, including external data; e.g., COBIT, ITIL): Used for guidance and instruction during project implementation. This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves. Process Status: All information regarding the state of any governance processes will be managed; examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations. Audit Information: This will record all completed governance process actions and will be used to support: Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process A reference for future architectural and supporting process developments, guidance, and precedence

70 Architecture Partitioning Determine the organization structure Governance bodies that are applicable to the team Team membership Team reporting lines Determine the responsibilities for each standing architecture team Subject matter areas being covered Level of detail that the team will work at Time periods to be covered Stakeholders Determine the relationships between architecutes Where do different architectures overlap/dovetail/drill-down? What are the compliance requirements between architectures? 70 /

71 Enterprise Continuum and Tools The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. The Enterprise Continuum describes how architectures can be partitioned and organized within a repository. 71 /

72 Architecture Repository Architecture Repository can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. 72 /

73 Architecture Repository The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise The Governance Log provides a record of governance activity across the enterprise The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been agreed with the Architecture Board The Solutions Landscape presents an architectural representation of the Solution Building Blocks (SBBs) supporting the Architecture Landscape which have been planned or deployed by the enterprise

74 Enterprise Continuum The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures 74 /

75 Enterprise Continuum in detail Architecture Continuum Foundation Common System Industry Organization- Specific Solution Continuum 75 /

76 Architecture Continuum Foundation Architecture: consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built Common Systems Architectures: guide selection and integration of specific services from the Foundation Architecture to create an architecture useful for building common solutions across a wide number of relevant domains 76

77 Architecture Continuum Industry Architectures: guide integration of common systems components with industryspecific components Organization-Specific Architectures: describe and guide final deployment of solution components for a particular enterprise or extended network of connected enterprises 77

78 Foundation Solutions: Foundation Solutions generic concepts, tools, products, services, and solution components that are fundamental providers of capabilities Services include: professional services that ensure the maximum investment value from solutions in the shortest possible time support services that ensure the maximum possible value from solutions 78

79 Common Systems Solutions Implementation of a Common Systems Architecture comprised of a set of products and services, which may be certified or branded Represents highest common denominator for one or more solutions in the industry segments that the Common Systems Solution supports Represent collections of common requirements and capabilities 79

80 Industry Solutions Implementation of an Industry Architecture, which provides reusable packages of common components and services specific to an industry Industry-specific, aggregate procurements, ready to be tailored to an individual organization s requirements 80

81 Organization-specific Solutions Implementation of the Organization-Specific Architecture that provides the required business functions Building Organization-Specific Solutions on Industry Solutions, Common Systems Solutions, and Foundation Solutions is the primary purpose of connecting the Architecture Continuum to the Solutions Continuum, as guided by the architects within an enterprise. 81

82 TOGAF Reference Models The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. The Enterprise Continuum describes how architectures can be partitioned and organized within a repository. 82 /

83 Technical Reference Model (TRM) TRM has two main components: A taxonomy An associated TRM graphic Architectural objectives: Application Portability Via the Application Platform Interface - identifying the set of services that are to be made available in a standard way to applications via the platform Interoperability Via the Communications Infrastructure Interface - identifying the set of Communications Infrastructure services that are to be leveraged in a standard way by the platform 83 /

84 TRM in Detail Categories of Application Software Business Applications, which implement business processes for a particular enterprise or vertical industry Infrastructure Applications, which provide general-purpose business functionality, based on infrastructure services The TOGAF TRM identifies a generic set of platform services, and provides a taxonomy in which these platform services are divided into categories of like functionality. A particular organization may need to augment this set with additional services or service categories which are considered to be generic in its own vertical market segment 84 /

85 Derivation of III-RM from TRM The Integrated Information Infrastructure Reference Model III-RM is a model of the major component categories for: Developing Managing Operating It is a model of a set of applications It sits on top of an Application Platform. It is a subset of the TOGAF TRM, and it uses a slightly different orientation. Supports the Boundaryless Information Flow Introduction TOGAF Reference Models 85 /

86 Components of III-RM Business Applications Brokering Applications Information Provider Applications Information Consumer Applications Infrastructure Applications Development Tools Management Utilities Application Platform Interfaces Qualities Security Mobility Performance SLA Management Utilities Introduction TOGAF Reference Models 86 /

87 Governance Framework The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps. (Conceptual Structure) (Organizational Structure) 87 /

88 Governance Framework Benefits: Links IT processes, resources, and information to organizational strategies and objectives Integrates and institutionalizes IT best practices Aligns with industry frameworks such as COBIT Enables the organization to take full advantage of its information, infrastructure, and hardware and software assets Protects the underlying digital assets of the organization Supports regulatory and best practice requirements Promotes visible risk management 88 /

89 Architecture Board Role Key element in a successful architecture governance strategy: Cross organization Architecture Board to oversee implementation of strategy Representing all key stakeholders in the architecture Comprises a group of executives responsible for review and maintenance of overall architecture May have global, regional, or business line scope 89 /

90 Architecture Board Responsibilities Providing the basis for all decision-making with regard to the architectures Consistency between sub-architectures Establishing targets for re-use of components Flexibility of enterprise architecture: To meet changing business needs To leverage new technologies Enforcement of Architecture Compliance Improving the maturity level of architecture discipline within the organization Ensuring that the discipline of architecture-based development is adopted Supporting a visible escalation capability for out-of-bounds decisions 90 /

91 Setting Up The Architecture Board Typical triggers for establishment of Architecture Board: New CIO Merger or acquisition Recognition that IT is poorly aligned to business Creation of enterprise architecture program Significant business change or rapid growth Recommended size: Four or five (and no more than ten) permanent members 91 /

92 Architecture Contracts Statement of Architecture Work The Statement of Architecture Work is created as a deliverable of Phase A, and is effectively an Architecture Contract between the architecting organization and the sponsor of the enterprise architecture Contract between Architecture Design and Development Partners This is a signed statement of intent on designing and developing the enterprise architecture, or significant parts of it, from partner organizations, including systems integrators, applications providers, and service providers. Contract between Architecture Function and Business Users This is a signed statement of intent to conform with the enterprise architecture, issued by enterprise business users. 92 /

93 Architecture Compliance The Architecture function will be required to prepare a series of Project Architectures; i.e., project-specific views of the enterprise architecture that illustrate how the enterprise architecture impacts on the major projects within the organization. The IT Governance function will define a formal Architecture Compliance review process for reviewing the compliance of projects to the enterprise architecture. 93 /

94 Architecture Compliance Goals Catch errors in the project architecture early, and thereby reduce the cost and risk of changes required later in the lifecycle. Ensure the application of best practices to architecture work. Provide an overview of the compliance of an architecture to mandated enterprise standards. Identify where the standards themselves may require modification. Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure. Document strategies for collaboration, resource sharing, and other synergies across multiple architecture teams. Take advantage of advances in technology. Communicate to management the status of technical readiness of the project. Identify key criteria for procurement activities. Identify and communicate significant architectural gaps to product and service providers. 94 /

95 Architecture Compliance Review The Architecture Compliance review can be a good way of deciding between architectural alternatives. The output of the Architecture Compliance review is one of the few measurable deliverables to the CIO to assist in decision-making. Architecture reviews can serve as a way for the architecture organization to engage with development projects that might otherwise proceed without involvement of the architecture function. Architecture reviews can demonstrate rapid and positive support to the enterprise business community. 95 /

96 Levels of Architecture Conformance Implementation accordance specification, means: Supports the stated strategy and future directions Adheres to the stated standards (including syntax and semantic rules specified) Provides the stated functionality Adheres to the stated principles; for example: Open wherever possible and appropriate Re-use of component building blocks wherever possible and appropriate 96 /

97 Compliance Assessment Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Content: Overview of project progress and status Overview of project architecture/design Completed architecture checklists: Hardware and operating system checklist Software services and middleware checklist Applications checklists Information management checklists Security checklists System management checklists System engineering checklists Methods and tools checklists 97 /

98 Establishing an Architecture Capability Phase A: Architecture Vision Establish the Project Identify Stakeholders and Concerns, Business Requirements, and Architecture Vision Identify Business Goals and Business Drivers Define Scope Define Constraints Review Architecture Principles, including Business Principles Develop Statement of Architecture Work and Secure Approval Phase B: Business Architecture Architecture Ontology Architecture Process Architecture Viewpoints and Views Architecture Framework Architecture Accountability Matrix Architecture Performance Metrics Architecture Governance Framework 98 /

99 TOGAF 9 Training: Foundation Day 2 99 /

100 Preliminary Preliminary Phase is about defining "where, what, why, who, and how we do architecture 100 /

101 Objectives Determine the Architecture Capability (desired by the organization) Review the organizational context Identify organizations affected by the Architecture Capability Identify the established frameworks, methods, and processes Establish the Architecture Capability Organizational Model for Enterprise Architecture Architecture Governance Tools that support the Architecture Capability Define the Architecture Principles 101 /

102 Approach This Preliminary Phase is about defining "where, what, why, who, and how we do architecture" in the enterprise concerned. The main aspects are as follows: Defining the enterprise Identifying key drivers and elements in the organizational context Defining the requirements for architecture work Defining the Architecture Principles that will inform any architecture work Defining the framework to be used Defining the relationships between management frameworks Evaluating the enterprise architecture maturity

103 Applying the ADM across the Architecture Landscape Characteristics used to organize the Architecture Landscape Breadth: The breadth (subject matter) Depth Time Recency / Domains Architecture Landscape Strategic Architecture operational and change activity and allows for direction setting at an executive level. Segment Architecture operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level. Capability Architecture change activity and the development of effective architecture roadmaps realizing capability increments. 103 /

104 Applying the ADM across the Architecture Landscape Each iteration completes an ADM cycle at a single level of architecture description. This approach to the ADM uses Phase F (Migration Planning) to initiate new more detailed architecture development projects 104 /

105 Tailored Architecture Framework Tailor the TOGAF model for integration into the enterprise Tailoring includes: integration with project and process management frameworks customization of terminology development of presentational styles selection, configuration deployment of architecture tools Framework tailored to the enterprise, needs further tailoring in order to tailor it for the specific architecture project Tailoring at this level selects appropriate deliverables and artifacts to meet project and stakeholder needs

106 Architecture Repository Acts as a holding area for all architecture-related projects within the enterprise Allows projects to: manage deliverables locate re-usable assets publish outputs to stakeholders and other interested parties

107 Organizational Model for Enterprise In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Scope of organizations impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints oirn architecture work Budget requements Governance and support strategy 107 /

108 Business Principles/Goals/Drivers Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. The content and structure of business context for architecture is likely to vary considerably from one organization to the next 108 /

109 Request for Architecture Work A document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Content: Summary of Request Organization Sponsors Organization Mission Statement Business Goals (and Changes) Strategic Plans of the Business Changes in the Business Environment Purpose of Architecture Work Success Criteria Timescale Key Constraints Organizational Constraints Budget Information and Financial Constraints External and Business 109 /

110 A: Architecture Vision Phase A starts with receipt of a Request for Architecture Work 110 /

111 Objectives Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision 111 /

112 Approach Creating the Architecture Vision Business Scenarios

113 Business Scenarios A business scenario is essentially a complete description of a business problem, both in business and in architectural terms. Without a business scenario: There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description. The business value of solving the problem is unclear. The relevance of potential solutions is unclear. 113 /

114 Business Scenarios Business Scenario describes: A business process, application, or set of applications that can be enabled by the architecture The business and technology environment The people and computing components (called "actors") who execute the scenario The desired outcome of proper execution 114 /

115 Business Scenarios within the ADM cycle

116 Defining Interoperability From an Organization perspective From an IT perspective Operational or Business Interoperability defines how business processes are to be shared. Information Interoperability defines how information is to be shared. Technical Interoperability defines how technical services are to be shared or at least connect to one another. Presentation Integration/Interoperability Common look-and-feel approach through a common portal-like solution. Information Integration/Interoperability Corporate information is seamlessly shared between the various corporate applications. Application Integration/Interoperability Corporate functionality is integrated and shareable so that the applications are not duplicated. Technical Integration/Interoperability Common methods and shared services for the communication, storage, processing, and access to data primarily in the application platform and communications infrastructure domains. 116 /

117 Interoperability within the ADM A: In the Architecture Vision, the nature and security considerations of the information and service exchanges are first revealed within the business scenarios. B: In the Business Architecture, the information and service exchanges are further defined in business terms. C: In the Data Architecture, the content of the information exchanges are detailed using the corporate data and/or information exchange model. C: In the Application Architecture, the way that the various applications are to share the information and services is specified. D: In the Technology Architecture, the appropriate technical mechanisms to permit the information and service exchanges are specified. E: In Opportunities & Solutions, the actual solutions (e.g., Commercial Off-The-Shelf (COTS) packages) are selected. F: In Migration Planning, the interoperability is logically implemented. 117 /

118 Business Transformation Readiness The assessment should address three things, namely: Readiness Factor Vision Readiness Factor Rating Readiness Factor Risks & Actions 118 /

119 Risk Classification time (schedule) cost (budget) scope client transformation relationship risks contractual risks technological risks scope and complexity risks environmental (corporate) risks personnel risks client acceptance risks. 119 /

120 Risk Management Identify, classify, and mitigate risks before starting implementation and migration (all Phases) Mitigation is ongoing effort and often risk triggers may be outside scope: monitor the transformation context constantly (Phase G) Enterprise architect may identify risks and mitigate certain ones, but: within the governance framework risks have to be accepted and managed Two levels of risk should be considered: 1. Initial Level of Risk 2. Residual Level of Risk 120 /

121 Capability-Based Planning The capabilities are directly derived from the corporate strategic plan by the corporate strategic planners that are and/or include the enterprise architects and satisfy the enterprise goals, objectives, and strategies 121 /

122 Capability-Based Planning The capabilities are directly derived from the corporate strategic plan by the corporate strategic planners that are and/or include the enterprise architects and satisfy the enterprise goals, objectives, and strategies 122 /

123 Architecture Styles The TOGAF framework is designed to be flexible and it can be used with various architectural styles. Further information can be found in the following Guides: Integrating Risk and Security within a TOGAF Enterprise Architecture TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service- Oriented Architectures Step 1: the distinctive features of a style must be identified Step 2: determining how these distinctive features will be addressed In Phase B, Phase C, and Phase D the practitioner is expected to select the relevant architecture resources, including models, viewpoints, and tools, to properly describe the architecture domain and demonstrate that stakeholder concerns are addressed Addressing the distinctive features will usually include extensions to the Architecture Content Metamodel and the use of specific notation or modeling techniques and the identification of viewpoints.

124 Business Scenarios A business scenario is essentially a complete description of a business problem, both in business and in architectural terms. Without a business scenario: There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description. The business value of solving the problem is unclear. The relevance of potential solutions is unclear. 124 /

125 Business Scenarios Business Scenario describes: A business process, application, or set of applications that can be enabled by the architecture The business and technology environment The people and computing components (called "actors") who execute the scenario The desired outcome of proper execution 125 /

126 Communications Plan Enterprise architectures contain large volumes of complex and inter-dependent information. Content: Purpose of this Document Stakeholders Communication Requirements Communication Mechanism Communication Timetable 126 /

127 Capability Assessment To understand the baseline and target capability level of the enterprise Content: Purpose of this Document Business Capability Assessment IT Capability Assessment Architecture Maturity Assessment Business Transformation Readiness Assessment 127 /

128 Architecture Principles Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission Principle 1: Primary of Principles Statement Rationale Implications These principles of information management apply to all organizations within the enterprise. The only way we can provide a consistent and measurable level of quality information to decisionmakers is if all organizations abide by the principles. Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information. Information management initiatives will not begin until they are examined for compliance with the principles. A conflict with a principle will be resolved by changing the framework of the initiative. Components of a principles: Name Statement Rationale Implications 128 /

129 Five criteria that distinguish a good set of principles Understandable Robust Complete Consistent Stable

130 Architecture Vision The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome Content: Problem description: Stakeholders and their concerns List of issues/scenarios to be addressed Objective of the Statement of Architecture Work Summary views necessary for the Request for Architecture Work and the Version 0.1 Business, Application, Data, and Technology Architectures; typically including: Value Chain diagram Solution Concept diagram Mapped requirements Reference to Draft Architecture Definition Document 130 /

131 Statement of Architecture Work The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. Content: Architecture project request and background Architecture project description and scope Overview of Architecture Vision Specific change of scope procedures Roles, responsibilities, and deliverables Acceptance criteria and procedures Architecture project plan and schedule Approvals 131 /

132 Architecture Principles Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. Content: Name Statement Rationale Implications Architecture Domains: Business Principles Data Principles Application Principles Technology Principles 132 /

133 B: Business Architecture Phase B describes the product and/or service strategy, and the organizational, functional, process and information the business environment. 133 /

134 Objectives Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures 134 /

135 Approach Business Architecture is a representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders. General Developing the Baseline Description Applying Business Capabilities Applying Value Streams Applying the Organization Map Applying Modeling Techniques Using the Architecture Repository

136 General General A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain The scope of work in Phase B is primarily determined by the Architecture Vision as set out in Phase A. Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort.

137 Developing Baseline Description Existing Architecture Descriptions should be used as the basis for the Baseline Description The reasons to update these materials include having a missing business capability, a new value stream, or changed organizational unit that has not previously been assessed within the scope of the Enterprise Architecture project If no Architecture Descriptions exist, information should be gathered and Business Architecture models developed.

138 Applying Business Capabilities Identifies, categorizes, and decomposes the business capabilities required for the business to have the ability to deliver value to one or more stakeholders Business Capability Map from Phase A is a self-contained view of the business that is independent of the current Organisational structure Business processes Information Systems Applications Product or Service Portfolio Business Capabilities must be mapped to Strategic plans Organisational units Value streams Information systems Techniques include a Business Capability Heat Map

139 Applying Value Streams The breakdown of activities that an organisation performs to create the value being exchanged with stakeholders Value Streams provide contect for the need for business capabilities Start with initial set of value streams documented in the Architecture Vision Analyze a value stream using Heat Mapping Developing use cases Highest benefit arises from Mapping Relationships between stages to business capabilities Perform gap analysis for capabilities

140 Applying the Organization Map The organisation map shows key Organisational units Partners Stakeholder groups Working relationships between entitities The organisation maps identify business units that Possess or use business capabilities Participate in value streams The organisation map provides Understanding of which business untis to involce in architecture Who and when to talk about a requirement How to measure the impact of decisions

141 Applying Modelling Techniques Examples of other Modelling techniques Activity Models Use-Case Models Class Models

142 Using the Architectury Repository As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository

143 Baseline - Target Architecture 143 /

144 Gap Analysis Verify the architecture models for internal consistency and accuracy Identify gaps between the baseline and target Perform trade-off analysis to resolve conflicts (if any) among the different views Validate that the models support the principles, objectives, and constraints Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document Test architecture models for completeness against requirements People gaps (e.g., cross-training requirements) Process gaps (e.g., process inefficiencies) Tools gaps (e.g., duplicate or missing tool functionality) Information gaps Measurement gaps Financial gaps Facilities gaps (buildings, office space, etc.) 144 /

145 Gaps between Baseline and Target 145 /

146 Architecture Requirements Spec. The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition. Content: Success measures Architecture requirements Business service contracts Application service contracts Implementation guidelines Implementation specifications Implementation standards Interoperability requirements IT Service Management requirements Constraints Assumptions 146 /

147 Architecture Definition Document The Architecture Definition Document is the deliverable container for the core architectural artifact. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). Content: Scope Goals, objectives, and constraints Architecture principles Baseline Architecture Architecture models Rationale and justification for architectural approach Mapping to Architecture Repository Gap analysis Impact assessment Transition Architecture 147 /

148 Phase C: Information Systems Architectures - Data Architecture A structured and comprehensive approach to data management enables the effective use of data to capitalize on its competitive advantages. 148 /

149 Objectives Develop the Target Information Systems Architectures, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures 149 /

150 Approach Key considerations for the Data Architecture Using the Architecture Repository

151 Reasons to split Architecture phase Data Architecture Data driven approach Service Oriented Architectures (SOA) Master Data Management Application Architecture Complex systems, like: Enterprise Resource Planning (ERP) Customer Relationship Management (CRM), etc. When a combination of technology infrastructure and business application logic is necessary. 151 /

152 Example: Data Patterns Data Integration/SOA ETL MFT ESB Data Architecture Transaction Data Stores (TDS/OLTP) Master Data Store Business Intelligence Transactional Reporting Analytical Reporting Operational Reporting Data Modeling Dimensional Data Modeling E-R Data Modeling Operational Data Store Data Mart Data Warehouse Master Data Management Master Data Hub 152 /

153 Telecommunications industry The TeleManagement Forum (TMF) Example: Architecture Models / Patterns Healthcare, Transportation, Finance The Object Management Group (OMG) Enterprise Integration Patterns 65 integration patterns Integration Strategies Batch Data Exchange Shared Database Raw Data Exchange Remote Procedure Calls Messaging 153 /

154 Example: Enterprise Integration Patterns describes 65 integration patterns Technology-independent design guidance helps developers and architects describe and develop robust integration solutions. Useful for: IBM WebSphere MQ TIBCO, BizTalk Sonic ServiceMix Mule ESB, ActiveMQ JMS-based messaging systems, MSM Windows Communication Foundation (WCF), 154 /

155 Architecture Requirements Spec. The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition. Content: Success measures Architecture requirements Business service contracts Application service contracts Implementation guidelines Implementation specifications Implementation standards Interoperability requirements IT Service Management requirements Constraints Assumptions 155 /

156 Architecture Definition Document The Architecture Definition Document is the deliverable container for the core architectural artifact. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). Content: Scope Goals, objectives, and constraints Architecture principles Baseline Architecture Architecture models Rationale and justification for architectural approach Mapping to Architecture Repository Gap analysis Impact assessment Transition Architecture 156 /

157 D: Technology Architecture The architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Repository 157 /

158 Objectives Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures 158 /

159 Architecture Requirements Spec. The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition. Content: Success measures Architecture requirements Business service contracts Application service contracts Implementation guidelines Implementation specifications Implementation standards Interoperability requirements IT Service Management requirements Constraints Assumptions 159 /

160 Architecture Definition Document The Architecture Definition Document is the deliverable container for the core architectural artifact. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). Content: Scope Goals, objectives, and constraints Architecture principles Baseline Architecture Architecture models Rationale and justification for architectural approach Mapping to Architecture Repository Gap analysis Impact assessment Transition Architecture 160 /

161 Approach Emerging technologies a driver for change Using the Architecture Repository

162 E: Opportunities & Solutions Phase E concentrates on how to deliver the architecture. 162 /

163 Objectives Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value Define the overall solution building blocks to finalize the Target Architecture based on the Architecture Building Blocks (ABBs) 163 /

164 Approach Phase E identifies the parameters of change, the major phases along the way, and the toplevel projects to be undertaken in moving from the current environment to the target Phase E is the first phase which is directly concerned with implementation. The task is to identify the major work packages or projects to be undertaken. The most successful strategy for Phase E is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects Work package identifies a logical group of changes. Architecture Roadmap lists individual work packages in a timeline. Transition Architectures provide interim Target Architectures. Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.

165 Architecture Roadmap The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. Content: Work package portfolio Implementation Factor Assessment and Deduction matrix Consolidated Gaps, Solutions, and Dependencies matrix Any Transition Architectures Implementation recommendations 165 /

166 F: Migration Planning The focus of Phase F is the creation of an Implementation and Migration Plan in cooperation with the portfolio and project managers. 166 /

167 Objectives Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders 167 /

168 Approach The focus of Phase F is the creation of an Implementation and Migration Plan in cooperation with the portfolio and project managers. Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Request for Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are integrated with the enterprise's other change activity. Activities include assessing the dependencies, costs, and benefits of the various migration projects within the context of the enterprise's other activity. The Architecture Roadmap, Version 0.1 and Implementation and Migration Plan, Version 0.1 from Phase E will form the basis of the final Implementation and Migration Plan that will include portfolio and project-level detail. The architecture development cycle should then be completed and lessons learned documented to enable continuous process improvement

169 Confirm Management Framework Interactions Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes. Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain. Portfolio/Project Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes. Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes. 169 /

170 Architecture Building Blocks Architecture documentation and models from the enterprise's Architecture Repository Content: Fundamental functionality and attributes: Semantic Unambiguous including security capability and manageability Interfaces: chosen set, supplied Interoperability and relationship with other building blocks Dependent building blocks with required functionality and named user interfaces Map to business/organizational entities and policies 170 /

171 Implementation and Migration Plan The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. The Implementation and Migration Strategy identifying the approach to change is a key element of the Implementation and Migration Plan. Content: Implementation and Migration Strategy: Strategic implementation direction Implementation sequencing approach Project and portfolio breakdown of implementation: Allocation of work packages to project and portfolio Capabilities delivered by projects Milestones and timing Work breakdown structure May include impact on existing portfolio, program, and projects 171 /

172 Implementation Governance Model Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis. Content: Governance processes Governance organization structure Governance roles and responsibilities Governance checkpoints and success/failure criteria 172 /

173 G: Implementation Governance It is here that all the information for successful management of the various implementation projects is brought together. 173 /

174 Objectives Ensure conformance with the Target Architecture by implementation projects Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests 174 /

175 Approach Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap Follow the organization's standard for corporate, IT, and architecture governance Use the organization's established portfolio/program management approach, where this exists Define an operations framework to ensure the effective long life of the deployed solution

176 Compliance Assessment Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Content: Overview of project progress and status Overview of project architecture/design Completed architecture checklists: Hardware and operating system checklist Software services and middleware checklist Applications checklists Information management checklists Security checklists System management checklists System engineering checklists Methods and tools checklists 176 /

177 Solution Building Blocks Implementation-specific building blocks from the enterprise's Architecture Repository Content: Specific functionality and attributes Interfaces; the implemented set Required SBBs used with required functionality and names of the interfaces used Mapping from the SBBs to the IT topology and operational policies Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability Performance, configurability Design drivers and constraints, including the physical architecture Relationships between SBBs and ABBss 177 /

178 Architecture Contract Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture Content: Introduction and background The nature of the agreement Scope of the architecture Architecture and strategic principles and requirements Conformance requirements Architecture development and management process and roles Target Architecture measures Defined phases of deliverables Prioritized joint workplan Time window(s) Architecture delivery and business metrics 178 /

179 Change Request During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions Content: Description of the proposed change Rationale for the proposed change Impact assessment of the proposed change, including: Reference to specific requirements Stakeholder priority of the requirements to date Phases to be revisited Phase to lead on requirements prioritization Results of phase investigations and revised priorities Recommendations on management of requirements Repository reference number 179 /

180 H: Architecture Change Management The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. 180 /

181 Objectives Ensure that the architecture lifecycle is maintained Ensure that the Architecture Governance Framework is executed Ensure that the enterprise Architecture Capability meets current requirements 181 /

182 Approach Drivers for change Enterprise architecture management process Guidelines for maintenance versus architecture redesign

183 Strategic: Business-as-usual developments Business exceptions Business innovations Business technology innovations Strategic change Drivers for a Change Experience: Lessons Learned Problem Management Infrastructure: New technology reports Asset management cost reductions Technology withdrawal Standards initiatives 183 /

184 Enterprise Architecture Change Management Process Classifying architectural change Simplification change: A simplification change can normally be handled via change management techniques. Incremental change: An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change. Re-architecting change: A re-architecting change requires putting the whole architecture through the architecture development cycle again. To determine whether a change is simplification, incremental, or rearchitecting, following activities are undertaken: Registration of all events that may impact the architecture Resource allocation and management for architecture tasks The process or role responsible for architecture resources has to make assessment of what should be done Evaluation of impacts 184 /

185 ADM Architecture Requirements Management As indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process. 185 /

186 Requirements Management Objectives: Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases Manage architecture requirements identified during any execution of the ADM cycle or a phase Ensure that relevant architecture requirements are available for use by each phase as the phase is executed 186 /