TOGAF Standard Techniques PDF

Seite 1 TOGAF standard Techniques Techniques used in Phases  Seite 2 TOGAF standard components Architecture Content Framework  Seite 3 Reference Models Enterprise Continuum ...

Seite 1 TOGAF standard Techniques Techniques used in Phases  Seite 2 TOGAF standard components Architecture Content Framework  Seite 3 Reference Models Enterprise Continuum  Seite 4 Architecture Capability Purposes of Enterprise Architecture EA Capability is the ability to develop, use and sustain the architecture of a particular enterprise, and use the architecture to govern change. TOGAF distinguishes between four EA purpose capabilities that typically frame the planning horizon, depth and breadth of an Architecture Project, and the contents of the EA Repository: - EA to support Strategy: Deliver ES to provide an end-to- end Target Architecture, and develop roadmaps of change over a 3 to 10 year period - EA to Support Portfolio: Deliver EA to support cross-functional, multi-phase, and multi-project change initiatives - EA to Support Project: Deliver EA to support the Enterprise’s project delivery method - EA to Support Solution Delivery: Deliver EA that is used to support the solution deployment  Seite 5 Archticetural Artifacts  Seite 6 ADM Cycle Stakeholders are KING --> Architects are rather giving option where stakeholders decide than deciding on themselves ADM Cycle – Phases Architecture Board is responsible for a good architecture process Preliminary Phase Stakeholder are the authority to take decisions Objectives: One time thing, after that doing cycles - Determine the Architecture Capability desired by the Organization: o Review the organizational context for conducting enterprise architecture o Identify the established frameworks, methods, and processes that intersect with the architecture Capability o Establish Capability Maturity target - Establish the Architecture Capability: o Define and establish the organizational model for Enterprise Architecture o Define and establish the detailed process and resource for architecture governance o Select and implement tools that support the architecture Capability o Define the Architecture principles In exam no stakeholders in Preliminary phase Main Goals: Defining the enterprise Architecture Governance ADM and other frameworks Architecture Team and organization Architecture Maturity Architecture principles Request of Architecture Work (optional) Approach: 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 Steps - Preliminary Phase: Anhand der Steps erkennen können, welche Phase es ist Preliminary Phase is about defining “Where, what, why, who and how we do architecture in the enterprise concerned 1. Scope the enterprise / Organizations impacted 2. Confirm governance and support frameworks 3. Defined and establish enterprise architecture team and organization  Seite 7 4. Identify and establish architecture principles 5. Tailor TOGAF framework and any other selected architecture framework 6. Develop strategy and implementation plan for architecture tools Request for Architecture Work This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Request of Architecture Work can be created as an outpout of the Preliminary Phase, a result of approved architecture Change Request, or terms of reference for architecture work originating from migration planning. Federated Architecture: In Federated Architecture each BU has its own Enterprise Architecture, fitting into an overall corporate Enterprise Architecture Business Units may decide to have shared capabilities where it adds value for them. The Corporate Enterprise Architecture is the combination of its own Enterprise Architecture and the Enterprise Architectures of the Business Units. The mandatory shared Capabilities are often based on Regulations. Architecture Governance Framework: Architecture Governance: The organizational competence for continuously exercising guiding authority over enterprise architecture strategy, architecture development including design, implementation and operation of the enterprise. Architecture Governance is the practice and orientation by which enterprise architecture and other architectures are managed and controlled at an enterprise-wide level. It includes - A system of controls over the creation and monitoring of all architectural components and activities - A system to ensure compliance with internal and external standards and regulatory obligations - Processes that support effective management of the above processes within agreed parameters - Practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization Seite 8  Seite 9 Architecture Board: Role: A key element in a successful Architecture Governance strategy is a cross-organization Architecture Board to oversee the implementation of the strategy. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture. Responsibilities: Architecture Board is typically made responsible, & accountable, for achieving e.g. - Consistency between sub-architectures - Establishing targets for re-use of components - Enforcement of Architecture Compliance - Improving the maturity level of architecture discipline within the organization Further responsibilities from an operational perspective should include e.g. - All aspects of monitoring and control of the Architecture Contract - Providing advice, guidance, and information From a governance perspective, the Architecture Board is also responsible for: - The production of usable governance material and activities - Providing a fundamental control of the architecture Essential Governance: The Architecture Board owns the process and a recommendation regarding completeness and confidence in the work that led to the target architecture. Decision rights about the target architecture, relief, and enforcement are always vested in the architectures stakeholders, independent of the architecture tier. TOGAF provides decision-tree checklists for an EA board to require an architect to answer when assessing a target architecture. These Check Lists provide a flow of questions in form of a decision tree which have to be answered by the architecture team. A negative response to a question may force the team to reenter the tree at a higher level. Two Checklists are given for - Stakeholder identification and analysis - Non-compliance reports Techniques used in Preliminary Phase Architecture Principles: Principles are general rules and guidelines - They are designed to be permanent and are rarely changed - Inform and support the way in which the organization goes about fulfilling its mission A hierarchy of principles can include - Enterprise principles, providing a basis for decision making throughout the enterprise - Architecture principles, are set of principles that relate to the architecture work EA principles should address the following purposes: - Enable decision-making - Align the enterprise to the enterprise values - Governance of architecture process and content - Values and culture – embody the spirit and thinking of existing enterprise principles  Seite 10 TOGAF standard distinguishes 4 principle Categories - Business - Data - Application - Technology Structure of Architecture Principles ----------> Wörter Kennen  Seite 11 - First Phase in the ADM circle - Includes a first-cut, high-level description of the baseline & target environments, from both a business and a technical perspective. - Baseline for the work in the subsequent phases A. Architecture Vision - Important to get consensus and support for the vision Request for Architecture Work triggers to start Phase A: This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle Objectives: - Develop a high-level aspirational vision of the business value and capabilities 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 Main Goals: The set-up essentials of Phase A are: - Define the scope of the Architecture Project What is the task at hand? Is there a clear statement regarding the business cycle where the new architecture should be used? - Identify stakeholders, concerns, and associated requirements A stakeholder Map is a mandatory tool together with knowledge of architecture constrains from the repository - Assess the capability of the EA team Analysis of the architecture capability to fill gaps The completion essentials of Phase A: - Key stakeholder agreement to the architecture vision Approach: - Defines the scope of the architecture effort, and the constraints - Creates the Architecture Vision document - Focus is on developing Business Capabilities, Courses of Action and Value Streams - Produces a first-cut High-level description of the Baseline and Target architectures Steps – Architecture Vision 1. Establish the project o To secure recognition and resources for the project o Use existing project mgmt. procedures and resource if available 2. Identify stakeholders, concerns and business requirements 3. Confirm and elaborate business goals, drivers and constraints o As relevant to this project o Re-use if possible o Validate with the sponsors (originators of the Request for Architecture Work ) 4. Evaluate business capabilities o Capabilities an organization will need to develop an Enterprise Architecture and required Business Capabilities to fulfil its business goals 5. Assess readiness for transformation 6. Define the scope of the architecture effort (this architecture project) o Organization units to be included o Level of detail do be defined o Architecture domains to be covered  Seite 12 o Time horizon to be considered o Which architecture assets are to be leveraged 7. Confirm and elaborate architecture principles 8. Develop the Architecture Vision for the project o Develop the architecture Vision – “elevator pitch”, both business and technical o What do we have? o What is not good about it? o What could the future look like? 9. Define the Target Architecture value propositions and KPIs o Develop the business case o Produce the value proposition for eacht of the stakeholder groupings o Review and agree the value propositions with the sponsors and stakeholders concerned o Define the performance metrics and measures o Assess the business risk 10. Identify business transformation risks and mitigation activities 11. Develop the statement of Architecture Work; secure approval o Determine domains to be covered o Estimate time and resources required (including funding) o Develop work plan and schedule o Compile the Statement of Architecture Work o Obtain approval for the Statement of Architecture Work Vision Phase Approach -Initiated by Request of Architecture Work from the sponsoring organization -Establish Architecture Project utilizing appropriate Project mgmt. disciplines -Discover dan document business requirements, and articulate an architectural vision responding to these with Business Scenarios -Document Vision in the Statement of Architecture Work and build consensus -The consensus is represented by the sponsoring organization signing the Statement of Architecture Work Essential Outputs of Phase A at the end of the Phase  Seite 13 Business Scenarios (sehr wichtig für Exam!) Business Scenarios is a technique to develop Architecture Vision in Phase A: Important method to derive business and technical requirements the architecture development project (this cycle of the ADM) has to address. 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 A business scenario is a uniform description of: - Real business problems - The business and technology environment in which those problems occur - Value streams enabled by capabilities - The desired outcome(s) of proper execution - The human and computing component who provide capabilities Business Scenario Development Content Framework  Seite 14 Techniques used in Vision Phase Stakeholder Mgmt. Identify Stakeholders --> classify stakeholders position --> determine stakeholder management approach --> tailer engagement deliverables Interoperability Requirements A definition of interoperability is “the ability to share information and services” Operating model describes which type of interoperability will be appropriate. Interdisciplinary facilitated workshops are a good way to defined interoperability. To be determined throughout the entire ADM (Phases A --> E): - Phase A: Architecture Vision: the nature and security considerations of the information and service exchanges are first revealed within the business scenarios - Phase B: Business Architecture: the information and service exchanges are further defined in business terms - Phase C: Data Architecture: the content of the information exchanges is detailed using the corporate data and/or information exchange model - Phase C: Application Architecture: the way that the various applications are to share the information and services is specified - Phase D: Technology Architecture: the appropriate technical mechanisms to permit the information and service exchanges are specified - Phase E: Opportunities & Solutions: the actual solutions are selected - Phase F: Migration Planning: the interoperability is logically implemented Business Transformation Readiness Assessment Business transformation readiness assessment is used to evaluate and quantify an enterprises readiness to undergo change. Most important dimension to change is the human factor. Best Architecture plans could lead to nowhere if there is a change averse culture and a narrowly skilled workforce Understanding readiness of the organization to accept change, identifying the issues in the vision phase A and then dealing with them in Phases E and F is key to successful architecture transformation  Seite 15 Risk management Process of risk management: - Risk identification - Risk classification - Initial risk assessment - Risk mitigation and residual risk assessment - Risk monitoring Two levels of risk to be considered: Initial risk: risk categorization prior to determining and implementing mitigation actions Residual risk: risk categorization after implementing mitigation actions (if any) Architecture Alternatives and Trade-Offs Single alternative does not exist that will meet all stakeholders concerns. Alternatives are defined per architectural domain. The alternatives per domain can be merged into one overall analysis of the alternatives for the whole architecture. Trade-Offs requires a compromise between one stakeholders preferences as well as between different stakeholders preferences. Practitioners need to facilitating trade-offs between stakeholders and across organizational boundaries. Context or objective of the enterprise have to be carefully analyzed by the practitioner in order to avoid misjudgments. Capability Dimensions The capability architecture describes the abilities that an enterprise possesses. A business capability defines the organisation´s capacity to successfully perform a unique business activity. Capabilities: - Are the building block of the business - Represent stable business functions - Are unique and independent from each other - Are abstracted from the organizational model - Capture the business interest  Seite 16 B. Business Architecture A Business Architecture is a representation of holistic, multi-dimensional business views of capabilities, end-to-end value delivery, information, and organizational structure; and their relationships. 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 Work and Stakeholder needs. - Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architecture Approach: - Developing the Baseline Description - Applying Business Capabilities - Applying Value Streams - Applying the Organization Map - Applying Modelling Techniques Steps – in Architecture Phase B – D Steps to develop architecture in Phases B, C and D are identical. The steps are identical because the approach to developing an architecture, confirming the work product developed fits, and confirming approval are identical. The steps are also mandatory. Steps can be skipped, but the final outcome could be at risk. What changes from purpose to purpose, domain to domain, project to project and EA team to EA team is the level of detail, precision and formality. 1. Select reference models, viewpoints & tools o Determine overall modeling process ▪ Structured analysis/functional decomposition ▪ Use-case Analysis ▪ Process Modeling o Identify required service granularity Level, Boundaries and Contracts ▪ Services have contracts, interfaces and wrap responsibilities and functionality o Identify (out of Architectural Artifacts) ▪ Required catalogs of Business Building Blocks ▪ Required matrices ▪ Required diagrams 2. Develop baseline architecture description o Utilize Architecture Repository to identify relevant building blocks 3. Develop target architecture description o Select Business Architecture Building Blocks for the future architecture 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across architecture landscape 7. Conduct formal stakeholder review 8. Finalize architecture o Select Standards for building blocks o Document building blocks o Cross check against business goals o Record requirements for traceability o Publish re-usable building blocks o Finalise work products 9. Create architecture definition document  Seite 17 Essential Outputs Phases B, C, D at the end of the Phase Business Architecture Phase Summary Architecture Definition Document The architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and contains all important related information. It spans all architecture domains (Business, data, application and technology) and all architecture states (Baseline, transition, target). The Architecture Definition Document is a companion to the requirement specification with a complementary objective: - It provides a qualitative view of the solution and aims to communicate the intent of the architects - The architecture requirements specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture  Seite 18 Techniques used in Business Architecture Phase Gap Analysis Gap Analysis does not only serve to evaluate the differences between baseline and target architecture. A main prupose is to identify stakeholders concerns that have not been addressed in prior architecture work. The technique of Gap analysis is used in the four architecture development phases.  Seite 19 C. Information Systems Architectures- Data Architecture Information Systems Architectures is split into one part Data Architecture and one part Application Architecture Objectives: Develop the Target Data Architecture that enables the Business Architecture and Architecture Vision, while addressing the Statement of Architecture Work and stakeholder concerns. Identify candidate architecture roadmap components based upon gaps between the Baseline and Target Architectures Data Architecture Phase Approach Content Framework  Seite 20 Steps – in Architecture Phase B – D Steps to develop architecture in Phases B, C and D are identical. The steps are identical because the approach to developing an architecture, confirming the work product developed fits, and confirming approval are identical. The steps are also mandatory. Steps can be skipped, but the final outcome could be at risk. What changes from purpose to purpose, domain to domain, project to project & EA team to team is the level of detail, precision & formality. 1. Select reference models, viewpoints & tools o Determine overall modeling process ▪ Collect data related models from Business Architecture ▪ Rationalize data requirements and align with data catalogues ▪ Update and develop matrices across the architecture o Identify required catalogs of Data Building Blocks o Identify required matrices o Identify required diagrams o Identify types of requirements to be collected ▪ Functional, non-functional, assumptions, constraints, domain- specific Data Architecture principles, Policies, Standards, Guidelines, Specifications 2. Develop baseline architecture description 3. Develop target architecture description o As for baseline data architecture description o Select Data Architecture Building Blocks ▪ Re-use from existing where possible ▪ Define new where necessary ▪ Base these on Industry Domain Models 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across architecture landscape 7. Conduct formal stakeholder review 8. Finalize architecture o Fully specify Building Blocks o Document requirements traceability report o Document mapping of Building Blocks to the Architecture Continuum 9. Create/Amend architecture definition document Essential Outputs Phases B, C, D at the end of the Phase  Seite 21 Data Architecture Phase Summary Architecture Definition Document (Data Architecture) Techniques used in Data Architecture Phase  Seite 22 C.Information Systems Architectures- Application Architecture A description of the structure and interaction of the applications that provide key business capabilities and manage the data assets. Objectives: Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Statement of Architecture Work and stakeholder concerns. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures. In this contexts applications are: - Logical groups of capabilities that manage the data object in the Data Architecture and support the business functions in the Business Architecture - Not described as computer systems - Defined without reference to particular technologies - Stable and relatively unchanging over time e.g. We will talk about the “Human Resources Management System” NOT about SAP HR or Peoplesoft Approach: Steps in Architecture Phase C – Application Architecture 1. Select reference models, viewpoints & tools o Determine overall modeling process ▪ Use industry models ▪ Prepare lists, abstract upwards, develop matrices to services, functions, processes o Identify required catalogs of Application Building Blocks o Identify required matrices o Identify required diagrams o Identify types of requirements to be collected ▪ Functional, non-functional, assumptions, constraints, domain- specific Data Architecture principles, Policies, Standards, Guidelines, Specifications 2. Develop baseline architecture description 3. Develop target architecture description o As for baseline application architecture description o Select Application Architecture Building Blocks ▪ Re-use from existing where possible ▪ Define new where necessary ▪ Base these on Industry Domain Models 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across architecture landscape 7. Conduct formal stakeholder review 8. Finalize architecture o Fully specify Building Blocks o Document requirements traceability report o Document mapping of Building Blocks to the Architecture Continuum 9. Create/Amend architecture definition document  Seite 23 Essential Outputs Phase C Application Architecture Phase Summary Architecture Definition Document (Application Architecture)  Seite 24 Techniques used in Application Architecture Phase Content Framework  Seite 25 D. Technology Architecture 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 components 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 Technology Architectures. Approach: Enterprises looking for new innovative ways of operating and improving their business need to follow new technology intentions. The adoption of new technology can offer transformation opportunities and could be drivers for change. The TOGAF ADM enables technology change to become a driver and strategic resource and stakeholders need to anticipate and be open to technology-driven change. Technology Architecture may drive business capabilities and respond to information system requirements at the same time. The Architecture team need to consider what relevant Technology resources are available in the repository. Steps Technology Architecture 1. Select reference models, viewpoints & tools o Determine overall modeling process ▪ Locations where technology is deployed ▪ Create physical inventory and abstract up ▪ Determine configuration of selected technology o Identify ▪ required catalogs of technology Building Blocks ▪ required matrices ▪ required Diagrams o Identify Types of Requirements to be collected o Select Services 2. Develop baseline architecture description 3. Develop target architecture description 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across architecture landscape 7. Conduct formal stakeholder review 8. Finalize technology architecture o Select standards per building block o Document building blocks o Document mapping of building blocks to requirements, identify potential reuse & publish via repository o Finalize all work products 9. Create/Amend architecture definition document o Functionality and attributes o Dependencies and interfaces o Interface definitions o Mapping to Business entities and policies  Seite 26 Essential Outputs Phase Technology Architecture Phase Summary Architecture Definition Document (Technology Architecture)  Seite 27 Techniques used in Architecture Phase Content Framework  Seite 28 E. Opportunities & Solutions 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 (SBB) to finalize the Target Architecture based on the Architecture Building Blocks (ABB) Approach: Thise phase is the first step to realize the future architecture defined in the architecture development phases B through D --> First phase which is directly concerned with the Target Architecture implementation. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages (work packages can be part of a project, a complete project, or a program) within the enterprise´s portfolios. It is the initial step in the creation of the implementation and Migration Plan which is completed in Phase F. The following four concepts are key to transitioning from developing to delivering a Target Architecture: - Architecture Roadmap - Work Packages - Transition Architectures - Implementation and Migration Plan The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. ➔ Collaborative effort with stakeholders from business and IT to identify and group the major work packages into projects to be undertaken: o Consolidate, integrate and analyse the information collected to determine the best way ahead o Closely assess inter-dependencies to derive the critical path o Analyse implementation risks and define mitigation strategies ➔ Consider the coexistence strategy for each new element, taking into account: o The need to integrate old and new user interfaces o The need to integrate, and possibly synchronize, old and new data o The need to maintain connectivity to the old elements and to keep their infrastructure running for the duration of the coexistence window Focus on projects that will deliver short-term payoffs in order to build an impetus for longer term projects.  Seite 29 Steps – Opportunities and Solution Phase 1. Determine/confirm key corporate change attributes o Determine how the Enterprise Architecture can be best implemented respecting the enterprise´s culture o Create: ▪ Implementation factor catalog ▪ Assess transition capabilities ▪ Document in implementation factor matrix 2. Determine business constraints for implementation 3. Review and consolidate gap analysis results Phases B to D 4. Review consolidated requirements across related business functions 5. Consolidate and reconcile interoperability requirements 6. Refine and validate dependencies 7. Confirm readiness and risk for business transformation 8. Formulate Implementation and Migration Strategy o Possible strategic approaches for implementation ▪ Greenfield completely new implementation ▪ Revolutionary, radical change (i.e., switch on, switch off) ▪ Evolutionary, strategy of convergence, such as parallel running or a phased approach to introduce new capabilities o Most common methodologies: ▪ Quick win ▪ Achievable targets ▪ Value chain method 9. Identify and group major work packages 10. Identify Transition Architectures o Transition Architectures must be based upon the preferred implementation approach, the consolidated gaps, solutions, and Dependencies Matrix, the listing of projects and portfolios, as well as the enterprise´s capacity for creating and absorbing change 11. Create the Architecture Roadmap & Implementation and Migration Plan Essential Outputs Phase E Evaluating costs is already included Opportunities and Solution Phase Summary  Seite 30 Techniques used in Opportunity and Solution Phase Content Framework Balance opportunity and Viability (Architecture to Support Portfolio) While in the previous phase all efforts were focused on the enterprise itself in Phase E the focus is directed to the outside. Specifications and requirements from the previous phases are used to scan the market for appropriate options. Motivations behind the required solution may help to find possibilities of reuse. To enable viability analysis and trade-offs with the stakeholders a matrix of options, risks and controls should be created. Under consideration of dependencies between different work packages resource estimates have to be compiled for each work package. Partial Capability Level Phases B, C, and D. For each capability or project in the portfolio: - Elaborate specifications to estimate effort size - Identify reference architectures and market benchmarks - Identify candidate Architecture Building Blocks (ABB) - Identify Solution Building Blocks (SBB) (optional) Partial Capability Level Phase E. For each project in the portfolio: - Identify solution providers - Readiness assessment - Gather estimates - Assess viability and fitness of solution options Partial Capability Level Phase F. For each capability in the portfolio: - Initial/ draft Implementation and Migration Plan - Draft governance Plan Partial Project Level Phase A. For each project in the portfolio: - Candidate proof-of-concept work packages (as needed) - Draft success measures  Seite 31 Architecture Requirement Specification The Architecture Requirement Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. It is a major component of an architecture contract and it is a companion to the Architecture Definition document. - The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect. - The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that mus be met during the implementation of the architecture Typical content: - Success measures - Architecture requirements - Business services contracts - Application services contracts - Implementation guidelines - Implementation specifications - Implementation standards - Interoperability requirements - Constraints - Assumptions Solution Building Blocks Specification Architecture Roadmap Inte the Architecture Roadmap individual work packages are listed that will realize the architecture with a timeline showing the progression from Baseline to Target Architecture. The business value of each stage is highlighted in the Roadmap and Transition Architectures are shown as intermediate steps. The roadmap is developed throughout the Phases E and F and informed by readily identifiable roadmap components from Phases B,C, and D within the ADM.  Seite 32 F. Migration Planning 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 to managing and implementing change in the enterprise´s overall change portfolio. Ensure that the business value and cost of work packages and Transition Architecture is understood by key stakeholders. Approach: Assessment of migration projects in view of other activities of the organization: - Dependencies - Costs - Benefits Influenced by - Size and complexity of the organization - Architecture complexity / extent - Lifecycle stage and asset value of current systems - Risk levels and appetite Sequence often dictated by key business drivers - New services - Reduction of costs - Consolidation of services Final Migration plan should focus on - Addressing greatest risk with least possible expense - Planning for getting benefits as early as possible - Projects that deliver short term pay-offs Steps – Migration Plan 1. Confirm management framework interactions for Implementation and Migration Plan 2. Assign a business value to each project 3. Estimate resource requirements, project timings, and availability / delivery vehicle 4. Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation o Compare costs to net benefits o Verify that all risks have been mitigated and factored in o Revise risk assessments and ensure that there is full understanding of residual risks o Get stakeholder agreement 5. Confirm Architecture Roadmap and update Architecture Definition Document o Update architecture roadmap including transition architectures o Review the work to assess the time-spans between transition architectures – take BIZ value, capability and other factors in account o Consolidate the deliverables by project 6. Complete the Implementation Roadmap and Migration Plan 7. Establish the architecture evolution cycle and document lessons learned  Seite 33 Essential Outputs Phase F at the end of the Phase Migration Planning Phase summary Content Framework Techniques used in Migration Plan Phase  Seite 34 Implementation and Migration Plan  Seite 35 G. Implementation Governance 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. Approach: Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase and perform the required risk monitoring. 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. The pase establishes the connection between architecture and implementation organization, through the Architecture Contract. Project details are developd, including: - Name, description and objectives - Scope, deliverables, and constraints - Measures of effectiveness - Acceptance criteria - Risks and issues Steps – Implementation Governance Phase 1. Confirm scope and priorities for deployment with development management 2. Identify deployment resources and skills 3. Guide development of solutions deployment 4. Perform enterprise architecture compliance reviews 5. Implement business and IT operations 6. Perform post-implementation review and close the implementation Essential Outputs Phase G  Seite 36 Implementation Governance Phase – Summary Architecture Compliance An essential aspect of Architecture Governance is to ensure the compliance of individual projects with the Enterprise Architecture. The IT Governance function will normally define two complementary processes: - The Architecture function will be required to prepare a series of Project Architectures: I.E., project-specific vies of the Enterprise Architecture that illustrate hoe the Enterprise Architecture impacts on the major projects within the the organization (see ADM Phases A-F) - The Enterprise and IT Governance functions will define a formal Architecture Compliance review process for reviewing the compliance of all projects to the Enterprise Architecture ➔ Architecture Compliance Review (either periodic or in case of issues) The Purpose of the Architecture Compliance Review is to evaluate the compliance of a specific project against established architectural criteria, spirit, and business objectives and includes several checkpoints To guarantee compliance the Architecture team should participate in the technology selection process, in the commercial relationships involved in external service provision and product purchases. To ensure that the original Architecture Vision is appropriately realized periodic compliance reviews are necessary to analyze project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives. Typical contents of a Compliance Assessment are: - Overview of project progress and status - Overview of project architecture/design - Completed architecture checklists Two checklists are given for the practitioner to execute architecture governance: - Target checklist - Implementation and other change checklist  Seite 37 nicht im detail kennen Levels of Architecture Conformance Architecture Governance Organisation  Seite 38 Techniques used in Implementation Governance Phase Agile Implementation Content Framework  Seite 39 H. Architecture Change Management 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 Approach: The change management process once established will determine: - The circumstances under which the enterprise architecture, or parts of it, will be permitted to change after implementation, and the process by which that will happen - The circumstances under which the enterprise architecture development cycle will be initiated again to develop a new architecture. The architecture change management process is very closely related to - The architecture governance processes of the enterprise, and - The management of the Architecture Contract between the architecture function and the business users of the enterprise The governance body should establish criteria to judge whether a change request warrants just an architecture update or whether it warrants starting a new cycle of the ADM. Important to judge changes on their business value General guidelines for establishing these criteria are difficult to prescribe, as many companies accept risk differently. Typical contents of a Change Request are: - Description of the proposed change - rationale for the proposed change - impact assessment of the proposed change Steps – Change Management Phase 1. Establish value realization process 2. Deploy monitoring tools 3. Manage risk 4. Provide analysis for architecture change management 5. Develop change requirements to meet performance targets 6. Manage governance process 7. Activate the process to implement change Change Request Typical contents of a Change Request are: - Description of proposed change - rationale for the proposed change - repository reference number - impact assessment of the proposed change, including: o reference to specific requirements o stakeholder priority of the requirements to date o phases to be revisited o Phase to lead on requirements prioritization o Results of phase investigations and revised priorities o Recommendations on management of requirements  Seite 40 Change Management Process For each Change request the Architecture Board: - Has to classify the change request Evaluating the change --> defining which of these o Simplification categories it is o Incremental o Re-Architecting - And has to assess and approve the Request for Change which is often in response to known problems but can also include improvements Change Requests based on technology drivers are usually manageable through change management processes for architecture Change Requests. E.g. new technology reports, asset management cost reductions, technology withdrawal, standards initiatives Business drivers for architecture change often result in a complete re-development of the architecture or at least in an iteration of part of the architecture development cycle. E.g. Business exceptions, business innovations, business technology innovations, strategic change ➔ Change Classification A good rule-of-thumb is: - If the change impacts two stakeholders or more --> architecture re-design and re-entry to the ADM - If the change impacts only one stakeholder --> candidate for change management - If the change can be allowed under a dispensation --> candidate for change management If there is a need for a refreshment cycle, then a new Request for Architecture Work must be issued (to move to another cycle) Essential Outputs Phase H  Seite 41 Change Management Phase Summary Coordination and Business Cycle Most architecture work after installation of an EA capability is initiated from Phase H. The development of the enterprise is depending on the budgeting cycle, normally the fiscal year The architect should therefore try to meet his cycle in order to deliver practical input for the decision an organization needs to make otherwise it will be a less informed choice. The EA team needs to be aligned with the organization’s planning, budgeting, operational and change processes. Although Support Portfolio and Project are constrained by the architecture to support Strategy, nothing is committed until resources (budget) are allocated. Techniques used in Change Management Phase  Seite 42 Requirements Management Phase 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. Approach The ADM is continuously driven by the requirements management process. Requirements are dynamically changing, they and their changes are identified, stored and fed into the phases or received from the phases. TOGAF standard does not mandate any specific process or tool for the management Requirements management is critical to architecture because: - Architecture is an activity that deals with uncertainty and change – the “grey area” between what stakeholders aspire to and what can be specified and engineered as a solution - Architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc. ) and which can produce changes in requirements in an unforeseen manner Steps – Requirements Management Phase Essential Output Requirements Management Typical contents of Requirements Impact Assessment are: - 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  Seite 43 Requirements Management Summary Purpose of Requirements Management Requirements management and stakeholder engagement are at the center of architecture development. EA is developed in accordance with the preferences and priorities of the organization’s stakeholders. Architecture is never sold to a stakeholder. Stakeholder preferences are never manipulated. Architects must completely submerge their own preferences, biases, and priorities of their stakeholders, they have to act for them. Effective requirements management is dependent upon clear traceablity from the organization’s vision, mission, business model, and strategies through the most detailed statement of requirement. In order to perform this, the Architect must carefully distinguish between direct effective support and loose association. Things that do not best enable the complete set of stakeholder preferences are distractions from the main chance. Volere Template  Seite 44 Techniques used in Requirements Management Content Framework  Seite 45 Reading Material ADM Phases in parallel --> Phase A always the starting one Digital Practitioner Body of Knowledge Standard (DPBoK) Business Architecture Approach Business Architecture is a holistic view of capabilities, end-to-end value delivery, information and organizational structure and the relationship between these Business Architecture is prerequisite for other domains: - May have been done by other processes, e.g. strategic business planning, business process re-engineering etc. Baseline architecture is usually built bottom-up, based on existing artefacts Target architecture is usually built top down - Business scenarios or other requirement gathering techniques Business Modelling - Should be a logical extension of the business scenarios - Use high level techniques to quickly understand and evaluate alternatives Leverage assests in the Enterprise Continuum - Existing assets - Generic industry sector models - Relevant standards  Seite 46 Technology Architecture Enterprises looking for new innovative ways of operating and improving their business need to follow new technology inventions. The adoption of new technology can offer transformation opportunities and could be driver for change. The TOGAF ADM enables technology change to become a driver and strategic resource and stakeholders need to anticipate and be open to technology-driven change. Technology Architecture may drive business capabilities and respond to information system requirements at the same time. The architecture team need to consider what relevant Technology resources are available in the repository.