Integrated Information Infrastructure Reference Model


Chapter 44                             <<< Previous | Next >>>

44.1 Basic Concepts | 44.2 High-Level View | 44.3 Detailed Taxonomy

This chapter describes the Integrated Information Infrastructure Reference Model (III-RM), in terms of its concepts, an overview, and taxonomy.

44.1 Basic Concepts

This section looks at the basic concepts of the III-RM, including background, components, and drivers.

44.1.1 Background

With the emergence of Internet-based technologies in recent years, for many organizations the main focus of attention, and the main return on investment in architecture effort, has shifted from the Application Platform space to the Application Software space. (Indeed, this has been one of the drivers behind the migration of TOGAF itself from a framework and method for Technology Architecture to one for overall enterprise architecture.)

The TOGAF Technical Reference Model (TRM) described in 43. Foundation Architecture: Technical Reference Model focuses on the Application Platform space.

This section describes a reference model that focuses on the Application Software space, and "Common Systems Architecture" in Enterprise Continuum terms. This is the Integrated Information Infrastructure Reference Model (III-RM).

The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM – in particular, the business applications and infrastructure applications parts – in order to provide help in addressing one of the key challenges facing the enterprise architect today: the need to design an integrated information infrastructure to enable Boundaryless Information Flow. These concepts are explained in detail below.

This introductory section examines the concept of Boundaryless Information Flow; why an integrated information infrastructure is necessary to enable it; and how the III-RM can help the architect in designing an integrated information infrastructure for their enterprise.

44.1.2 Components of the Model

Like the TOGAF TRM, the III-RM has two main components:

  1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated information infrastructure
  2. An associated III-RM graphic, which provides a visual representation of the taxonomy, and the inter-relationship of the components, as an aid to understanding

The model assumes the underlying existence of a computing and network platform, as described in the TRM; these are not depicted in the model.

44.1.3 Relationship to Other parts of TOGAF

The relationship of the III-RM to the TRM is explained above.

Although the III-RM is intended as a useful tool in the execution of the TOGAF Architecture Development Method (ADM), it is important to emphasize that the ADM is in no way dependent on use of the III-RM (any more than it is dependent on use of the TRM). Other taxonomies and reference models exist in this space that can be used in conjunction with the ADM, and indeed may be preferable for some organizations.

44.1.4 Key Business and Technical Drivers Problem Space: The Need for Boundaryless Information Flow

The Boundaryless Information Flow problem space is one that is shared by many customer members of The Open Group, and by many similar organizations worldwide. It is essentially the problem of getting information to the right people at the right time in a secure, reliable manner, in order to support the operations that are core to the extended enterprise.

In General Electric, Jack Welch invented the term "the Boundaryless Organization", not to imply that there are no boundaries, but that they should be made permeable.

Creating organizational structures that enabled each individual department to operate at maximum efficiency was for a long time accepted as the best approach to managing a large enterprise. Among other benefits, this approach fostered the development of specialist skills in staff, who could apply those skills to specific aspects of an overall activity (such as a manufacturing process), in order to accomplish the tasks involved better, faster, and cheaper.

As each overall activity progressed through the organization, passing from department to department (for example, from Design to Production to Sales), each department would take inputs from the previous department in the process, apply its own business processes to the activity, and send its output to the next department in line.

In today’s world where speed, flexibility, and responsiveness to changing markets make all the difference between success and failure, this method of working is no longer appropriate. Organizations have been trying for some time to overcome the limitations imposed by traditional organization structures. Many business process re-engineering efforts have been undertaken and abandoned because they were too ambitious, while others cost far more in both time and money than originally intended.

However, organizations today recognize that they need not abandon functional or departmental organization altogether. They can enable the right people to come together in cross-functional teams so that all the skills, knowledge, and expertise can be brought to bear on any specific problem or business opportunity.

But this in turn poses its own challenges. CIOs are under enormous pressure to provide access to information to each cross-functional team on an as-required basis, and yet the sources of this data can be numerous and the volumes huge.

Even worse, the IT systems, which have been built over a period of 20 or 30 years at a cost of many billions of dollars, and are not about to be thrown out or replaced wholesale, were built for each functional department. So although it may be possible to get people to work together effectively (no minor achievement in itself), the IT systems they use are designed to support the old-style thinking. The IT systems in place today do not allow for information to flow in support of the boundaryless organization. When they do, then we will have Boundaryless Information Flow. Solution Space: The Need for Integrated Information Infrastructure

The Open Group’s Interoperable Enterprise Business Scenario1 originally published in 2001, crystallizes this need for Boundaryless Information Flow and describes the way in which this need drives IT customers’ deployment of their information infrastructure.

In this scenario, the customer’s problem statement says that I (as the customer enterprise) could gain significant operational efficiencies and improve the many different business processes of the enterprise – both internal processes, and those spanning the key interactions with suppliers, customers, and partners – if only I could provide my staff with:

  • Integrated information so that different and potentially conflicting pieces of information are not distributed throughout different systems
  • Integrated access to that information so that staff can access all the information they need and have a right to, through one convenient interface

The infrastructure that enables this vision is termed the "integrated information infrastructure".

As an example, one current approach to integrated information infrastructure is to provide "enterprise portals" that allow integrated access to information from different applications systems enterprise-wide, via a convenient, web-enabled interface (one of the colored segments in the ends of the cylinder in Figure 44-1).

Figure 44-1: An approach to Boundaryless Information Flow (Enterprise Portals)

One of the key challenges for the architect in today’s enterprise is to work out, and then communicate to senior management, how far technologies such as web services, application integration services, etc., can go toward achieving an integrated information infrastructure, and realizing the vision of Boundaryless Information Flow, in the enterprise concerned.

The Open Group’s follow-up analysis of the Interoperable Enterprise Business Scenario has resulted in the development of an integrated information infrastructure model (the III-RM), which depicts the major components required to address the Boundaryless Information Flow problem space, and can help the architect in this task.

The III-RM thus provides insights related to customer needs for Boundaryless Information Flow in enterprise environments. The model also points to rules and standards to assist in leveraging solutions and products within the value chain.

The following subsections discuss the model in detail.

44.1.5 Status of the III-RM

The III-RM is documented as it stands today, and is by no means considered a finished article. However, it is a model that has been developed and approved by the members of The Open Group as a whole, in response to the Interoperable Enterprise Business Scenario, which itself was developed in response to an urgent need articulated by the customer members of The Open Group for assistance in this field.

The Business Scenario and the Reference Model thus represent a problem and a solution approach that The Open Group membership as a whole fully endorses.

It is hoped that publication of the model as part of TOGAF will encourage its widespread adoption and use, and provide a channel of communication whereby experience with use of the model can be fed back, improvement points assimilated, and the model refined and republished as necessary.

44.2 High-Level View

This section provides a high-level view of the III-RM, including derivation of the model, high-level graphic, and components.

44.2.1 Derivation of the III-RM from the TRM

The III-RM is a model of the major component categories for developing, managing, and operating an integrated information infrastructure. It is a model of a set of applications that sits on top of an Application Platform. This model is a subset of the TOGAF TRM, and it uses a slightly different orientation.

Consider Figure 44-2 where two views of the TOGAF TRM are presented. The left side is the familiar view of the TOGAF TRM; it is a side view, where we look at the model as if looking at a house from the side, revealing the contents of the "floors". The top-down view on the right-hand side depicts what one might see if looking at a house from the "roof" down.

Figure 44-2: TOGAF TRM Orientation Views

The subset of the TRM that comprises the III-RM is depicted in Figure 44-3, in which those parts of the TRM not relevant to the III-RM are "greyed out".

Figure 44-3 illustrates that the focus is on the Application Software, Application Platform, and qualities subset of the TOGAF TRM.

Figure 44-3: Focus of the III-RM

44.2.2 High-Level III-RM Graphic

The resulting III-RM itself is depicted in Figure 44-4. It is fundamentally an Application Architecture reference model – a model of the application components and application services software essential for an integrated information infrastructure. (There are more business applications and infrastructure applications than these in the environment, of course, but these are the subsets relevant to the Boundaryless Information Flow problem space.)

Figure 44-4: III-RM – High-Level

As explained above, the model assumes the underlying existence of a computing and network platform, and does not depict them explicitly.

Although the computing and network platform are not depicted, there may be requirements on them that must be met, in addition to requirements on the components of the III-RM, in order to fully address the Boundaryless Information Flow problem space.

44.2.3 Components of the High-Level III-RM

The III-RM has the following core components:

  • Business Applications, denoted by the yellow boxes in the high-level model (corresponding to the "Business Applications" box in the TRM graphic). There are three types of Business Application in the model:
    • Brokering Applications, which manage the requests from any number of clients to and across any number of Information Provider Applications
    • Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a particular server
    • Information Consumer Applications, which deliver content to the user of the system, and provide services to request access to information in the system on the user’s behalf
  • Infrastructure Applications, denoted by the orange boxes in the high-level model (corresponding to the "Infrastructure Applications" box in the TRM graphic). There are two types of Infrastructure Application in the model:
    • Development Tools, which provide all the necessary modeling, design, and construction capabilities to develop and deploy applications that require access to the integrated information infrastructure, in a manner consistent with the standards of the environment
    • Management Utilities, which provide all the necessary utilities to understand, operate, tune, and manage the run-time system in order to meet the demands of an ever-changing business, in a manner consistent with the standards of the environment
  • An Application Platform, which provides supporting services to all the above applications – in areas such as location, directory, workflow, data management, data interchange, etc. – and thereby provides the ability to locate, access, and move information within the environment. This set of services constitutes a subset of the total set of services of the TRM Application Platform, and is denoted by the dark green underlay in the high-level model (corresponding to the Application Platform in the TRM graphic).
  • The Interfaces used between the components. Interfaces include formats and protocols, application programming interfaces, switches, data values, etc. Interfaces among components at the application level are colored red. Interfaces between any application-level components and their supporting services in the Application Platform are colored white (corresponding to the API box in the TRM graphic).
  • The Qualities backplane, denoted by the brown underlay in the high-level model (corresponding to the Qualities backplane in the TRM graphic). The Application Software and Application Platform must adhere to the policies and requirements depicted by the qualities backplane.

44.3 Detailed Taxonomy

This section provides a detailed taxonomy of the III-RM, including detailed graphic, platform service categories, and external environment sub-entities.

44.3.1 Detailed III-RM Graphic

The detailed III-RM is depicted in Figure 44-5.

Figure 44-5: III-RM – Detailed

The remaining subsections expand on the taxonomy/component detail shown in Figure 44-5.

44.3.2 Business Applications

There are three types of business application in the model:

  • Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a particular server
  • Brokering Applications, which manage the requests from any number of clients to and across any number of service providers
  • Information Consumer Applications, which deliver content to the user of the system, and provide services to request access to information in the system on the user’s behalf

The overall set of Information Provider, Information Consumer, and Brokerage Applications collectively creates an environment that provides a rich set of end-user services for transparently accessing heterogeneous systems, databases, and file systems. Information Provider Applications

To the extent that information today can be regarded as being "held hostage", as depicted in Figure 44-6, Information Provider Applications are those applications that "liberate" data from their silos.

Figure 44-6: Liberate Data Silos to Meet Information Needs of Cross-Functional Enterprise Teams

Information Provider Applications achieve this by providing an open interface to a potentially proprietary silo interface, as illustrated in Figure 44-7, where the interfaces on the left of the Information Provider Applications are open interfaces and the interfaces between the Information Provider Applications and silo data are proprietary interfaces.

Figure 44-7: Information Provider Applications Liberate Data by Providing Open Interfaces to Data Silos Brokerage Applications

Brokerage Applications serve up single requests that require access to multiple information sources. A Brokerage Application breaks down such a request, distributes the request to multiple information sources, collects the responses, and sends a single response back to the requesting client.

Brokerage Applications access Information Provider Applications using the open interfaces provided by the Information Provider Applications (as described above); they integrate information from multiple Information Provider Applications and pass the integrated information to Information Consumer Applications using open interfaces.

Brokerage Applications also enable access to information within the enterprise by strategic partners.

Figure 44-8: Brokerage Applications Integrate Information from Information Provider Applications Information Consumer Applications

Information Consumer Applications provide information to end users in the form in which they need it, when they need it, and in a secured manner. This includes providing the information in text, video, audio, English, German, etc.

Information Consumer Applications communicate with Brokerage Applications or Information Provider Applications using the open interfaces that the Brokerage and Information Provider Applications provide. Security is provided through the firewalls and/or security services.

Figure 44-9 depicts the Information Consumer Applications with the security services depicted as the brick pattern.

Figure 44-9: Information Consumer Applications Communicate using Open Interfaces

44.3.3 Infrastructure Applications

There are two types of Infrastructure Application in the model:

  • Development Tools, which provide all the necessary modeling, design, and construction capabilities to develop and deploy applications that require access to the integrated information infrastructure, in a manner consistent with the standards of the environment
  • Management Utilities, which provide all the necessary utilities to understand, operate, tune, and manage the run-time system in order to meet the demands of an ever-changing business, in a manner consistent with the standards of the environment Development Tools

The Development Tools component of the model comprises applications that take the form of tools for modeling, designing, and constructing the integrated information infrastructure. Specifically, it includes tools for business, process, and data modeling, as well as the traditional application construction tools that transform the business model into software that automates the business processes revolving around information.

Note that each set of tools will be logically connected through a directory, allowing one tool to be driven by data from another. The following sections describe the requirements for components of Development Tools. The tool set also includes a repository.

Business Modeling Tools

This category covers tools for the modeling of business rules and business process rules.

Business modeling describes and documents the business in a comprehensive knowledge base. It establishes a consensus among general management of the business direction, organization, processes, information requirements, and the current environment of the business. Perhaps most importantly, this understanding is documented in a common, business-oriented format to be utilized for subsequent enhancement.

Design Modeling Tools

This category covers tools for designing, defining, and documenting the most pertinent IT elements of the business based upon the business and business process rules. Examples of elements to be designed include: connections between people, organizations, workflows and computers; data and object models; physical data translation and translation rules; and constraints.

Implementation and Construction Tools

Implementation tools enable timely development of re-usable processes, applications, and application services. Such tools include intelligent browsers, data manipulation language compilers and optimizers, distributed application compilers and debuggers, heterogeneous client and server development tools, policy definition tools, and workflow script generation tools.

Data Modeling Tools
Deployment Tools

Deployment tools are necessary to move implemented software from the development environment into the operational environment.


This component includes re-usable libraries of software that use the standards of the operational environment. Management Utilities

This category covers applications that take the form of utilities for operations, administration, and systems management, and for the management of data based on availability and cost requirements. Such utilities may execute in an attended or an unattended environment.

Operations, Administration, and Management (OA&M) Utilities

The OA&M component covers traditional systems management and administration utilities that manage business rules and information objects. Examples include: utilities for installation, copyright and license management; and miscellaneous administration, configuration, and registration functions. Additionally there are utilities for the control of service billing, service triggering, and account management.

Quality of Service Manager Utilities

These include health monitoring and management utilities.

Copy Management Utilities

Copy Management utilities are those that manage data movement from any given operational system to necessary distribution points in the enterprise, in order to ensure the maximum leverage of operational systems data. They also include tools that detect and flag poor quality data.

Storage Management Utilities

These are utilities that provide least-cost data storage management. Storage management utilities support the wide variety of storage mechanisms and are connected to file, object, and database systems.

44.3.4 Application Platform

All the different types of application described above are built on top of the services provided by the Application Platform.

The Application Platform component of the III-RM comprises a subset of all the services defined in the TOGAF TRM, the subset that pertains to integrated information infrastructure. Specifically, it comprises all those services in the TRM Application Platform that allow applications to focus on understanding and processing the information required, rather than understanding the form, format, and/or location of the information.

The services of the Application Platform component can be used to support conventional applications as well as Brokerage, Information Consumer, and Information Provider applications. When used as part of an overall Application Architecture in this way, such an approach enables maximum leverage of a single operational environment that is designed to ensure effective and consistent transfer of data between processes, and to support fast and efficient development, deployment, and management of applications.

The Application Platform component comprises the following categories of service. Software Engineering Services
  • Languages
  • Libraries
  • Registries Security Services
  • Authentication, authorization, and access control
  • Single sign-on
  • Digital signature
  • Firewall
  • Encryption
  • Intrusion detection
  • Identity management
  • Key management Location and Directory Services

Location and directory services provide access facilities for name, location, description, and relationship data that describes the integrated information infrastructure.

Directory services support the deployment and enterprise-wide availability of an integrated information infrastructure directory. The data in the directory is made available to all other components in the architecture model.

Figure 44-10 depicts the juxtaposition of location and directory services to the other components.

Figure 44-10: Juxtaposition of Location and Directory Services to Other Components

Specific services include:

  • Directory
  • Registration
  • Publish/subscribe
  • Discovery
  • Naming
  • Referencing/dereferencing Human Interaction Services

Human Interaction services provide the means to consistently present data to the end user in the appropriate format. They comprise services that assist in the formulation of customer data requests and enable visualization and presentation of the data accessed.

Specific services include:

  • Presentation
  • Transformation
  • Browser
  • Meta indices
  • Portal and personalization Data Interchange Services

Specific services include:

  • Information format
  • eForm
  • Instant messaging
  • Application messaging
  • Application-to-application communications
  • Enterprise application integration Data Management Services

Specific services include:

  • Information and data access
  • Transformation mapping
  • Query distribution
  • Aggregation
  • Search
  • File

Information access services provide the ability for an application to access an integrated view of data, regardless of whether the data exists in a mainframe system or in a distributed system. The information access services ensure that data integrity is maintained among multiple databases, and also provide online data cleansing (whereby data is checked against data rules for each access).

Data access services provide open interfaces to legacy data, provide new applications standard database access services to vast amounts of existing data, and provide standard access services to new data types. Additional Operating System Services

Specific services include:

  • Event brokering
  • Workflow

These additional services enable the flow of information, as depicted in Figure 44-11.

Figure 44-11: Workflow Services Enable Information Flow

Workflow denotes the concept of automating processes by facilitating user interactions and executing applications according to a process map. Workflow services enable integration of enterprise applications, resulting in applications of extended value.

Workflow services also address the needs of managing an environment where legacy systems are prevalent.

Workflow services also provide a means to encapsulate existing applications, thereby supporting customer needs for leverage of existing assets.

44.3.5 Qualities

The qualities component of the model is supported by quality of service services, including the various services required to maintain the quality of the system as specified in Service Level Agreements (SLAs).

Included in this are the services to post conditions to, and react to requests from, the Quality of Service Manager.

  1. Available at

return to top of page