Microsoft Word - Togaf 9 Artifact Summary 6i215n

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 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

Phase E Opportunities and Solutions Artifacts Project Context Diagram Benefits Diagram Phase C Data Architecture artifacts Data Entity/Data Component Catalog

Actor/Role Matrix

Data Entity/Business Function Matrix System/Data Matrix

Business Footprint Diagram

Class Diagram

Business Service/Information Diagram Functional Decomposition Diagram Product Lifecycle Diagram

Data Dissemination Diagram

Goal/Objective/Service Diagram Business Use-Case Diagram

Data Lifecycle Diagram

Organization Decomposition Diagram Process Flow Diagram

Data Security Diagram (or matrix) Data Migration Diagram

Class Hierarchy Diagram

Phase C Application Architecture artifacts Application Portfolio Catalog

Phase D Technology Architecture artifacts Technical Reference Model

Interface Catalog

Technology Standards Catalog Technology Portfolio Catalog

System/Organization Matrix

System/Technology Matrix

Role/System Matrix System/Function Matrix Application Interaction Matrix Application Communication Diagram Application and Location Diagram System Use-Case Diagram

Environments and Locations Diagram Platform Decomposition Diagram Processing Diagram

Enterprise Manageability Diagram Process/System Realization Diagram Software Engineering Diagram Application Migration Diagram Software Distribution Diagram

Networked Computing/Hardware Diagram Communications Engineering 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 Concerns Matrix Chief Information IT Budget, Demonstrable Officer Benefits Design Authority Justification of Role Business Manager Business continuity Business s Usability

Power

Interest

High

Low

Medium High Low

Medium Medium High

Communication Plan

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 AV1 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). Optional Organization/Actor Catalog 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 Sales Competitor A USP Match USP Sales Competitor B Price Beat Cost Role Catalog Roles Salesman Salesman Personal Assistant

Functions performed Capture customer orders Maintain customer relationship Maintain salesman diary

Training required tbd tbd tbd

Objective tbd 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 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 Organisation Unit Business Function

Business Service

Sales

Promotion

Optional Information System Service Monthly Email Advert

Order Capture

Order Capture

Sales

Customer Relationship Mngmnt 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 Customer Site Head Office

Business functions Order Capture Fulfilment Direction

End- computers Lap Top PC

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

Servers tbd tbd

Control [Precondition] Price agreed, Stock Available Order Closed

Contract/Measure Catalog Contract/Measure Catalog Business or IS Service Service Contract Customer Look Up tbd Monthly Email Advert tbd There isn’t enough room to record a service contract in this table. And really, measures should be included in the contract itself.

Product [ Order Clo Instructio

Optional Measure tbd tbd

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 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”. Met through Offered by Which perform Using these Business Footprint 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 Consumes From And Produces Business Service 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, ports). 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 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 Business Service Driver Business Use-Case Diagram Nothing to say here that adds to industry norms.

Goal Goal

Objective Objective

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 Data Entity 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 Data Data Entity Data Entity

Logical Application Component

Logical Application Component

CR by CRUD by

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.. 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 isn’t great here. Better draw a diagram with arrows from sources to targets. Stage 1: Stage 2: Stage 3: Stage 4: Data sources (baseline Target (applications or Extract Profile 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

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 Vehicle Tester Trainer/Booker Individual Taxi Driver Driver Driving Instructor 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 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 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 Physical Application Component

Sales

Delivery

Salesforce.com SAP Role/System Matrix System means application here. Role Application CRM ERP

Salesman

Product Manager

System/Function Matrix System means application here. Function Application CRM ERP

Sales

Fulfillment

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. Logical Application Physical Application Application Application Service Component Component Application Application Service consumes communicates with Logical Application 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. ERP Data Entities in the Application CRM 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 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 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 Management Enterprise Manageability 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 Process Capture customer Create Order Record Capture order Create Order Record Order Enquiry Check Price and Availability Order Closure Update Order Record

Data Entities

Billing

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 migrations (for example, parallel run environments, etc).” Software Distribution Diagram (shown in tabular form) Composed of Deployed on Software Distribution Physical Application Physical Technology Component Component Physical Application Component Physical Application Component

Deployed at Location

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 Standard

Logical Technology Component Logical Technology Component

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

Physical Technology Component Physical Technology Component

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

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 Physical Application Application Platform Service Component Component Technology Platforrn Service consumes [s] Logical Technology [Offers] [s] Component Realizes Physical Technology Component [s] Environments and Locations Diagram (shown in tabular form) Hosted at Contains Application Components Locations etc. Location Environments Development Environment Test Environment Pre-production Environment Production Environment Disaster Recovery Environment Environment Platform Decomposition Diagram (shown in tabular form) Hosted at Contains Platform Location Application Components Hardware

Contains Technology 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 Deployment Unit Uses Protocols On this Network Required Platform (Application Bandwidth Components) Work station Browser, Ajax http/t/ip WAN Web servers http/t/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 Platform (Application Components) Work station Browser, Ajax http/t/ip WAN DMZ Firewall http/t/ip WAN and LAN Web servers http/t/ip LAN DMZ Firewall http/t/ip LAN Application server Java App LAN Database server LAN

Required Bandwidth

“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 Location Diagram Processing Diagram Software Distribution Diagram Networked Computing/Hardware Diagram Application and Location Diagram “shows the geographical distribution of applications, where applications are used by the end ; 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 s 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) Organisations Business Project Functions Context Work Package Work Package Benefits Diagram (shown in tabular form) Size Benefits Opportunities Opportunities

Business Processes

Benefit

Data Entities

Applications & Technologies

Complexity

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