TOGAF, CBD and
SOA (TOGAF as service-oriented, component-based design)
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
them helpful, please spread the word and link to the site in whichever social
media you use.
This is one of more than 200 papers on http://avancier.website that you might find helpful.
This paper examines the core concepts and entities in the TOGAF meta model with reference to the principles of service-orientation and component-based design.
Contents
Service-oriented specification of components
Defining the behavioural properties of a system
Read TOGAF Buildings Blocks for in-depth answers to this question.
In short, TOGAF proposes an enterprise’s architecture is described and documented in terms of interoperating building blocks.
A “building block” is a component as in any CBD or SOA methodology that
emphasises the specification of active components by interfaces.
This table summarises what TOGAF says about building blocks, which corresponds to what CBD says about components.
|
TOGAF building block |
CBD component |
|
“is generally recognizable as "a thing" by domain experts” |
is a structural element rather than behavioural. |
|
“may be assembled from other building blocks; may be a subassembly of other building blocks” |
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, building blocks.” |
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. |
General system theory suggests systems have common features. Typically, in business systems:
· Components cooperate in processes that create, move and modify objects.
· Components perform processes in response to discrete events or service requests.
· Components are bounded by interfaces through which they offer services to other components.
One component can offer more than one service.
One service can be offered by more than one component, though EA discourages duplication of service provision.
How does TOG apply CBD principles?
It defines an enterprise as a collection of inter-related building blocks, each defined by the "service portfolio" it provides.
“For each building block, build up a service description portfolio as a set of non-conflicting services.” Phase D 12.4.1.6
In TOGAF a logical technology component or architecture building block (ABB) defined by the "service portfolio” it is required to provide: e.g. the IETF standard FTP interface.
A physical technology component or solution building block (SBB) is hired, bought or built to realise a logical component’s service portfolio: e.g. the particular FTP server on your device(s).
Read TOGAF Buildings Blocks for more about how components and services are described
at different levels of abstraction in TOGAF.
The term “service-oriented architecture” (SOA) has been fashionable since the turn of the century, but is used loosely and variously.
People use “service” as a synonym for other kinds of system element (process, component, interface etc.) and for business relationships.
If we are to be unambiguous and systematic about SOA, we have to narrow the meaning of the term.
A fundamental property of a system (as of a component) is its boundary, which separates the system from its environment.
External entities, outside the system of interest, trigger systems (and components in them) to provides services.
All business systems must respond to events that are detected in or received from the wider environment.
So, the concept of the event, and the discrete unit of behaviour it triggers, is essential to business system description.
TOGAF defines a service thus:
“an element of behaviour that provides specific functionality in response to requests from actors or other services”
“a logical representation of a repeatable business activity, has a specified outcome, is self-contained, is a ‘‘black box’’ to its consumers.”
E.g.
Check customer credit, Provide weather report, Consolidate drilling reports.
In other words, a service is a discrete unit of behaviour that encapsulates processing and produces a result for its service requester/consumer.
A service is defined at whatever level of granularity an external entity (playing the role of service requester or consumer) recognises as a discrete operation.
A service encapsulates the processes (aka behaviour, functionality, activities) that respond to an event or meet a service request.
Service
documentation
TOGAF builds its “architecture requirement
specification” around definitions of required services.
A service contract template (not to be confused with an SLA document) is usually divided into three parts:
· The signature: the service name, inputs and outputs (from which value may be derived).
· The functional rules: the preconditions and post conditions of the service.
· The non-functional rules: including performance and commercial conditions.
Higher
level goals and objectives
The detailed requirements for a system can be
captured in contracts for the services it provides.
Higher level requirements are the outcomes
that provision of those services lead to in the wider environment.
These outcomes, or values, or desired
effects, are typically documented as business goals or objectives.
Services
as the requirements for systems
The Open Group (TOG) was created with the idea of standardising systems, to enable portability and reuse.
TOG develop and publish vendor and technology-neutral specifications. E.g. the Unix specification.
They achieve this by specifying systems (and components thereof) by the services they offer. For example:
TOGAF 1 to 7 were centred on a Technical Reference Model (TRM).
This defines the enterprise’s complete technology architecture or computing environment by the services it offers (or groups of services).
It defines infrastructure/platform technologies logically, by the services they deliver to business applications.
|
Service Portfolio |
Start, Commit, Roll Back. |
Get, Put, Post, Delete. |
Print doc, Scan doc |
|
Building Block |
Transaction Manager |
HTTP Server: |
Printer |
TOGAF 8 and 9 extended this idea into the business and applications domains.
The Architecture Requirements Specification specifies services required of “architecture building blocks” in these domains.
|
|
Business |
Application |
|
Service Portfolio |
Pour drink, Take money. |
Register claim, Pay claim. |
|
Building Block |
Barman role |
Claims application |
Defining components is not enough; it is necessary to define the services they provide and the processes they cooperate in.
“[Architecture descriptions are]
organized in a way that supports reasoning about the structural and behavioral properties
of the system and its evolution.”
(ArchiMate® 2.1 Specification, The Open Group.)
A structural view has no start and end points (as in a network diagram, a data model, or a class diagram in UML).
Structural
elements describe what a system is made of – are typically called
components, actors or roles – and are addressable.
Active
components perform processes; passive objects (on
which behavior is performed) are not shown here.
A behavioural view
has start and end points (as in a
flow chart, use case definition, state chart or interaction diagram in UML).
Behavioural
elements describe what a system does - are typically called processes or
activities – and have a time dimension.
Behavioural elements are usually repeated, and sometimes cyclical.
Service contracts
A service encapsulates behaviours (aka processes, activities) that respond to an event or meet a service request.
Service contract template
· Signature: service name, inputs and outputs.
· Functional rules: preconditions and post conditions
· Non-functional characteristics: including performance and commercial conditions.
A service is defined at whatever level of granularity an external entity (playing the role of service requester or consumer) sees as a discrete operation.
Services are <realised by> Processes
There are human processes, computer processes, and hybrid human-computer processes that may be called workflows or use cases.
A process or activity is
· specified by defining it to a level of detailed “actions” that actors/components can understand and perform.
· deployed by publishing it where actors/components can read and perform it
· performed when actors/components read and follow the published process.
Application Components (in the IS layer) are business-oriented products that help human Actors by capturing and providing business data.
Technology
Components (in the technology layer) are generic products
that serve
business-oriented Application Components, and each other.
Technology Components include hardware, virtual hardware, operating systems, execution environments, FTP servers, HTTP servers etc.
Both Application Components and Technology Components are technologies, and most are software systems.
The dividing line between them is blurred, especially when it comes to middleware products that move business data around.
Middleware with that is primarily used for message routing are probably best seen as a Technology Component.
Middleware
components that apply more sophisticated business rules to data may be seen as
Application Components.
If your software system includes building blocks of both types, then it probably ought to be classified as an Application Component.
Or, you can classify it in both layers; it doesn’t matter very much where you position it in the two layers, provided it is related to the right things.
One Role can be played by many Actors; one Actor can play
many Roles.
The term Actor is used when naming the one individual who
plays a particular Role.
But architects never model a human Actor per se; they
model only the Roles that Actor play in systems.
An Actor is an individual system component, whereas a
Role is a type of component.
Role: a type (e.g. barber, customer, supplier) inside or
outside a system.
Actor: an individual (my barber, me, you) who plays a
role inside or outside a system.
(Note however that a UML Actor usually = an ArchiMate or
TOGAF Role.)
You could reasonably restrict the Role and Actor to human components only.
If the TOGAF meta model had an entity called “electro-mechanical device”, then it would be easier to do this.
Or else, can you add a smiley face to Role and Actor names?
Application Components are nested. So, an application is an Application Component at the top of a nest of related Application Components.
Consider a bespoke business application that:
· has client-side and server-side (web server and data server) building blocks.
· depends on two Web Services (post code look up, date conversion) it shares with other applications.
· sends messages via a JMS broker to another business application.
· is subscribed to receive notifications via TIBCO of customer address change events.
Is this one Application Component or many? It depends on the concerns you have to address.
The TOGAF meta model uses the term Process in the business layer only.
But a “use case” is readily seen as
a process (with main and alternative paths) encapsulated within
an Information System Service.
Three generalised building blocks are Service, Logical Component and Physical Component.
The two essential inter-element relations are described
below.
Service-
Logical Component relation
1 Logical Component <can
offer> more than one Service.
1 Service <can be offered by> more than one Logical
Component (though ideally only 1).
Physical
Component- Logical Component relation
1 Physical Component <can realise> more than one Logical
Component.
1 Logical Component <can be
realised by> more than one Physical Component (though ideally only
1).
A capability is not a singular architectural entity.
A capability is a view of, or aggregate of,
the entities in an enterprise architecture meta
model.
Capability = a combination of processes, people and technologies that deliver
desired effects.
Capability = a logical
encapsulation of those parts of an enterprise or system that deliver required products or services.
A
capability can be seen as a required function + aims + activities and resources
needed to deliver the effects desired of the named function.
Read Capability-Based Planning in an EA context for more.
If only! For a simple example of ambiguity, what does “data
architecture” mean?
An IS architect thinks of data at rest (stores) and in motion (flows), the data
structures they contain (logical and canonical data models), data qualities,
data owners.
An IT architect thinks of disc arrays, NAS, SAN, active/passive, synch/asynchronous replication, availability and disaster recovery.
Different architects use the same words with different meanings.
The terms “service” and interface” are especially ambiguous.
The Web Services Definition Language is an Interface Definition Language that names concepts as shown below.
|
WSDL |
Behavioural view |
Structural view |
|
External view |
WS Operation (service contract) |
Web Service (interface definition) |
|
Internal view |
hidden |
Addresses of components that perform the operations named in the interface |
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 06/05/2016 10:55
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