TOGAF 9 - Study Notes

I successfully completed my TOGAF-9 certification in May 2013. While preparing for the certification, I made short notes which really helped me in revising concepts within short period of time and help me ace the certification. 

Here I am sharing these notes so that everyone can get help from them.

Introduction –

·         7 parts of TOGAF document -

o    Part I - Introduction

o    Part II - Architecture Development Method

o    Part III - ADM Guidelines & Techniques

o    Part IV - Architecture Content Framework

o    Part V - Enterprise Continuum & Tools

o    Part VI - TOGAF Reference Models

o    Part VII - Architecture Capability framework

ADM –

·         Every phase is validated against current requirements and in turn validates the current requirements of the business.

·         ADM is an iterative process -

o    Over the whole process

o    Between phases

o    Within phases

Preliminary phase -

·         Understand business environment

·         High level management commitment

·         Agreement on scope

·         Establish principles

·         Establish governance structure

·         Customization of TOGAF

·         Definition of an Organization-Specific Architecture framework

·         Definition of principles

·         Determine and establish architecture capability desired by organization.

·         Define the requirements for architecture work.

·         Inputs -

o    Reference materials external to enterprise

o    Architectural and non-architectural inputs

·         Outputs -

o    Organization model for enterprise architecture

o    Tailored architecture framework

o    Initial architecture repository

o    Request for architecture work

o    Architecture governance framework

Phase A - Architecture vision

·         Sets scope, constraints and expectations.

·         Create architecture vision

·         Validate business context

·         Create architecture vision document.

·         Business scenario technique can be used to create architecture vision

·         Create statement of architecture work and obtain approval

·         Communication plan is made in Phase A.

Phase B - Business architecture

·         Business architecture depicts fundamental organization of a business embodied in -

o    Business processes and people

o    Their relationship to each other and environment

o    Principles governing its design and evolution.

·         Develop target business architecture

Phase C - Information systems architecture

·         Fundamental organization of an IT system.

·         Top down design - Business, Data, Applications, Technology

·         Bottom up design - Technology, Applications, Data, Business

Phase D - Technology architecture

·         Develop target technology architecture

Phase E - Opportunities and Solutions

·         Perform initial implementation planning

·         Identify major implementation projects

·         Group changes into work packages

·         Determine if an incremental approach is required. If yes, define 'Transition architecture'.

·         Decide on approach

o    Make vs Buy vs Reuse

o    Outsource

o    COTS

o    Open source

·         Assess priorities

·         Identify dependencies

Phase F - Migration planning

·         For work packages identified in phase E perform -

o    Cost/benefit analysis

o    Risk assessment

·         Develop a detailed implementation and migration plan

·         Finalize the architecture roadmap

Phase G - Implementation governance

·         Define architecture constraints on implementation projects

·         Govern and manage an architecture contract

·         Monitors implementation work for governance

·         Produce a business value realization

·         Phase G provides architectural oversight of the implementation.

·         Phase G - Implementation Governance, ensure conformance with the defined architecture by the implementation projects.

Phase H - Architecture change management

·         Provide continual monitoring and a change management process

·         Monitors the business and capacity management

Requirements Management phase -

·         Applies to all phases of the ADM cycle

·         Is central to the ADM process

·         Is a dynamic process addressing the identification of requirements, their storage and delivery to the phases

Enterprise Architecture -

·         Reasons for EA -

o    Critical to business survival and success

o    Enabled managed innovation within the enterprise

·         Pressure to develop EA -

o    Laws and regulations

o    More extended enterprises

o    More co-operative IT operations

o    Greater publicity to failures

o    Increase in litigation

o    Audit requirements

·         Helps an organization achieve its strategy.

·         EA is as good as the decision making framework established around it - Governance framework.

Enterprise continuum -

·         View of architecture repository.

·         Provides methods for classifying artifacts.

·         Two complementary concepts -

·         Architecture continuum

·         Solution continuum

·         The architecture and solutions continuum are related by guidance, direction and support.

·         Practical implementation of enterprise continuum is architecture repository.

·         Enables effective use of COTS products

·         Requirements for missing elements are passed to the left of the continuum for inclusion.

·         The continuum contains complete and work-in-progress solutions.

Content Metamodel -

·         Defines all types of building blocks in an architecture.

·         Describe building blocks and how they relate

·         Consists of Core and Extensions

·         Core content is designed not to be altered

·         Extension content allows for more specific or more in-depth modeling

·         Extensions available -

·         Governance extensions - To support the enterprise architecture with operational governance

·         Contract, Service quality, measure

·         Services extensions - To support definition of discreet business & application services

·         Information system service

·         Process modeling extensions - To support process modeling

·         Event, control, product

·         Data extensions - To support data modeling

·         Logical data component, Physical data component

·         Infrastructure consolidation extensions -

·         Location, Physical application component, Logical technology component

·         Motivation extensions - To support linkage of drivers, goals and objectives to org & services

·         Driver, Goal, Objective

·         Core components -

·         Principle, Constraint, Assumption, Requirement, Gap, Work package, Capability

·         Organization, Actor, Role

·         Function, Business service, Process

·         Data entity

·         Logical application component

·         Platform service, Physical technology component

·         Architecture realization artifacts capture the transitions between architecture states and are used to steer and govern the implementation.

Architecture Repository -

·         TOGAF ADM has reminders when to use assets from the Architecture repository.

·         The architecture repository is a model for a physical instance of Enterprise continuum.

·         Six classes of architectural information (repository areas) -

o    Architecture Metamodel

o    Architecture Capability

o    Architecture Landscape

o    Reference Library

o    Standards Information base (SIB)

o    Governance Log

·         Architecture Metamodel

o    Describes the architecture framework in use within the enterprise.

·         Architecture Capability -

o    Describes the organization, roles, skills and responsibilities of Enterprise architecture practice

·         Reference Library  -

o    Should contain Reference architectures, Reference Models, Viewpoint Library, Templates.

o    In order to segregate different classes of architecture reference materials, the Reference Library can use the Architecture Continuum as a method for classification.

·         Standards Information Base (SIB)

o    Types of Standards -

·         Legal and Regulatory obligations

·         Industry standards

·         Organizational standards

·         Governance Log

·         Enterprise Repository -

o    Architecture Repository

o    Requirements Repository

o    Solutions repository (Holds SBBs)

·         External Repositories -

o    External reference models

o    External standards

o    Architecture board approvals

·         Architecture requirements -

o    Strategic requirements

o    Segment requirements

o    Capability requirements

TOGAF Technical Reference Model (TRM) -

·         It can be used to build any system architecture.

·         TRM has two main components -

o    Taxonomy - Terminology & description

o    Associated Graphic - Visual representation of taxonomy

·         Aims to emphasize the aspect of

o    Application Portability.

o    Interoperability.

·         It is an example and should be tailored to the needs of an organization.

·         The core of TOGAF is its ADM: the TRM is a tool used in applying the ADM in the development of specific architectures.

·         TRM is composed of 3 major entities -

o    Application software.

·         <Application Platform interface>

o    Application platform.

·         <Communications infrastructure interface>

o    Communications infrastructure.

·         The high-level TRM seeks to emphasize two major common architectural objectives:

o    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

o    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

Integrated Information Infrastructure Reference Model

·         IIM-RM has two main components -

o    Taxonomy - Terminology & description

o    Associated Graphic - Visual representation of taxonomy

·         III-RM is an example of Application Architecture Reference Model.

·         Core components of III-RM -

o    Business applications

·         Brokering applications

·         Information provider applications

·         Information consumer applications

o    Infrastructure applications

·         Development tools

·         Management utilities

o    Application platform

o    Interfaces

o    Qualities

Architecture content framework -

·         Section IV of TOGAF document - Detailed model of architectural work products

·         Content framework provides a structure to the ADM that defines inputs and outputs in detail and puts each deliverable into the context of the architecture.

·         Three types of architectural work products -

o    Deliverable

o    Artifact

o    Building block

·         Deliverable - Contractually specified. Formally reviewed, agreed & signed by stakeholders

·         Artifact -

o    Catalogs - List of things

o    Matrices - Relationships between things.

o    Diagrams - Pictures of things

·         Artifacts will form the content of Architecture Repository.

·         Building block -

o    Architecture building blocks - Typically describe required capability.

o    Solution building blocks - Represent components that will be used to implement the required capability.

·         Artifacts describe building blocks.

·         Includes detailed meta-model

Architecture capability framework -

·         Section VII of TOGAF document.

·         Describes processes, skills and roles to establish and operate an architecture function within an enterprise.

·         Provides a set of reference materials for establishing an architecture function within an organization.

·         Structured as follows:

o    Introduction

o    Establishing an Architecture Capability

o    Architecture Board

o    Architecture Compliance

o    Architecture Contracts

o    Architecture Governance

o    Architecture Maturity Models

o    Architecture Skills Framework

Architecture Compliance

·         Levels of Architecture Conformance -

o    Irrelevant

o    Consistent

o    Compliant

o    Conformant

o    Full Conformant

o    Non conformance

·         Architecture Compliance reviews -

o    To review a project against established architecture criteria and business objectives.

o    A formal process for such reviews normally forms the core of an enterprise Architecture Compliance strategy.

o    Purpose -

·         Catch errors in the project architecture early

·         Ensure the application of best practices to architecture work.

·         Deciding between architectural alternatives.

Architecture contract -

·         Architecture Contracts may occur at various stages of ADM -

o    SOAW created in Phase A.

o    Development of one or more architecture domains (business, data, application, technology) in appropriate phases.

o    At the beginning of Phase G (Implementation Governance).

o    When the enterprise architecture has been implemented (at the end of Phase G).

·         Contents -

o    Statement of Architecture work (Contract b/w architecting organization & sponsor of EA).

o    Contract between Architecture Design and Development Partners.

o    Contract between Architecting Function and Business Users. (End of phase F)

o    Relationship to Architecture Governance. (End of phase G)

Architecture Changes -

·         Simplification change:

o    Driven by requirement to reduce investment.

o    Can normally be handled via change management techniques.

·         Incremental change:

o    Driven by requirement to derive additional value from existing investments.

·         Re-architecting change:

·         Top-down :

o    Strategic, top-down directed change to enhance or create new capability (capital)

·         Bottom-up :

o    Changes to correct or enhance capability

Business Transformation Readiness Assessment -

·         Recommended activities -

o    Determine the readiness factors that will impact the organization

o    Present the readiness factors using maturity models

o    Assess the readiness factors, including determination of readiness factor ratings

o    Assess the risks for each readiness factor and identify improvement actions to mitigate the risk

·         Implementation and Migration plan incorporates the actions arising from this technique.

·         Initial assessment done in Phase A

·         Implemented in Phase E & F.

·         Readiness factor levels -

o    Not defined

o    Adhoc

o    Repeatable

o    Defined

o    Managed

o    Optimized

Business value assessment technique -

·         Comes under Migration planning techniques (Phase F).

·         Draw a matrix - Risk(X) vs Value (Y).

Building Block –

·         Building blocks can relate to "architectures" or "solutions".

·         They are a package of functionality intended to meet business needs across the organization.

·         They should have stable, published interfaces that allow other building blocks to interoperate with them.

·         They may be assembled from other building blocks.

·         Good building block should be reusable and replaceable.

·         Architecture Building blocks -

o    Architecture documentation and models from the enterprise's architecture continuum

o    They are defined or selected mainly in phases A, B, C & D.

o    They define what functionality will be implemented

o    They capture business and technical requirements

o    They are technology aware

o    They direct and guide the development of solution building blocks

·         Solution building blocks -

o    Relate to solutions continuum

o    Can either be procured or developed

o    They define the implementation

o    They fulfill business requirements

o    They are product or vendor aware

·         Three classes of building blocks -

o    Reusable building blocks such as legacy items

o    Building blocks to be developed (new applications)

o    Building blocks to be purchased (COTS applications)

Request for Architecture work -

·         Sent from sponsor to the architecture organization.

·         Initiates a cycle of the ADM

Statement of architecture work -

·         Deliverable output from Phase A

·         A plan for the architecture work

Architecture Vision -

·         TOGAF recommends use of business scenarios in developing architecture vision.

Architecture definition document -

·         Deliverable container for core artifacts

·         BDAT architectures

·         Includes baseline, target and transition architectures

·         Developed through phases A, B, C, D

·         Provides qualitative view of the solution

Architecture requirements document -

·         Companion to architecture definition document

·         Contains measurable criteria - a quantitative view

·         Often used as a component of architecture contract.

Architecture roadmap -

·         Incrementally developed in phases E & F.

·         Informed by the candidate roadmap components identified in phases B, C, D

·         Shows progression from baseline to target.

Techniques for architecture development -

·         Architecture principles

·         Stakeholder management

·         Architecture patterns

·         Business Scenarios

·         Gap analysis

·         Migration planning techniques

·         Interoperability requirements

·         Risk management

·         Capability based planning

Architecture Principles -

·         Initial output of preliminary phase

·         Architecture principles template -

o    Name

o    Statement - To communicate rule/principle.

o    Rationale - To highlight business benefit of adhering to principle.

o    Implications - Effect/impact of following principle on business & IT.

Stakeholder management -

·         Used in phase A to identify key players and updated throughout each phase

·         Output of this process forms part of communications plan

·         TOGAF approach -

o    Identify stakeholders

o    Classify stakeholder positions

o    Determine stakeholder management approach (Power/interest matrix)

o    Tailor engagement deliverables

·         Power/interest matrix

o    Minimal effort

o    Keep informed

o    Keep satisfied

o    Key players

Architecture patterns -

·         Architecture patterns

·         Design patterns

·         Idioms - Low level patterns specific to a programming language.

·         Architecture patterns in use -

o    The US Treasury Architecture Development Guidance (TADG)

o    The IBM Patterns for e-Business

Business Scenario -

o    Are methods used to help identify and understand the business requirements that the architecture must address.

o    Describes a business process, application or set of applications.

o    Describes the business and technology environment.

o    Describes the people and computing components (actors) who execute the scenario.

o    Describes the desired outcome of proper execution.

o    A good business scenario is SMART - Specific, Measurable, Actionable, Realistic, and Time-bound.

o    Mainly used in Architecture vision (Phase A) and also Business Architecture phase (Phase B)

Gap Analysis -

o    Used to validate architecture that is being developed.

o    Technique used in phase - B, C, D & E.

o    It highlights services that are yet to be developed.

o    Identify potential missing or overlapping functions.

Interoperability requirements -

·         Information Interoperability:

o    Knowledge management

o    Business intelligence

o    Information management

o    Trusted identity

·         Business Interoperability:

o    Delivery networks

o    e-Democracy

o    e-Business

o    Enterprise resource management

o    Relationship and case management

·         Technical Interoperability:

o    IT infrastructure

Risk Management -

·         Risks are identified in Phase A as part of Business Transformation Readiness Assessment.

·         Risk monitoring is conducted in Phase G.

·         Initial risk assessment is done by classifying risks with respect to effect and frequency.

·         Effect -

o    Catastrophic - Critical financial loss (bankruptcy)

o    Critical - Serious financial loss (loss in productivity and no ROI)

o    Marginal - Minor financial loss (reduced ROI)

o    Negligible

Capability based planning -

·         Business planning technique that focuses on business outcomes.

·         Steps -

o    Phase A - Corporate strategic action must drive this.

o    Phases B, C, D - Specific capabilities must be targeted for completion

o    Phase E - Capability increments must drive this.

Architecture Governance -

·         Governance should be established in the preliminary phase

·         Architecture board should ensure that ADM is being applied correctly

·         Governance plays a key role in phases G & H.

·         Levels of governance -

o    Technology Governance

o    IT Governance

o    Architecture Governance

·         COBIT - Open standard IT Governance framework

·         Process, content and context

View & Viewpoint -

·         View

o    A view is used to describe how concerns of a stakeholder are being met.

o    Representation of an overall architecture.

·         Viewpoint

o    Represents concerns of stakeholders.

o    Defines how to construct and use a view

·         View creation process -

o    Refer to any existing library of viewpoints

o    Select key stakeholders, analyze their concerns and document them

o    Select appropriate viewpoints

Architecture Partitioning -

·         Need to partition - Managing complexity, conflicts, parallel development, and reuse.

·         Solution Partitioning -

o    Subject matter (Breadth)

o    Time

o    Maturity/Volatility

·         Architecture Partitioning -

o    Depth (Level of detail)

·         The Preliminary phase supports identification of appropriate architecture partitions and establishment of governance relationship between related architecture partitions.

ADM Iterations -

·         Iteration to describe a comprehensive architecture landscape.

·         Iteration within an ADM cycle.

·         Iteration to manage the architecture capability.

·         Architecture Development iterations support creation and evolution of architecture content by cycling through phases B, C and D.

·         As iterations converge on a target, extensions into phases E & F ensures the viability of implementation is considered.

·         Transition planning iteration supports the creation of formal change roadmaps.

·         Architecture capability iterations support creation and evolution of architecture capability.

·         Approaches to architecture development (iterations) -

o    Baseline first

o    Target first

·         Baseline first -

o    An assessment of baseline landscape is used to identify problem areas and opportunities for improvement.

o    Suitable approach when baseline is complex or not clearly understood.

o    Iteration 1 - Define baseline architecture

o    Iteration 2 - Define target architecture and gaps

o    Iteration n - Refine baseline architecture, target architecture and gaps

·         Target first -

o    Target solution is elaborated in detail and then mapped back to the baseline.

·         Classes of architecture engagement -

o    Identification of change required

o    Definition of change

o    Implementation of change

·         Transition planning iteration -

o    Iteration 1 - Define and agree a set of improvement opportunities aligned against a provisional transitional architecture

o    Iteration n - Agree the transition architecture, refining the identified improvement opportunities to fit.

·         Architecture governance iteration -

o    Iteration 1 - Mobilize architecture governance and change management process.

o    Iteration n - Carry out architecture governance and change control.

·         Organizing architecture landscape -

o    Breadth (subject matter)

o    Depth

o    Time

o    Recency

ADM Security -

·         Intended to inform EA of the security architecture task and role.

·         Security objectives have been developed for each ADM phase.

·         Typical security artifacts -

o    Business rules regarding handling of data/information assets.

o    Written and published security policy

o    Codified data/information asset ownership and custody

o    Risk analysis documentation

o    Data classification policy documentation

Miscellaneous

·         Request for Architecture word document - This document is used to initiate a TOGAF ADM cycle.

·         Purpose of enterprise architecture - To optimize an enterprise into an environment that is responsive to business needs.

·         Theory suggests that data architecture comes first but that is not a rule.

·         Types of TOGAF tailoring -

o    Terminology tailoring

o    Process tailoring - Tailoring ADM

o    Content tailoring - using Architecture content framework

·         There are four architecture domains within TOGAF: business, data, application, and technology (BDAT)

References –

http://www.opengroup.org/