Introduction Entities and Interfaces Application Software Application Platform Communications Infrastructure Application Program Interface Communications Infrastructure Interface Qualities
The Detailed Technical Reference Model diagram expands on High Level TRM diagram to present the service categories of the Application Platform and the two categories of Application Software.
Figure 1: Detailed Technical Reference Model (Showing Service Categories)
The Detailed TRM diagram is only a depiction of the TRM entities: it neither implies nor inhibits interrelationships among them.
IT architectures derived from TOGAF may differ greatly depending on the requirements of the information system. In practice, many architectures will not include all of the services discussed here, and many will include additional services to support application software that is specific to the organization or to its vertical industry.
In building an architecture, users of TOGAF should assess their own requirements and select the services, interfaces, and standards that satisfy their own business needs.
The following sections discuss in detail each element of the Technical Reference Model illustrated in the Detailed Technical Reference Model diagram. They are dealt with in the following order:
The detailed TRM recognises two categories of application software:
During development of the IT architecture, Business Applications and Infrastructure Applications are important sources of requirements for IT infrastructure services, and the selection of standards for the application platform will be influenced strongly by the application software configuration to be supported.
Business Applications are applications that are specific to a particular enterprise or vertical industry. Such applications typically model elements of an enterprise's domain of activity or business processes. Examples of Business Applications might include:
Over time, particular Business Applications may become Infrastructure Applications, if they become sufficiently ubiquitous, interoperable, and general purpose to be potentially useful to a broad range of enterprise IT users.
Infrastructure Applications are applications that have all, or nearly all, of the following characteristics:
Examples of Applications in this category include:
Infrastructure applications have strong dependencies on lower-level services in the architecture. For example, a workflow application may use platform services such as messaging or transaction processing to implement the flow of work among tasks. Similarly, a groupware application is likely to make extensive use of both Data and Communication services for the structure of documents, as well as the mechanics of storing and accessing them.
The Infrastructure Applications by definition are applications that are considered sufficiently ubiquitous, interoperable, and general purpose within the enterprise to be effectively considered as part of the IT infrastructure. Just as Business Applications may over time come to be regarded as Infrastructure Applications, so Infrastructure Applications are normally candidates for inclusion as Infrastructure Services in future versions of an IT architecture.
The term "platform" is used in many different ways within the IT industry today. Because of the different usages, one often see the term qualified: for example, "Application Platform", "Standardized" and "Proprietary Platforms", "Client" and "Server Platforms", "Distributed Computing Platform", "Portability Platform". Common to all these usages is the idea that someone needs a set of services provided by a particular kind of "platform", and will implement a "higher level" function that makes use of those services.
The TOGAF Technical Reference Model focuses on the Application Platform, and the "higher level function" is the set of Application Software, running on top of the Application Platform, that is needed to address the enterprise's business requirements.
It is important to recognize that the Application Platform in the TOGAF Technical Reference Model is a single, generic, conceptual entity. From the viewpoint of the TOGAF TRM, the Application Platform contains all possible services. In a specific target architecture, the Application Platform will contain only those services needed to support the required functions.
Moreover, the Application Platform for a specific target architecture will typically not be a single entity, but rather a combination of different entities for different, commonly required functions, such as Desk Top Client, File Server, Print Server, Application Server, Internet Server, Data Base Server, etc., each of which will comprise a specific, defined set of services necessary to support the specific function concerned.
It is also important to recognize that many of the real-world IT systems that are procured and used today to implement an IT architecture come fully equipped with many advanced services, which are often taken for granted by the purchaser. For example, a typical desktop computer system today comes with software that implements services from most if not all of the service categories of the TOGAF Technical Reference Model. Since the purchaser of such a system often does not consider anything "smaller" than the total bundle of services that comes with the system, that service bundle can very easily become the "platform". Indeed, in the absence of an IT architecture to guide the procurement process, this is invariably what happens. As this process is repeated across an enterprise, different systems purchased for similar functions such as Desk Top Client, Print Server, etc., can contain markedly different bundles of services.
Service bundles are represented in an IT Architecture in the form of "Building Blocks". One of the key tasks of the IT architect in going from the conceptual Application Platform of the TRM to an organization-specific IT architecture, is to look beyond the set of real-world "platforms" already in existence in the enterprise. The IT architect must analyse the services actually needed in order to implement an IT infrastructure that meets the enterprise's business requirements in the optimal manner, and define the set of optimal solution building blocks - real-world "platforms" - to implement that architecture.
The TOGAF TRM identifies a generic set of platform services, and provides a taxonomy in which these platform services are divided into categories of like functionality. A particular organization may need to augment this set with additional services or service categories which are considered to be generic in its own vertical market segment.
The set of services identified and defined for the Application Platform will change over time. New services will be required as new technology appears and as application needs change.
In addition to supporting application software through the API, services in the Application Platform may support each other, either by openly specified interfaces which may or may not be the same as the API, or by private, unexposed interfaces. A key goal of architecture development is for service modules to be capable of replacement by other modules providing the same service functionality via the same service API. Use of private, unexposed interfaces among service modules may compromise this substitutability. Private interfaces represent a risk that should be highlighted to facilitate future transition.
The Technical Reference Model deals with future developments in the application platform in two ways. Firstly, as interfaces to services become standardized, functionality which previously formed part of the application software entity migrates to become part of the application platform. Secondly, the TRM may be extended with new service categories as new technology appears.
Examples of functional areas which may fall into Application Platform service categories in the future include:
A detailed taxonomy of the Application Platform is given later.
The Communications Infrastructure provides the basic services to interconnect systems and provide the basic mechanisms for opaque transfer of data. It contains the hardware and software elements which make up the networking and physical communications links used by a system, and of course all the other systems connected to the network. It deals with the complex world of networks and the physical communications infrastructure, including switches, service providers and the physical transmission media.
A primary driver in enterprise-wide IT architecture in recent years has been the growing awareness of the utility and cost effectiveness of the Internet as the basis of an communications infrastructure for enterprise integration. This is causing a rapid increase in Internet usage and a steady increase in the range of applications linking to the network for distributed operation.
This is considered further under Communications Infrastructure Interface below.
The Application Platform Interface specifies a complete interface between the Application Software and the underlying Application Platform across which all services are provided. A rigorous definition of the interface results in application portability, provided that both platform and application conform to it. For this to work, the API definition must include the syntax and semantics of not just the programmatic interface but also all necessary protocol and data structure definitions.
Portability depends on the symmetry of conformance of both applications and the platform to the architected API. That is, the platform must support the API as specified, and the application must use no more than the specified API.
The API specifies a complete interface between an application and one or more services offered by the underlying application platform. An application may use several APIs, and may even use different APIs for different implementations of the same service.
The Communications Infrastructure Interface is the interface between the application platform and the communications infrastructure.
The High-Level Model seeks to reflect the increasingly important role of the Internet as the basis for inter- and intra-enterprise interoperability. The horizontal dimension of the model in the High Level TRM diagram represents diversity, and the shape of the model is specifically intended to emphasise minimum diversity at the interface between the application platform and the communications infrastructure.
In particular, the model emphasises the importance of focusing on the core set of services that can be guaranteed to be supported by every IP-based network, as the foundation on which to build today's interoperable enterprise computing environments.
Besides the set of components making up the TRM, there is a set of attributes or qualities that are applicable across the components. For example, for the management service to be effective, manageability must be a pervasive quality of all platform services, applications and communications infrastructure services.
The Detailed TRM diagram captures this concept by depicting the TRM components sitting on a backplane of Qualities.
Another example of a service quality is Security. The proper system-wide implementation of Security requires not only a set of Security services, corresponding to the Security services category shown in the Platform, but also the support (i.e., the 'security awareness' ) of software in other parts of the TRM. Thus an application might use a security service to mark a file as read-only, but it is the correct implementation of the security quality in the Operating System services which prevents write operations on the file. Security and Operating System services must co-operate in making the file secure.
Qualities are specified in detail during the development of a target architecture. Some qualities are easier than others to describe in terms of standards. For instance, support of a set of locales can be defined to be part of the specification for the international operation quality. Other qualities can better be specified in terms of measures rather than standards. An example would be performance, for which standard APIs or protocols are of limited use.
Copyright © The Open Group, 1998, 1999