TOGAF® Reference Models

Owned by Selvyn Wright
Last updated: Apr 21, 2017
3 min read

Introduction

 

A reference model is a standard, template or pattern that can be redeployed in a number of different ways. They can be organisational specific, industry standards or open standards cutting across a number of industries.

Reference models come in many forms and sizes, there may be

  • reference data models such as the Data Reference Model (DRM) in the Federal Enterprise Architecture (FEA), or SID from eTOM
  • reference business operating models such those found in eTOM, called the Business Process Framework
  • application reference models as those found in JEE, known as the JEE Reference Architecture
  • technical reference models such as Androids TRM, the technical specification for and any PC or laptop and the technical specification for Symbian

Collateral

TOGAF® defines two reference models.  They are just examples and nothing more.  You can use them as they are or define your own.  In actual fact you will need to define your own.

Technical Reference Model (TRM)

A formal description of the platform on which you deploy your services, here are two examples, the Windows 8 TRM followed by the Android TRM

Here is another example of type of TRM but it's a BRM (Business Reference Model), it's from the Federal Enterprise Architecture (FEA)

Integrated Information Infrastructure - Reference Model (III-RM)

If you look back through history at the way in which we have tackled the problem of integrating systems, you can see very clear points in time where we have made significant leaps forward.  I would define these significant points as EDI, RPC/ORPC, Application Servers and SOA.  For many of us who have been involved in the architecture/design of distributed systems, we are well familiar with these four architectural styles

  • Electronic Data Interchange - using EDIFACT, ASC x12, or TRADACOMS
  • Remote Procedure Calls (middleware) - using DCE RPC, ONC RPC, MS-RPC, JSON-RPC, or XML-RPC
  • Object Remote Procedure Calls (middleware) - using Java RMI, MS COM and DCOM, or OMG CORBA
  • Application Servers - would make use of the technologies listed above but perform the exchange of information through transformation rules between clients and corporate data sources
  • Service Oriented Architecture - sometimes referred to by some vendors as CORBA on steroids, adds to the ORPC middleware services such things as routing, message transformation, security, service location and registration.  All of these services would be built into what is typically referred to as an ESB (Enterprise Service Bus).

Typically today, most people when asked about their data and application interoperability strategy, will respond by saying we have a SOA initiative.  SOA in purest sense is simply an architectural style to achieve application and data interoperability.  Whether that interoperation is through business services or not, it finally results in the exchange of data or the call of procedures.  In the mid 90s during the development of the OMG's CORBA, the OpenGroup alternatively defined the III-RM as a means of achieving application and data interoperability.  You don't have to use it but, you need to clearly demonstrate how you are going to achieve this very important facet in your information architecture space.

In the following example we have mapped the JEE architecture to the III-RM as an example what each element within the model represents