EA meta model comparison (older paper – not entirely superseded by new ones)

This page is published under the terms of the licence summarized in the footnote.

 

Abstract

This document is a guide to building a formal or quasi-formal enterprise architecture description, based on a meta model.

 The guide compares and contrasts several approaches to enterprise architecture description.

Two of them (CAM and SAM) are based on the idea that the meta model is paramount – should be defined before anything else.

 

Contents

EA meta model comparison (older paper – not entirely superseded by new ones)

Three EA frameworks to be explored

Why an enterprise architecture meta model?

Enterprise architecture description as a process

Enterprise architecture meta models

Enterprise architecture ingredients

Classifications of ingredients

Mapping ingredients to architecture domains

Hierarchical structures of ingredients

Relationship-level models

Display-level models

Business patterns

About dimensions

About the level idealization

About the process-system dichotomy

About the analogous architecture domains

About the effects of time

Is there a universal meta meta model?

 

 

Three EA frameworks to be explored

TOGAF 8 architecture models and views

TOGAF 8 talks a lot about models and views.

It does not include a meta model in the form of a diagram that relates the concepts in these models and views.

Nevertheless, it is easy to define the TOGAF 8 meta model, as we shall see.

CAM (Crompton Architecture Metamodel)

Allister Crompton developed CAM to capture the essence of his experience in a series of enterprise architecture assignments.

It is designed to be a ready-to-go model that he or you copy and customise for the next enterprise architecture assignment.

It is relatively specific.

 

This document describes an extensive (though not exhaustive) meta model which Allister Crompton has built up.

This implements many business architecture aspects.

It has evolved, and is still evolving, over many assignments to support varied architecture description requirements.

This document lists around 50 “Facts”, which may be assembled into any number of different Views, The actual number will depend on the architect’s role and the assignment’s specific requirements.

To learn more about CAM, find/ask Allister Crompton (sorry I can’t maintain links in this old paper).

SAM (Strategic Architecture Model)

SAM is more generic than CAM.

Bob Jarvis developed SAM as a distillation of many years of architectural description experience starting with Modular Programming and Structured Analysis and Design in the 1970s, through Data Modelling and Information Engineering in the 1980s to CBD, BPR and other TLAs in the 1990s through to SOA today.

SAM is the methodology implemented in the Strategy SAVI™ architectural tool.

(Google “systems-advisers”, since I can’t maintain hyperlinks in this old paper).

 

A specific version of SAM is MAP (the Microsoft Architecture Paradigm).

In 2000/1.

Microsoft had flirted with the Zachman Framework but were somewhat disenchanted.

Bob Jarvis developed MAP for Microsoft in 2000/1 for internal use by enterprise and strategy architects and it is still used today in Microsoft by a handful of senior, business-facing architects.

 

The major use of SAM today is in defining Business Patterns, discussed at the end of this document.

The major business pattern developed with SAM/MAP is Microsoft’s “Connected Health Framework” published in 2006 and available in the public domain

To learn more about SAM, then contact find/ask Bob Jarvis (sorry I can’t maintain links in this old paper).

Why an enterprise architecture meta model?

How can you plan changes to a structure if you don’t know what the structure is?

How can your IS/IT department plan solutions that are optimal for the enterprise (rather than suboptimal and localized) without an enterprise-wide repository of its data processing assets?

Every enterprise should record its assets – at least at an overview level.

 

An architecture description is a model  of a system – it is a restricted view of reality - it does not tell you everything, but it should tell you what you need to know to make well-informed judgements about – for example – the impact of a change.

It also helps you plan ahead.

 

In the philosopher’s “eternal golden braid” there are things, descriptions of things, and descriptions of descriptions.

An architecture description contains a collection of artifacts that are related to each other directly or indirectly.

You simply cannot manage a large and complex architecture description without describing the description itself.

 

The description of description, or model of a model, is known here as a meta model.

A meta model can help you manage documentation in Word and Excel.

But if you store your description in a CASE tool, then the meta model is not just helpful, it is essential.

 

If you want to know more answers to the question in the title, read the Architecture Repository Challenges paper.

That paper is divided into four sections, on:

  • The importance of a repository to enterprise architecture
  • The process of creating your architecture repository.
  • Ten challenges that must be overcome if you intend this repository to be enterprise-wide.
  • CASE tool selection issues.

 

An enterprise architecture methodology involves a process and a product.

The product is an enterprise description.

This is itself defined in a meta model.

Enterprise architecture description as a process

An enterprise architecture repository contains a vast number of ingredients (users, computers, entities, processes, etc), all connected to each other directly or indirectly.

To document a specific enterprise architecture you can:

  • Record the elementary ingredients (users, computers, etc) in distinct lists.
  • Arrange any single list of ingredients in a structure, be it a hierarchical structure or a network structure.*
  • Relate any 2 kinds of ingredient to each other in a relationship-level model, typically drawing a table or a network structure diagram to do this.
  • Build and display many display-level models that show 2, 3, 4 or more ingredients related to each other, typically drawing a network structure diagram to do this.
  • Present 3 or 4 perspectives of the full architecture repository in distinct documents.

 

* It is usually not enough to make a plain list of ingredients - of users, of computers, whatever.

You need to consider the relationships between ingredients of a given type, and record them, perhaps in a network diagram.

And where there are many of them, you need to consider imposing a hierarchical structure, so you can relate things at a higher level of abstraction.

See the later section of this document.

Enterprise architecture meta models

An enterprise architecture meta model is a kind of data model that shows the ingredients of an enterprise architecture, and all the relationships between them that are possible and useful to know about.

Allister Crompton lists his relationships in a table like this.

 

Facts in a meta model

Term

relates to

Term

Aggregate entity

comprises

Logical Entity

Application

accesses

Data Store

Application

automates

Process

Application

available over

Network

Application

interfaces with

Application

 

An enterprise architecture repository is predicated upon an enterprise architecture meta model.

You have to:

  • Define Terms for the kinds of elementary ingredient you want to document.
  • Define the Facts the relationships between ingredients that matter to you.

 

Having done this, you can build Views that show any selection of Terms and Facts that matter to you or another interested party.

The table above is at the “relationship-level”.

The rest of this document explores the four different levels of enterprise architecture meta model

 

TOGAF 8

SAM

CAM

AM

Report level

4 Perspectives

4 Perspectives

undefined

3 Perspectives

Display level

undefined

Cascade report

n-dimensional View

undefined

Relationship level

undefined

Relationship

2-dimensional View

Fact

Ingredient

undefined

Structure

Term

Term

 

Let us look at the ingredients in more detail.

Enterprise architecture ingredients

Let us compare the elementary ingredients of the four enterprise architecture frameworks acknowledged as sources.

SAM “structures”

Bob Jarvis’s SAM is based on ingredients he calls “Structures”.

 A “Structure” is defined as a “Tree” structure with a number of levels.

The bottom level contains the atomic “members” of the structure.

The intermediate levels are summarisations thereof.

Bob usually presents SAM using 10 structures – these are generalizations that Bob manipulates to fit the bill of the given enterprise architecture assignment.

The table below names the 10 ingredients.

SAM structures

Objective or Goal

Organisation

Business Function

Business Process

Business Component

Data

Application

Technology

Infrastructure

Programme/Project

Remember that each structure can be decomposed.

So data can be a data store, an aggregate entity, or an entity.

And business process can be a system use case.

TOGAF 8 artifacts

TOGAF 8 is not explicit about its meta model, but more than a dozen ingredients are apparent from study of its text.

TOGAF 8

 

Object

Notes

Application

TOGAF 8 provides a template to define these.

Application Platform Service

 

Business Function

 

Business Service

 

Data Entity

 

Data Source

mostly databases

Event

 

Function

 

Goal

 

Location

 

Measure (SMART)

 

Network

 

Objective

 

Organization Unit

 

Process

 

Role

 

Security Level

 

Standard

 

Technology

TOGAF 8 provides a template to define these.

Time Period

 

CAM Terms

Allister Crompton’s CAM is based on 28 ingredients known as “Terms” - the things that Allister has found he most often needs to define in practical enterprise architecture assignments.

CAM

CAM

Term

Notes

Goal

 

Objective

 

Critical success factor

The realization of some part of a strategic business goal/objective that has a significant impact on a business’s market status, e.g., increasing production, decreasing cost.

Marketing aim

 

Standard

A standard or regulation to which a business must comply.

Critical assumption

 

IT system

 

Product

 

User

 

Supplier

 

Interested party

 

Business process

An operation within a Function or spanning Functions, usually manual, i.e., carried out by a person, describing a specific unit of work with a defined start and finish.

Increasingly, a business process is partly automated by mechanical devices and/or computer(s).

Business

 

Function

 

Location

 

Aggregate entity

A group or composite of smaller ‘logical’ entities.

Data store

A place where data/information can be stored, maintained and accessed.

Logical entity

A data group close to the level of third normal form, usually stored in a single database table.

Application

 

Computer

 

DBMS

 

Language

A computer programming language

Network

 

Peripheral

 

Platform

 

Protocol

A standard sequence and pattern that enables two parties to communicate.

Security facet

A hardware device or software program that protects a target from unauthorised or malicious access.

UI (OS)

UI operating system

Fact

A sentence or phrase that relates one term to another term.

 

When we place these Terms in the architecture domains, it becomes clear that Allister has focused on the business and technology perspectives.

Classifications of ingredients

To assist comparison, the table below classifies “structures” in SAM, ingredients of TOGAF 8 and “terms” in CAM to areas of concern mentioned in our “Architecture Framework Visualisations”.

 

Bob Jarvis

The Open Group

Allister Crompton

 

SAM

TOGAF 8

CAM

Concern

Structure

Ingredient

Term

Stakeholders

 

 

Interested Party

 

 

Role

User

 

 

 

Supplier

Precursors

Objective or Goal

Goal

Goal

 

 

Objective

Objective

 

 

Measure (SMART)

Critical Success Factor

 

 

 

Marketing Aim

 

 

 

Standard

 

 

 

Critical Assumption

Scope

 

 

IT system

 

Business Service

Product

Processes

Business Process

Process

Process

Organizations

Organisation

Organization Unit

Business

Business Function *

Business Function

Function

Locations

Infrastructure

Location

Location

Data

Data

Data Source

Data Store

Business Component *

 

Aggregate entity

 

Data Entity

Logical Entity

 

 

Security Level

 

 

 

Event

 

Applications and components

Application

Application

Application

Function

 

Technologies

Technology

Technology

Computer

 

 

DBMS

 

 

Language

 

Network

Network

 

 

Peripheral

 

Application Platform Service

Platform

 

Standard

Protocol

 

 

Security Facet

 

Time Period

UI (OS)

Operations

 

 

 

Plans

Project plan

 

 

 

* Business component is an interesting concept.

It can be regarded as a low-level Organisation Unit – an automated business function - one that provides data update and retrieval services to any client that asks for them.

It can be regarded as a kind of application.

At the same time, it encapsulates what Allister calls an aggregate entity.

 

Bob’s structures are more abstract than Allister’s Terms.

I have placed each of Bob’s structures in the one cell where it seems most at home, except for a few which seem equally at home in two cells or several cells.

Mapping ingredients to architecture domains

We could try to map our ingredients to any or all of the scales mentioned in our architecture visualisations, but we’re going to pick only one – the architecture domains.

You’ll see that terms or structures in one domain have relatives in other domains.

Most obviously, things we want to model in the business domain have counterparts in the information system domain.

SAM structures in the architecture domains

This table places Bob’s Structures in the three architecture domains.

Business

IS development

IT operations

Objective or Goal

Business organisation

Business Function

Data

Application

 

Technology

 

 

 

Business Component

Business Process

 

Programme/Project

Infrastructure

 

Infrastructure

 

SAM is very much focused on business and IS concerns, much less on technology and IT operations.

 

Bob’s structures are more abstract than Allister’s Terms.

I have placed each of Bob’s structures in the one cell where it seems most at home, except for Infrastructure and Business Process, which seem equally at home in two cells.

Some other structures could be placed in several cells.

TOGAF 8 objects in the architecture domains

This table places TOGAF 8’s ingredients in the three architecture domains.

Business

IS development

IT operations

Business goals

Business objectives

Measure (SMART)

Business services

Business roles

Business processes

Business functions

Organisation units

Locations

Time Period

Role (user)

Data entities

Data sources

Events

Security Level

Applications

Function

Application Platform Service

Standard

Technologies

Networks

 

Like SAM, TOGAF 8 is focused on business and IS concerns, much less on technology and IT operations.

CAM terms in the architecture domains

This table places CAM Terms in the three architecture domains.

Business

IS development

IT operations

Goal

Objective

Critical Success Factor

Marketing Aim

Standard

Critical Assumption

Supplier

Interested Party

Business

Location

Product

Process

Function

User

Logical Entity

Aggregate Entity

Data Store

Application

 

Protocol

DBMS

Language

Security Facet

Computer

Platform

Peripheral

UI (OS)

Network

 

Allister’s Terms are reasonably specific.

So I have placed each in the one column where it seems most at home.

Some Terms could be generalized a little and placed in several cells, but I have not done this.

 

You can see that Allister has been led by business people to focus on marketing aims, and led by technical architects to distinguish technology types.

And while CAM does classify a range of technologies, it isn’t concerned with the IT services management organisation.

Hierarchical structures of ingredients

It is rarely enough to make a plain list of ingredients - of users, of computers, of entities.

You ought to consider the relationships between ingredients of a given type, and record them.

 

Bob encourages people to draw hierarchical structures, and to impose a hierarchical structure on elementary ingredients? Why? Sometimes because the higher level nodes in the structure represent things in the real world – say a location where several computers are housed.

Sometimes just to manage scale and complexity.

The architect must sometimes map relationships between ingredients at a summary level to avoid humungous models that are difficult to populate and maintain.

 

This implies a meta model of this kind.

Term

groups

Term

Business

Subdivided into

Business

Goal

Met by group of subordinate

Goal

Process

Decomposes into

Process

 

Or more generally

Node of structure (higher)

Groups

Node of structure (lower)

 

Although a tree is hierarchical you can also model network structures by drawing a redundant hierarchy with duplicate entries, or showing recursive relationships within the tree structure.

In short, where there are many ingredients of a type, you need to consider imposing a hierarchical structure, so you can relate things at a higher level of abstraction.

See our paper on “Composition Hierarchies” for more detailed discussion.

 

Of course, a structure may be reduced to its most trivial form - a flat list.

Relationship-level models

We have already seen that ingredients can be related.

Bob tends to assumes that ingredients of the same type can and should be related in hierarchy.

That’s why he calls them structures.

 

Grouping and relating ingredients of one kind is only the start.

The enterprise architect is interested in the relationships between ingredients of different types – and understanding these is the key to building and using an effect enterprise architecture repository.

Avancier

Bob Jarvis

The Open Group

Allister Crompton

AM

SAM

TOGAF 8

CAM

Concern

Structure

Ingredient

Term

Mappings

Relationship

Matrix

Fact

SAM Relationships

A Relationship is a 2-dimensional association between Structures.

Given 10 structures, there is a very much larger number of possible Relationships.

 

Bob Jarvis has defined 11 Minimum Essential Relationships, listed in the table below.

Bob considers the first 3 relationships in bold to be the essence of the essence, and they underpin his efforts to define business patterns.

Structure

Relates to

Structure

Business Process

Executes

Business Function

Business Function

Needs or produces

Data

Business Component

Encapsulates

Data

Business Process

Decomposes into

Business Process

Business Function

Invokes

Business Component

Business Component

Used in

Application

Application

Runs on

Technology

Project

Needs

Technology

Project

Changes

Application

Project

Meets

Objective

Business Process

Meets

Objective

 

A user may define more than these essential Relationships.

The number will depend on the user’s role and the assignment’s specific requirements.

Bob’s structures are more generic than Allister’s Terms, which explains why Bob is less specific about the nature of the relationships.

As Bob says “The model is NOT fixed.

SAM gives you the ability to build the model you want (even Zachman).

Thus you can accommodate your own concepts, terms and views without problem – all you do is define your particular model.

So, the structures and relationships I suggest are just that – suggestions.

They are based on experience of what customers usually want and are actually able to build without great research.

Fine-graining the definitions is up to you. Granularity is up to you.  The particular views offered are up to you.”

 

How to document and present relationships?

Ideally, you want the freedom to present any relationship in a table, hierarchy or network diagram form.

Bob recommends a variety of UML and other diagram types.

Bob’s tool, Savi, can present a relationship in the form of a table or a hierarchical cascade list

TOGAF 8 Facts

People say TOGAF 8 has no meta model.

True there is no published data model or class diagram.

But a meta model can be easily drawn from those phrases in the text (like Application deployed on Technology) that reveal the terms and facts agreed by domain experts.

Even better, the TOGAF 8 authors have provided lists of Architecture Views and Application and Technology templates which reveal the terms and facts that matter most in TOGAF 8.

CAM Facts

A Fact is a 2-dimensional association of Terms.

Given only a few Terms, there is a large number of possible Facts.

Allister has defined more than 50 Facts that he has found useful.

A user may only use a fraction of these Facts.

The number will depend on the user’s role and the assignment’s specific requirements.

Term

relates to

Term

Aggregate entity

comprises

Logical Entity

Application

accesses

Data Store

Application

automates

Process

Application

available over

Network

Application

interfaces with

Application

Application

resides on

Computer

Application

services

User

Application

used at

Location

Application

written in

Language

Business

contracted by

Critical Assumption

Business

contracted with

Business

Business

generates

Product

Business

initiates

Marketing Aim

Business

involved with

Interested Party

Business

must realize

Critical Success Factor

Business

works to

Standard

Computer

communicates with

Computer

Computer

distributed across

Network

Computer

enhanced by

Peripheral

Computer

housed at

Location

Computer

incorporates

DBMS

Computer

used via

UI (OS)

Data store

relates to

Data Store

Data Stores

reside on

DBMS

DBMS

interrogated by

Language

Function

supported

Process

Goal

achieved by completion of

Objective

Goal

decomposes into

Goal

Goal

realizes future for

Business

Interested Party

achieves

Goal

Interested Party

initiates

Marketing Aim

Interested Party

interacts with

Interested Party

IT system

runs on

Platform

Location

found in

Location

Logical Entity

is associated with

Logical Entity

Network

extends operation to

Location

Network

has attached

Peripheral

Network

implemented via

Protocol

Network

interlinks with

Network

Network

used via

UI (OS)

Peripheral

housed at

Location

Peripheral

makes use of

Peripheral

Platform

built from

Computer

Platform

built from

Peripheral

Platform

comprises

Platform

Process

affects

Process

Security Facet

protects

Network

Supplier

supports

Function

UI (OS)

includes as a component

UI (OS)

User

carries out

Function

User

interacts with

User

User

meets

Objective

User

populates

Data Store

User

works for

Business

User

works in

Location

 

How to document and present Facts? Ideally, you want the freedom to present Facts in

  • a table,
  • a hierarchy or
  • a network diagram.
  •  

Allister usually documents and presents Facts using a tool designed to draw a network structure diagram – which can show lists and hierarchies of course.

Display-level models

SAM Cascades

A Cascade is an n-dimensional hierarchy of Relationships.

The number of possible Cascades is large.

TOGAF 8 Architecture domains or reports

TOGAF 8 presents an architecture in four reports, each for one of four architecture domains.

CAM Views

A View is an n-dimensional cluster of Terms and Facts.

There is a vast number of possible Views.

The actual number will depend on the user’s role and the assignment’s specific requirements.

Allister has – over several years - used about 30 Views in his enterprise architecture assignments.

A user may only use a fraction of Allister’s default Views.

The table below shows what 9 of these default Views contain.

The rest are shown in the associated training course.

Business Views

Term

Relates to

Term

Business Geography

Location

Found in

Location

User

Works for

Business

User

Works in

Location

Business Organisation

 

User

Interacts with

User

User

Works for

Business

Business Standards

Business

Works to

Standard

Market Context

 

Business

Contracted with

Business

Interested Party

Interacts with

Interested Party

Business

Involved with

Interested Party

Market Initiatives

 

Business

Initiates

Marketing Aim

Interested Party

Initiates

Marketing Aim

Business Strategy

 

Business

Contracted by

Critical Assumption

Business

Must realize

Critical Success Factor

Goal

Realizes future for

Business

Market Strategy

Interested Party

Achieves

Goal

Goal

Decomposes into

Goal

Goal

Realizes future for

Business

IS Views

Term

Relates to

Term

Application Architecture

Application

Interfaces with

Application

Application Data Access

 

Application

Available over

Network

Application

Interfaces with

Application

Application

Accesses

Data Store

Ideally, you want the freedom to present any View in a list, table, hierarchy or network diagram form.

Crompton presents a Crompton View in a network diagram (which can accommodate lists and hierarchies).

Business patterns

A major use of SAM today is in defining Business Patterns.

A business pattern is “a business function related to data, encapsulated as business components which offer services.”

In other words, the enterprise architecture meta model of a business pattern features only these three structures and three relationships.

 

Term

Relates to

Term

Business Process

Executes

Business Function

Business Function

Needs or produces

Data

Business Component

Encapsulates

Data

 

Of course these three structures and their relationships as just a small part of the overall enterprise architecture repository.

And further mappings can be made to enterprise-specific structures such as organisation, applications and technology.

 

The benefit of the business pattern is that it supplies a template for a particular industry or type of enterprise and thus saves time and improves quality.

At the level of business function and data, one bank, or airline, is pretty much like another so why reinvent the wheel.

 

A recent example of a business pattern is contained in Microsoft’s “Connected Health Framework” (CHF), which describes business and technical frameworks for patient-centric healthcare.

The CHF documentation is publicly available (sorry I can’t maintain links in this old paper).

The CHF has now been presented in detail to healthcare organisations in over 20 countries worldwide and is being used by several as the basis for the design of national-scale patient record and healthcare management systems.

 

SAM (or strictly its MAP variant) was used to define 18 business components, such as

  • “Patient Identity”,
  • “Care Pathways”.
  • “Clinical Processes, etc.

 

These are defined in terms of the three structures and their inter-relationships detailed above and provide an indicative set of business services required for patient-centric healthcare systems.

These form an essential input to the design of a service-oriented architecture.

About dimensions

Architecture frameworks like those of Zachman and TOGAF feature several dimensions of architecture definition.

Our “Architecture Framework Visualisations” include the nine scales listed below.

 

  • Roles:  Enterprise Architect -- Solution Architect -- Software Architect -- Technical Architect.
  • Stakeholders:  Owner -- Manager -- Buyer -- Supplier -- Designer -- Builder -- Tester -- User -- Operator -- Maintainer.
  • Breadth:  Business-wide -- Division or line of business -- Department.
  • Timescale:  Long term or strategic target -- Short term or tactical target -- Change to baseline.
  • Height or domain:  Business people and process -- Software application -- Technical infrastructure.
  • Idealisation:  Conceptual model -- Logical model -- Physical model -- Physical material.
  • Generalisation:  Universal -- Fairly generic -- Fairly specific -- Uniquely configured.
  • Composition:  Coarse-grained composite -- Mid-grained composite -- Fine-grained composite -- Elementary part.
  • Omission of detail:  Nominal -- Sketchy -- Elaborate -- Complete.

 

This section is not an exhaustive analysis of these dimensions.

It contains only a few notes of interest.

About the level idealization

Most if not all the ingredients we want to include in an enterprise architecture repository can be specified at both logical and physical levels.

A business process can be specified at logical level, then realized as a top-level procedure in a workflow system.

Similarly there are logical and physical levels in the specification of use cases and data models.

 

This table suggests some words tend be used at either logical or physical levels.

Logical word

Business Function

Business Process

?

Data Model

Physical word

Organisation unit

Workflow

Application

Database Schema

 

This section goes on to contrast physical organisation units with logical business functions.

 

Consider this end-to-end business process (or value stream):

1 Design advertisement.

2 Publish advertisement.

3 Capture reply to advertisement.

4 Call customer.

5 Take order.

6 Deliver service.

7 Bill for service.

8 Collect payment.

 

Clearly, the steps in this business process will be carried out (executed) by people in working in different organisation units.

  • Marketing,
  • Sales,
  • Delivery,
  • Accounts
  • Other (Legal Affairs, Personnel and Payroll).

 

You define an organisation unit because you expect that unit to be realized, to have a mission statement, a manager and employees.

You envisage its employees will be asked and guided to execute (parts of) the business processes.

 

However, you may also choose to define purely logical business functions.

Think of these as idealized organisation units.

Talking about business functions helps you to communicate with business people, without debate about the existing organisation structure, and without committing yourself to a new organisation structure.

And an attraction of discussing logical business functions is that they change less rapidly than the management hierarchy.

 

You can map logical business functions to organisation units and/or business processes as an analysis exercise.

Ultimately however, you have to map business processes to physical organisation units.

 

The only way to realize a business function is to give it a mission statement and a manager.

And if/when you do this, then the logical business function becomes realized as a physical organisation unit in the organisation structure.

About the process-system dichotomy

In the processing space there are two and only two kinds of thing:

  • Processes – procedures describable in flow charts.
  • A process is triggered by a start event and runs from start to end, when it delivers an output.
  • We define a process to deliver a required output or result.
  • Systems – entities that are defined by their I/O interface and implemented to execute processes.
  • We define a System to be a manageable and deployable grouping of processing capability.
  • Systems are (at least roughly) encapsulated subsystems.

 

At a high level of abstraction, Business Processes, Use Cases and individual Business Services are all the same, they are 'processes'.

Staying at that high level of abstraction, Organisation units, Business Functions, Applications and Business Components are the same.

They are all "systems" or "components".

The table below summarizes this view.

System (or component)

Process

Business Function / Organisation unit

Business Process

Application

Use Case

Business Component

Singular Business Service

About the analogous architecture domains

Terms or structures in one domain can have relatives in other domains.

Most obviously, things we want to model in the business domain have counterparts in the information system domain.

E.g.

Organisation units are close relatives of applications.

Both are created to execute processes.

Organisation units execute steps in business processes.

Applications execute steps in use cases.

 

Consider again the end-to-end business process (or value stream) introduced earlier:

1 Design advertisement.

2 Publish advertisement.

3 Capture reply to advertisement.

4 Call customer.

5 Take order.

6 Deliver service.

7 Bill for service.

8 Collect payment.

 

Now consider the Organisation units and applications that might be involved in this end-to-end process.

Organisation units and business processes

Applications and use cases

Organisation units are things like Marketing, Sales, Delivery, Accounts, Legal affairs, Personnel, Payroll.

 

Applications may be centered on Adverts, Orders, Expenses.

But applications are often given funny names so you can't tell what they do.

Many business processes are performed entirely within one Organisation unit.

Many use cases are performed entirely by one application.

However, some business processes span Organisation units.

However, if you define a workflow to support an end-to-end business process, then that workflow (that use case) may involve several applications.

The steps in our end-to-end business process will be carried out (executed) by people in working in different Organisation units.

The steps in our end-to-end workflow will be carried out (executed) by processes in different applications.

An organisation unit encapsulates the processes that it performs.

Some are whole processes.

Some are steps within a wider end-to-end process, of the kind above.

So, you can define an organisation unit by defining its interface, the inputs and outputs of the processes it performs.

An application encapsulates the processes that it performs.

Some are whole use cases.

Some are steps within a wider end-to-end workflow, of the kind above.

So, you can define an application by defining its interface, the inputs and outputs of the processes it performs.

 

Broadly speaking, Organisation units and applications are both “components”.

An Organisation unit is a component of a human activity system in the business architecture.

It is a processing body.

It is formed for the purpose of executing some business process(es) or parts of business processes.

A software application is a component of a software system in an IS architecture.

It is a processing body.

It is formed for the purpose of executing some business process(es) or parts of business processes.

Organisation units are specified (if only in a summary level mission statement).

Applications are fully detailed in code.

Organisation units are assigned to people (processors) in one or more divisions of the organisation structure for execution.

Applications are assembled and deployed on one or more nodes (processors) in the IT infrastructure for execution.

 

An application offers, to actors, a set of use cases that are related in some way (perhaps draw on and update the same data store.).

An application is a high-level component.

Within an application, we may define smaller business components that each encapsulate a data structure (defined as an entity or aggregate entity).

About the effects of time

The effects of time on meta models

Enterprise architecture processes suggest you maintain architecture descriptions at two or more states

  • The baseline (current) state
  • Any number of Intermediate states
  • The target (required) state

 

The trouble is that many of the ingredients, structures and relationships will remain stable from one state to the next, and none of the popular CASE tools really helps maintain these across several versions.

Even more worryingly, your meta model tends to change through the process of architecture definition…

The effects of time on meta models

Most architecture methods speak of migration from a baseline architecture to a target architecture.

It is clear therefore that the enterprise architecture description changes over time.

An architect may be passive, merely record the changes, or may be active, may plot the migration path from the foundation architecture to the target architecture.

There is a distinct guide to planning an architecture migration.

 

Less obviously, the enterprise architecture meta model changes over time.

The facts you want to record in an early or high-level architecture are not the same as the facts you want to record in a detailed solution architecture.

It is impossible to prescribe an enterprise architecture meta model that will work for you at every level and every stage of architecture definition.

 

This is a complex topic.

If we try to think and talk about concepts like Business Process, Organisation unit and Business Component at every possible level of granularity all at once, then the discussion becomes impossibly hard to follow.

So let us say that:

  • A Business Process is an end-to-end process in a human activity system that is supported in some steps by information systems.
  • An organisation unit is for example: Marketing, Sales, Delivery, Accounts
  • A Business Component is software that encapsulates Business Data.

 

There may be current and required versions of all of these.

There can be real/current/foundation Business Processes (the ones we find in the current business) and ideal/required/target Business Processes, which our business process engineers regard as a more optimal.

On the other hand, we may have no Business Components at the moment, meaning the Data is not yet encapsulated.

How "essential" relationships change over time

The primary high level relationship is between Organisation units (or Business Functions if you prefer to idealise the organisation) and Business Processes.

 

You may start by saying

Intermediate analysis

You may end by saying

An organisation unit uses legacy Applications.

 

 

abstract from Applications to Business Processes.

define the required Business Processes and identify the new Applications needed to support them.

An organisation unit uses target Applications.

 

A different set of applications.

An organisation unit needs and produces Data.

define Applications and Business Components which perform CRUD actions on the Data.

An organisation unit is supported by Applications, which invoke Business Components, which encapsulate Data.

 

The original relationship is indirect.

You should maintain indirect relationships in your meta model only if they add more information, or you know you can manage their consistency with direct relationships.

 

What you end up with

By the end of analysis and design, you might be able to say that:

  • A Business Process has a start and end, a sequence, logic and rules.
  • An organisation unit executes (at least some parts of) Business Processes.
  • An organisation unit, Application or Component has a specification aspect that defines the services it offers.
  • (In the case of an organisation unit, the specification may be little more than a mission statement).
  • An organisation unit, Application or Component has an implementation aspect that fulfils or realises the specification, and requires a platform to do this.
  • An organisation unit requires a human world platform (staff, buildings, HR, payroll).
  • An Application or Business Component requires a computer platform (see below).
  •  
  • An Application has a user interface for humans to access it, and so requires a platform with a UI OS.
  • A Business Component encapsulates Data, and so requires a platform with a DBMS.

 

The initial state of the world is different.

E.g.

  • before you introduce Business Components to encapsulate all the Data, you have to say an Application requires DBMS(s)
  • before you mention Applications, you may say that an organisation unit requires computer platform(s).

 

Again, it is impossible to prescribe an enterprise architecture meta model that will work for you at every level and every stage of architecture definition.

Is there a universal meta meta model?

Some people find it frustrating that we do not prescribe a universal enterprise architecture meta model.

Some reasons were given in the previous section.

This appendix is only a short discussion for people who still hope there is a scheme that is more fundamental and universal than the ones defined earlier.

 

The BAF features 12 areas of concern.

These 12 areas were not defined in an ad hoc way; they were defined by mapping practical architecture definition work to 7 concepts that most people regard as fundamentally different from each other.

Goals

People

Systems

I/O

Processes

Data

Locations

 

A Technology is really a subclass of System, but for convenience, people normally treat Technology as an 8th fundamental concept.

So, if our meta meta model has 8 concepts, can we map our schemes to them? The table below maps CAM terms to the 8 fundamental concepts.

Goals

People

Systems

I/O

Processes

Data

Locations

Technology

Goal

Business

Product

Business Process

Data Store

Location

DBMS

Objective

Interested Party

Business Function

 

 

Aggregate Entity

 

Language

Critical Success Factor

User

Application

 

 

Logical Entity

 

Security Facet

Critical Assumption

Supplier

 

 

 

 

 

Platform

Standard

 

 

 

 

 

 

Peripheral

Marketing Aim

 

 

 

 

 

 

UI (OS)

 

 

 

 

 

 

 

Network

 

 

 

 

 

 

 

Computer

 

 

 

 

 

 

 

Protocol

 

The gap analysis does highlight one point worth noting.

CAM is typical of enterprise architecture frameworks in that it treats inputs and outputs very lightly.

Methodologists often placed input and output as an after thought under the heading of data, alongside data stores and data models.

Yet output is the whole purpose of a system, and input is the price we pay to get output.

 

The table below shows it is possible to map Allister’s 8 or 9 technologies to the other 7 fundamental concepts, thus:

Goal

People

System

I/O

Process

Data

Location

Technology

Security Facet

Peripheral

Computer

Platform

UI (OS)

Protocol

Language

DBMS

Network

 

 

In practice, a security facet can appear in any column.

 

So, if you are looking for a universal meta model, you might consider one based on the 7 or 8 concepts in this section.

However, this guide is based on practical experiences, and earlier sections presented schemes people have found useful.

 

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

 

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org