Premises of EA (as in UML, ArchiMate and TOGAF)

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 25/08/2017 15:11

 

Enterprise architecture (EA) frameworks grew out of business system planning methods.

They are intended to help people design, plan and govern changes that transform a baseline business system into a target business system.

Business systems are not new; they evolved over millennia by formalising the roles and rules, messages and memories, of social systems.

However, formal modelling of business systems has been refined since the start of the Information Age.

And business system modelling is underpinned by the more general premises or axioms of system theory.

This paper on system theory follows a more general discussion that starts with Stability and change in entities and systems.

And leads on to more detailed discussion of how EA applies the concepts of general system theory and systems thinking.

Contents

Beware analogies. 1

General premises for modelling system structures and behaviors. 2

Premises of EA in general 4

Premises of TOGAF in particular 5

Further reading. 7

Premises wrt management science. 7

 

Beware analogies

Analogies can be useful, but beware they can also be misleading.

 

Business system architecture is very unlike mechanical engineering or thermodynamics

Engineers model systems that work on matter and energy.

By contrast, enterprise architectures is about business roles and processes that create and use data

The data encodes information about entities and events that a business needs to monitor and direct.

 

Business system architecture is very unlike building architecture

A building architect models a customer’s requirement for a passive structure.

True, the building is a location where the customer will perform behaviors, but the architects don’t design or limit those processes.

By contrast, enterprise business architects model activity systems that are driven by discrete events

The customers (within or outside the enterprise) require specific services/products.

When triggered by events, business systems perform behaviors to deliver services/products.

 

Business systems are unlike biological organisms

You may regard the human body as responding to events by performing processes, but in reality, biological dynamics are continuous.

Events appear in psychological interpretations of what is continuous in reality, and in discrete-event driven models of a body's dynamics.

For more on system dynamics, read papers 4 and 6 on this system theory page.

 

Business systems unlike informal social entities

A business in operation is a complex mixture of informal social entities and formalised social systems.

Every social system depends on actors sending and receiving messages, and remembering what has happened to date.

Business systems are social systems in which messages have been formalised in data flows and memories have been formalised in data stores.

Actors respond to messages, in the light of retained memories, by performing appropriate behaviors and sending messages.

General premises for modelling system structures and behaviors

Architects observe baseline systems, they envisage and design target systems, and describe these systems in models.

Business system models are idealisations of real-world business operations.

Enterprise architecture

Business system models

<create and use>                     <idealise>

Architects <observe & envisage> Business operations

 

General system theory ideas have long been successfully applied to business systems.

They help us to understand what EA is and is not - what it can and cannot do.

Understanding system theory principles and premises helps to us unscramble what is not always clear to readers of relevant standards.

 

Consider for example two standard languages for modelling business operations in terms of structure and behaviour types: ArchiMate and UML.

The UML standard is harder to read than ArchiMate, but is clearer about its premises, which can be adapted for EA as shown below.

The objective of UML is to provide system architects and others with tools for analysis, design, and implementation of software-based systems and modeling business processes.

 

Premise: Models abstract types from the individuals they model

In natural language, people often blur the distinction between types and instances of system elements.

The following extract from UML indicates that the distinction is fundamental to modelling a system.

 

“A model contains three major categories of elements… each models individuals in an incarnation of the system being modeled

Models do not contain objects, occurrences, and executions, because those things are the subject of models, not their content.

Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties.”  UML version 2.4.1 section 6.3.1.

 

The UML standard goes on (in section 6.3.1) to say what is shown below in a table.

A type in a UML model

describes a set of

individuals in a system

that is each

A classifier

describes a set of

objects

an individual thing with a state and relationships to other objects.

An event

describes a set of

occurrences

something that happens that has some consequence within the system.

A behavior

describes a set of

executions

the performance of an algorithm according to a set of rules.

 

The ArchiMate standard divides “classifiers” into active and passive structures – that latter being data objects of some kind.

This means an EA model contains four major types of element; each models individuals in an incarnation of the business operations being modeled.

A type in a EA model

describes similar

instances in a real system

that each

An active structure

describes similar

actors, components or nodes

has a state and relationships to other actors.

A passive data object

describes similar

data structures or items

encodes meaningful information (and may be created, moved, changed or destroyed).

An event

describes similar

occurrences

triggers a process performance.

A behavior

describes similar

performances

runs from start to end according to business rules.

 

Premise: An architecture typifies concrete structures and behaviors (observed or envisaged)

Individual things in a real system are somewhat different from each other, and as UML puts it, “complete, precise, and concrete”.

An architecture definition is composed of types that generalise the properties things have in common, and as UML puts it, can be “incomplete, imprecise, and abstract”.

A type is often defined by its boundary, its interface, a list of event-triggered services or information exchanges.

 

Architects usually define structures and behaviors using general type names rather than particular instance names.

Sometimes however, they use the name of an individual structure or behaviour, especially where there is only one instance of a type in given context.

“Value, occurrence and execution specifications model individual objects, occurrences, and executions within a particular context.” UML

 

Premise: All behavior is event-driven, or discrete

The premise is that external events trigger internal actors or components to change the state of a system and/or provide services to external entities.

This is the premise of discrete event-driven system modelling in general, rather than any particular modelling language standard.

 

Premise: All behavior is performed by structural actors (active objects in UML; individually nameable actors, components and nodes in ArchiMate).

You might regard an individual actor or component as behavioral.

After all, it responds to messages, in the light of retained memories, by performing appropriate behaviors and sending messages.

However, although it has its own “thread of control”, it is called a structural element, because it can be addressed (located in space) and asked to do work (over time).

 

Countless business systems have been designed, built and operated on the basis of these premises.

Premises of EA in general

“Enterprise architecture … regards the enterprise as a system or system of systems” TOGAF 9.1

To begin with, the systems may be uncoordinated, overlap, duplicate, conflict or fail to share information.

The ultimate (never fully achievable) vision of EA is to unscramble this mess of systems.

To coordinate, de-duplicate and integrate distinct systems into one system, without duplication or disintegrity.

And to optimise and extend systems to the benefit of the business.

 

Premise: All behavior is performed by structural actors that embody structural roles

This table exemplifies the idea.

Behaviors

are performed by

actors that embody structural roles

Processes (value streams)

are performed by

Organisation units that embody Functions/Capabilities

Atomic actions

are performed by

Humans and Machines that embody Roles

 

Premise: A logical type is realised by one or more physical instance(s)

This table exemplifies the idea.

Logical  description/type

is realised by

physical instance(s)

Role

is realised by

Actor(s)

Function/Capability

is realised by

Organisation unit(s)

Event

is realised by

Occurrence(s)

Process

is realised by

Performance(s)

Data variable

is realised by

Data value(s)

 

The distinction between a logical description/type and a named entity/instance is fundamental to system definition.

An instance is defined by naming an individual system or component that realises a general type or interface.

See “Premises of TOGAF in particular”.

 

Premise: Systems and components are definable by the event-triggered services they provide

A logical type is often defined by its boundary, its interface, a list of event-triggered services or information exchanges.

This table exemplifies the idea.

Systems and components

are definable by

the event-triggered services they provide

Functions/Capabilities

are definable by

Business services

Application components

are definable by

Information services

Infrastructure technology components

are definable by

Platform services

 

Summary list of premises

The following premises provide a reasonable basis for business system modelling.

 

Abstraction of types

·         An architecture typifies concrete structures and behaviors (observed or envisaged)

·         A logical type is realised by one or more physical instance(s)

·         A role or component type describes (each member in a set of) similar actors or components.

·         A behaviour describes (each member in a set of) similar start-to-end or cyclical performances.

·         An event describes (each member in a set of) similar occurrences, which trigger behaviors.

Discrete event-driven behavior

·         All behavior is event-driven, or discrete

·         All behavior is performed by structural actors that embody structural roles

·         Systems and components are definable by the event-triggered services they provide.

Information

·         A data object contains a data structure or item that is meaningful and valuable information to its creators and users.

·         A message or data flow conveys a data object from a source to a target.

·         A memory or data store retains a data object for the use of actors or components performing behaviors.

Premises of ArchiMate and TOGAF in particular

The Open Group’s ArchiMate and TOGAF standards for EA contain much that illustrates the application of system theory to business systems.

The term “system” appears 1,357 times in TOGAF 9.1, including:

·          “Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems”

·          “Architecture descriptions are formal descriptions of a system.”

·         “Systems are built up from … building blocks [that] interoperate with other building blocks”

 

ArchiteMate’s core architectural entities can be arranged in a table reflecting the general premises of EA above.

Required services

assigned from

Logical components/interfaces

realised by

Physical components

Business services

assigned from

Business interfaces and Roles

realised by

Actors (organisation units or humans)

Application services

assigned from

Application interfaces

realised by

Application components

Technology services

assigned from

Technology interfaces

realised by

Technology components

 

Similarly, TOGAF’s core architectural entities can be arranged in a table reflecting the general premises of EA above.

Required services

result from

Behaviors

assigned to

Logical components/interfaces

realised by

Physical components

Business services

result from

Processes (or value streams)

assigned to

Functions (or capabilities)

realised by

Organisation units

Business services

result from

Processes (or process steps)

assigned to

Roles

realised by

Actors

Information system services

 

assigned to

Logical application components

realised by

Physical application components

Platform services

 

 

assigned to

Logical technology components

realised by

Physical technology components

 

The distinction between a logical description/type and a named entity/instance is fundamental to system definition.

In TOGAF, this distinction appears in the difference between a logical architecture definition and its physical realisation.

 

This table illustrates that one logical description/type may be realised by one or more named entity/instances (separately or collectively).

Logical Architecture Definition elements

Physical Realisations (named entities)

Function

"Sales"

Organisation unit

The Sales Department

Function

“Operations”

Organisation units

Production Dept and Logistics Dept (collectively)

Role

"CEO"

Actor

Geoff Bezos

Role

“Salesman”

Actors

Joan Soap, Joe Smith… (separately)

Logical application component

“CRM system”

Physical application components

Sugar CRM and Eloqua (collectively)

Logical application component

“Clearing system”

Physical application component

BACS

Logical technology component

“Message broker”

Physical technology component

TIBCO

Logical technology component

“RDBMS”

Physical technology component

DB2

 

Architects almost never refer to individual behaviors (event occurrences or process performances).

But they do sometimes name individual structures (actors, organisation units or components) and invariant values of individual data structures/items.

 

Architects may well know the names of candidate physical realisations during architecture definition in TOGAF phase A to D.

TOGAF discourages using those names in the Architecture Definition Document, with the exception of Organisation Unit names.

But those names are used from phase E onwards, when defining Solution Options and a Solution Architecture.

 

TOGAF aligns the terms “solution” and “physical” in some places.

Elsewhere, it aligns “solution architecture” with short/narrow project-level “capability architecture”.

Outside of TOGAF, others contrast tactical/narrow scope solution architecture and strategic/wide scope enterprise architecture.

For further reading: try Enterprise and Solution Architecture: How do they differ? and EA and TOGAF: How do they differ?

Further reading

You may regard the premises above as axioms.

Think of them as starting point, declarations rather than conclusion from references.

However, the paper refers to the UML, ArchiMate and TOGAF standards, which you can quickly find on the internet.

Readers familiar with any of those will recognise the application of the premises without further reading.

For references to EA history, this EA history paper concludes with a link to references.

For references to system theory and systems thinking, read papers 5, 6, 8 and 9 on this system theory page.

Premises wrt management science

A social system employs actors that play describable roles in describable processes.

E.g. consider an orchestra’s performance of a symphony.

The symphony score is a system description; every performance of that symphony instantiates that system description in reality.

A social entity is a group of actors who may chose their own behaviors, and may interact to reach aims they agree.

E.g. the group of actors hired to play in the orchestra, who might agree to go out for dinner after a performance.

 

EA regards the enterprise as a system, or system or systems, in which events trigger system state changes.

Describing a business system in terms of discrete entities and events is a necessary precondition of digitisation.

Reader: So this is what digitization implies!

Digitization occurs at the conceptual level, not just the physical level.

And part of what EA does is to determine what is digitizable.

 

At the same time an enterprise is a social entity, or collection of social entities.

To hugely over simplify:

·         EA is about the roles in the symphony (a social system)

·         Management is about the actors in the orchestra (a social entity).

 

Managers may decompose business goals and assign them to individual actors.

Managers can encourage actors to share the goals of the business, e.g. through team building.

They can also help actors reach their own goals (and not only by paying them).

A great deal can be achieved by good man management, but this is outside the scope of EA.

 

Human actors have personal goals or purposes above and beyond those of any social entity they belong to.

And of course they will act in ad hoc ways above and beyond any roles given to them.

But again, personal goals and ad hoc activities are outside the scope of what EA can design, plan and govern.

 

 

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.