TOGAF Certification Series 7: TOGAF® 9 Certified ADM Phases E,F,G,H And Requirements Management

Chapter 9 Phase E: Opportunities & Solutions

  • The objectives of Phase E: Opportunities and Solutions are to:
    • 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
  • Phase E is a collaborative effort with stakeholders required from both the business and IT sides. It should include both those that implement and those that operate the infrastructure. It should also include those responsible for strategic planning, especially for creating the Transition Architectures, if required.
  • Phase E consists of the following steps:
    • 1. Determine/confirm key corporate change attributes
    • 2. Determine business constraints for implementation
    • 3. Review and consolidate Gap Analysis results from 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
    • 9. Identify and group major work packages
    • 10. Identify Transition Architectures
    • 11. Create the Architecture Roadmap & Implementation and Migration Plan
  • The most significant issue to be addressed is business interoperability. Most SBBs or COTS will have their own embedded business processes. Changing the embedded business processes will often require so much work, that the advantages of re-using solutions will be lost with updates being costly and possibly requiring a complete rework. Furthermore, there may be a workflow aspect between multiple systems that has to be taken into account. The acquisition of COTS software has to be seen as a business decision that may require rework of the domain architectures. The enterprise architect will have to ensure that any change to the business interoperability requirements is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work.

Chapter 10 Phase F: Migration Planning

  • The objectives of Phase F: Migration Planning are to:
    • 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 Architectures is understood by key stakeholders
  • Phase F consists of the following steps:
    • 1. Confirm management framework interactions for the Implementation and Migration Plan
    • 2. Assign a business value to each work package
    • 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
    • 5. Confirm Architecture Roadmap and update Architecture Definition Document
    • 6. Complete the Implementation and Migration Plan
    • 7. Complete the architecture development cycle and document lessons learned
  • A technique to assess business value is to draw up a matrix based on a value index dimension and a risk index dimension. An example is shown in Figure 12. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure. Each criterion should be assigned an individual weight. The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.

Chapter 11 Phase G: Implementation Governance

  • The objectives of Phase G: Implementation Governance are to:
    • Ensure conformance with the Target Architecture by implementation projects
    • Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
  • The Architecture Contract produced in this phase features prominently in the area of Architecture Governance (see Chapter 22). It is often used as the means to driving change. In order to ensure that the Architecture Contract is effective and efficient, the following aspects of the governance framework should be introduced in this phase:
    • Simple process
    • People-centered authority
    • Strong communication
    • Timely responses and effective escalation process
    • Supporting organization structures
  • Phase G consists of the following steps:
    • Confirm scope and priorities for deployment with development management
    • Identify deployment resources and skills
    • Guide development of solutions deployment
    • Perform enterprise Architecture Compliance Reviews
    • Implement business and IT operations
    • Perform post-implementation review and close the implementation

Chapter 12 Phase H: Architecture Change Management

  • The objectives of Phase H: Architecture Change Management are to:
    • Ensure that the architecture lifecycle is maintained
    • Ensure that the Architecture Governance Framework is executed
    • Ensure that the enterprise Architecture Capability meets current requirements
  • Phase H consists of the following steps:
    • 1. Establish value realization process
    • 2. Deploy monitoring tools
    • Manage risks
    • 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

Chapter 13 ADM Architecture Requirements Management

  • The objectives of the Requirements Management phase are to:
    • 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

Advertisements

TOGAF Certification Series 5: Building Blocks

Chapter 11 Building Blocks

  • A building block is a package of functionality defined to meet business needs across an organization. A building block has published interfaces to access functionality. A building block may interoperate with other, possibly inter-dependent building blocks.
  • An architecture is a composition of:
    • A set of building blocks depicted in an architectural model
    • A specification of how those building blocks are connected to meet the overall requirements of an information system
  • Architecture Building Blocks (ABBs) are architecture documentation and models from the enterprise’s Architecture Repository classified according to the Architecture Continuum.
  • The characteristics of ABBs are as follows:
    • They define what functionality will be implemented.
    • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
    • They direct and guide the development of Solution Building Blocks
  • The characteristics of ABBs are as follows:
    • They define what functionality will be implemented.
    • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
    • They direct and guide the development of Solution Building Blocks

  • 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 that. Patterns offer the promise of helping the architect to 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.

Chapter 12 ADM Deliverables

  • Architecture Building Blocks (ABBs): ABBs are architecture documentation and models from the enterprise’s Architecture Repository.
  • Architecture Contract: Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are produced in Phase G: Architecture Governance. Successful implementation of these agreements will be delivered through effective Architecture Governance.
  • Architecture Definition Document: The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. 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).
  • Architecture Definition Document versus Architecture Requirements Specification The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective: The Architecture Definition Document 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.
  • Architecture Requirements Specification: 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 a contract for more detailed Architecture Definition.
  • 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. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by the roadmap components developed in Phases B, C, and D.
  • The Architecture Vision is created in Phase A and provides a high-level summary of the changes to the enterprise that will follow from successful deployment of the Target Architecture.
  • Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. These will have usually been defined elsewhere in the enterprise prior to the architecture activity. Many factors that lie outside the consideration of architecture discipline may have significant implications for the way that architecture is developed.

Chapter 13 TOGAF Reference Models

  • Major characteristics of a Foundation Architecture include the following:
    • It reflects general computing requirements.
    • It reflects general building blocks.
    • It defines technology standards for implementing these building blocks. It provides direction for products and services.
    • It reflects the function of a complete, robust computing environment that can be used as a foundation.
    • It provides open system standards, directions, and recommendations.
    • It reflects directions and strategies.
  • The TRM has two main components:
    • 1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system
    • 2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding

  • The Integrated Information Infrastructure Reference Model: The III-RM is a reference model that focuses on the Application Software space, and is a “Common Systems Architecture” in Enterprise Continuum terms. The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM – in particular, the business applications and infrastructure applications parts – in order to provide help in addressing one of the key challenges facing the enterprise architect today: the need to design an integrated information infrastructure to enable Boundaryless Information Flow.

  • Boundaryless Information Flow 1. A trademark of The Open Group. 2. A shorthand representation of “access to integrated information to support business process improvements” representing a desired state of an enterprise’s infrastructure specific to the business needs of the organization. An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer’s extended enterprise that:  Combine multiple sources of information  Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information

Microservices, TOGAF, Solution Blueprint and API Design


While providing microservices architecture consulting services, I found it necessary to extract the Interface Design from the Application Architecture. The Interface Design is usually part of the application architecture. However, the Interface design both UI and API are of extreme importance and value to the solution and to the organization offerings, it requires having a sperate section of its own. With the emergence of Microservices and many companies offering their services through APIs to allow clients to hock in and utilize their services. Or as business/marketing people refer to “Monetizing the API”. I think it is paramount to get the interface design more attention and specifically the API design. That is why I defined this new Interface Architecture phase in my customized TOGAF offering to the organization.

Architecture Type

Description

Business Architecture

The business strategy, governance, organization, and key business processes.

Interface Architecture

A blueprint for the individual application interfaces both User Interface and Application Programming Interface and their relationships to the core business processes of the organization.

Application Architecture

A blueprint for the individual application components to be deployed, their interactions, and their relationships to the core business processes of the organization.

Data Architecture

The structure of the application logical and physical data assets and data management resources.

Technology Architecture

The logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.

 

I would like to know your thoughts on this, and how did you handle the API design in the Solution Architecture Blueprint.