IX) TOGAF Learning Outcome: Architecture Views, Viewpoints, and Stakeholders

The Candidate must be able to:

1. Define and explain the following key concepts (KLP 35.1-1):

o Stakeholders
o Concerns
o Views
o Viewpoints
2. Describe a simple example of a viewpoint and view (KLP 35.1-2)
3. Discuss the relationship between stakeholders, concerns, views, and viewpoints (KLP 35.1-3)
4. Describe the view creation process (KLP 35.2-1)

VIII) TOGAF Learning Outcome: Architecture Governance (Level 1)

The Candidate must be able to:
1. Briefly explain the concept of Architecture Governance (KLP 50.1-1)
2. Describe the main concepts that make up an Architecture Governance framework (KLP 50.2-1)
3. Explain why Architecture Governance is beneficial (KLP 50.3-1)
4. Briefly explain the need for establishment of an Architecture Board (KLP 47.1-1)
5. List the responsibilities of an Architecture Board (KLP 47.2-1)
6. Briefly explain the role of Architecture Contracts (KLP 49.1-1)
7. Briefly explain the meaning of Architecture Compliance (KLP 48.2-1)
8. Briefly explain the need for Architecture Compliance (KLP 48.1-1)
9. Briefly explain the purpose of Architecture Compliance Reviews (KLP 48.3-1)
10. Briefly describe the Architecture Compliance Review process (KLP 48.4-1)
11. Briefly explain how the ADM can be used to establish an Architecture Capability (KLP 46.1-1)

VII) TOGAF Learning Outcome: ADM Guidelines and Techniques

The Candidate must be able to:
1. Briefly explain the contents of Part III of TOGAF 9 (KLP 18.1-1)
2. Briefly explain the need for Architecture Principles and where they are used within TOGAF (KLP 23.1-1)
3. Describe the standard template for Architecture Principles (KLP 23.3-1)
4. Explain what makes a good Architecture Principle (KLP 23.4-2)
5. Understand what a Business Scenario is and its purpose (KLP 26.1-1)
6. Explain where Business Scenarios are used within the ADM cycle (KLP 26.1-2)
7. Explain the purpose of Gap Analysis (KLP 27.2-1)
8. Describe the Gap Analysis technique (KLP 27.2-1)
9. Explain the term interoperability (KLP 29.2-1)
10. Understand the use of Interoperability Requirements within the TOGAF ADM (KLP 29.1-1)
11. Understand the Business Transformation Readiness program (KLP 30.1-2)
12. Understand where Business Transformation Readiness is used within the ADM (KLP 30.1-1)
13. Understand the characteristics of Risk Management (KLP 31.1-2)
14. Understand where Risk Management is used within the TOGAF ADM (KLP 31.1-1)
15. Understand Capability-Based Planning (KLP 32.1-1)

VI) TOGAF Learning Outcome: ADM Phases (Level 1)

Preliminary Phase:

The Candidate must be able to:
1. Describe the objectives of the phase (KLP 6.1-1)
2. Briefly explain the seven aspects of the approach undertaken in this phase (KLP 6.2-1):

o Defining the enterprise
o Identifying key drivers and elements in the organizational context
o Defining the requirements for architecture work
o Defining the Architecture Principles that will inform any architecture work
o Defining the framework to be used
o Defining the relationships between management frameworks
o Evaluating the enterprise architecture maturity

Phase A:

The Candidate must be able to:

1. Describe the main objectives of the phase (KLP 7.1-1)
2. Briefly explain the two main aspects to the approach in this phase (KLP 7.2-1):

o Creating the Architecture Vision

o Business Scenarios

Phase B:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 8.1-1)
2. Briefly explain the main aspects of the approach in this phase (KLP 8.2-1):

o Developing the Baseline Description
o Business Modeling
o Using the Architecture Repository

Phase C:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 9.1-1,10.1-1,11.1-1)
2. Briefly explain the approach recommended by TOGAF, including:
o Key considerations for the Data Architecture (KLP 10.2-1)
o Using the Architecture Repository (KLP 10.2-1,11.2-1)

Phase D:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 12.1-1)
2. Briefly explain the approach to the phase (KLP 12.2-1), including:
o Using the Architecture Repository

Phase E:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 13.1-1)
2. Briefly explain the approach to the phase (KLP 13.2-1)

Phase F:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 14.1-1)
2. Briefly explain the approach to the phase (KLP 14.2-1)

Phase G:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 15.1-1)
2. Briefly explain the approach to the phase (KLP 15.2-1)

Phase H:

The Candidate must be able to:
1. Describe the main objectives of the phase (KLP 16.1-1)
2. Briefly explain the approach to the phase (KLP 16.2-1), including:

o Drivers for change
o Enterprise architecture management process
o Guidelines for maintenance versus architecture redesign

ADM Architecture Requirements Management:

The Candidate must be able to:
3. Briefly explain how Requirements Management fits into the ADM cycle (KLP 17.1-1)

1. Describe the nature of the Requirements Management process (KLP 17.1-2)
2. Describe the approach to Requirements Management (KLP 17.2-1)

V) TOGAF Learning Outcome: Enterprise Continuum and Tools

The Candidate must be able to:
1. Briefly explain what the Enterprise Continuum is

  • The enterprise continuum is a categorization mechanism which provides a view of the architecture repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete and from logical to physical.

2. Explain how it is used in organizing and developing an architecture

  • Enterprise is the outermost continuum and classifies assets related to the context of overall enterprise architecture.
  • Enterprise Continuum classes of assets may influence architectures but are not directly used during the ADM architecture development.

3. Explain how the Enterprise Continuum promotes re-use of architecture artifacts

  • Enterprise Continuum promotes re-use of artifacts by managing an architecture repository which includes architecture and solution artifacts. These artifacts can be used as building blocks for future or/and current architecture development.

4. Describe the constituents of the Enterprise Continuum

  • The Enterprise Continuum is partitioned into three distinct continua as follows:
    • Enterprise Continuum
      It is the outermost continuum and classifies assets related to the context of overall enterprise architecture
    • Architecture Continuum
      It offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships. It represents a structure of architecture building blocks which are re-usable architecture assets.
    • Solutions Continuum
      It provides a consistent way to describe and understand the implementation of the assets defined in the architecture continuum. The Solutions Continuum defines what is available in the organizational environment as re-usable Solution Building Blocks (SBBs).

5. Explain the purpose of the Enterprise Continuum (KLP 39.3-2)
6. Explain the purpose of the Architecture Continuum (KLP 39.4-3)

7. List the stages of architecture evolution defined in the Architecture Continuum (KLP 39.4-4)

8. Explain the purpose of the Solutions Continuum (KLP 39.4-6)

9. List the stages of architecture evolution defined in the Solutions Continuum (KLP 39.4-7)

10. Explain the relationship between the Enterprise Continuum and the TOGAF ADM (KLP 39.5-1)

11. Describe the Architecture Repository (KLP 41-1)

12. Explain the relationship between the Enterprise Continuum and the Architecture Repository (KLP 39.1-2,41.1-2)

13. Describe the classes of information held in the Architecture Repository (KLP 41.1-2)

14. List the three levels of the Architecture Landscape (KLP 41.2-1)

15. Explain the purpose of the Standards Information Base within the Architecture Repository (KLP 41.4-1)



TOGAF Learning Outcome: Introduction to the ADM

The Candidate must be able to:
1. Briefly describe the ADM cycle, its phases, and the objective of each phase

ADM Cycle

2. Describe a typical set of steps, such as those for Phases B, C, and D

Typical set of steps in Phase B, C, and D are:

  • Select Reference Models, Viewpoints and Tools
  • Develop Baseline Architecture description
  • Develop Target Architecture description
  • Perform Gap analysis
  • Define Candidate Road map components
  • Resolve impacts across architecture landscape
  • Conduct formal stakeholder review
  • Finalize the arcihtecture
  • Create ADD – Architecture definition document.

3. Describe the versioning convention for deliverables used in Phases A to D

  • Version 0.1 – High level outline of the architecture is in place.
  • Version 1.0 – A formally reviewed detailed architecture is in place.

ADM Version Numbering Convention
4. Briefly describe the relationship between the ADM and other parts of TOGAF (Enterprise Continuum, Architecture Repository, Foundation Architecture, Supporting Guidelines and Techniques)

  • Enterprise Continuum provides a framework and context to support the leverage of relevant architecture assets in executing the ADM.
  • The practical implementation of Enterprise Continuum typically takes the form of Architecture Repository that includes reference architectures, models and patterns that have been accepted for use within the enterprise, and actual architectural work done previously in the enterprise
  • ADM helps populate the foundation architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture.
  • ‘Supporting Guidelines and techniques’ is a set of resources – guidelines, templates, checklists, and other detailed materials – that support application of the TOGAF ADM.

5. Explain the purpose of the supporting guidelines and techniques, and the difference between guidelines and techniques

  • ‘Supporting Guidelines and techniques’ is a set of resources – guidelines, templates, checklists, and other detailed materials – that support application of the TOGAF ADM.
  • Difference between G & T ???

6. Briefly describe the key points of the ADM cycle

  • For each ADM iteration, a fresh decision must be taken as to:
    • The breadth and coverage of the enterprise to be defined.
    • The level of detail to be defined
    • Extent of time period aimed at, including the number and extent of any intermediate time periods.
    • Architectural assets to be leveraged
      • Assets created in the previous iterations of ADM cycle within the enterprise
      • Assets available elsewhere in the industry
  • ADM is an iterative process
  • ADM is intended to be used by enterprises in a wide variety of geographies and applied in different vertical sectors / industries.


7. List the main reasons why you would need to adapt the ADM

  • Main reasons for adapting the ADM
    • The order of phases in ADM depends on the maturity of architecture discipline within the enterprise.
    • The possible need to integrate TOGAF with another enterprise framework in use at the enterprise.

8. Explain the need for the ADM process to be governed

  • ADM process should be governed as the architecture board should be satisfied that the ADM is being correctly applied across all phases of an architecture development iteration.

9. Describe the major information areas managed by a governance repository

  • Major information areas managed by governance repository:
    • Reference Data
    • Process Status
    • Audit Information


10. Briefly explain the reasons for scoping an architecture activity

  • Reasons for scoping an architecture activity relate to limits in
    • The organization authority of the team producing the architecture
    • Th objectives and stakeholder concerns to be addressed by the architecture
    • The availability of people, finance and other resources

11. List the possible dimensions for limiting the scope

  • Four dimensions are typically used to define and limit the scope of an architecture
    • Breadth
    • Depth
    • Time period
    • Architecture domains

12. Briefly explain the need for an integration framework that sits above individual architectures

  • Architectures that are created to address a subset of issues within an enterprise require a consistent frame of reference so that they can be considered as a group as well as point deliverables
  • Need for effective standards governance to reduce the need for manual co-ordination and conflict resolution.

TOGAF Learning Outcome: General Definitions

The Candidate must be able to understand and explain the following definitions from Chapter 3:
1. Application

  • A deployed and operation IT system that supports business functions and services.
  • Applications use data and are supported by multiple technology components but are distinct from the technology components.

2. Application Architecture

  • A description of the structure and interaction of applications as groups of capabilities that provide key business functions and manage the data assets.

3. Architecture

  • A formal description of the system, or a detailed plan of the system at component level, to guide its implementation.
  • The structure of the components, their interrelationships and the principles and guidelines governing their design and evolution over time.

4. Architecture Building Block

  • A constituent of the architecture model that describes a single aspect of the overall model.

5. Architecture Development Method

  • The core of TOGAF.
  • A step by step guide to develop and use an enterprise architecture.

6. Architecture Domain

  • The architecture area being considered in a phase. There are 4 domains: B, D, A & T.

7. Architecture Framework

  • A contractual structure used to develop, implement and sustain an architecture.

8. Architecture Principles

  • A qualitative statement of intent that should be met by the architecture.
  • A sound architecture principle has at least a sound rationale and a measure of importance.

9. Architecture Vision

  • A succinct description of the target architecture that describes its business value and the changes to the enterprise that will result from its successful deployment.
  • It serves as an aspirational vision and a boundary for detailed architecture work.

10. Baseline

  • A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

11. Building Block

  • Represents a potentially re-usable component of business, IT or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

12. Business Architecture

  • A definition of the structure and interaction between the business strategy, organization, functions, business processes and information assets.

13. Business Governance

  • It is concerned with ensuring that the business processes and policies deliver the business outcomes and adhere to relevant business regulation.

14. Capability

  • An ability that a person, organization or system possesses.
  • Capabilities are typically expressed in general and high level terms and typically require a combination of organization, people, processes and technology to achieve. e.g. marketing, customer contact, or telemarketing.

15. Concerns

  • The key interests that are crucially important to the stakeholders in a system. and determine the acceptability of the system.
  • Concerns may pertain to any aspect of the system’s functioning, development or operation, including considerations such as performance, reliability, security, distribution and evolvability.

16. Constraint

  • An external factor that prevents an organization from pursuing particular approaches to meet its goals.

17. Data Architecture

  • A description of the structure and interaction of enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources.

18. Deliverable

  • An architectural work product that is contractually specified and in turn formally reviewed, agreed and signed off by the stakeholders.
  • A deliverable represents the output of a project.

19. Enterprise

  • The highest level of description of an organization, typically covers all missions and functions.
  • An enterprise will often span multiple organizations.

20. Foundation Architecture

  • Generic building blocks, their interrelationships with other blocks, combined with principles and guidelines that provide a foundation on which more specific architectures can be built.

21. Gap

  • A statement of difference between two states.
  • Used in the context of gap analysis where the difference between Baseline and Target architecture is identified.


22. Governance

  • The discipline of managing, monitoring and steering a business (or IS/IT landscape) to deliver the desired business outcome.

23. Information

  • Any communication or representation of facts, data or opinion, in any media or form, including textual, graphical, numerical, cartographic, narrative, or audio-visual form.

24. Information Technology (IT)

  • A term commonly assigned to a department within an organization tasked with provisioning some or all of following subject areas: Business Continuity, Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content Management, Hardware, Information Management, Internet, Off-shoring, Networking, Programming and Software, Professional Issues, Project Management, Security, Standards, Storage, Voice and Data Communications

25. Logical

  • An implementation independent definition of the architecture, often grouping related physical entities according to their purpose and structure.

26. Metadata

  • Data about data, of any sort in any media, that describes the characteristics of an entity.

27. Metamodel

  • A model that describes how and with what the architecture will be described in a structured way.

28. Method

  • A defined repeatable approach to addressing a particular type of problem.

29. Methodology

  • A defined, repeatable series of steps to address a particular type of problem
  • Typically centers on defined process, but may also include definition of content.

30. Model

  • A representation of a subject of interest.
  • A model provides a simpler, smaller scale and/or abstract representation of the subject matter.
  • A model is constructed as a ‘means to an end’

31. Modeling

  • A technique through construction of models, which enables a subject to be represented in a form that enables reasoning, insight and clarity concerning the essence of the subject matter.

32. Objective

  • A time-bound milestone for an organization used to demonstrate progress towards a goal.

33. Physical

  • A description for a real-world entity. Physical elements in an enterprise architecture may still be considerable abstracted from the solution architecture, design or implementation views.

34. Reference Model (RM)

  • A reference model is an abstract framework for understanding significant relationships among the entities of an environment, and for the development of consistent standards or specifications supporting that environment.
  • A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.

35. Repository

  • A system that manages all of the data of an enterprise, including data and process models and other enterprise information.

36. Requirement

  • A statement of need that must be met by a particular architecture or work package.

37. Solution Architecture

  • A description of a discreet and focused business operation or activity and how IS/IT supports that operation.
  • A solution architecture typically applies to a single project or project release.

38. Solution Building Block (SBB)

  • A candidate solution that confirms to the specification of an architecture building block (ABB).

39. Stakeholder

  • An individual with interests in, or concerns relative to, the outcome of the architecture.

40. Strategic Architecture

  • A summary of formal description of the enterprise,
  • Provides an organizing framework for operational and change activity.
  • An executive level long-term view for direction setting.

41. Target Architecture

  • The description of the future state of the architecture being developed for an organization.

42. Technology Architecture

  • A description of the structure and interaction of platform services, and logical and physical technology components.

43. Transition Architecture

  • A formal description of one state of the architecture at an architecturally significant point in time.

44. View

  • The representation of a related set of concerns.
  • A view does not have to be graphical or visual in nature.

45. Viewpoint

  • A definition of the perspective from which a view is taken.
  • A view is what you see, and a viewpoint is where you are looking from.
  • It a specification of the conventions for constructing and using a view.



Srinagar Hotels

TOGAF Learning Outcome: Core Concepts

The Candidate must be able to define and explain the following core concepts:
1. The ADM: phase names and the purpose of each phase (high-level)

ADM consists of following phases:

  • Preliminary Phase
    Describes the preparation and initiation activities required to create an architecture capability including customization of TOGAF & definition of Architecture principles
  • Phase A – Architecture Vision
    Describes initial phase of Architecture Development Cycle. It includes information about

    • defining scope of architecture development initiative,
    • identifying the stakeholders,
    • creating Architecture Vision, and
    • obtaining approval to proceed with architecture development.
  • Phase B – Business Architecture
    Describes the development of business architecture to support agreed architecture vision.
  • Phase C – Information Systems Architecture
    Describes development of information systems architectures (Data & Application) to support agreed architecture vision.
  • Phase D – Technology Architecture
    Describes development of technology architecture to support agreed architecture vision.
  • Phase E – Opportunities and Solutions
    In this phase, initial implementation planning is conducted and delivery vehicles for the architecture defined in previous phases are identified.
  • Phase F – Migration Planning
    This phase addresses how to move from the Baseline architecture to Target architecture by finalizing a detailed implementation and migration plan.
  • Phase G – Implementation Governance
    This phase provides an architecture oversight of the implementation.
  • Phase H – Architecture Change Management
    Establishes procedures for managing change to the new architecture.
  • Requirements Management
    Examines process for managing architecture requirements throughout the ADM.

2. The Architecture Content Framework: deliverables, artifacts, and building blocks

  • Deliverable
    A work product that is contractually specified, formally reviewed, agreed and signed off by stakeholders.
  • Artifact
    An architectural work product that describes an aspect of the architecture.Artifacts can be diagrams, matrices or catalogs.
  • Building Block
    It represents a potentially re-usable component of business, IT or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

3. The Enterprise Continuum

The Enterprise Continuum is a view of the architecture repository that provides methods for classifying architecture and solution artifacts as they evolve from Foundation architectures to Organization-specific architectures.
4. The Architecture Repository

An architecture repository stores different classes of architectural output at different levels of abstraction, created by ADM.

5. How to establish and maintain an enterprise Architecture Capability

In order to carry out architectural activity effectively in an enterprise, it is important to put in place appropriate business capability for architecture through organization structuresrolesresponsibilitiesskills and processes. Below diagram shows an overview of TOGAF architecture capability.

6. Establishing the Architecture Capability as an operational entity

Central to the notion of operating an ongoing architecture is the execution of well defined and effective governance, whereby all significant architecture activity is controlled and aligned within a single framework. To this end, an enterprise architecture practice should establish capabilities in following areas:

  • Financial management
  • Performance management
  • Service management
  • Risk management
  • Resource management
  • Communications and stakeholder management
  • Quality management
  • Supplier management
  • Configuration management
  • Environment management

7. How to use TOGAF with other frameworks

TOGAF is a generic framework and is intended to be used in a wide variety of environments. It provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.

TOGAF can be used

  • Either in its own right, with its generic deliverables as outlined.
  • Extend TOGAF deliverables by replacing or extending by a more specific set, defined in any other framework that the architect considers relevant.

TOGAF Basic Concepts

The Candidate must be able to:

1. Describe what an enterprise is
The highest level of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.
2. Explain the purpose of an enterprise architecture 
Enterprise architecture enables effective execution of an organization’s strategy to achieve change.
3. List the business benefits of having an enterprise architecture

  • A more efficient business operation
  • Better return on existing investment, reduced risk of future investment
  • A more efficient IT operation
  • Faster, simpler and cheaper procurement

4. Define what an Architecture Framework is

  • Architecture framework is a foundational structure, or a set of structures, which can be used to develop a wide range of architectures.
  • It should define a method for defining the target state of an enterprise in terms of building blocks, and for showing how the building blocks fit together.
  • It should contain a set of tools
  • It should provide a common vocabulary.
  • It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

5. Explain why TOGAF is suitable as a framework for enterprise architecture (KLP 1.2-5)

TOGAF is suitable because

  • It has been developed through the collaborative efforts of over 300 Architecture forum member companies.
  • Using TOGAF results in enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practices, and gives due consideration both to current requirements and perceived future needs of the business.
  • TOGAF plays an important role in standardizing and De-risks the architecture development process.
  • TOGAF provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which addresses their business issues and needs.

6. Describe the structure of TOGAF, and briefly explain the contents of each of the parts

There are seven parts in TOGAF document

  1. Introduction
    • This part provides a high level introduction to key concepts of enterprise architecture and in particular the TOGAF approach.
    • It contains definitions of terms used throughout TOGAF
    • It contains release notes detailing the changes between this version and previous versions of TOGAF
  2. Architecture Development Method (ADM)
    • This part is the core of TOGAF
    • It describes TOGAF ADM (Architecture Development Method), a step by step approach to developing an enterprise architecture
  3. ADM Guidelines and techniques
    • This part contains a collection of guidelines and techniques available for use in applying TOGAF & TOGAF ADM.
  4. Architecture content framework
    This part describes TOGAF content framework which includes

    • A structured meta-model for architectural artifacts
    • The use of re-usable architecture building blocks
    • Overview of typical architecture deliverables.
  5. Enterprise Continuum and Tools
    This part discusses appropriate taxonomies and tools to categorize and store the output of architecture activity within an enterprise.
  6. TOGAF Reference Models
    This part provides a selection of architecture reference models which includes TOGAF Foundation architecture and III-RM (Integrated Information Infrastructure Reference Model).
  7. Architecture Capability framework
    This part discusses the organization, processes, skills, roles and responsibilities required to establish and operate an architecture function within an enterprise.

7. Briefly explain what TOGAF is

  • TOGAF is an architecture framework.
  • It provides methods and tools for assisting in the acceptance, production, use and maintenance of an enterprise architecture.
  • It is based on an iterative process model supported by best practices and re-usable set of existing architecture assets.

8. Explain what architecture is in the context of TOGAF 
In TOGAF, architecture has two meanings depending upon the context:

  • A formal description of the system, or a detailed plan of the system at component level to guide its implementation.
  • The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.

9. List the different types of architecture that TOGAF deals with

TOGAF deals with

  • Business architecture – Defines business strategy, governance, organization, and key business processes.
  • Data architecture – Describes structure of an organization’s logical and physical data assets and data management resources
  • Application architecture – Provides blueprint for individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
  • Technology architecture – Describes logical software and hardware capabilities that are required to support the deployment of business, data and application services. This includes IT infrastructure, middleware, networks, communication, processes, standards etc.


Hotels in Udhampur, Hotels in Jammu

This post captures TOGAF learning outcomes in an easy to read format. It should serve as a revision guide.

I) Basic Concepts

II) Core Concepts

III) General Definitions

IV) Introduction to the ADM

V) Enterprise Continuum and Tools

VI) ADM Phases (Level 1)

VII) ADM Guidelines and Techniques

VIII) Architecture Governance (Level 1)

IX) Architecture Views, Viewpoints, and Stakeholders

X) Building Blocks

The Candidate must be able to:
1. Define what a building block is, and explain what makes a good building block (KLP 37.2-1)
2. Explain the distinction between Architecture Building Blocks and Solution Building Blocks (KLP 37.2-2)
3. Briefly explain the use of building blocks in the ADM cycle (KLP 37.3-1)
4. Describe the characteristics of an Architecture Pattern (KLP 25.1-1)


XI) ADM Deliverables

The Candidate must be able to:

1. Briefly explain the role of architecture deliverables across the ADM cycle (KLP 36.1-1)
2. Briefly explain the purpose of the following deliverables (KLP 36.2-1):

o Architecture Building Blocks

o Architecture Contract

o Architecture Definition Document

o Architecture Principles

o Architecture Repository

o Architecture Requirements Specification

o Architecture Roadmap

o Architecture Vision

o Business Principles, Business Goals, and Business Drivers

o Capability Assessment

o Change Request

o Communications Plan

o Compliance Assessment

o Implementation and Migration Plan

o Implementation Governance Model

o Organizational Model for Enterprise Architecture

o Request for Architecture Work

o Requirements Impact Assessment
o Solution Building Blocks
o Statement of Architecture Work
o Tailored Architecture Framework

Note: It is expected that at least some of these deliverables would be covered as part of the learning in other units


XII) TOGAF Reference Models (Level 1)

The Candidate must be able to:
1. Explain the role of the TRM as a Foundation Architecture (KLP 43.1-2, 43.3-1)
2. Describe the major characteristics of a Foundation Architecture (KLP 43.1-1)
3. Briefly explain the basic concepts of the III-RM (KLP 44.1-1)
4. Briefly explain the relationship of the III-RM to the concept of Boundaryless Information Flow (KLP 44.1-2)


XIII) TOGAF Certification Program

The Candidate must be able to:
1. Explain the TOGAF Certification program, and distinguish between the levels for certification

The fundamental difference between the campaigns of BJP & AAP is the same as that between organic & inorganic growth.

Anyone who has ever used google adwords will know the difference. Inorganic growth is like a sponsored growth with the hope that you become popular enough to withdraw the sponsorship eventually and let the popularity take its own course.

Organic growth is like fire. It has the potential of becoming a wild bush fire or equally die down anonymously, if there isn’t enough ‘ground’ support. More often that not, the momentum built using organic growth is sustained over a very long term, provided the fundamentals stay constant.

AAP’s success on the ground has been mostly led via organic growth. Whereas, BJP’s growth resembles a lot like inorganic growth. That is not to say that ALL of BJP’s growth is inorganic. But, with an alleged budget of 5000 crore, it is not totally false to claim that a lot of it is sponsorship driven.

Phase A: Architecture Vision

Stakeholder Map Matrix
  • Identifies the stakeholders
  • Their influence over the process
  • Their concerns that the architecture needs to address
Value Chain Diagram
  • High level orientation view of an enterprise
  • How enterprise interacts with the outside world
  • Allows high level execs to be quickly on boarded
  • Allows aligning stakeholders for a particular change initiative
  • Focuses on presentational impact
Solution Concept Diagram
  • Provides a high level orientation of the solution that is envisaged in order to meet the objectives of architecture engagement.
  • Not a formal document but a ‘pencil-sketch’ of the expected solution.
  • It highlights areas to be more formally investigated
  • Provides clarity to the execs in terms of the goals of the architecture engagement

Phase B: Business Architecture

Organization / Actor Catalog
  • Definite list of all participants that interact with IT
  • Referenced while developing requirements to test for completeness
  • Entities: Organization Unit, Actor & Location
Driver/Goal/Objective Catalog
  • Provides cross organizational reference of how an organization meets its drivers through its goals, objectives and (optionally) measures.
  • Entities: Organization unit, drivers, goals, objectives, measures(optional)
Role Catalog
  • Provides listing of all authorization levels within an enterprise
  • Serves as an input into identifying organizational change management impacts, defining job functions and executing end-user training.
  • Entities: Role
Business Service / Function Catalog
  • Provides functional decomposition in a form that can be filtered, reported on and queries.
  • Provides supplement to graphical functional decomposition diagrams
  • Entities: Organization Unit, Business service, Business function, Information System service (Optional)
Location Catalog
  • Provides listing of all locations where an enterprise does business OR hosts architectural assets
  • Entities: Location
Control/Product Catalog
  • Provides hierarchy of processes
  • Provides events that trigger processes
  • Provides output from processes
  • Provides controls applied to the execution of processes
  • Supplement to the Process Flow Diagrams
  • Allows enterprise to see relationships of Processes to Sub-processes in order to identify full chain of impacts resulting from changing a high level process
  • Entities: Process, Event, Control, Product
Contract/Measure Catalog
  • Provides listing of all agreed service contracts & (optionally) measures attached to those contracts
  • Forms master list of Service Levels across enterprise
  • Entities: Business Service, Information System Service, Contract, Measure
Business Interaction Matrix
  • Shows relationships between organizations and business units across the enterprise
  • Helps highlight value chain and dependencies across organizations
  • Entities: organization, Business Function, Business Service, Business Service communicates with Business Service relationships, Business Service is dependent on Business Service relationships
Actor / Role Matrix
  • Shows which actor performs which role
  • Entities: Actor, Role, Actor performs Role relationships
Business Footprint Diagram
  • Describes links between business goals, organizational units, business functions and services
  • Maps the above to technical components delivering required capability
Business Service / Information Diagram
  • Shows information needed to support a business service
  • Shows what information is product/consumed by a business service
Functional Decomposition Diagram
  • Shows capabilities of an enterprise that are relevant to the consideration of an architecture.
Product Lifecycle Diagram
  • Shows life cycle of key entities within an enterprise
Goal / Objective / Service Diagram
  • Defines the ways in which a service contributes to the achievement of a goal or objective(business vision/strategy)
Business Use-case Diagram
  • Displays relationships between consumers and providers of business services.
Organization Decomposition Diagram
  • Describes links between actor, roles and locations within an organization tree
Process Flow Diagram
  • Shows sequential flow of control between activities
Event Diagrams
  • Shows relationship between events and process.

Phase C: Information Systems Architecture – Data Architecture

Data Entity / Data Component Catalog
  • Shows a list of all the data used across the enterprise
  • Includes data entities as well as the data components where the entities are stored.
  • Entities: Data Entity, Logical Data Component, Physical Data Component
Data Entity / Business function Matrix
  • Shows relationship between data entities and the business functions which access the data entities
Application / Data Matrix
  • Shows relationship between applications and the data entities that are accessed/updated by them.
Conceptual Data Diagram
  • Shows conceptual relationship between critical entities in an enterprise
  • Addresses concerns of business stakeholders
  • Uses Entity relationship models & simplified UML class diagrams
Logical Data Diagram
  • Logical view of the relationships between critical data entities in an enterprise
  • Addresses concerns of application developers & database designers
Data Dissemination Diagram
  • Shows relationship between data entities, business service and application components.
  • Shows how logical entities are to be physically realized by application components
Data Security Diagram
  • Shows how enterprise data is kept safe and access is suitably controlled.
  • Shows which actor/role can access which data entity
  • Can be used to show legislation compliance
Data Migration Diagram
  • Shows flow of data from source to target applications
  • Concerned with data cleansing, de-duplication, standardization, normalization etc.
Data Lifecycle Diagram
  • Shows the lifecycle of data entities across an enterprise
  • Separation of data from process allows data to be treated as first class citizen and helps identify common data requirements
Phase C: Information Systems Architecture – Application Architecture
Application Portfolio Catalog
  • Identifies and maintains a list of applications in the enterprise
  • Entities: Information System Service, Logical Application Component, Physical Application Component
Interface Catalog
  • Scopes and documents interfaces between applications
  • Enable overall dependencies between applications to be scoped
  • Entities: Logical Application Component, Physical Application Component, Application communicates with Application relationship
Application / Organization Matrix
  • Shows relationship between applications and the organization units within the enterprise
  • It is a matrix showing Logical / Physical application components on one side axis and Organizational units on the other axis.
Role / Application Matrix
  • Shows relationship between the applications and the roles within the enterprise that use them.
  • 2-dimensional matrix showing applications on one axis, and role on the other axis.
Application / Function Matrix
Application Interaction Matrix
Application Communication Diagram
Application and User Location Diagram
Application Use-Case Diagram
Enterprise Manageability Diagram
Process / Application Realization Diagram
Software Engineering Diagram
Application Migration Diagram
Software Distribution Diagram

Phase D: Technology Architecture

Technology Standards catalog
  • Documents the agreed standards for technology across the enterprise covering:
    Technology life cycles, and
    Refresh cycles for the technology.
  • Provides snapshot of the enterprise standard technologies that are deployed
    or can be deployed.
  • Helps identify the discrepancies across the enterprise.
  • Entities:
    Platform Service,
    Logical Technology Component,
    Physical Technology Component.
Technology Portfolio catalog
  • Identifies and maintains a list of all the technology in use across enterprise
  • Includes hardware, infrastructure software & application software
  • Provides foundation on which to base remaining matrices and diagrams
  • Typically the starting point of the technology architecture phase.
  • Entities referred to include:
    Platform service,
    Logical Technology Component, and
    Physical Technology Component.
Application / Technology Matrix
  • Documents mapping of applications to technology platform.
  • This matrix shows:
    Logical / Physical Application Components,
    Services, Logical and Physical Technology Components, and
    Physical Technology Components realizes Physical Application Components.
Environment and Locations Diagram
  • Depicts which location hosts which applications.
  • Identifies what technologies and/or applications are used at which locations.
  • Identifies the locations from which business users interact with the applications.
Platform Decomposition Diagram
  • Depicts the technology platform that supports the operations of the Information Systems architecture.
  • Covers all aspects of the infrastructure platform.
  • Provides an overview of the enterprise’s technology platform.
  • It can simply be an informal ‘eye-chart’ providing an overview of the technology environment.
  • May show details of the specifications such as Product versions, #CPUs.
Processing Diagram
  • Shows how deployable units of code/configuration are deployed onto the technology platform.
  • A deployable unit represents a business function, service or application components.
  • This diagram addresses
    – Which set of application components need to be grouped to form a deployable unit.
    – how one deployable unit connects to another
    – how app config & usage requirements generate load or capacity requirements for different technology components.
Networked Computing / Hardware Diagram
  •  This diagram shows ‘as deployed’ logical view of the logical application components in a distributed network computing environment.
Communications Engineering Diagram
  •  This diagram shows the means of communication – the method of sending and receiving information – between assets in the Technology Architecture.

Phase E: Opportunities and Solutions

Process Context Diagram
Benefits Diagram