Professional Documents
Culture Documents
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 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.
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.
Looking at the official TOGAF sample: it is OK except that it is a catalog rather than a matrix
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
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.
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.
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
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
The MODAF equivalent artifact is the OV-7 Logical Data Model, shown below.
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
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.
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 Platform Service Logical Application Physical Application
Technology Component Component
Platforrn Service consumes [supports]
Logical Technology [Offers] [supports]
Component
Physical Technology Realizes
Component [supports]
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