TOGAF and VDML

Copyright 2017 Graham Berrisford.

One of about 300 papers at http://avancier.website. Last updated 28/01/2017 13:05

References are to TOGAF 9.1 and VDML 1.0.

Contents

Preface. 1

Mapping TOGAF terms to VDML terms. 3

Real or abstract?. 5

Structure or behaviour?. 6

Function as Capability. 7

Preface

The Open Group’s TOGAF and the Object Management Group’s VDML share similar aims and principles.

VDML model an enterprise as “collaborative business relationships and role based business networks”.

Participants interact as providers/producers and recipients/consumer of business items (material and/or information).

The values that recipients obtain from business items are measurable and quantified.

TOGAF models an enterprise as network of interoperating building blocks.

Building blocks interact as providers and receivers of services that consume and produce materials and information.

The values that receivers obtain from services are measurable and quantifiable (in the Architecture Requirements Specification).

General system theory

This table defines and illustrates some general system theory concepts we can use to compare VDML with TOGAF.

It distinguishes structures from behaviors, and abstract structures from concrete ones.

System theory		Human	Business	Application	Software
Abstract active structures	group required behaviors/actions	Role	Business function/capability	Interface	Class
Concrete active structures	assigned to perform behaviors/actions	Actor	Organisation unit	Application	Object
Abstract behaviors	sequence required behaviors/actions	Process	Business process/value stream	Use case	Interaction
Abstract actions	atomic behaviors	Action	Process step	User story	Operation
Events	triggers behaviors	Event	Event

VDML

The OMG’s Value Delivery Modelling Language (VDML) describes a business system as a network of interoperating roles.

A business system or subsystem (a community, business network or organization unit) is called a collaboration.

“Activities define the work of Roles of Participants in a Collaboration [think, subsystem].

They are linked in networks by Deliverable Flows through which they receive and produce or modify Business Items (inputs and outputs).”

Participants interact as providers/producers and recipients/consumer of business items (material and/or information).

VDML encourages architects to measure and quantify values that actors in recipient roles obtain from business items.

It focuses on the structural view of a system, rather than behavioral views.

However, the capability profile of a role must group activities that actors in that role can perform.

And higher-level processes must be sequences of the same elementary activities.

System theory		VDML
Abstract active structures	group required behaviors/actions	Role	“An expected behavior pattern or capability profile associated with participation in a collaboration.”
Concrete active structures	assigned to perform behaviors/actions	Participant	“Anyone or anything that can fill a role in a collaboration (named in the model, or dynamically determined in run-time).”
Abstract behaviors	sequence required behaviors/actions	Process	“A sequence or flow of activities in an organization with the objective of carrying out work.”
Abstract actions	atomic behaviors	Activity	“Work contributed to a collaboration by a participant in a role.” “An activity consumes and produces business items.”
Events	triggers behaviors	Deliverable Flow	“The transfer of a deliverable [business item] from a provider (or producer) to a recipient (or consumer).”

TOGAF

The Open Group Architecture Framework (TOGAF) looks at a human and computer activity system as a network of interoperating building blocks.

The building blocks interact as providers and receivers of services that consume and produce materials and information.

The values that receivers obtain from services can be measured, and quantified in the Architecture Requirements Specification.

TOGAF’s building blocks take many forms, but here, let us consider only the human actors.

There is no explicit concept of an elementary action or activity – there are only higher level services, processes and roles.

System theory		TOGAF
Abstract active structures	group required behaviors/actions	Role, Function	A definition of the activities performable by an actor.
Concrete active structures	assigned to perform behaviors/actions	Actor, Organisation unit	Anyone who can play a role (named in the model, or dynamically determined in run-time)
Abstract behaviors	sequence required behaviors/actions	Process	A sequence or flow of activities leading to the delivery one or more business services.
Abstract actions	atomic behaviors
Events	triggers behaviors	Service	A unit of behavior that transforms input materials or information into outputs of value to a recipient.

Mapping TOGAF terms to VDML terms

The VDML vocabulary might mapped to TOGAF, but the two cannot be integrated without significantly revising one or other vocabulary.

It is always difficult merge any two separately-developed controlled vocabularies or meta models.

It is tempting to assume the same words mean the same thing, especially where one or both definitions are loose, but this can make things worse.

The universal confusions over the meanings of “service” and “capability” arise.

In VDML a service seems to be an accessible portfolio of discrete services/capabilities, which might be called a service portfolio or interface in TOGAF.

Here is a mapping of 20 core concepts; it is not perfectable for several reasons discussed in the later sections.

One reason is that VDML draws from many sources and some of its definitions are open to interpretation - don’t clearly distinguish structural and behavioral views of activities.

TOGAF concept	VDML term	VDML definition
Building Block (instance?)	Actor	An individual (indivisible) participant, which might be human (a person) or non human (e.g., a software agent or machine)
	Participant	Anyone or anything that can fill a role in a collaboration. Participants can be actors (human or automatons) or collaborations or roles of actors or collaborations. They maybe named in the model, or dynamically determined in run-time
Building Block network	Activity network	A network of activities of participants in a collaboration that are lined by deliverable flows
	Value Network	Any set of roles and interactions in which participants engage in both tangible and intangible exchanges to achieve economic or social good (Allee (2008) ). Or: Any web of relationships that generates both tangible and intangible value through complex dynamic exchanges between two or more individuals, groups or organizations (Allee (2003)).
Data component	Store	Represents a container of resource. The resource that is stored is identified by a business item. Data store in BPMN (2011) is a similar construct, though with a more narrow meaning).
Enterprise	Organization	An administrative or functional structure normally interpreted as a network of Organization Units at a higher level in an organizational hierarchy
Enterprise, System, Subsystem	Collaboration	Collection of participants joined together for a shared purpose or interest.
Event, Data entity	Resource	Anything that is “used” or “consumed” in the production of a deliverable
Event, Product	Business Item	A business item is anything that can be acquired or created, that conveys information, obligation or other forms of value and that can be conveyed from a provider to a recipient. For example, it includes parts, products, units of fluids, orders, emails, notices, contracts, currency, assignments, devices, property and other resources
Function (or process?)	Capability	Ability to perform a particular kind of work and deliver desired value.
Functional decomposition	Value Chain	Set of activities that an organization carries out to create value for its customers (Porter (1985)).
Interface	Service	A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.
Organization Unit	Organization Unit	An administrative or functional organizational collaboration, with responsibility for defined resources, including a collaboration that occurs in the typical organization hierarchy, such as business units and departments (and also the company itself), as well as less formal organizational collaboration such as a committee, project, or task force
Process	Process	A sequence or flow of Activities in an organization with the objective of carrying out work. VDML does not represent process, per se, but represents a process abstraction with a network of activities and flows that represent dependencies and statistical characteristics of a process.
Process (elementary step)	Activity	Work contributed to a collaboration by a participant in a Role of the collaboration. A role may be filled by another collaboration and a role may contribute to multiple activities in the same collaboration
Process/Scenario	Scenario	A scenario defines a consistent business use case and set of measurements of a value delivery model by specifying a, possibly recursive, AnalysisContext for elements in scope of that use case. The nesting of contexts allows a collaboration to be used as a sub-collaboration by more than one activity, each of which sets its particular delegation context and measurements
Process (or function?)	Value Stream	The network of activities that includes resources, value contributions and capabilities to determine a value proposition for a customer who may be the ultimate customer or an internal end user of the result
Product	Deliverable	Product or service defined by an associated business item that is produced by an activity or delivered from a store that can be conveyed to another activity or store
Role	Role	An expected behavior pattern or capability profile associated with participation in a collaboration.
Service Output	Deliverable Flow	The transfer of a deliverable from a provider (or producer) to a recipient (or consumer)
Transport mechanism?	Channel	Mechanism to execute a deliverable flow, such as e-mail, face-to-face converzation, SOAP, REST, physical transportation, postal service, telephone, fax, FTP, etc.

Real or abstract?

TOGAF is geared towards maintaining abstract descriptions of logical functions, roles and components.

VDML refers rather more to physical, quantifiable realities, but does feature abstractions as well.

TOGAF	VDML
Logical Building Blocks: Function, Role, Logical Application and Technology Components	Capability, Role,
Physical Building Blocks: Organization Unit, Actor, Physical Application and Technology Components	Participant, Organization Unit, Actor,

VDML Collaborations– more real than abstract

TOGAF regards the enterprise as a system, or system of systems.

VDML’s collaboration (a community, a business network, or an organization unit) is a kind of system or subsystem.

It focuses on participants in real operational systems

“A Collaboration represents the interaction of multiple participants for a shared purpose.”

“Collaborations involve participants in roles working together to perform activities.”

“Participants may be individuals or other collaborations.”

VDML Actors and participants – more real than abstract

TOGAF speaks of enterprise architecture being “considerably abstracted from implementation”.

VDML refers to actors and participants as individuals that may be named or instantiated at run-time.

“Actor: An individual (indivisible) participant, which might be human (a person) or non human (e.g., a software agent or machine)”

“Participant: Anyone or anything that can fill a role in a collaboration. Participants can be actors (human or automatons) or collaborations or roles of actors or collaborations.”

“They may be named in the model, or dynamically determined in run-time.”

VDML Business items –more real than abstract

TOGAF mentions products; VDML speaks of business items.

“A business item is anything that can be acquired or created, that conveys information, obligation or other forms of value and that can be conveyed from a provider to a recipient.

For example, it includes parts, products, units of fluids, orders, emails, notices, contracts, currency, assignments, devices, property and other resources”.

In short, business items are material or information/data structures.

VDML Resources –more real than abstract

“A resource is something that is used or consumed by an Activity to deliver its value.”

“This includes parts, intellectual property, energy, a person, knowledge assets, a machine, a tool, and so on.”

Do resources include participants, collaborations and business items?

VDML Capabilities – more abstract than real

TOGAF speaks of functions – and of mapping functions to organization units.

VDML speaks of capabilities in the same sense.

“Capabilities are owned by organization units

“The Org Unit either has or can obtain the necessary resources to deliver the Capability.”

“An Org Unit will typically have a manager or leader responsible for the management of the Org Unit and its resources and operations.”

VDML capability libraries and maps are exactly the same as TOGAF functional decomposition diagrams.

The VDML examples could be seen as prototypical of a functional decomposition diagram.

VDML says “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

This suggests the authors are unaware of the “functional decomposition” and “structured analysis” techniques mentioned in TOGAF.

Read Structured analysis (functions and processes) for more.

Structure or behaviour?

VDML Capability – more structure than behavior

“Capability: the ability to perform a particular kind of work and deliver desired value.”

Does that define a behaviour (a particular kind of work) that terminates in the delivery of a value?

Or a structural element that groups behaviors that deliver a variety of values?

“A specific Capability may be performed by one Actor or a team of actors.”

That sounds like capabilities are behavioral elements - performed by actors, but then…

“Deliverables such as products or services are produced by using business Capabilities to perform Activities”.

So capabilities are structural elements - they perform activities?

The confusion arises because a capability is a logical business function.

It is a structure that groups behaviors that deliver values, but does not actually perform them.

Before performance can happen, a logical capability/function has to be realised by physical participants, notably organization units and human actors

VDML Activity network - more structure than behavior

“An activity network describes the elements and relationships of activities and stores that occur within collaborations including the assignment of roles and the flow of business items.

“A role is represented as swim-lane.”

This sounds like it could be end-to-end behaviour, but more is likely a structural model (like a classic data flow diagram, or goods and services flow diagram).

VDML Scenario – more behaviour than structure.

“A Scenario element represents the root analysis context for the set of Measurements for a particular situation.”

“A Scenario defines a consistent business use case and set of measurements of a value delivery model.”

That seems very much like TOGAF’s idea of a scenario – which is based on a process – an end-to-end behaviour.

Function as Capability

VDML say: “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

Which suggests the authors are ignorant of the “functional decomposition” and “structured analysis” techniques mentioned in TOGAF.

Everything VDML says of a capability map can be said of a functional decomposition hierarchy.

· It arranges business functions/capabilities (needed to deliver results the business desires) in a hierarchical structure.

· It structures what the business does, in progressively more detail at each level of the hierarchy.

· It enables people to start with a broad discussion and then dive into more detail where needed.

· It is defined using function/capability names that help to establish a common vocabulary across the business.

· It is analyzed to identify functions/capabilities that require improvement - often coloured coded on a diagram as a “heat” map.

· It is more stable than the business processes and organisation’s management structure.

· It gives the architects a logical business structure, to which other architectural entities can be mapped.

The VDML example of a capability map (below) could be seen as prototypical of a functional decomposition diagram.

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.