Making sense of TOGAF’s Meta Model and Enterprise Continuum – wrt ArchiMate

Explanatory notes to accompany these four slides.

“brilliant” “great, love it” "elegant” “easy to understand” “nice and simple” “nice and practical” “intuitively obvious".

The aim here is not to promote TOGAF or ArchiMate; it is to reduce confusion and mystification they create.

Since 2008, the meta model here has helped me teach TOGAF, since it organises what I believe its authors had in mind.

More recent contributors have obscured the model by introducing their favored terminology into the standard text.

And kludging terms used by the BA Guild into TOGAF has further obscured what could be a simple picture.

So, an aim here is to ease the terminology torture.

THE PURPOSES OF A META MODEL

A modelling language is a set of graphical (usually box and line) symbols for concepts represented in diagrammatic models.

To see an example, go to The Open Group web site, find their ArchiMate standard and look at diagrams in it.

A meta model is a model (usually an entity-relationship model) of the concepts that appear in models.

To see an example, go to The Open Group web site, find their TOGAF standard, and read the meta model chapter.

Generally, a meta model gives architects:

1) a domain-specific language for the terms and concepts of their profession / architectural thinking.

2) a definition of which inter-concept relationships most likely appear in architectural descriptions (graphical or narrative)

3) potentially, a structure for an architecture description repository.

For purpose 3), architects will surely never document a whole enterprise in the excruciating detail John Zachman proposed.

Few record much more than this: Technologies <serve> Applications <support and enable> Business Processes <are performed by> Business Entities.

(Where the Business Entities could be Roles, Organisation Units, Functions or Capabilities - depending on what architecture method or framework you favor.)

Still, architects must 1) think about architectures and 2) document architectures, however partially or transiently, in a consistent and coherent way.

The meta model here is somewhat simplified version of the TOGAF meta model; it organises core architecture concepts in a simple framework, compatible with general system theory.

The table below presents a further simplified version of the model.

Domain	Required behaviors	Logical Structures	Physical Structures
Business	Business Services	Functions/Capabilities	Organization Units
Business	Processes/Value Streams	Roles	Actors
Information Systems	Application Services	Application Interfaces	Application Components
Information Systems		Data Entities. Logical Data Models	Data Components
Technologies	Technology Services	Technology Interfaces	Technology Components

THE CONTEXT FOR ARCHITECURE DESCRIPTION

The column names do not classify business context and motivation entities.

For example, Business Mission, Vision and Drivers – and what they lead to - Directives, Aims and Plans.

Add a higher level "context" box at the top of the model if you want to show those in the diagram.

Recursive decomposition of descriptive entities

Assume every entity in the meta model is potentially recursive, is composable and decomposable.

Some divide a decomposable entity type into subtypes - at two or three different levels of decomposition - and give them different names.

· Directives may be divided into Principle and Policy levels,

· Aims may be divided into Goal and Objective levels,

· Plans (cf. Courses of Action) may be divided into Strategy and Tactic levels,

However, in a generic meta model, it is better to show one recursive entity type, and leave the level of decomposition to the practitioner.

REQUIRED BEHAVIORS

Behaviors are what happens over time.

A principle of system theory is the primacy of behavior, or “a system is what it does”.

Every behavior in a designed system ends in a result of value to some actor(s) in reaching their aim(s); else there would be no point in designing the behavior.

Another principle is to encapsulate a system, and consider the external before the internal.

The external and internal views of behavior are distinct entities in the TOGAF and ArchiMate meta models.

Services (external view)

You can define each Service a Function, Capability, Organization Unit, Application or Technology is required to provide, in a contract.

· Service name

· Entry conditions (Inputs/Supplies, other Preconditions)

· Exit conditions (Outputs/Products, other Postconditions)

· The value to actors who use the Service.

· Quality of Service measures (Time, Volume etc.)

Every Service encapsulates the Process(es) needed to complete that Service.

Behavior decomposition

Given any required Service, you can define the Process(es) needed to complete it.

In the business layer, a relatively long end-to-end Process may be called a Value Stream.

A Value Stream diagram is an artifact that represents a Process as stages composed of activities.

You can map a Process to whatever structural entities are needed to perform it.

You might map a coarser-grained stage to one or more Functions/Capabilities or Organizational units

You might map a finer-grained activity to one or more Roles.

You might map an elementary business process/activity to one or more Application Services – use cases or epics.

A use case description is an artifact that typically shows the flow of a Process (at the human-computer interface) underneath the attributes of a Service contract.

It may refer to finer-grained server-side Application Services that are invoked during the flow of the use case.

There is no universal prescription for what to document, which artifacts to draw, or what level of granularity

LOGICAL AND PHYSICAL STRUCTURES

Structures are what exists; they act and/or are acted on.

TOGAF includes logical structures that are realised by physical structures.

Functions/Capabilities are realised by Organization Units

A logical Function is defined from the outside by the Services it delivers to its users/customers.

E.g. the Function Package Delivery is defined by Business Services like Standard Delivery, Recorded Delivery and Express Delivery.

The logical Function may be mapped to the Organisation Units that realise it, and the Processes it enables and/or contains.

For Function, read Capability. For Process, read Value Stream.

To perform any given Function, an enterprise needs the corresponding Capability.

The two concepts are different, but the appearance and uses of hierarchical functional decomposition diagrams and capability maps are the same.

To perform a Function, or demonstrate a Capability, an enterprise needs one or more Organization Units.

In a “functional organization” structure, the physical Organization Units correspond to logical Functions, in other cases, the two structures are different.

Roles are realised by Actors

To perform any given Role, an enterprise needs one or more physical Actors.

Documenting all the Actors is difficult unless your repository can be auto-populated from some kind of identity management system.

Application Interfaces are realised by Components

The meta model here recasts TOGAF’s Logical Application Components as Application Interfaces.

An Application Interface lists Application Services made available to clients (which may be human Roles or digital Application Components).

Confusingly, a “microservice” is a small Application Component.

The meta model makes no presumption about size of Application Components or any design pattern for their distribution or integration.

Technology Interfaces are realised by Components

The same principles apply to the Technology layer and the Information Systems/Applications layer.

Beware the difference between Technology Services (required behaviors) and Technology Components (active structures).

That difference is reflected in the distinction TOGAF draws between a Technical Reference Model and a Technology Component Catalogue.

Note that a Technical Reference Model mostly contains cohesive groups of Technology Services rather than individual ones.

Tailoring the relationships in the meta model

To stop the meta model here becoming a spider's web, it shows only a selection of the many possible relationships,

You can tailor it by – perhaps by adding relationships or by deleting entities.

You could complicate.

E.g. relate an Application or Data Component to the Technology Services it requires (rather than to Technology Components).

You could simplify

E.g. relate Services to the physical Organization Units and Component(s) that provide them (by-passing logical Functions/Capabilities and Interfaces).

Going down that road might lead you to a simpler meta model of the kind below.

Domain	Required behaviors	Structures
Business	Business Services	Organization Units
Business	Processes/Value Streams	Roles
Information Systems	Application Services	Application Components
Information Systems		Data Entities, Models and Components
Technologies	Technology Services	Technology Components

KINDS OF ABSTRACTION in TOGAF and ArchiMate

Architecture is more abstract than detailed design.

Abstraction by idealization is traditionally divided into four levels called Conceptual, Logical, Physical and Real.

This table maps those four levels, somewhat naïvely, to features of TOGAF.

	ADM Phase	Enterprise repository	Enterprise Continuum	Example “building block”
Conceptual	A	Requirements repository	Context and requirements
Logical	B, C and D	Architecture repository	Architecture Continuum	CRM
Physical	E, F and G	Solutions repository	Solutions Continuum	Saleforce.com (the type)
Real			Deployed solutions	Salesforce.com (instances)

TOGAF’s enterprise repository is a data store containing architecture deliverables, artefacts and building blocks.

TOGAF’s enterprise continuum is a two-dimensional classification scheme for artefacts and building blocks.

Think of it as a bookcase with four shelves, and four pigeon holes.

The shelves represent three levels of abstraction by idealisation from deployed solutions.

The pigeon holes represent three degrees of abstraction by generalisation from unique to universal.

These two classifications could be recorded in meta data, as attributes attached to entities in the meta model.

TOGAF’s Enterprise Continuum
Generalisation Idealisation	Foundation (Universal)	Common	Industry	Organisation (Unique)
Contextual
Architecture
Solutions
Deployed solutions

ArchiMate includes four kinds of abstraction relationship: Delegation, Composition, Generalization and Idealization.

This table below shows names used in TOGAF for those four kinds of abstraction.

Domains	Levels	Dimensions of the Enterprise Continuum
Delegation	Composition	Generalization	Idealization
Business	Enterprise	Foundation	Context & Requirements
Information Systems	Segment	Common System	Architecture Continuum
Technologies	Capability*	Industry	Solutions Continuum
		Organization	Deployed Solutions
Service provision	Decomposition	Specialization	Realization

(*) The term Capability is oddly placed here, and whether it correspond to the Capabilities in a Capability map is debatable.

UNDERPINNING THEORY

The TOGAF meta model presumes the logic of general system theory:

First, the evolution of human memories, messages, social and business systems

Hierarchy

· Decomposition of systems into smaller systems/components

· Decomposition of processes into shorter processes

Information input and output

· Encapsulation of systems behind interfaces

· Coupling by I/O feedback (as in Ashby's cybernetics)

· For messages: formal grammars and Shannon's information theory

System state

· A system has a model of what it monitor and directs (Conant-Ashby theorem)

· For memories: data modelling using predicate logic

System structure

· Centralization v distribution: design patterns

· Distribution of system state between subsystems (CAP theorem)

· Synchronization of subsystem state: design patterns

System behavior

· Delegation of required services from clients to servers

· Declarative specification of behavior in service contracts (Hoare logic).

· Deterministic processing of events wrt to system state (DEDS).

For more detailed analysis of TOGAF and ArchiMate, go to the “Short Cuts” at the bottom of this page http://avancier.website