TOGAF Part 6: Reference Models
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on the Avancier web site 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.
TOGAF is the most popular public domain enterprise architecture framework.
Since it is voluminous, multi-authored and not an easy read; the Avancier web site hosts papers to help you understand it.
Beware that most TOGAF authors take it for granted you know architecture description techniques already.
TOGAF is a specific transformation management framework
If you want to understand enterprise architecture in general
and specific architecting practices, then go to avancier.website.
Abstract
A reference model is a general structure or design pattern that can be tailored for use in a specific enterprise or solution.
It is a structure (of components, roles, entities, processes or services) that can be used as starter or template for more specific models.
TOGAF mentions various industry reference models in passing; and includes chapters outlining two more generic reference models.
|
Chapter |
Part VI: TOGAF Reference Models |
Status (v9 vintage) |
Description |
Place in ADM |
|
43 |
Foundation Architecture: Technical Reference Model |
Mandated/Recommended |
A hierarchical classification of platform
services. |
D: Technology architecture |
|
44 |
Integrated Information Infrastructure Reference Model |
Recommended |
An SOA-style design pattern for
applications architecture. |
C: Applications architecture |
Both reference models are based on the idea that components can be encapsulated behind the services they deliver.
They can be slotted into the enterprise continuum as below.
|
|
Foundation |
Common System |
Industry |
Organisation |
|
Context and requirements |
|
|
|
|
|
Architecture Continuum |
TRM |
III-RM |
Domain-specific RM |
|
|
Solutions Continuum |
|
|
|
|
|
Deployed solutions |
|
|
|
|
Contents
Technical
Reference Model (TRM)
Standards
Information Base (SIB)
Integrated
Information Infrastructure Reference Model (III-RM)
TOGAF
and Service-Oriented Architecture
The enterprise’s TRM defines
the enterprise’s complete technology architecture or computing environment.
It defines the
infrastructure/platform technologies logically, by defining the services that
they deliver to end-user applications.
The TRM is a structure for
the platform services provided by
technology components to business
applications.
|
TRM Structure |
|
|
Infrastructure applications |
Business applications |
|
Application platform interface |
|
|
Platform application services |
|
|
Operating system services |
|
|
Network services |
|
|
Communications infrastructure interface |
|
|
Comnunications infrastructure |
|
(Confusingly, what TOGAF calls
“infrastructure applications” are generic business applications like word
processors and email.)
The core of the TRM is the
structured catalogue of platform services.
This details about 150
services under 12 broad headings, as shown in the table below (you can read the
TOGAF text for a description of each item).
|
User Interface Services |
Transaction Processing Services |
Security Services |
Software Engineering Services |
|
Graphical Client/Server services Display Objects services Window Management services Dialogue Support services Printing services Computer-Based Training and Online Help services Character-Based services |
Starting a transaction Co-ordination of recoverable resources in a transaction Committing or rolling back transactions Controlling timeouts on transactions Chaining transactions together Monitoring transaction status |
System Entry Control services Security Management services Audit services Access Control services Non-Repudiation services Trusted Recovery services Encryption services Trusted Communication services |
Programming Language services Object Code Linking services CASE Environment and Tools services Graphical User Interface (GUI) Building services Scripting Language services Language Binding services Run-Time Environment services Application Binary Interface services |
|
Graphics and Imaging Services |
International Operation Services |
Location and Directory Services |
Operating System Services |
|
Graphics services Graphical Object Management services Drawing services Imaging functions |
Character Sets and Data Representation services Cultural Convention services Local Language Support services |
Directory services Special-Purpose Naming services Service Location services Registration services Filtering services Accounting services |
Kernel Operations Command Interpreter and Utility services Batch Processing services File and Directory Synchronization |
|
Data interchange services |
Data Management Services |
Network Services |
System and Network Management Services |
|
Document Generic Data Typing and Conversion services Graphics Data Interchange services Specialized Data Interchange services Electronic Data Interchange services Fax services Raw Graphics Interface functions Text Processing functions Document Processing functions Publishing functions Video Processing functions Audio Processing functions Media Synchronization functions Multimedia Processing functions Information Presentation and Distribution functions Hypertext functions |
Data Dictionary/Repository services Database Management System (DBMS) services OO Database Management System (OODBMS) services File Management services Query Processing functions Screen Generation functions Report Generation functions Networking/Concurrent Access functions Warehousing functions |
Electronic Mail services Distributed Data services Distributed File services Distributed Name services Distributed Time services Remote Process (Access) services Remote Print Spooling and Output Distribution services Enhanced Telephony functions Shared Screen functions Video-Conferencing functions Broadcast functions Mailing List functions |
User Management services Configuration Management (CM) services Performance Management services Availability and Fault Management
services Accounting Management services Security Management services Print Management services Network Management services Backup and Restore services Online Disk Management services License Management services Capacity Management services Software Installation services Trouble Ticketing services |
Do not confuse:
Mapping the latter to the former should spotlight where two
components offer the same service.
The enterprise’s SIB is a
hierarchically structured catalogue of standards.
Some platform services may be
defined in terms of standard protocols and interfaces.
You can define the particular
platform services required of components (to be bought or built) with reference
to the SIB.
The SIB and TRM can be
prestented under the same hierarchical structure – and perhaps combined in one
document.
The III-RM is a common
systems architecture, an SOA-style design pattern for applications
architecture.
The table below shows the
architecture domains as layers – and subdivides the applications architecture
into three layers.
|
This architecture domain |
is composed of building
blocks |
that provide services to each
other and to |
by executing |
|
Business architecture |
Business functions |
Customers |
Business processes |
|
Applications architecture |
Info consumer apps |
Business functions |
Information System Services (use cases) |
|
Broker apps |
Info consumer apps |
Information System Services (automated business services) |
|
|
Info provider apps |
Broker apps |
Information System Services (automated data services) |
|
|
Infrastructure architecture |
Platform technologies |
Applications |
|
This pattern is a common
system architecture; well known outside of TOGAF.
It is often used by vendors
in a sales pitch for middleware, BPM and SOA tools.
They recommend it as a way
for an enterprise to develop, manage and operate an integrated set of business
applications (using their tools of course).
The table below defines the
role played by each layer of business application components.
(Note that the III-RM
terminology is inherently query-oriented rather than update-oriented.)
|
Information Consumer
Applications |
Request services from remote and potentially shared services. |
|
Brokering
Applications |
Consume requests from consumers (above) Integrate information from one more providers (below) to meet requests. Offer potentially shared business services to client apps. |
|
Information
Provider Applications |
Offer potentially shared data services to brokers. |
At first sight this looks
like a 3-layer software architecture.
The middle layer is not a business
data processing layer (as in a conventional 3 layer software architecture).
It is rather a middleware
layer that passes messages between the top and bottom layers.
The pattern can be viewed as
hub-and-spoke architecture, presented in a hierarchical manner.
The III-RM is presented as
graphic that shows the above design pattern for integrating legacy
applications.
It is logged as a common
system architecture in the enterprise continuum.
|
(Security
Policy) Qualities (Mobility
Policy) |
||
|
Information
Consumer Applications |
||
|
Development Tools |
Brokering
Applications |
Management Utilities |
|
Information
Provider Applications |
||
|
(Performance) Qualities (Manageability
Policy) |
||
The III-RM is an SOA design
pattern in which end-user applications liberate data from silos, and integrate
those silos.
A client-side application component
can draw data from and coordinate many server-side application components.
The business parts of
III-RM
Information Consumer
Applications are those that want to use remote and potentially shared
services.
Brokering Applications
consume requests from consumers (above) and integrate information from one more
providers (below) to meet that request.
Information Provider
Applications are those that offer potentially shared services.
In theory, any application
could be a consumer or provider in relation to any other.
In practice, probably:
Infrastructure parts of
III-RM
Dev Tools are tools to model,
design and build business applications. Includes business process and data
modeling tools and forward engineering tools.
Management Utilities are
tools to operate, tune and manage the run-time system.
There may be utilities for
installation, copyright and licence management; administration, configuration
and registration functions; service billing, service triggering and account
management., copy management (distribution of data), storage management:
archive, recovery etc.
Q) How does the III-RM relate
to the TRM?
A) The TRM defines
application platform services that are useful in the III-RM pattern.
The III-RM is a Common System
Architecture that employs some of the services defined in the TRM.
“All the different types of
application [defined in the III-RM] are built on top of the services provided
by the Application Platform [defined in the TRM].” TOGAF
Q) What does TOGAF mean by a
system?
A) TOGAF tends to use the
word systems as a synonym of application.
A Common System Architecture
is a pattern for the structure of an application, or an assembly of application
components.
So, the III-RM is an
application architecture view or model, and it is also a Common System
Architecture.
Q) What does TOGAF mean by an
application?
A) TOGAF does not formally
distinguish an application from an application component.
The III-RM undermines the
traditional view of a silo application.
A brokerage application
component takes requests from
A brokerage application
component collects data from IPA components.
(See “What is an
application?” in the Software Architecture papers at Avancier.co.uk.)
Q) Is an
A) Perhaps, but TOGAF doesn’t
rule out the possibility that an application component could play both roles in
different interactions.
Q) Is the III-RM a multi-layer software architecture pattern?
A) You can see it that way.
But although a brokerage
application may apply some business rules, its role is more application
integration than business logic..
(See “LSA and MVC patterns”
in the Software Architecture papers at Avancier.co.uk.)
Q) Is the III-RM a multi-tier platform architecture pattern?
A) It might be interpreted that
way, but there is no requirement for the layers to be assigned to any
particular platform.
The brokerage applications do
not have to be implemented using middleware.
Q) Is a Brokerage Application
needed where one
A) Not necessarily. Brokerage
applications are used to decouple ICAs from IPAs.
They can hide IPA locations,
communication protocols and parochial data formats from ICAs.
But
Q) TOGFA says IPAs provide an
open interface to a potentially proprietary silo interface? Is that always
true?
A) Not necessarily. If IPA do
provide such an interface, then ICAs might invoke them directly.
If not, the Brokerage
Applications can translate from parochial protocols or data formats supplied by
IPAs.
First a short rant: SOA
should not start with the deployment of SOA technologies – whatever you or I
take those to be.
SOA should start with the
identification of some services you actually want to reuse.
Choosing the technologies we
need to make those services available to the clients who want them is a
secondary concern.
SOA concepts map well on to
the TOGAF concept of the Integrated Information Infrastructure Reference Model
(III-RM).
TOGAF use a graphic to show
how the III-RM enables “Boundaryless Information Flow”.
The table below is a simpler
version of the graphic.
|
Business |
Buy space |
Internal Space |
Sell space |
Platform services |
||||||||
|
Procurement |
Manufacturing,
Assembly, Legal, Finance, |
Customer
support, Selling |
||||||||||
|
HCI |
Many Consumer Applications |
Workflow,
Messaging &
Directory Services |
||||||||||
|
Security
Services |
||||||||||||
|
Provision of Business Services |
Many Brokering Applications |
Workflow,
Messaging &
Directory Services |
||||||||||
|
Security
Services |
||||||||||||
|
Provision of Data Services |
Provider App |
Provider App |
Provider App |
Provider App |
Provider App |
Provider App |
Provider App |
Provider App |
Provider App |
Data
Storage, Replication |
||
|
Database |
Database |
Database |
Database |
Database |
Database |
Database |
Database |
Database |
||||
|
Data Content |
Parts |
Procure |
Design |
Build |
Shipping |
Sales |
Fulfilment |
Billing |
Support |
|||
The III-RM is a powerful way
to integrate other TOGAF concepts. It has an impact on:
Since the III-RM is a kind of
SOA, the Application Reference Model can be defined as a service catalogue
containing two types of Application Service.
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