A Conceptual Framework for Enterprise Architecture

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

All free-to-read materials on 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.co.uk in whichever social media you use.


“The method proposed by systems theory is to model complex entities (multiple interacting components) by abstracting from certain details of structure and component.” (Laszlo and Krippner).


The essence of this conceptual framework for the architectural description of an enterprise or system is this:

·         Customers/users <require the products of> regular behaviors.

·         The behaviors <are assigned for performance to> logical components.

·         The logical components <are realised by hiring, buying or building> physical components.


This paper explores what “component” means, and how component description may proceed.

It is one of more than 200 papers on http://avancier.website that you might find helpful.


EA as the description and coordination of digitisable business systems. 1

A service as a discrete behaviour 1

A subsystem as an active system component 2

Component interoperation, as specified in interfaces. 3

Common attributes of components. 3

Components as described in architecture phases. 4

A controlled vocabulary. 5


EA as the description and coordination of digitisable business systems

The word “architect” comes from the Greek “master builder”.

In enterprise and solution architecture, the buildings are business systems.

TOGAF says: “Enterprise architecture structures the business planning [and] regards the enterprise as a system or system of systems.


Enterprise architecture aims to support, enable and improve business roles and processes that are repetitive and regular enough to be systematised and digitised.

It is prominent, even strategic, in banks, telcos and government departments.

These are “information-intensive organisations”; their business depends on data processing.

As such, they have always been well-placed to systematise and digitise their core business processes.

Nowadays, digitisation of business roles and processes is considered important to every kind of enterprise.


·          "Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (“EA as Strategy” Ross, Weill and Robertson)

·          “Enterprise Architecture is the determinant of survival in the Information Age.” (John Zachman)

·          “Today’s CEOs know that the effective management and exploitation of information through IT is a key factor to business success.” (TOGAF)

·         “The domain of information-intensive organisations…is the main focus” (The ArchiMate modelling language standard v2.1)


Enterprise architecture also aims to standardise and/or integrate business processes.

“The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.” TOGAF

A service as a discrete behaviour

 “The principal heuristic innovation of the systems approach is what may be called ‘reduction to dynamics’ as contrasted with ‘reduction to components’ ” (Laszlo and Krippner)

"Cybernetics does not ask "what is this thing?" but ''what does it do?" It is thus essentially functional and behaviouristic.” (Ross Ashby)

“[Cybernetics] deals with all forms of behaviour in so far as they are regular, or determinate, or reproducible.” (Ross Ashby)


What a business does is partly ad-hoc, informal or unpredictable, and therefore un-architectable.

Architects focus on regular behaviours that can be performed systematically by performers, as DoDAF calls them.

Those regular behaviours are commonly defined as services to be provided by human actors and computer components.


The term “service” is widely used with various meanings, but here, it is necessary to be specific.

A service is not an interface that presents one or more services for access by clients.

Nor a component that performs processes to deliver one or more services.

Nor a group of discrete services - which might be associated with a function, role, interface or component.


A service is a discretely invokable behaviour (short or long), that is triggered by an event/input received from client actors or components, is defined in a service contract that encapsulates internal process(es), produces results of value to clients, and is presented for access in one or more interfaces.

The table below abstracts this general definition from those in the TOGAF and ArchiMate standards.


TOGAF’s definition

ArchiMate’s definition

Generally speaking, a service is

“an element of behaviour that provides specific functionality

“a unit of functionality that

A discretely invokable behaviour (short or long) that

in response to requests from actors or other services.

a system exposes to its environment,

is triggered by an event/input received from client actors or components,

A logical representation of a repeatable business activity,

hides internal operations,

is defined in a service contract that encapsulates internal process(es),

has a specified outcome,

provides a value,

produces results of value to clients, and is

is self-contained, is a ‘‘black box’’ to its consumers.”

accessible through interfaces.”

presented for access in one or more interfaces.

A subsystem as an active system component

Enterprise and solution architects view a business as a recursively composable and decomposable structure of systems and subsystems.

They gather contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

They describe current and required business systems (cf. architect's drawings, which designers and builders can follow).

They monitor the development and operation of business systems (cf. buildings, both to be built and already built).


Systems are built from components – in the broadest sense of that term.

An enterprise is a collection of humans and technologies that cooperate in the performance of processes.

In operation, it is composed of active subsystems (organisation units, actors and physical components).

An architecture describes those active components at a logical level (functions, roles and logical components).


Architecture as description

After Stephen Spewak, John Zachman and TOGAF, an “architecture” is a description of an operational system - real or envisaged.

Architecture frameworks assume architects document and maintain enterprise system descriptions in line with concrete, operational, systems.


Architecture domains/layers

Architecture frameworks commonly divide the description of an enterprise’s business systems into three domains or layers.

The focus is on business functions and human roles that are served by information systems that capture and provide business data.

And on the information systems themselves, which depend in turn on generic infrastructure or platform technologies.

The table below indicates that in each domain/layer, components deliver services to the layer above (and to other components in the same layer).


Architecture domain or layer

Generic elements

Specific elements



Business services


Business functions & roles

Information systems


Information system services


Application components

Infrastructure technology


Platform services


Technology components


A component in this table is a component as in any component-based design (CBD) or service-oriented architecture (SOA) methodology.

It is an encapsulated package of behaviour (aka functionality), definable by the services it offers.

Component interoperation, as specified in interfaces

“[Cybernetics] depends in no essential way on the laws of physics or on the properties of matter.” (Ross Ashby)

A component can be specified at logical and physical levels.

A physical component is a material thing that is hired, bought or built to implement/realise specified interfaces (described as “solution building block” in TOGAF).

A logical component is a material-independent component description – often specified in terms of interfaces provided (an “architecture building block” in TOGAF).


Components (in this broadest sense of the term) include not only application and technology components, but also business units and actors.

In this Harvard Business Review piece <https://hbr.org/2011/12/first-lets-fire-all-the-managers> Gary Hamel talks about Morning Star.

“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another.

And each employee negotiates a Colleague Letter of Understanding [an interface specification] with associates most affected by his or her work.

“As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]

This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.”


It is important that the interfaces to a component are published and reasonably stable.

An interface is an abstract implementation-independent description of what a system or component can do, of some or all of the services it can offer.


In short, an enterprise’s architecture is described and documented in terms of interoperating components.

This table summarises what TOGAF and CBD methods say about components.

TOGAF component

CBD component

“is generally recognizable as "a thing" by domain experts”

is a structural element rather than behavioural.

“may be assembled from other components; may be a subassembly of other components”

is recursively composable and decomposable.

is a package of functionality defined to meet the business needs across an organization.”

groups behaviours performable by an actor or component instance,

that is, groups services requested of it and/or processes performed by it.

“has a defined boundary”

is encapsulatable behind an interface specification.

may interoperate with other, inter-dependent, components.”

is related to other components by requesting or delivering services.

“Ideally, is re-usable and replaceable, and well specified.”

should offer generally useful services via an interface that is free of implementation detail.

considers implementation and usage, and evolves to exploit technology and standards.

can be specified with particular technology-specific components in mind, or reverse-engineered from them.

Common attributes of components

The essence of our conceptual framework for the architectural description of an enterprise or system is this:

·         Customers/users <require the products of> regular behaviors.

·         Behaviors <are assigned for performance to> logical components.

·         Logical components <are realised by hiring, buying or building> physical components.



Regular behaviors

assigned to

Logical building blocks

realised by

Physical building blocks



Run over time


Encapsulated collections

of services/processes


Occupy space and do work



Business Services / Processes




Organisation Units






Value Streams






IS Services


Logical Application Components


Physical Application Components


Application Services


Application Interfaces


Application Components


Use Cases / User Stories


User Interfaces




Platform Services


Logical Technology Components


Physical Technology Components


Infrastructure Services


Infrastructure Interfaces


Nodes (System Software, Devices)








Notice that the generic architectural entities have different generic qualities. E.g. behaviours run over time, whereas physical components occupy space (sometimes distributed) and do work.


Common attributes of Behaviors e.g. Services, Processes, Value Streams, Scenarios

·         name

·         start conditions: triggering events, inputs, preconditions for success

·         end conditions: outputs, results or values delivered, other post conditions

·         duration

·         volume or throughout

·         performers (components).


“Systems concepts include: system-environment boundary, input, output, process, state….”  (Principia Cybernetica)

The inputs and outputs of a behaviour can include materials/goods as well information/data flows.

The preconditions and post conditions of services and processes can refer to system state, as may be recorded in databases.


Common attributes of Logical Components e.g. Roles, Business Functions/Capabilities, Logical Application and Technology Components

·         name

·         provided interface(s) that group services offered to other components

·         required interface(s) that group services needed from other components

·         behaviors performed

·         physical components that implement the logical component

·         generalised requirements for some or all of the more physical attributes below.


Common attributes of Physical Components e.g. Actors, Organisation units, Physical Application and Technology Components

·         name

·         deployment place(s) or location(s)

·         abilities possessed: power and memory, or skills and knowledge

·         physical resources used: materials and/or energy

·         cost to employ

·         predicted life span or retirement date

·         logical components realised.

Components as described in architecture phases

Architecture frameworks propose architects describe components at several levels of abstraction, depending on what stage of architecture development has been reached.

Components are described in artefacts (e.g. an actor/role matrix or business function decomposition) and in deliverables (most notably, in solution visions and solution outlines).



Architects gather contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

They present, refine and agree this information, getting approval to proceed.

They may name business system components (say Billing, or CRM), with a sketchy description.



Architects describe current and required business systems.

They refine the architecture vision by defining the features of logical components.

They can and do specify these components as interface definitions, decoupled from specific solutions. E.g.

·         A Billing function is defined by the 20 business services it provides.

·         A CRM application is defined by the 15 critical use cases it offers via its interface, and 50 business data entities it maintains.

·         A relational DBMS is defined by conformance to standards such as SQL, ODBC.


Initially, component specifications are abstract – meaning their description tends to be generalised, logical and coarse-grained.

Architects then identify physical components to realise logical components.

They might a select a COTS package, e.g. Salesforce.com, Oracle DBMS.

Or produce a technology-specific description of a system to built.



Architects help managers plan the work to implement the physical components



Architects monitor the projects that implement new/changed business systems.

Designers and software architects complete the designs that builders work from.

Implementers realise the solution components as concrete elements in deployed systems.

Architects ensure compliance of deployed systems with architecture components, changing them if need be.


Under change management, maintainers maintain concrete elements of the implemented systems.

Architects ensure the compliance of deployed/operational systems with architecture building blocks, changing them if need be.

A controlled vocabulary

Here is an attempt to define the core terms in TOGAF in line with the conceptual framework above.


External entity

[A logical or physical component] outside the business or system of interest, which interacts with that business or system by requesting or supplying services.


[A physical component] or individual able to play one or more roles in the performance of processes. (Where non-human actors are represented as application and/or technology components, then the actors must be human.)

Organisation unit

[A physical component] or individual node in a management structure, able to fulfil one or more functions. It should have goals and objectives with measures, and a manager.


[A logical component] realised or played by individual actors, specified in terms of services provided and/or processes performed and abilities required.


[A logical component], a cohesive cluster of behaviors required of any organisation unit that fulfils the function, specified in terms of services provided and/or processes performed and abilities required. (It is a logical business capability, not to be confused with a managed organisation unit or discrete business service.)

Business process

[A process] that is performed by the actors in a business, with or without information technologies.

Business service

[A service] that can be requested of a business, or a component thereof. (Not to be confused with a business function.)

Data entity

[A data element] composed of data items that represent facts about a discrete business entity or event. It may be specified at a conceptual, logical or physical level. It may be mapped to data stores and/or data flows input to or output from IS services.

IS (app) service

[A service] that can be requested of a business-oriented application component, by a human actor or another application component.

Application component

[A component] of business-oriented software (e.g. CRM, Billing). It is specified logically by the IS services it provides, and sometimes also by the data entities it maintains, and/or physically as a vendor/technology specific product that can be hired, bought or built.

Platform service

[A service] that can be requested of a technology component by an application component or another technology component.

Technology component

[A component] of generic infrastructure software (e.g. OS, DBMS). It is specified logically by the platform services it provides, and/or physically as a vendor/technology specific product that can be hired or bought.


References to TOGAF refer to version 9 or 9.1 unless otherwise stated.




Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0                     13/05/2016 14:38

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