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
Stakeholder Map Matrix
Value Chain Diagram
Solution Concept Diagram
Phase B Business
Architecture artifacts
Organization/Actor Catalog
Driver/Goal/Objective
Catalog
Role Catalog
Business Service/Function
Catalog
Location Catalog
Process/Event/Control/
Product Catalog
Contract/Measure Catalog
Business Interaction Matrix
Actor/Role Matrix
Business Footprint Diagram
Business Service/Information
Diagram
Functional Decomposition
Diagram
Product Lifecycle Diagram
Goal/Objective/Service
Diagram
Business Use-Case Diagram
Organization Decomposition
Diagram
Process Flow Diagram
Event Diagram
Phase C Data Architecture Phase C Application
artifacts Architecture artifacts
Data Entity/Data Component Application Portfolio Catalog
Catalog
Interface Catalog
Data Entity/Business System/Organization Matrix
Function Matrix
System/Data Matrix Role/System Matrix
System/Function Matrix
Application Interaction
Matrix
Class Diagram Application Communication
Diagram
Data Dissemination Diagram Application and User
Location Diagram
Data Security Diagram (or System Use-Case Diagram
matrix)
Data Migration Diagram Enterprise Manageability
Diagram
Data Lifecycle Diagram Process/System Realization
Diagram
Class Hierarchy Diagram Software Engineering
Diagram
Application Migration
Diagram
Software Distribution
Diagram
Phase E Opportunities and
Solutions Artifacts
Project Context Diagram
Benefits Diagram
Phase D Technology
Architecture artifacts
Technical Reference Model
Technology Standards
Catalog
Technology Portfolio Catalog
System/Technology Matrix
Environments and Locations
Diagram
Platform Decomposition
Diagram
Processing Diagram
Networked
Computing/Hardware
Diagram
Communications Engineering
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 Concerns Power Interest Communication Plan
Matrix
Chief Information IT Budget, Demonstrable High Low
Officer Benefits
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 Promotion Monthly Email Advert
Mngmnt
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 [
Order Closure Order Confirmation Price agreed, Stock Available Order Clo
Fulfilment Instruction End of Day Order Closed Instructio

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
Business Business Business
element Organization
Function Service Service
Matrix
Organization
Business
Function
Business Communicates
Service with
Business
Is dependent on
Service

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 Salesman Customer Contact
Actor Matrix
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 Business Technical
Units Functions Components
Generate income Kitchen Kitchen Sales Order Capture Lap top, Back office
Refurbishment Division applications
Generate income Haircut, Hairwash, Barber Shops Barbering Shampoo, Scissors,
Manicure 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 Business Function Org Unit
Data Entity
Data Entity CR by
Data Entity CRUD by Owned by

System/Data Matrix
System means application here.
Application Logical Application Component Logical Application Component
Data
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 Stage 1: Stage 2: Stage 3: Stage 4: Target (applications or
applications or Extract Profile Transform Load databases)
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
Individual
Taxi Driver
Driving Instructor Driver
Driving Examiner
Customer
Driving Examiner
Manufacturer
Organisation
Operator
Dealing
Keeper
Purchaser/Nominee
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 communicates with Logical Application Component
(CRM) (ERP
Physical Application Component communicates with Physical Application Component
(Seibel) (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 Sales Delivery
Physical Application Component

Salesforce.com
SAP

Role/System Matrix
System means application here.
Role Salesman Product Manager
Application
CRM
ERP
System/Function Matrix
System means application here.
Function Sales Fulfillment
Application
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 Service Logical Application Physical Application
Application Component Component
Application Service consumes
Logical Application communicates with
Component
Physical Application communicates with
Component

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 CRM ERP Data Entities in the
Interface 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 User locations Server locations Dev/test locations
Application
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 Data Entities
Technology Component
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 Physical Technology Location
Component Component
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
Platform Service
Platform Service
[provided by?] [realised in?]
Logical Technology Component Physical Technology Component
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 Platform Service Logical Application Physical Application
Technology Component Component
Platforrn Service consumes [supports]
Logical Technology [Offers] [supports]
Component
Physical Technology Realizes
Component [supports]

Environments and Locations Diagram (shown in tabular form)

Hosted at Contains Contains
Locations etc. Location Application Components Technology
Environments 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 Deployment Unit Uses Protocols On this Network Required
Platform (Application Bandwidth
Components)
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 Deployment Unit Uses Protocols On this Network Required
Platform (Application Bandwidth
Components)
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 Organisations Business Business Data Applications &
Context Functions Processes Entities 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