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.
Contents
EA as the description and
coordination of digitisable business systems
A service as a discrete behaviour
A subsystem as an active system
component
Component interoperation, as
specified in interfaces
Common attributes of components
Components as described in
architecture phases
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
“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. |
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 services |
|
Components |
Business functions &
roles |
|
|
Information systems |
Services |
Information system services |
|
Components |
Application components |
|
|
Infrastructure technology |
Services |
Platform services |
|
Components |
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.
“[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. |
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.
|
Vocabulary |
Regular behaviors |
assigned to |
Logical building blocks |
realised by |
Physical building blocks |
|
Generic attributes |
Run over time |
|
Encapsulated collections of services/processes |
|
Occupy space and do work |
|
TOGAF & ArchiMate |
Business Services / Processes |
|
Functions |
|
Organisation Units |
|
|
Roles |
|
Actors |
||
|
Other |
Value Streams |
|
Capabilities |
|
|
|
TOGAF |
IS Services |
|
Logical Application Components |
|
Physical Application Components |
|
ArchiMate |
Application Services |
|
Application Interfaces |
|
Application Components |
|
Other |
Use Cases / User Stories |
|
User Interfaces |
|
Applications |
|
TOGAF |
Platform Services |
|
Logical Technology Components |
|
Physical Technology Components |
|
ArchiMate |
Infrastructure Services |
|
Infrastructure Interfaces |
|
Nodes (System Software, Devices) |
|
Other |
|
|
APIs |
|
|
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).
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.
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).
Initiate
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.
Architect
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.
Plan
Architects help managers plan
the work to implement the physical components
Govern
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.
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. |
|
Actor |
[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. |
|
Role |
[A
logical component] realised or played by individual actors, specified in terms of services provided
and/or processes performed and abilities required. |
|
Function |
[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