TOGAF - Solution Architect

Lesson Plan

Creating a lesson plan for training Solution Architects using TOGAF (The Open Group Architecture Framework) standards involves introducing learners to the essential principles, methods, and deliverables within the framework. Here’s a comprehensive lesson plan designed to cover the core concepts and skills a Solution Architect needs, structured around TOGAF.

Lesson Plan for Solution Architects Using TOGAF Standards

Course Title:

Solution Architecture Using TOGAF

Target Audience:

Course Duration:

Day 1: Introduction to TOGAF and the Solution Architect Role

  1. Learning Objectives:

    • Understand TOGAF and its value.
    • Understand the role of a Solution Architect within the framework.

  2. Topics Covered:

    • Introduction to TOGAF 9.2: Overview of TOGAF, key principles, and its components.
    • Solution Architecture Overview: Role, responsibilities, and skills of a Solution Architect.
    • Architecture Development Method (ADM): Introduction to TOGAF’s ADM phases and how they guide the development of architectures.

  3. Activities:

    • Group discussion: The role of Solution Architecture in digital transformation.
    • Case study: Review of a basic solution architecture framework.

Day 2: Architecture Development Method (ADM) and TOGAF Components

  1. Learning Objectives:

    • Understand the ADM phases and how they apply to Solution Architecture.
    • Know the core TOGAF artifacts and their use in Solution Architecture.

  2. Topics Covered:

    • ADM in Detail:
      • Preliminary Phase: Setting the architecture framework.
      • Phase A (Architecture Vision): Establishing scope and high-level objectives.
      • Phase B (Business Architecture): Aligning business goals and strategy.
      • Phase C (Information Systems Architectures – Data and Application): Creating a solution based on data and application architecture.
    • Core TOGAF Deliverables and Artifacts:
      • Architecture Vision, Architecture Definition, and Architecture Contract.
      • Building Block concepts (ABB, SBB).

  3. Activities:

    • Hands-on exercise: Create a high-level architecture vision document.
    • Case study analysis: Walk through a sample ADM process.

Day 3: Architecture Domains and Building Blocks

  1. Learning Objectives:

    • Gain detailed understanding of the architecture domains.
    • Learn to develop and utilize architecture building blocks (ABBs and SBBs).

  2. Topics Covered:

    • Data and Application Architectures:
      • Data modeling, data flows, and governance.
      • Application architecture: defining application components and their interactions.
    • Technology Architecture (Phase D):
      • Mapping solution to infrastructure: platforms, security, and operational layers.
    • Architecture Building Blocks (ABB): Key solution elements used across phases.
    • Solution Building Blocks (SBB): Actual components used in building systems.

  3. Activities:

    • Group exercise: Develop ABBs and SBBs for a specific solution scenario.
    • Use case review: Analyze the architecture domains for an enterprise solution.

Day 4: TOGAF Artifacts and Governance

  1. Learning Objectives:

    • Learn about TOGAF artifacts and their role in delivering solutions.
    • Understand architecture governance and how it supports project success.

  2. Topics Covered:

    • Artifacts for Solution Architecture:
      • Architecture Principles, Models, and Roadmaps.
      • Architecture Repository and Enterprise Continuum.
    • Governance and Compliance:
      • Architecture Governance Framework.
      • Risk management and architecture maturity.
      • Architecture contracts and capability assessments.

  3. Activities:

    • Create an architecture roadmap based on a business scenario.
    • Interactive discussion: Applying governance in a real-world solution.

Day 5: Practical Application and Case Study

  1. Learning Objectives:

    • Apply TOGAF principles to real-world solution scenarios.
    • Learn best practices and troubleshooting for solution architecture.

  2. Topics Covered:

    • Practical Solutions Architecture:
      • Identifying business needs and technical requirements.
      • Managing stakeholder expectations.
      • Evaluating the solution for performance, scalability, and security.
    • Finalizing ADM Cycle:
      • Phase E (Opportunities and Solutions), Phase F (Migration Planning).
      • Phase G (Implementation Governance), Phase H (Architecture Change Management).
    • Case Study:
      • Analyze and architect a solution based on a detailed business case.
      • Present a solution architecture and governance plan.

  3. Activities:

    • Case study project: Develop a full solution architecture for an enterprise problem.
    • Group presentations: Present the solution and review feedback.

Materials Needed:

Assessment:

Certification Path:

After completing this lesson plan, participants can opt for the TOGAF 9.2 Certification exam to validate their knowledge in TOGAF principles and methods.

Introduction

Core Concept

 

Enterprise architecture (EA) is a strategic discipline that defines the structure and operation of an organization. It provides a comprehensive framework to align business processes, information systems, technology infrastructure, and governance with the organization's vision and objectives.

 

Key Characteristics of Enterprise Architecture:

Purpose of Enterprise Architecture:

Artifacts & Building Blocks

Artifacts in TOGAF

Artifacts are specific documents, diagrams, or models that describe various aspects of the architecture. They are outputs from the architecture development process and are used to represent information in a structured and actionable manner.

Types of Artifacts:

  1. Catalogs: Lists or inventories of things like applications, data entities, or roles.

    • Example: Applications Portfolio, Business Function Catalog.

  2. Matrices: relationships between different architectural elements.

    • Example: Business Value Matrix, Application Stability Index, Estimations etc.

  3. Diagrams: graphic representations of a subset of the architecture.

    • Example: Business Process Flow, Data Flow Diagram, Use Case Diagram, UML, Technology Infrastructure Diagram.

  4. Deliverables: Any documents that are agreed upon and signed off.

    • Example: SOW, Department Roadmap, Estimation, HLD, SPD etc.

 

 

Building Blocks in TOGAF

Building blocks are reusable components that define capabilities and services within the architecture. They can represent either logical or physical elements and are foundational to creating consistent architectures.

Types of Building Blocks:

  1. Architecture Building Blocks (ABBs): Represent logical components that describe what needs to be done.

    • Example: Business processes, data models, or application functionalities.

  2. Solution Building Blocks (SBBs): Represent physical components that describe how the logical requirements will be implemented.

    • Example: Specific software, hardware, or platforms.

 

Architecture Building Blocks (ABBs) in TOGAF

 

Introduction

Architecture Building Blocks (ABBs) are high-level, logical components that describe the essential capabilities and services an organization requires to meet its business objectives. ABBs are abstract and technology-neutral, focusing on what needs to be achieved rather than how it will be implemented.

Characteristics of ABBs:

Structure of an ABB

An ABB typically contains the following attributes:

Attribute Description
Name A clear, concise name (e.g., "User Authentication").
Purpose A description of what the ABB does (e.g., "Provides secure access to applications").
Capabilities Key functions are provided by the ABB.
Relationships Interactions with other ABBs (e.g., dependencies on Data Storage ABB).
Constraints Business or regulatory constraints affecting the ABB.
Requirements High-level requirements the ABB must fulfill.
Rationale Justification for its inclusion in the architecture.

Approach

we can use left-to-right approach such as starting from foundation Architecture to Common System Architecture to Industry Specific Architecture.

Example : Starting with basic LMS system to Industry specific or College or University specific LMS and so on.

 

Solution Building Block (SBB)

Introduction:


Solution Building Blocks (SBBs) represent the actual products, services, or components required to implement architecture. These blocks are specific, tangible, and are directly mapped to deliverables in an enterprise's technical or business domains.

Characteristics of SBBs:

  1. Tangible and Realizable:

    • Unlike ABBs, which are conceptual, SBBs deal with real-world technologies, systems, or processes.

  2. Implementation-Ready:

    • Detailed to a level where they can be developed or acquired.

  3. Vendor-Specific or Technology-Oriented:

    • Often align with specific software, platforms, or services (e.g., SAP for ERP, AWS for cloud hosting).

  4. Traceability to ABBs:

    • SBBs realize the concepts and capabilities defined by ABBs.
    • Example: ABB might describe "Payment Gateway Functionality," while the SBB specifies the technology like Stripe or PayPal.

  5. Lifespan Management:

    • SBBs may evolve as technology or business needs change.

SBB Structure:

A typical Solution Building Block includes:

Attribute Description
Name Clear identification and purpose of the SBB.
Purpose / Specification Functional and non-functional requirements, including performance, scalability, and compliance.
Relationships Connections to other SBBs or ABBs.
Implementation Details:
  • Platforms (e.g., Java, .NET, Kubernetes).
  • Technologies (e.g., specific APIs or tools).
Constraints/Vendor/Product Information Commercial or open-source solutions, such as Oracle DB, Salesforce.
Requirements/Standards and Guidelines Adherence to enterprise policies, such as data security protocols.

Approach

We can use a left-to-right approach, such as starting from foundational Solution architecture to common solution architecture to industry-specific solution architecture.

 

 

TOGAF Architecture Repository

 

Introduction

The Architecture Repository in TOGAF is a structured framework that stores all the artifacts, guidelines, and references required for enterprise architecture management. It is a centralized repository used throughout the enterprise to govern architecture development and ensure consistency and compliance across projects.

Purpose of the Architecture Repository

Key Components of the Architecture Repository

The Architecture Repository is divided into six main areas:

  1. Architecture Metamodel:

    • Defines the structure of architecture descriptions, ensuring consistency.
    • Includes definitions of artifacts, relationships, and viewpoints.

  2. Architecture Capability:

    • Captures the resources needed to operate and manage the architecture function, such as policies, governance models, and roles.
    • Includes:
      • Governance Frameworks: Processes for compliance and decision-making.
      • Skills Database: Information about the capabilities of enterprise architecture personnel.

  3. Architecture Landscape:

    • Represents the current, target, and transitional states of the enterprise architecture.
    • Organized into:
      • Strategic Architecture: Long-term visions and roadmaps.
      • Segment Architecture: Focus on specific business areas or capabilities.
      • Capability Architecture: Details of projects and initiatives supporting capabilities.

  4. Reference Library:

    • A collection of reusable resources, such as templates, standards, and patterns.
    • Examples:
      • Technology standards (e.g., HTTP, RESTful APIs).
      • Industry models (e.g., TOGAF templates, BPMN models).

  5. Standards Information Base (SIB):

    • Repository of industry standards and regulatory requirements.
    • Ensures compliance with legal and technical obligations.
    • Examples:
      • GDPR for data protection.
      • ISO/IEC standards for IT systems.

  6. Governance Log:

    • Records decisions, approvals, and compliance checks for architecture work.
    • Provides traceability and auditability.

Architecture Repository and the ADM Cycle

The Architecture Repository is closely integrated with TOGAF’s Architecture Development Method (ADM). It supports each ADM phase by providing relevant resources and capturing outputs.

  1. Preliminary Phase:

    • Establishes and populates the repository with initial standards, principles, and reference materials.

  2. Phases A-F (Architecture Vision, Business/Data/Application/Technology Architecture, Opportunities and Solutions):

    • Uses the repository to draw reference models and templates.
    • Updates the repository with new artifacts, building blocks, and plans.

  3. Phases G-H (Implementation Governance, Architecture Change):

    • Tracks progress and ensures governance compliance using the Governance Log.
    • Stores as-built architecture in the Architecture Landscape.

  4. Requirements Management:

    • Links requirements to architecture artifacts in the repository, enabling traceability.

ADM - Architecture Development Method

Introduction

The Architecture Development Method (ADM) is the core of the TOGAF framework. It provides a step-by-step, iterative approach for developing and managing enterprise architecture to align IT solutions with business goals

The ADM cycle consists of 10 phases, starting from establishing the architecture vision to managing its implementation and ongoing changes. Each phase delivers specific outputs, which are used in subsequent phases.

Phases of the TOGAF ADM

  1. Preliminary Phase: Preparing the Architecture Effort

    • Purpose: Establish the architecture capability within the organization.
    • Key Activities:
      • Define architecture principles.
      • Develop the architecture governance framework.
      • Set up the Architecture Repository.
    • Outputs:
      • Architecture Principles.
      • Governance Framework.

  2. Phase A: Architecture Vision

    • Purpose: Define the high-level vision, goals, and scope of the architecture project.
    • Key Activities:
      • Identify stakeholders and their concerns.
      • Create an Architecture Vision document.
      • Validate business goals and objectives.
    • Outputs:
      • Statement of Architecture Work.
      • Architecture Vision document.

  3. Phase B: Business Architecture

    • Purpose: Develop the business architecture to support the agreed architecture vision.
    • Key Activities:
      • Analyze the business strategy and objectives.
      • Define the business capabilities, processes, and organizational structure.
    • Outputs:
      • Business Architecture artifacts (catalogs, matrices, diagrams).

  4. Phase C: Information Systems Architectures

    • Purpose: Define architectures for data and applications.
    • Sub-phases:
      • Data Architecture: Focuses on the organization and management of data.
      • Application Architecture: Addresses the structure and interaction of application systems.
    • Outputs:
      • Data and Application Architecture artifacts.

  5. Phase D: Technology Architecture

    • Purpose: Develop the technology architecture to support business, data, and application needs.
    • Key Activities:
      • Identify technology standards and platforms.
      • Define infrastructure services and systems.
    • Outputs:
      • Technology Architecture artifacts (network diagrams, infrastructure models).

  6. Phase E: Opportunities and Solutions

    • Purpose: Identify and prioritize potential solutions to address business needs.
    • Key Activities:
      • Assess and consolidate implementation opportunities.
      • Develop a high-level roadmap.
    • Outputs:
      • Transition Architecture(s).
      • Project work packages.

  7. Phase F: Migration Planning

    • Purpose: Create a detailed implementation and migration plan.
    • Key Activities:
      • Develop a roadmap showing dependencies and timelines.
      • Align project sequencing with organizational priorities.
    • Outputs:
      • Implementation and Migration Plan.

  8. Phase G: Implementation Governance

    • Purpose: Ensure the solutions are implemented in accordance with the defined architecture.
    • Key Activities:
      • Provide architectural oversight for projects.
      • Ensure compliance with standards and guidelines.
    • Outputs:
      • Architecture Contract.
      • Compliance assessments.

  9. Phase H: Architecture Change Management

    • Purpose: Manage changes to the architecture and ensure it evolves with the business.
    • Key Activities:
      • Monitor the environment for changes.
      • Assess impact and update the architecture.
    • Outputs:
      • Updated Architecture Requirements.
      • Architecture Change Request.

  10. Requirements Management

ADM Cycle and Iteration

The ADM is iterative, allowing architects to revisit phases as required:

Outputs of the ADM Phases

Each ADM phase produces artifacts, deliverables, and building blocks:

ADM Cycle Iteration Approach

The Iteration Approach in TOGAF ADM allows organizations to adapt the architecture development process to their specific needs by revisiting phases and refining outputs iteratively. This ensures that the architecture evolves effectively and aligns with changing business priorities, complexities, and scales.

 

Analysing Current State

Why Changes are required

 

Functional Decomposition / Process Analysis

 

 

Define Future State

Template:

Business Value Matrix.xls

 

Architecture Vision in TOGAF ADM (Phase A)

The Architecture Vision phase is the starting point of the architecture development process in the ADM cycle. It sets the foundation by defining what the organization wants to achieve with the architecture effort. Think of it as creating a blueprint of goals and priorities that aligns with the business strategy and meets stakeholder needs.

 

Key Purpose of the Architecture Vision Phase:

 

Example in Simple Terms:

Business Architecture in TOGAF ADM (Phase B)

The Business Architecture phase in the ADM cycle focuses on understanding and designing the business aspects of the enterprise. It ensures that the architecture supports the organization’s strategic goals by analyzing its processes, organizational structure, and capabilities.

In simple terms, this phase answers:

Purpose of Business Architecture Phase

 

Example in Simple Terms

Scenario: A bank wants to improve its customer experience for loan processing.

Information Systems Architecture in TOGAF ADM (Phase C)

The Information Systems Architecture phase in the ADM cycle focuses on the systems and data needed to support the business. It is divided into two parts:

  1. Data Architecture: Defines how data is stored, managed, and shared across the organization.
  2. Application Architecture: Identifies the applications required and how they interact to deliver business capabilities.

In simple terms, this phase answers:

Purpose of the Information Systems Architecture Phase

 

Outputs of the Information Systems Architecture Phase

1. Data Architecture Artifacts

2. Application Architecture Artifacts

3. Gap Analysis Results

4. Updated Architecture Requirements:

5. Baseline and Target Architectures:

 

Example in Simple Terms

Scenario: A hospital wants to create a seamless patient experience by integrating its systems.

Different Types of Common System Architecture

System architecture refers to the structure and design of a system, defining how its components interact to deliver functionality. There are several common types of system architectures, each suited to specific use cases, complexities, and business requirements.

 

1. Monolithic Architecture

2. Layered (Tiered) Architecture

3. Client-Server Architecture

4. Microservices Architecture

5. Event-Driven Architecture

6. Service-Oriented Architecture (SOA)

7. Serverless Architecture

8. Peer-to-Peer (P2P) Architecture

9. Distributed Architecture

10. Modular / Domain Architecture

11. Component-Based Architecture

12. Hybrid Architecture

Choosing the Right Architecture

The selection depends on:

  1. Scale of the Application: Small, medium, or large-scale.
  2. Complexity: Single-functionality vs. multi-functional systems.
  3. Performance Needs: Real-time processing vs. batch processing.
  4. Future Growth: Scalability and modularity requirements.

Opportunity & Solutions in ADM (Phase E)

In TOGAF’s Architecture Development Method (ADM), Opportunity & Solutions refers to identifying and designing potential solutions to address the business and technical challenges revealed earlier in the ADM cycle. This phase ensures that the architecture aligns with business needs while providing practical solutions for the identified opportunities.

In simple terms, it’s about turning the problems or gaps you've identified in the earlier phases into concrete solutions that will be implemented to meet the organization's needs. This phase also ensures that opportunities for improvement are captured and addressed in the solution design.

This phase will be done with POC or MVP. Based on the outcome, it will be further moved to project proposal and approval.

Purpose of Opportunity & Solutions Phase (Phase E)

  1. Identify Solutions for Business Needs: It connects business goals and requirements to practical solutions, ensuring that the architecture will support the business in the most efficient way possible.
  2. Assess Feasibility and Value: Evaluate the potential solutions and their feasibility, ensuring they provide value in terms of cost, time, and resources.
  3. Define Transition Roadmap: Plan how to move from the current architecture to the future architecture through specific projects, phases, or releases.

 

Outputs of the Opportunity & Solutions Phase

  1. Opportunity and Solution Definition:

    • A clear definition of the opportunities that have been identified and the solutions proposed to address them.

  2. Solution Architecture Models:

    • Detailed solution designs provide a blueprint for the proposed solution, ensuring all technical and business aspects are covered.

  3. Feasibility Assessments:

    • Evaluation reports on the feasibility of the proposed solutions, covering aspects like technical viability, cost, and risk.

  4. Transition Roadmap:

    • A roadmap or plan that outlines how the transition from the current architecture to the target architecture will happen step-by-step.

  5. Implementation and Migration Plans:

    • A detailed plan for implementing the selected solutions, including projects, timelines, resource requirements, and milestones.

  6. Updated Architecture Requirements:

    • Refined or additional requirements based on the solutions, potentially including new technology, infrastructure, or applications.

Example in Simple Terms

Let’s say a retail company wants to improve its Customer Experience Domain.