Vocabulary
Hell (especially
“Components” and “Services”)
One of about
300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 23/02/2017 13:33
And a postscript to one of several papers on the home
page about the terms and concepts used in architecture frameworks.
The language
used
by
architects,
designers
and
programmers
in
the
IT
industry
is
a
mess.
A component is sometimes called a service, or an interface, or a building block.
A application component is sometimes called a microservice.
An interface is sometimes called a service.
In the
UML
standard,
an
actor
is
a
role,
a
function
is
a
process,
and
a
service
is
an
interface.
The table below classifies the three concepts represented by those six words (adding the terms class and object).
|
UML |
Behaviour elements |
Logical structure element definitions |
Physical structure element instances |
|
External view |
Service = Interface |
||
|
Internal view |
Function = Process |
Actor = Role Class |
Object |
The same
six
words
have
different
meanings
in
other
standards,
as
this
table
indicates.
|
Behaviour elements |
Logical structure element definitions |
Physical structure element instances |
|
|
External view |
Service |
Interface |
|
|
Internal view |
Process |
Function, Role |
Actor |
This paper tackles
the vocabulary hell facing every modern enterprise or solution architect.
Enterprise and solution architects describe the structures and behaviours of business systems.
That is, business activity systems in which the actors are humans and computers (and sometimes other machines).
The behavioural
elements of a business system
Behavioral elements run from start-to-end over time.
Services and processes are behaviours that produce results (products, outputs) of value to consumers of those results.
A service is definable declaratively in a service contract; a process is definable as a step-by-step flow of actions.
The structural
elements of a business system
Structural elements exist
independently of behaviours they are engaged in, and must be locatable
or addressable.
· Passive structure elements (data structures, locations, containers) are acted on or in.
· Active structural elements (actors, components) act; they perform actions in response to events and service requests.
To act, structural elements need abilities and resources.
When acting, they have a “thread of control”, but they are not defined as flows over time.
Logical an physical
components
TOGAF divides building blocks and components into two kinds: logical and physical.
The logical variants include function, role, logical application component, logical data component and logical technology component.
The physical variants include organisation unit, actor, physical application component, physical data component and physical technology component.
TOGAF’s architecture definition process can be distilled into one sentence.
Architects define
requirements as discrete services, then assign them to
logical roles/components, with a view to hiring/buying/building physical
actors/components.
Requirements are gathered and then expressed in terms of
services to be provided by components to be hired, bought, built or changed.
A service portfolio is defined by listing closely related services and/or groups of
services.
A service portfolio is assigned to a logical component (aka
architecture building block).
One or more physical components (aka solution building
blocks) are selected to realise a logical component.
The language used by
architects, designers and programmers in the IT industry is a mess.
The table below is an attempt to classify terms used – in a compromise between TOGAF and ArchiMate standards.
|
ArchiMate TOGAF |
Behaviour elements |
Logical structure element definitions |
Physical structure element instances |
|
External
view |
Service |
Interface |
|
|
Internal
view |
Process |
Role Function |
Actor Organisation Unit |
Here, a service is a discretely requestable operation.
An interface is a collection of services
made available to a client (and perhaps also, a place via which those services
can be accessed).
TOGAF uses the term interface
differently, for a data flow passing between application components.
And below is an
attempt to explain further confusions.
When is an interface
called a service? When the interface is a web service.
The Web Service
Definition Language (WSDL) is an Interface
Definition Language (IDL).
It is used to define
an interface that holds the information needed by clients to access one or more
remote "operations" across the web.
The interface
defines, for each operation, its signature, its address and protocols used to
access it.
The operations listed
in one interface may be found in different places, provided by different server
components.
So any client
component with access to that one interface definition (or holding it) can use
it to access those operations, wherever they are.
However, some refer
to a WSDL-defined interface as a “service”.
When is a component
called a service? When the component is a server component
(wrapped behind an interface called a service).
Programmers commonly
wrap up one server component behind one web service interface definition.
Any client component
with access to that one interface definition (or holding it) can use it to
access the operations performable by that one server component.
However, some refer
to the server component (behind the interface) as a "service".
When is a component
called an interface? When it is a façade component.
In
ArchiMate, an interface as defined as a place where discrete services can be
accessed.
This definition might
be interpreted as saying an interface is a design-time interface definition
(think, a menu)
However, it seems
rather to be saying an interface is a
run-time façade component (think, a waiter) that receives and forwards
service requests.
Further, ArchiMate limits
an interface to fronting one and only one component.
Where is a component
called a building block? In TOGAF.
TOGAF authors and
readers have at least three interpretations of the term building block.
1. The
building block chapter defines a building block as a component (as above).
2. Some
TOGAF 9 authors used the term building block for
any meta model type, including goals and
locations.
3. Some
now use the term to mean an instance of a meta model
type, found in a specific architecture model.
The last two options
radically change the meaning of building block around which TOGAF was built.
And they tend to
undermine the principles of component-based design and SOA that underpin TOGAF.
When is a component
called a microservice?
Microservices are not a new idea.
A microservice is a micro-application that can be defined logically by its service portfolio, by the discrete services it offers.
Read this paper for more detail.
Architects are given motivational inputs – purposes, concerns, problems, requirements and opportunities.
They may clarify these motivations, document them and attach quantified success measures.
The architect’s primary role is to architect systems in response to the given motivations.
They determine system structures and behaviours that will help a business meet its purposes.
They choose between different architectures that might meet the given purposes.
The chosen architecture is very rarely *technology-independent*.
Whether it is *vendor-neutral* or not is up to the architecting process they follow.
There is a place where requirements and system architectures come together.
That is in contracts that define the services required of a system.
You can’t design the internal architecture of a system until you know the inputs and outputs.
Service contracts (or use case descriptions) define inputs, outputs and behaviours by which a system meets its purposes.
TOGAF acknowledges this by putting service contracts in the Architecture Requirements Specification rather than the Architecture Definition Document.