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