Premises of Enterprise Architecture Models

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

Abstract: summary list of premises. 1

Beware analogies. 2

General premises for modelling system structures and behaviors. 2

Premises of EA in general 4

Premises of ArchiMate and TOGAF in particular 5

Abstract: summary list of premises

This paper concludes that the following premises provide a reasonable basis for business system modelling.

· An architecture typifies concrete structures and behaviors

· A logical type is realisable by one or more similar things

· A role lists activities performable by similarly able actors

· A behavior describes similar start-to-end or cyclical performances

· An event describes similar occurrences, which trigger behaviors

· All behavior is event-driven, or discrete

· All behavior is performed by actors that embody roles

· Systems and roles are definable by input/output services

· Data is meaningful/valuable information to its creators and users

· Messages/data flows convey data from sender to receivers

· Memories/data store retain data for the use of actors performing behaviors

Beware analogies

An architecture typifies concrete structures and behaviors

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

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.

A logical type is realisable by one or more similar things

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.

The standard can be paraphrased as saying an EA model contains four major types of element.

Each of those 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.

Key premises summarised here include:

· A role lists activities performable by similarly able actors

· A behavior describes similar start-to-end or cyclical performances

· An event describes similar occurrences, which trigger behaviors

An architecture typifies concrete structures and behaviors

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

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.

All behavior is performed by actors that embody roles (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.

All behavior is performed by actors that embody 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

A logical type is realisable by one or more similar things

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

Systems and roles are definable by input/output services

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

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?

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.

Abstract: summary list of premises

Beware analogies

General premises for modelling system structures and behaviors

Premises of EA in general

Premises of ArchiMate and TOGAF in particular

Further reading

Premises wrt management science