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 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



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.



Part VI: TOGAF Reference Models

Status (v9 vintage)


Place in ADM


Foundation Architecture: Technical Reference Model


A hierarchical classification of platform services.

D: Technology architecture


Integrated Information Infrastructure Reference Model


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.


Enterprise Continuum


Common System



Context and requirements





Architecture Continuum



Domain-specific RM


Solutions Continuum





Deployed solutions






Technical Reference Model (TRM) 1

Standards Information Base (SIB) 3

Integrated Information Infrastructure Reference Model (III-RM) 3


TOGAF and Service-Oriented Architecture. 7


Technical Reference Model (TRM)

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:


  • The technology catalogue/portfolio – a list of physical technology components
  • The TRM - a de-duplicated list of the platform services provided by (or required of) the technology components.


Mapping the latter to the former should spotlight where two components offer the same service.

Standards Information Base (SIB)

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.

Integrated Information Infrastructure Reference Model (III-RM)

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


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




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:

  • the consumers are components in the UI or workflow layers of applications
  • the providers are components in the business/data service layers of applications.


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 ICA components.

A brokerage application component collects data from IPA components.


(See “What is an application?” in the Software Architecture papers at


Q) Is an ICA or IPA a small application component that only ever plays one or other role?

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


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 ICA requires one IPA?

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 ICA and IPA could be decoupled in other ways (using WSDL, REST, whatever).


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.


TOGAF and Service-Oriented Architecture

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.


Buy space

Internal Space

Sell space

Platform services


Manufacturing, Assembly, Legal, Finance,

Customer support, Selling



Consumer Applications

Workflow, Messaging

& Directory Services

Security Services

Provision of

Business Services


Brokering Applications

Workflow, Messaging

& Directory Services

Security Services

Provision of

Data Services



















Data Storage,











Data Content











The III-RM is a powerful way to integrate other TOGAF concepts. It has an impact on:

  • Application Architecture. The III-RM defines a structure of application building blocks. It is a three-layer pattern in which Information Consumer Applications call Broker Applications, which in turn call Information Provider Applications.
  • Data Architecture. This should contain the enterprise's Canonical Data Model, that is a definition of data names and data types used by all Information Consumer Applications to invoke Application Services provided by other applications.
  • Organisation Architecture. This can developed to include an organisation-specific Application Reference Model that complements the generic infrastructure services in the TRM.


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.

  • Business Application Service -  a service defined using the enterprise’s canonical data model
  • Data Application Service - a service defined using a parochial data model.



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:” 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