Foundation Architecture: Technical Reference Model
opengroup.orgThis chapter describes the Technical Reference Model (TRM), including core taxonomy and graphical representation.
The detailed platform taxonomy is described in Detailed Platform Taxonomy .
Concepts
This section describes the role of the TRM, the components of the TRM, and using other TRMs.Role of the TRM in the Foundation Architecture
The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture has two main elements:- The Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services
- The Standards Information Base (SIB), which provides a database of standards that can be used to define the particular services and other components of an organization-specific architecture that is derived from the TOGAF Foundation Architecture
The list of standards and specifications in the SIB is designed to facilitate choice by concentrating on open standards, so that architectures derived from the framework will have good characteristics of interoperability and software portability, but the TOGAF Architecture Development Method (ADM) specifically includes extending the list of specifications to allow for coexistence with or migration from other architectures.
TRM Components
Any TRM has two main components:- A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an information system
- An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding
Other TRMs
One of the great difficulties in developing an architecture framework is in choosing a TRM that works for everyone.The TOGAF TRM was originally derived from the Technical Architecture Framework for Information Management (TAFIM) TRM (which in turn was derived from the IEEE 1003.0 model - see Part IV: Resource Base, ISO/IEC TR 14252 (IEEE Std 1003.0) for details). This TRM is "platform-centric": it focuses on the services and structure of the underlying platform necessary to support the use and re-use of applications (i.e., on application portability). In particular, it centers on the interfaces between that platform and the supported applications, and between the platform and the external environment.
The current TOGAF TRM is an amended version of the TAFIM TRM, which aims to emphasize the aspect of interoperability as well as that of portability.
The objective of the TRM is to enable structured definition of the standardized Application Platform and its associated interfaces. The other entities, which are needed in any specific architecture, are only addressed in the TRM insofar as they influence the application platform. The underlying aim in this approach is to ensure that the higher-level building blocks which make up business solutions have a complete, robust platform on which to run.
Other architectural models - taxonomies and/or graphics - not only are possible, but may be preferable for some enterprises. For example, such an enterprise-specific model could be derived by extension or adaptation of the TOGAF TRM. Alternatively, a different taxonomy may be embodied in the legacy of previous architectural work by an enterprise, and the enterprise may prefer to perpetuate use of that taxonomy. Similarly, an enterprise may prefer to represent the TOGAF taxonomy (or its own taxonomy) using a different form of graphic, which better captures legacy concepts and proves easier for internal communication purposes.
Apart from the need to recognize that the structure embodied in the taxonomy is reflected in the structure of the SIB (so any enterprise adopting a different taxonomy will need to reflect its taxonomy in its own SIB), there is no problem with using other architectural taxonomies and/or graphics with TOGAF. The core of TOGAF is its ADM: the TRM and the SIB are tools used in applying the ADM in the development of specific architectures. Provided consistency between TRM and SIB are maintained, the TOGAF ADM is valid whatever the choice of specific taxonomy, TRM graphic, or SIB toolset.
High-Level Breakdown
This section describes the major elements of the TRM.Overview
The coarsest breakdown of the TRM is shown in Technical Reference Model - High-Level View , which shows three major entities (Application Software, Application Platform, and Communications Infrastructure) connected by two interfaces (Application Platform Interface and Communications Infrastructure Interface).
The diagram says nothing about the detailed relationships between the entities; only that they exist.
Each of the elements in this diagram is discussed in detail in The TRM in Detail .
Portability and Interoperability
The high-level TRM seeks to emphasize two major common architectural objectives:- Application Portability, via the Application Platform Interface - identifying the set of services that are to be made available in a standard way to applications via the platform
- Interoperability, via the Communications Infrastructure Interface - identifying the set of Communications Infrastructure services that are to be leveraged in a standard way by the platform
In particular, 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 Technical Reference Model - High-Level View represents diversity, and the shape of the model is intended to emphasize the importance of minimum diversity at the interface between the Application Platform and the Communications Infrastructure.
This in turn means 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.
The TRM in Detail
This section describes the TRM in detail, including platform service categories and external environment sub-entities.Introduction
Detailed Technical Reference Model (Showing Service Categories) expands on Technical Reference Model - High-Level View to present the service categories of the Application Platform and the two categories of Application Software.
Detailed Technical Reference Model (Showing Service Categories) is only a depiction of the TRM entities: it neither implies nor inhibits inter-relationships 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.
TRM Entities and Interfaces
The following sections discuss in detail each element of the TRM illustrated in Detailed Technical Reference Model (Showing Service Categories) . They are dealt with in the following order:Application Software
The detailed TRM recognizes two categories of Application Software:- Business Applications, which implement business processes for a particular enterprise or vertical industry. The internal structure of business applications relates closely to the specific application software configuration selected by an organization.
- Infrastructure Applications, which provide general-purpose business functionality, based on infrastructure services.
Business Applications
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:- Patient record management services used in the Medical industry
- Inventory management services used in the Retail industry
- Geological data modeling services used in the Petroleum industry
Infrastructure Applications
Infrastructure applications are applications that have all, or nearly all, of the following characteristics:- Widespread availability as Commercial Off-The-Shelf (COTS) software means that it is uneconomic to consider custom implementation.
- User interaction is an important part of the application's function.
- Implementations are based on infrastructure services.
- Implementations may include significant extensions beyond that needed to use the underlying infrastructure services.
- Interoperability is a strong requirement.
- Electronic payment and funds transfer services
- Electronic mail client services
- Publish and subscribe
- Intelligent agents
- Calendaring and scheduling services
- Groupware services
- Workflow services
- Spreadsheets
- Presentation software
- Document editing and presentation
- Management applications, performing general-purpose system and network management functions for the system administrator
- Software engineering tools, providing software development functions for systems development staff
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.
Application Platform
The Platform Concept
The term "platform" is used in many different ways within the IT industry today. Because of the different usages, the term is often 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 TRM 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 TRM 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 desktop client, file server, print server, application server, Internet Server, database 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 a Technology 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 TRM. 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 a Technology 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 desktop client, print server, etc.) can contain markedly different bundles of services.
Service bundles are represented in a Technology 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 enterprise-specific Technology Architecture is to look beyond the set of real-world platforms already in existence in the enterprise. The IT architect must analyze 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 (SBBs) - real-world "platforms" - to implement that architecture.
Extending the TRM
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.
Interfaces Between Services
In addition to supporting Application Software through the Application Platform Interface (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 ability to substitute. Private interfaces represent a risk that should be highlighted to facilitate future transition.Future Developments
The TRM 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:
- Spreadsheet functions, including the capability to create, manipulate, and present information in tables or charts; this capability should include fourth generation language-like capabilities that enable the use of programming logic within spreadsheets
- Decision support functions, including tools that support the planning, administration, and management of projects
- Calculation functions, including the capability to perform routine and complex arithmetic calculations
- Calendar functions, including the capability to manage projects and co-ordinate schedules via an automated calendar
Communications Infrastructure
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 Technology Architecture in recent years has been the growing awareness of the utility and cost-effectiveness of the Internet as the basis of a 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 in Communications Infrastructure Interface .
Application Platform Interface
The Application Platform Interface (API) 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.
Communications Infrastructure Interface
The Communications Infrastructure Interface is the interface between the Application Platform and the Communications Infrastructure.Technical Reference Model - High-Level View 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 Technical Reference Model - High-Level View represents diversity, and the shape of the model is specifically intended to emphasize minimum diversity at the interface between the Application Platform and the Communications Infrastructure.
In particular, the model emphasizes 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.
Qualities
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.Detailed Technical Reference Model (Showing Service Categories) 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.
Application Platform - Taxonomy
This section describes the Application Platform taxonomy, including basic principles and a summary of services and qualities.Basic Principles
The TOGAF TRM has two main components:- A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an information system
- An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding
No claims are made that the chosen categorization is the only one possible, or that it represents the optimal choice.
Indeed, it is important to emphasize that the use of TOGAF, and in particular the TOGAF ADM, is in no way dependent on use of the TOGAF TRM taxonomy. Other taxonomies are perfectly possible, and may be preferable for some organizations.
For example, a different taxonomy may be embodied in the legacy of previous architectural work by an organization, and the organization may prefer to perpetuate use of that taxonomy. Alternatively, an organization may decide that it can derive a more suitable, organization-specific taxonomy by extending or adapting the TOGAF TRM taxonomy.
In the same way, an organization may prefer to depict the TOGAF taxonomy (or its own taxonomy) using a different form of TRM graphic, which better captures legacy concepts and proves easier for internal communication purposes.
However, a consideration to bear in mind in deciding which taxonomy to use, is that the taxonomy of the TOGAF TRM is used in structuring the TOGAF SIB, the database of all industry standards endorsed by The Open Group which is available for populating an architecture. Any differences from the TOGAF TRM taxonomy would need to be catered for when using the TOGAF SIB. (This typically represents an additional overhead, but not a major obstacle.)
Application Platform Service Categories
The major categories of services defined for the Application Platform are listed below.Note that "Object Services" does not appear as a category in the TRM taxonomy. This is because all the individual object services are incorporated into the relevant main service categories. However, the various descriptions are also collected into a single subsection (Object-Oriented Provision of Services) in order to provide a single point of reference which shows how object services relate to the main service categories.
- Data Interchange Services (Data Interchange 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
- Multimedia processing functions
- Media synchronization functions
- Information presentation and distribution functions
- Hypertext functions
- Data Management Services (Data Management Services):
- Data dictionary/repository services
- Database Management System (DBMS) services
- Object-Oriented Database Management System (OODBMS) services
- File management services
- Query processing functions
- Screen generation functions
- Report generation functions
- Networking/concurrent access functions
- Warehousing functions
- Graphics and Imaging Services (Graphics and Imaging Services):
- Graphical object management services
- Drawing services
- Imaging functions
- International Operation Services (International Operation Services):
- Character sets and data representation services
- Cultural convention services
- Local language support services
- Location and Directory Services (Location and Directory Services):
- Directory services
- Special-purpose naming services
- Service location services
- Registration services
- Filtering services
- Accounting services
- Network Services (Network Services):
- Data communications services
- 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
- Operating System Services (Operating System Services):
- Kernel operations services
- Command interpreter and utility services
- Batch processing services
- File and directory synchronization services
- Software Engineering Services (Software Engineering Services):
- Programming language services
- Object code linking services
- Computer-aided software engineering (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
- Transaction Processing Services (Transaction Processing Services):
- Transaction manager services
- User Interface Services (User Interface 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
- Security Services (Security Services):
- Identification and authentication services
- System entry control services
- Audit services
- Access control services
- Non-repudiation services
- Security management services
- Trusted recovery services
- Encryption services
- Trusted communication services
- System and Network Management Services (System and Network Management Services):
- 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
Object-Oriented Provision of Services
A detailed description of each of these service categories is given in Object-Oriented Provision of Services .- Object Request Broker (ORB) Services:
- Implementation repository services
- Installation and activation services
- Interface repository services
- Replication services
- Common Object Services:
- Change management services
- Collections services
- Concurrency control services
- Data interchange services
- Event management services
- Externalization services
- Licensing services
- Lifecycle services
- Naming services
- Persistent object services
- Properties services
- Query services
- Relationship services
- Security services
- Start-up services
- Time services
- Trading services
- Transaction services
Application Platform Service Qualities
Principles
Besides the platform service categories delineated by functional category, service qualities affect Information Systems Architectures. A service quality describes a behavior such as adaptability or manageability. Service qualities have a pervasive effect on the operation of most or all of the functional service categories.In general a requirement for a given level of a particular service quality requires one or more functional service categories to co-operate in achieving the objective. Usually this means that the software building blocks that implement the functional services contain software which contributes to the implementation of the quality.
For the quality to be provided properly, all relevant functional services must have been designed to support it. Service qualities may also require support from software in the Application Software entity and the External Environment as well as the Application Platform.
In some cases, a service quality affects each of the service categories in a similar fashion, while in other cases, the service quality has a unique influence on one particular service category. For instance, international operation depends on most of the service categories in the same way, both providing facilities and needing their co-operation for localization of messages, fonts, and other features of a locale, but it may have a more profound effect on the software engineering services, where facilities for producing internationalized software may be required.
During the process of architecture development, the architect must be aware of the existence of qualities and the extent of their influence on the choice of software building blocks used in implementing the architecture. The best way of making sure that qualities are not forgotten is to create a quality matrix, describing the relationships between each functional service and the qualities that influence it.
Taxonomy of Service Qualities
The service qualities presently identified in the TRM taxonomy are:- Availability (the degree to which something is available for use), including:
- Manageability, the ability to gather information about the state of something and to control it
- Serviceability, the ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system
- Performance, the ability of a component to perform its tasks in an appropriate time
- Reliability, or resistance to failure
- Recoverability, or the ability to restore a system to a working state after an interruption
- Locatability, the ability of a system to be found when needed
- Assurance, including:
- Security, or the protection of information from unauthorized access
- Integrity, or the assurance that data has not been corrupted
- Credibility, or the level of trust in the integrity of the system and its data
- Usability, or ease-of-operation by users, including:
- International Operation, including multi-lingual and multi-cultural abilities
- Adaptability, including:
- Interoperability, whether within or outside the organization (for instance, interoperability of calendaring or scheduling functions may be key to the usefulness of a system)
- Scalability, the ability of a component to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates
- Portability, of data, people, applications, and components
- Extensibility, or the ability to accept new functionality
- The ability to offer access to services in new paradigms such as object-orientation
return to top of page
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
Downloads
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.
Original Page: http://www.opengroup.org/architecture/togaf8-doc/arch/chap19.html
Shared from Read It Later
Sent from my iPad | ross | ross@button.ca |
No comments:
Post a Comment