02 Content framework

  • SystemSystem is a set of Components which are Organized together to perform single or multiple functions
  • Architecture – Is the systems fundamental organization, embodied in its components, their relationship to each other, and to the environment, and the principles guiding their design and evolution over a period of time
  • Architecture DescriptionSet or Collection of Artifacts which describe the Architecture
  • Stakeholders – They are the people who have key roles in the Organization Business and who may have specific view or concerns that needs to be addressed
  • Concerns – Key ares of interest by the stake holders , which are crucial for the Business
  • View – Is a representation of the System modelled to address the concerns of the stake holder
  • Viewpoint – Represents the perspective from which the view point is taken

ADM Phase and Viewpoints

  1. Preliminary Phase – Principles Catalog
  2. Architecture Vision Phase – Stakeholder Map, Value chain diagram , Solution Concept Diagram
  3. Business Architecture Phase – Actors and roles, Business Services and Functions catalog, Location Catalog, Business Footprints, Business Process, Use case and Events Diagrams
  4. IS – Data Architecture Phase – Data Entity, Data Business Map, Data Security, Logical and Physical Data Models,Data Migration, Data Life cycle
  5. IS – Application Architecture Phase – Application Portfolio, Applications Catalog, Application Interaction, Application Communication, Software Engineering, Software Distribution, Application Migration Diagrams
  6. Technology Architecture – Technology Standards, System – Technology Matrix, Environment and Location Diagrams, Platform Decomposition diagrams, Network diagrams, communication engineering diagrams
  7. Opportunities and Solution phase – Project Context diagrams , benefits diagram
  8. Requirement Management Phase – Requirements catalog

Whats New in TOGAF 9 ?

  1. Architecture Partitioning, Content Framework, Architecture Repository
  2. Capability Based Planning, (don’t do if you are not capable of doing it)
  3. Business Transformation Readiness (Ensure that you are ready before you do it)
  4. Stakeholder Management (How to deal with whom, who is more important , who can influence, who can impact final decisions etc)
  5. Using TOGAF for Security Architecture and SOA [ Service Oriented Architecture]

TOGAF 9  Structure?

  1. Introduction
  2. ADM [ Architecture Development Method ]
  3. ADM – Guidelines and Techniques
  4. CF [Architecture Content Framework]
  5. Tools [Enterprise Continuum and Tools]
  6. RM [TOGAF Reference Model]
  7. Capabilities [Architecture Capability Framework]

1 Introduction

  • Introduction to key Concepts of EA and TOGAF approach
  • Definition of Terms


  • Core TOGAF,
  • Step by Step guide to Develop EA

3 ADM Guidelines and Techniques

  • Guidelines on ADM, to be discussed later

4 Architecture Content Framework

  • Architecture Building Blocks
  • Architectural Deliverables e.g Architecture Vision Document

5 Enterprise Continuum and Tools

  • Continuum theories or models explain variation as involving a gradual quantitative transition without abrupt changes or discontinuities. It can be contrasted with ‘categorical’ models which propose qualitatively different states
  • Tools needed for Architecture work, e.g it can be Content Repository Software to manage and version control documents

5 TOGAF Reference Model

  • to be discussed later

6 Architecture Capability Framework

  • Organizational Process, People Skill , Resources needed so that an Organization is capable of Implementing the Architecture Framework
  • for e.g if new Architecture proposed to use Online Billing , it has to ensure that its Operators are trained to handle online billing systems and have no problems with online systems, so that productivity is not hit.

what are Deliverables, Artifacts and Building Blocks ?

what are Artifacts : Artifacts a more granular architectural work product that describes an architecture from a specific viewpoint. Examples include a network diagram, a server specification, a use-case specification, a list of architectural requirements, and a business interaction matrix. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository. Artifacts are further broken down into

  • Catalogs, e.g can be Organizational Chart, Locations of Business Units,
  • Diagrams, all below shown diagrams such as network , use case, environment diagram etc
  • Matrices, e.g CRUD Matrix on a particular data table and actors ,

Network Diagram example

Server Specification example

  • Dual Intel Xeon Processor 3.2GHz with 1MB Cache
  • 4 GB SDRAM
  • Dual 72 GB SCSI Drive (for the operating system)
  • RAID Mirroring (for the operating system)
  • Dual Power Supplies
  • Dual Gigabit Network Adapters

Use Case Specification example

Artifacts v/s ADM Phases 0 . Preliminary Phase Artifacts :


  1. Principles Catalog e.g Business Principles , Technology Principles, Architecture Principles,
  2. e.g Business Principles can be ” We follow the law and respect law at each country as they exists in the country that we work with”
  3. e.g Technology Principles can be “We follow Open standards softwares to an extent its possible unless we need to buy out something to support our business”
  4. e.g Architecture Principles can be “Documents / Emails will be retained at-least for a period of 5 years and there will efficient Business Continuity Architecture in place “

A . Architecture Vision Artifacts :

  1. Stake holder Map matrix , write down who is highly important, who needs to be kept highly satisfied , who is influential, who can take decision to disrupt the entire work, whose acceptance is required etc.
  2. Value Chain Diagram: Below fig shows typical Demand Generation and Demand fulfillment Scenario of Value Chain Diagram
  3. Solution Concept Diagrams : Sometimes Conceptual Solutions at very high level becomes guidelines to understand how the business would function and what are the goals the architect needs to cover, Solution Concept Diagrams might not have exact hardware / software / network systems in place but still they help us understand how the business plans to operate and their vision

B . Business Architecture Artifacts :

  1. Business foot print diagram

The above example shows how the bottles are manufactured at one unit , ingredients are produced / procured at another unit ( can also be a storage unit), how manufacturing takes place, distribution process , logistics, retailers, and vending machines , how the end user would get the packaged drink , this is very good example 2. Business Level Functional Charts  

3. Product lifecycle diagram

C . Information System Architecture [Data+Applications] Artifacts :

  1. Data Models ( it can be simple ER Diagrams explaining , entities, relationships, and views )

2. Data Dissemination Diagrams 3. Business Function Matrix ( who has access to which part of data , what sort of access, CRUD Operation details )

4. Data Matrix

5. Application Portfolio Catalog : (The purpose of this catalog is to identify and maintain a list of all the applications in the enterprise. This list helps to define the horizontal scope of change initiatives that may impact particular kinds of applications. An agreed Application Portfolio allows a standard set of applications to be defined and governed) 6. Application Interaction Matrix: (The purpose of the Application Interaction matrix is to depict communications relationships between systems (i.e., application components) 7. Application Communication Diagram: (The purpose of the Application Communication diagram is to depict all models and mappings related to communication between applications in the meta model entity.) 8. Software Engineering Diagram:  (The Software Engineering diagram breaks applications into packages, modules, services, and operations from a development perspective.)

 9. Communication Diagram:  (The Communications Engineering diagram describes the means of communication – the method of sending and receiving information – between these assets in the Technology Architecture; insofar as the selection of package solutions in the preceding architectures put specific requirements on the communications between the applications.) 10. Networked Computing/Hardware Diagram: D . Technology Architecture Artifacts :

  1. Technology Portfolio Catalog  (The Technology Portfolio catalog contains the following metamodel entities Platform Service, Logical Technology Component, Physical Technology Component)

  1. Technology Standards Catalog
  2. System/Technology Matrix
  3. Environment and Locations Diagram (The Environments and Locations diagram depicts which locations host which applications, identifies what technologies and/or applications are used at which locations, and finally identifies the locations from which business users typically interact with the applications.)
  4. Platform Decomposition Diagram (The Platform Decomposition diagram depicts the technology platform that supports the operations of the Information Systems Architecture. The diagram covers all aspects of the infrastructure platform and provides an overview of the enterprise’s technology platform. The diagram can be expanded to map the technology platform to appropriate application components within a specific functional or process area. This diagram may show details of specification, such as product versions, number of CPUs, etc. or simply could be an informal “eye-chart” providing an overview of the technical environment.)

E . Opportunities and Solutions :

  1. Project Context Diagram (A Project Context diagram shows the scope of a work package to be implemented as a part of a broader transformation roadmap. The Project Context diagram links a work package to the organizations, functions, services, processes, applications, data, and technology that will be added, removed, or impacted by the project.)
  2. Benefits Diagram (The Benefits diagram shows opportunities identified in an architecture definition, classified according to their relative size, benefit, and complexity. This diagram can be used by stakeholders to make selection, prioritization, and sequencing decisions on identified opportunities.)

O . Requirements Management :

  1. Requirements Catalog (Requirement,  Assumption, Constraint, Gap)

what are Building Blocks : A 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. for example it can be a complete use case document for “Call Logging System” where there would be set of Artifacts such as Use case and network diagrams etc. e.g can be Roles, Actors, Use Case, Data Entry and Read Screens , Application Components , Technology Components , these building can also be used else where in another use case document or any other deliverable document Building Blocks are further classified as

  • ABB [Architectural Building Blocks] ,  Architecture Related
  • SBB [Solution Building Blocks], Overall Solution Related, Architecture can be a part of over all solution

Architecture Building Blocks [ABB]

  • Relate to Architecture Continuum
  • They gather requirement from – Business, Data, Application and Technology perspective
  • They guide Solution Build up or Solution Building Blocks
  • They define clarity on chosen APIs, Protocols, Interfaces, Data formats, Hardware standards etc
  • Interoperability & Relation between other Building Blocks
  • Building Blocks map to Business Entities and Policies

Solution Building Blocks [SBB]

  • Relate to Solution Continuum
  • Solutions can be built up / home grown / or procured
  • Details are more at Interface level than to core APIs levels (as in case of ABBs)
  • Performance, Configurations , hardware software standards needed to run these solutions
  • Relationship between ABBs and SBBs

What are Deliverables: A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders, example , can be Statement of Work Document for “Call Logging System” which includes references to many Building Blocks and artifacts

Content Meta Model Architecture Principles, Vision and Requirements -> Orange Block Some of the important documents / content which goes into repository are

  • Principles such as Business Principles, Technology Principles, Architecture Principles etc
  • Gaps , e.g Gap Analysis reports, requirements that lead to Architecture work
  • Constraints, e.g Skill sets with the Organization, Budgets to be allocated
  • Scope and Out of Scope
  • Assumptions, such as the following versions of softwares wont be out dated till the end of architecture phase, integration possibilities with home grown applications
  • Requirements e.g, Merger with other Business Units, Aquisition of new Business, expansion of business in new geographies etc
  • Capabilities, e.g Organization capabilities with to deal with Business Changes, Adapt to new Technologies
  • Stake Holder list, Org Chart