TOGAFTM 9 artifact templates

This paper is published under the terms of the licence summarised in the footnote. (By the way, the artifacts in the Avancier Method overlap, but are not the same as these.) On relationship to TOGAF The tabular artifacts (catalogs, matrices and diagrams) herein correspond to those in TOGAF 9 chapter 35. The aim is to help you understand TOGAFs rather abstract narrative description of these artifacts. The architectural entities (or building blocks) 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.

Home page

On the official courseware samples Do compare each table with the official sample artifact slide in the courseware on the Open Group web site. Youll 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. Please do criticise and help to improve this free resource. Avancier will send you a Word version of this document in return for two short and presentable examples of any Phase D artifacts . Note that Avancier is the sole judge of whether your examples are presentable and may suggest some editing.

Phase A: Architecture Vision artifacts

Stakeholder Map Matrix This is more a catalog than a matrix. Stakeholder Map Matrix Concerns Chief Information Officer IT Budget, Demonstrable Benefits Design Authority Justification of Role Business Manager Business continuity Business Users Usability On the official sample: 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. On the official sample: This is Porters original meta diagram rather than an example. 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.

Power High Medium High Low

Interest Low Medium Medium High

Communication Plan

Phase B: Business Architecture artifacts

There is universal confusion in the industry between Business Capability, Business Function and Business Service. So it is not 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 Organization/Actor Catalog Surely better to show role (the type) here rather than actor (the individual). Organization/Actor Catalog Organisation Actor Sales Joe Henderson Sales Patrick Mancini Sales Salesforce.com

Optional Location Customer Site Home Address 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 Salesman Salesman Personal Assistant

Optional Measures tbd tbd

Functions performed Capture customer orders Maintain customer relationship Maintain salesman diary

Training required tbd tbd tbd

Business Service/Function Catalog Business Service/Function Catalog Organisation Unit Business Function Sales Customer Relationship Mngmnt Sales Order Capture Location Catalog Locations Customer Site Head Office

Business Service Promotion Order Capture

Optional Information System Service Monthly Email Advert Order Capture

Business functions Order Capture Fulfilment Direction

End-user computers Lap Top PC

Servers tbd tbd

Process/Event/Control/Product Catalog Process/Event/Control/Product Catalog Process Event [Input] Order Closure Order Confirmation Fulfilment Instruction End of Day

Control [Precondition] Price agreed, Stock Available Order Closed

Product [output] Order Closed Instruction Messages

Contract/Measure Catalog Optional Contract/Measure Catalog Business or IS Service Service Contract Measure Customer Look Up tbd tbd Monthly Email Advert tbd tbd There isnt 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 Function Business Service Business Service Business element Organization Matrix Organization Business Function Business Service Communicates with Business Service Is dependent on On the official sample: Better if the rows and columns show Business Functions, and Business Services are in the cells. Actor/Role Matrix Role Salesman Customer Contact Actor Matrix Joe Henderson performs Patrick Mancini performs Salesforce.com performs On the official 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. Met through Offered by Which perform Using these Business Footprint 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, Barber Shops Barbering Shampoo, Scissors, Chair, etc. Manicure

Business Service/Information Diagram (shown in tabular form) Information Data Entities Data Sources Data Entities Consumes From And Produces Business Service Order Capture Stock Item Price ERP System Order Monthly Email Advert Promotion CRM System Email On the official sample: Again, this shows Business Functions rather than Business Services. But TOGAF blurs the distinction. Functional Decomposition Diagram Nothing to say here that adds to industry norms. On the official 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 more functions). Product Lifecycle Diagram (shown in tabular form) Especially 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). Moves from To As result of Product: Credit Card Prior State Next State Event [Condition] Requested Posted Posting Posted Authorised First successful transaction Authorised Barred Customer loss report On the official sample: This represents a misunderstanding of the concept. Goal/Objective/Service Diagram (shown in tabular form) Goal/Objective/Service Catalog Business Service Driver Goal Business Service Driver Goal

Objective Objective

Measures Measures

Business Use-Case Diagram Nothing to say here that adds to industry norms. Organization Decomposition Diagram Nothing to say here that adds to industry norms. Process Flow Diagram Nothing to say here that adds to industry norms. On the official sample: Such a vacuous cartoon makes it look like TOGAF is written by or for a management consultant. Event Diagram To depict the business events or simply events that trigger a process and generate a business response or result.

On the official samples: see notes above. In phase B above all; it is difficult to present the official samples with conviction. Several seem not to reflect the meta model.

Phase C: Data Architecture artifacts

Data Entity/Data Component Catalog Data Entity/Data Component Catalog Data Entity Data Entity

Logical Data Component Logical Data Component

Physical 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. Org Unit Business Function Business Function Data Entity Data Entity CR by Data Entity CRUD by Owned by System/Data Matrix System means application here. Application Logical Application Component Data Data Entity Data Entity Class Diagram (shown in tabular form) TOGAF interprets class as data entity. Class Diagram Entity Entity Entity CR by CRUD by Logical Application Component CRUD by R by

Is related to Is related to Is related to

Entity Entity Entity

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.. Business Services Physical Application Components Data Dissemination Data Entity Data Entity Data Security Diagram (or matrix) Surely better to show role (the type) here rather than actor (the individual). Data Entity Actor Actor

Data Entity

Data Migration Diagram (shown in tabular form) The tabular form isnt great here. Better draw a diagram with arrows from sources to targets. Stage 1: Stage 2: Profile Stage 3: Stage 4: Data sources (baseline Target (applications or Extract Transform Load applications or 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) Moves From Entity Prior State Requested Posted Authorised

To Next State Posted Authorised Barred

As result of Event [Condition] Posting First successful transaction Customer loss report

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 Authorised User Vehicle Tester Trainer/Booker Driver Driving Examiner Manufacturer Operator Dealing Customer Organisation Keeper Purchaser/Nominee Subtype class Super type class

Taxi Driver Driving Instructor Driving Examiner

Individual

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 rather different from the one suggested by TOGAF below. Application Portfolio Catalog is logically provided by is realised in Information System Service 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 cant 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 Sales Physical Application Component Salesforce.com SAP Delivery

Role/System Matrix System means application here. Role Salesman Application CRM ERP System/Function Matrix System means application here. Function Sales Application CRM ERP 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. Logical Application Component Physical Application Component Application Application Service Application Application Service consumes Logical Application Component communicates with Physical Application Component communicates with Application Communication Diagram (shown in tabular form) This is essentially a data flow diagram. Data stores, perhaps even data entities, may be shown. ERP Application CRM Interface Customer Import Fulfillment Product Manager

Data Entities in the interface Customer

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) Application Component Enterprise Manageability Interface Interface Process/System Realization Diagram The table below gives an idea, but A UML sequence diagram would be better. Application CRM ERP Process Capture customer Create Order Record Capture order Create Order Record Order Enquiry Check Price and Availability Order Closure Update Order Record

Enterprise Management Technology Component

Data Entities

Billing

Create Payment Schedule

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) Composed of Software Distribution Physical Application Component Physical Application Component Physical Application Component

Deployed on Physical Technology Component

Deployed at Location

Phase D: Technology Architecture artifacts

WANTED! HELP TO COMPLETE THESE EXAMPLES Technology Standards Catalog Technology Standards Catalog Standard Standard Technology Portfolio Catalog Technology Portfolio Catalog Platform Service Platform Service [provided by?] Logical Technology Component Logical Technology Component [realised in?] Physical Technology Component Physical Technology Component

Logical Technology Component Logical Technology Component

Physical 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. Logical Application Component Physical Application Component Application Platform Service Technology Platforrn Service consumes [supports] Logical Technology Component [Offers] [supports] Physical Technology Component Realizes [supports]

Environments and Locations Diagram (shown in tabular form) Hosted at Locations etc. Location Environments Development Environment Test Environment Pre-production Environment Production Environment Disaster Recovery Environment User Environment Platform Decomposition Diagram (shown in tabular form) Hosted at Platform Location Hardware

Contains Application Components

Contains Technology Components

Contains Application Components

Contains Technology Components 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 Uses Protocols On this Network Required Bandwidth (Application 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). 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 Uses Protocols On this Network Required Bandwidth (Application 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. 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.

Duplication between artifacts in phases C and D

There is a huge amount of overlap. For example: suppose you want to document the deployment of application software to computers, and locations. You could end up repeating the information in 6 artifacts. 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 environmentEnable 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) Organisations Business Functions Project Context Work Package Work Package Benefits Diagram (shown in tabular form) Size Benefits Opportunities Opportunities Business Processes Data Entities Applications & Technologies

Benefit

Complexity

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