/
TOGAF® Reference Models

TOGAF® Reference Models

Apr 21, 2017

Introduction

 

 

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