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

Explanatory notes to accompany this model.

https://lnkd.in/gTAh9iW

 

 “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, this model 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.

 

Architects will surely never document a whole enterprise in the excruciating detail John Zachman proposed.

Still, architects must document architectures, however partially or transiently, in a consistent and coherent way.

This model organises core architecture concepts in a simple framework, compatible with general system theory.

 

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.

This model is somewhat simplified version of the TOGAF meta model.

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

Processes/Value Streams

Roles

Actors

Information Systems

Application Services

Application Interfaces

Application Components

 

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.

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

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

 

Services

You can define the Services a system is required provide, as they are seen by external entities, in contracts.

A contract defines a Service by its entry and exit conditions - regardless of how the Service is delivered.

A Service contract can include I/O data flow names, and I/O materials (Supplies and Products).

It can also include the value that the Service brings to any actor(s) who use the results of the Service.

 

Behavior decomposition

Given a 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.

 

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.

 

Functions/Capabilities are realised by Organization Units

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.

 

Application Interfaces are realised by Components

This model 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.

 

Other relationships?

This model helps to explain what enterprise and solution architects may record, at least transiently, while analysing and designing systems.

In practice, few can maintain a repository with all of that information in it.

Moreover, to stop the diagram being a spider's web, the model shows only a selection of the many possible relationships,

E.g. You could relate an Application or Data Component to the Technology Services it requires, rather than to Technology Components. 

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

That road might lead you to a more minimal meta model of the kind below.

 

Domain

Required behaviors

Logical Structures

Physical Structures

Business

Business Services

 

Organization Units

Processes/Value Streams

Roles

Information Systems

Application Services

Application Components

 

Data Entities. Logical Data Models

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

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

 

Copyright Avancier Ltd 2019. Last updated Friday, 04 October 2019.