TOGAFTM 9 and MODAF artifact templates

The “TOGAF Explained” section of the Avancier web site http://avancier.co.uk contains a paper “TOGAF Content

Framework” that introduces TOGAF deliverables, artifacts and architectural entities.

• An artifact is a view or model that shows architectural entities in relation to each other. It may take the

form of a catalog (list), matrix (table), or diagram

• An artifact type (or view point) is a template for an artifact.

This paper discusses the architecture artifacts in some detail. It illustrates most of the artifacts using tabular

templates or examples drawn from MODAF.

This paper is published under the terms of the licence summarised in the footnote. However, Avancier will send

you a pdf version of this document on request - in return for any short and presentable example of any Phase D

artifacts, or any criticism that helps to improve this free resource.

On the Avancier Method artifacts Both TOGAF and MODAF offer a curate’s egg set of artifacts, a mix of good and not-so-good. Both are vague

about the distinction between system/component decomposition and process decomposition. So the artifacts in the

Avancier Method overlap with, but are not the same as, those in this document.

On the MODAF artifacts Most of the 38 MODAF artifacts – those which can reasonably be mapped to TOGAF artifacts - are included here.

On the TOGAF artifacts All the artifacts in TOGAF 9 chapter 35 are represented here in tabular form. One aim is to help you understand

TOGAF’s rather abstract narrative description of these artifacts. The architectural entities (or building blocks)

shown in the tables are those suggested by TOGAF.

On the diagrams

The diagrams are converted here into a tabular form.

This may prove useful if you have only limited drawing tools. And it avoids debate about notations.

But the main reason is to expose the meta model, because that matters much more the diagram notations.

On the official courseware samples

Do compare each table with the official sample artifact slide in the courseware on the Open Group web site.

You’ll find many differences. And some difficulties are noted in the document. However, as the courseware

document says: “The exact format of the catalogs, matrices and diagrams will depend on the tools used and

adaptations for the specific EA.”

The table below contains the names of TOGAF artifact types, listed under the phase that produces them. Phase A: Architecture

Vision artifacts

Phase E Opportunities and

Solutions Artifacts

Stakeholder Map Matrix Project Context Diagram

Value Chain Diagram Benefits Diagram

Solution Concept Diagram

Phase B Business

Architecture artifacts

Phase C Data Architecture

artifacts

Phase C Application

Architecture artifacts

Phase D Technology

Architecture artifacts

Organization/Actor Catalog Data Entity/Data Component

Catalog

Application Portfolio Catalog Technical Reference Model

Driver/Goal/Objective

Catalog

Interface Catalog Technology Standards

Catalog

Role Catalog Technology Portfolio Catalog

Business Service/Function

Catalog

Location Catalog

Process/Event/Control/

Product Catalog

Contract/Measure Catalog

Business Interaction Matrix Data Entity/Business

Function Matrix

System/Organization Matrix System/Technology Matrix

Actor/Role Matrix System/Data Matrix Role/System Matrix

System/Function Matrix

Application Interaction

Matrix

Business Footprint Diagram Class Diagram Application Communication

Diagram

Environments and Locations

Diagram

Business Service/Information

Diagram

Data Dissemination Diagram Application and User

Location Diagram

Platform Decomposition

Diagram

Functional Decomposition

Diagram

Data Security Diagram (or

matrix)

System Use-Case Diagram Processing Diagram

Product Lifecycle Diagram Data Migration Diagram Enterprise Manageability

Diagram

Networked

Computing/Hardware

Diagram

Goal/Objective/Service

Diagram

Data Lifecycle Diagram Process/System Realization

Diagram

Communications Engineering

Diagram

Business Use-Case Diagram Class Hierarchy Diagram Software Engineering

Diagram

Organization Decomposition

Diagram

Application Migration

Diagram

Process Flow Diagram Software Distribution

Diagram

Event Diagram

Notice that 90% of the artifacts are produced during phases B, C and D, and may be copied into the Architecture

Definition Document deliverable.

Note there is much duplication and overlaps between artifacts. Suppose you want to document the deployment of

application software to computers, and locations. You could end up repeating the information in 6 artifacts. This is

discussed in a later section.

The TOGAF artifacts are illustrated using tables and MODAF examples in the following pages.

Phase A: Architecture Vision artifacts It is OK that we have two one-page cartoon-like artifacts; there is a place for management consultants to draw

informal rich pictures. These appear to make up two thirds of the artifacts output from this phase, when

stakeholders will want much more detail. But in practice, phase A will produce initial versions of artifacts from

phases B through to F.

Stakeholder Map Matrix This is more a catalog than a matrix.

Stakeholder Map

Matrix

Concerns Power Interest Communication Plan

Chief Information

Officer

IT Budget, Demonstrable

Benefits

High Low

Design Authority Justification of Role Medium Medium

Business Manager Business continuity High Medium

Business Users Usability Low High

Looking at the official TOGAF sample: it is OK except that it is a catalog rather than a matrix

Value Chain Diagram

A cartoon: a high-level orientation view of an enterprise, how it interacts with the outside world.

Solution Concept Diagram A cartoon: a high-level orientation of the solution that may embody key objectives, requirements, and constraints

for the engagement and may highlight work areas to be investigated with formal architecture modeling.

Looking at the official TOGAF sample: this is Porter’s original meta diagram rather than an example.

Looking at the MODAF artifacts, the closest comparator is the OV-1a High Level Operational Concept.

MODAF also includes an artifact that is equivalent to TOGAF’s Architecture Vision deliverable – that is the AV-

1 Overview and Summary Information.

Phase B: Business Architecture artifacts Looking at the official TOGAF sample in phase B; it is difficult to present them with conviction. Several seem not

to reflect the TOGAF meta model.

Organization/Actor Catalog Surely better to show role (the type) here rather than actor (the individual).

Organization/Actor Catalog Optional

Organisation Actor Location

Sales Joe Henderson Customer Site

Sales Patrick Mancini Home Address

Sales Salesforce.com Data Centre

Driver/Goal/Objective Catalog Not sure the organisation unit should be first. Measures might be attached to goals as well as objectives.

Driver/Goal/Objective Catalog

Organisation Unit Driver Goal Objective

Sales Competitor A USP Match USP tbd

Sales Competitor B Price Beat Cost tbd

Role Catalog

Roles Functions performed Training required

Salesman Capture customer orders tbd

Salesman Maintain customer relationship tbd

Personal Assistant Maintain salesman diary tbd

Business Service/Function Catalog There is universal confusion in the industry between Business Capability, Business Function and Business Service.

So it is no surprise that TOGAF sometimes uses the terms interchangeably. If you want to know how to resolve

this confusion, read “What is a Business Function?”, “Architecture meta meta concepts” and “Is Business

Capability needed?” in the Library at http://avancier.co.uk

Business Service/Function Catalog Optional

Organisation Unit Business Function Business Service Information System

Service

Sales Customer Relationship

Mngmnt

Promotion Monthly Email Advert

Sales Order Capture Order Capture Order Capture

Looking at the MODAF artifacts, the closest comparator appears to be the StV-5 Capability to System Deployment

Mapping, shown below.

Location Catalog

Locations Business functions End-user computers Servers

Customer Site Order Capture Lap Top tbd

Head Office Fulfilment Direction PC tbd

Process/Event/Control/Product Catalog

Process/Event/Control/Product Catalog

Process Event [Input] Control [Precondition] Product [output]

Order Closure Order Confirmation Price agreed, Stock Available Order Closed

Fulfilment Instruction End of Day Order Closed Instruction Messages

Contract/Measure Catalog

Contract/Measure Catalog Optional

Business or IS Service Service Contract Measure

Customer Look Up tbd tbd

Monthly Email Advert tbd tbd

There isn’t enough room to record a service contract in this table. And really, measures should be included in the

contract itself.

Business Interaction Matrix Notice that various entity types could be shown in the rows and columns. This suggests several alternative

matrixes could be drawn.

Business

element

Matrix

Organization Business

Function

Business

Service

Business

Service

Organization

Business

Function

Business

Service

Communicates

with

Business

Service Is dependent on

Looking at the official TOGAF sample: Better if the rows and columns show Business Functions, and Business

Services are in the cells.

Looking at the MODAF artifacts, the closest comparators are the StV-4 Capability Clusters, shown below.

And the OV-3 Operational Information Exchange Matrix, shown below.

Actor/Role Matrix

Role

Actor Matrix

Salesman Customer Contact

Joe Henderson performs

Patrick Mancini performs

Salesforce.com performs

Looking at the official TOGAF sample: The Actors are really Roles. The Roles are really Work Packages or

Activities.

Business Footprint Diagram (shown in tabular form)

There are probably too many entities and relationships for a table. This makes better sense as a high-level cartoon.

The intent is to get high level decision makers makes to recognise the problems; you need one easy diagram to

show the “enterprise”.

Business Footprint Met through Offered by Which perform Using these

Business Services Organisation

Units

Business

Functions

Technical

Components

Generate income Kitchen

Refurbishment

Kitchen Sales

Division

Order Capture Lap top, Back office

applications

Generate income Haircut, Hairwash,

Manicure

Barber Shops Barbering Shampoo, Scissors,

Chair, etc.

Business Service/Information Diagram (shown in tabular form)

Information Data Entities Data Sources Data Entities

Business Service Consumes From And Produces

Order Capture Stock Item Price ERP System Order

Monthly Email Advert Promotion CRM System Email

Looking at the official TOGAF sample: Again, this shows Business Functions rather than Business Services. since

TOGAF blurs the distinction.

Functional Decomposition Diagram Looking at the official TOGAF sample: a very obscure (SAP-specific) form is used for representation. Top layer

columns are organisation units. The horizontal bars are functions and sub-functions i.e. decomposition. The tool

enables you to drilldown to specific defined “services” (really “functions”).

Looking at the MODAF artifacts, the closest comparators are the StV-2 Capability Taxonomy, shown below.

And the SV-4 System Functionality Description, shown below.

Product Lifecycle Diagram (shown in tabular form) Especially useful where products must be tracked from manufacture to disposal, for security or environmental

reasons (e.g. credit/debit/loyalty/smart cards and other identity cards, passports).

Product: Credit Card Moves from To As result of

Prior State Next State Event [Condition]

Requested Posted Posting

Posted Authorised First successful transaction

Authorised Barred Customer loss report

Looking at the official TOGAF sample: this represents a misunderstanding of the artifact.

Looking at the MODAF artifacts, the closest comparator is the OV-6b Operational State Transition Diagram,

shown below.

Goal/Objective/Service Diagram (shown in tabular form)

Goal/Objective/Service Catalog

Business Service Driver Goal Objective

Business Service Driver Goal Objective

Business Use-Case Diagram Nothing to say here that adds to industry norms.

Organization Decomposition Diagram Looking at the MODAF artifacts, the closest comparator is the OV-4 Organisational Relationships Chart, shown

below.

Process Flow Diagram Looking at the official TOGAF sample: such a vacuous cartoon makes it look like TOGAF is written by or for a

management consultant.

Looking at the MODAF artifacts, the closest comparator is the OV-5 Operational Activity Model, shown below.

Event Diagram To depict the ‘‘business events’’ or simply ‘‘events’’ that trigger a process and generate a business response or

result.

Phase C: Data Architecture artifacts

Data Entity/Data Component Catalog

Data Entity/Data Component Catalog

Data Entity Logical Data Component Physical Data Component

Data Entity Logical Data Component Physical Data Component

Data Entity/Business Function Matrix

It would surely be better not to show Business Functions and Organisation Units in the same matrix; they would be

confused.

Business Function

Data Entity

Business Function Org Unit

Data Entity CR by

Data Entity CRUD by Owned by

System/Data Matrix System means application here.

Application

Data

Logical Application Component Logical Application Component

Data Entity CR by CRUD by

Data Entity CRUD by R by

Class Diagram (shown in tabular form)

It is a shame that both TOGAF and MODAF confuse class diagrams with data models. TOGAF interprets class as

data entity.

Class Diagram

Entity Is related to Entity

Entity Is related to Entity

Entity Is related to Entity

The MODAF equivalent artifact is the OV-7 Logical Data Model, shown below.

Data Dissemination Diagram (shown in tabular form) Again, notice that two entity types could be shown in the columns. This suggests several alternative matrixes could

be drawn..

Data Dissemination Business Services Physical Application Components

Data Entity

Data Entity

Data Security Diagram (or matrix) Surely better to show role (the type) here rather than actor (the individual).

Data Entity Data Entity

Actor

Actor

Data Migration Diagram (shown in tabular form) The tabular form isn’t great here. Better draw a diagram with arrows from sources to targets.

Data sources (baseline

applications or

databases)

Stage 1:

Extract

Stage 2:

Profile

Stage 3:

Transform

Stage 4:

Load Target (applications or

databases)

Application A CRM

Application B ERP

Application C Billing

Application D Data Warehouse

Transform may include: Standardize, normalize, de-duplicate source data (data cleansing); Match, merge, and

consolidate data from different source(s); and Source-to-target mappings.

Data Lifecycle Diagram (shown in tabular form)

Entity Moves From To As result of

Prior State Next State Event [Condition]

Requested Posted Posting

Posted Authorised First successful transaction

Authorised Barred Customer loss report

Looking at the MODAF artifacts, the closest comparator is the SV-10b Systems State Transition Description,

shown below.

Class Hierarchy Diagram Class hierarchies are often bad practice in data models (“How the Fuzziness of the Real-World Limits Reuse by

Inheritance Between Business Objects.” in OOIS 1995: 3-18)

Here, a class is a domain/data entity (not an OO class). For example, the table below represents the official sample

diagram.

Subtype class Subtype class Subtype class Super type class

Authorised User

Vehicle Tester

Trainer/Booker

Taxi Driver

Driving Instructor

Driving Examiner

Driver

Individual

Driving Examiner

Manufacturer

Operator

Dealing

Organisation

Keeper

Purchaser/Nominee

Customer

What is an enterprise architect to do with this? It might be a cartoon for discussion, but it is not a good domain or

data model.

If the subtypes are mutually exclusive, then (e.g.) a vehicle tester cannot be a driver.

If it is an inheritance tree, then (e.g.) a taxi driver must have a customer id, along with all other customer attributes

and behaviour.

With multiple inheritance you could make customer, individual, organization and driving instructor all top level

classes and create subtype classes like driving-instructor-individual and driving-instructor-organization.

But is generally unwise to draw inheritance relationships between persistent business entity types.

Generally speaking, most of the subtypes would be better modelled as roles along these lines.

Entity Relationship Entity

Organisation Employs Individual

Organisation Plays Role (customer, manufacturer,

examiner etc.)

Individual Plays Role (customer, taxi driver,

examiner etc.)

Role Is entitled to perform Action

Role Is a subtype of Role

Phase C Application Architecture: artifacts

Application Portfolio Catalog My idea of an application portfolio catalog content is very different from the one suggested by TOGAF below.

Application Portfolio Catalog

Information System Service is logically provided by is realised in

Logical Application Component Physical Application Component

Customer Look Up CRM Salesforce.com

Monthly Email Advert CRM Salesforce.com

Stock Availability ERP SAP

Interface Catalog Surely better to have two versions of this, since physical applications can’t talk to logical ones?

Interface Catalog

Logical Application Component

(CRM)

communicates with Logical Application Component

(ERP

Physical Application Component

(Seibel)

communicates with Physical Application Component

(SAP)

If you want to map how a logical application (say CRM) is physically realised (say an instance of SalesForce.com

running as part of their SaaS data centre etc etc), you need a distinct matrix.

System/Organization Matrix System means application here.

Org Unit

Physical Application Component

Sales Delivery

Salesforce.com

SAP

Role/System Matrix System means application here.

Role

Application

Salesman Product Manager

CRM

ERP

System/Function Matrix System means application here.

Function

Application

Sales Fulfillment

CRM

ERP

Looking at the MODAF artifacts, there is something that appears to be comparator - the SV-5 Operational Activity

to Systems Functionality Traceability Matrix, shown below. This appears to be the same – but isn’t.

Application Interaction Matrix Application Service probably means Information System Service.

Notice that various entity types could be shown in the rows and columns. This suggests several alternative

matrixes could be drawn.

Application

Application

Application Service Logical Application

Component

Physical Application

Component

Application Service consumes

Logical Application

Component

communicates with

Physical Application

Component

communicates with

Looking at the MODAF artifacts, the closest comparator is the SV-3 Systems-Systems Matrix, shown below.

Application Communication Diagram (shown in tabular form) This is essentially a data flow diagram. Data stores, perhaps even data entities, may be shown.

Application

Interface

CRM ERP Data Entities in the

interface

Customer Import Customer

Looking at the MODAF artifacts, the closest comparator is the SV-6 System Data Exchange Matrix, shown below.

Application and User Location Diagram (shown in tabular form) The intent of this diagram is really the first two columns. The third belongs in the “environments and locations”

diagram.

Location

Application

User locations Server locations Dev/test locations

CRM Anywhere with web access Cloud Computing unknown

ERP Headquarters Data Centre

System Use-Case Diagram Nothing to say here that adds to industry norms.

Enterprise Manageability Diagram (shown in tabular form)

Enterprise Manageability Application Component Enterprise Management

Technology Component

Data Entities

Interface

Interface

Process/System Realization Diagram

The table below gives an idea, but A UML sequence diagram would be better.

Application CRM ERP Billing

Process

Capture customer Create Order Record

Capture order Create Order Record

Order Enquiry Check Price and

Availability

Order Closure Update Order Record Create Payment Schedule

Looking at the MODAF artifacts, the closest comparator is the SV-10c Systems Event-Trace Description, shown

below.

Software Engineering Diagram As per industry norm – class, component or module diagram.

Application Migration Diagram “identifies application migration from baseline to target application components; enables a more accurate

estimation of migration costs by showing precisely which applications and interfaces need to be mapped between

migration stages; would identify temporary applications, staging areas, and the infrastructure required to support

migrations (for example, parallel run environments, etc).”

Software Distribution Diagram (shown in tabular form)

Software Distribution Composed of Deployed on Deployed at

Physical Application

Component

Physical Technology

Component

Location

Physical Application

Component

Physical Application

Component

Phase D: Technology Architecture artifacts

Technical Reference Model TOGAF’s Technical Reference Model is curiously missing from the TOGAF artifact set.

The closest MODAF equivalent artifact is the example version of the AV-2 Integrated Dictionary shown below.

Technology Standards Catalog

Technology Standards Catalog

Standard Logical Technology Component Physical Technology Component

Standard Logical Technology Component Physical Technology Component

Looking at the MODAF artifacts, there are two related artifacts, shown below.

Technology Portfolio Catalog

Technology Portfolio Catalog

[provided by?] [realised in?]

Platform Service Logical Technology Component Physical Technology Component

Platform Service Logical Technology Component Physical Technology Component

System/Technology Matrix

Notice that various entity types could be shown in the rows and columns. This suggests several alternative

matrixes could be drawn.

Application

Technology

Platform Service Logical Application

Component

Physical Application

Component

Platforrn Service consumes [supports]

Logical Technology

Component

[Offers] [supports]

Physical Technology

Component

Realizes

[supports]

Environments and Locations Diagram (shown in tabular form)

Hosted at Contains Contains

Locations etc.

Environments

Location Application Components Technology

Components

Development Environment

Test Environment

Pre-production

Environment

Production Environment

Disaster Recovery

Environment

User Environment

Platform Decomposition Diagram (shown in tabular form)

Platform Hosted at Contains Contains

Location Application Components Technology Components

Hardware

Logical Technology

Components (with

attributes)

Physical Technology

Components (with

attributes)

Software

Logical Technology

Components (with

attributes)

Physical Technology

Components (with

attributes)

Processing Diagram (shown as a catalog) Focuses on deployable units of code/configuration and how these are deployed onto the technology platform.

Processing

Technology

Platform

Deployment Unit

(Application

Components)

Uses Protocols On this Network Required

Bandwidth

Work station Browser, Ajax http/tcp/ip WAN

Web servers http/tcp/ip LAN

Application server Java App LAN

Database server LAN

Each deployment unit comprises parts, such as Installation (holds the executable code or package configuration),

Execution (application component with its associated state at run time) and Persistence (data that represents the

persistent state of the application component).

Looking at the MODAF artifacts, the closest comparator is the SV-1 System Interface Description, shown below.

Networked Computing/Hardware Diagram (shown in tabular form) The distributed network computing environment with firewalls and demilitarized zones.

Networked Computing/Hardware

Technology

Platform

Deployment Unit

(Application

Components)

Uses Protocols On this Network Required

Bandwidth

Work station Browser, Ajax http/tcp/ip WAN

DMZ Firewall http/tcp/ip WAN and LAN

Web servers http/tcp/ip LAN

DMZ Firewall http/tcp/ip LAN

Application server Java App LAN

Database server LAN

“To document the mapping between logical applications and the technology components - in the development and

production environments.”

Looking at the MODAF artifacts, the closest comparator is the SV-2a System Port Specification, shown below.

Communications Engineering Diagram Similar to the above, but instead of focusing on deployment of applications to servers, it focuses the network

infrastructure. It may include switches and routers, internet addresses, ports and the protocol assigned to each port.

Looking at the MODAF artifacts, the closest comparator is the SV-2b Systems to System Port Connectivity, shown

below.

Duplication between artifacts in phases C and D Suppose you want to document the deployment of application software to computers, and locations. You could end

up repeating the information in 6 artifacts.

Phase C Application Architecture artifacts Phase D Technology Architecture artifacts

System/Technology Matrix

Environments and Locations Diagram

Application and User Location Diagram Processing Diagram

Software Distribution Diagram Networked Computing/Hardware Diagram

Application and User Location Diagram “shows the geographical distribution of applications, where

applications are used by the end user; where the host application is executed and/or delivered in thin client

scenarios; where applications are developed, tested, and released; etc.

Software Distribution Diagram “shows how application software is structured and distributed across the estate…

shows how physical applications are distributed across physical technology and the location of that technology…

enables a clear view of how the software is hosted

System/Technology Matrix “documents the mapping of business systems [surely applications] to technology

platform.”

Environments and Locations Diagram “depicts which locations host which applications… identifies what

technologies and/or applications are used at which locations”

Processing Diagram “focuses on deployable units of code/configuration and how these are deployed onto the

technology platform.”

Networked Computing/Hardware Diagram “to document the mapping between logical applications and the

technology components (e.g., server) that supports the application both in the development and production

environments… “to show the ‘‘as deployed’’ logical view of logical application components in a distributed

network computing environment…“Enable understanding of which application is deployed where in the

distributed network computing environment.”

Phase E: Opportunities and Solutions Artifacts

Project Context Diagram (shown in tabular form)

Project

Context

Organisations Business

Functions

Business

Processes

Data

Entities

Applications &

Technologies

Work Package

Work Package

Benefits Diagram (shown in tabular form)

Benefits Size Benefit Complexity

Opportunities

Opportunities

Phase F: Migration Planning

Looking at the MODAF artifacts, the closest comparators are StV-3 Capability Phasing, shown below.

And the SV-8 Systems Evolution Description, shown below.

And the AcV-8 SoS Acquisition Programmes, shown below.

And perhaps the SV-9 Systems Technology Forecast, shown below, may be relevant in this context.

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier

Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not

derivative works based upon it.

For more information about the licence, see http://creativecommons.org