Consolidated Guidance: Technical Reference Models
| General guidelines |
| Source Material |
| Sample Top-level Categories |
Synopsis
The TRM helps organize the technology descriptions used across the Agency. Some general guidance on establishing the TRM, pointers to source materials, and sample categories are provided to help the Agency architects generate a model specific to their needs.
General guidelines
General guidelines on creating and maintain the TRM follow:
- Review the boundary descriptions produced during the Describe Technology Boundaries activities, focusing on the application-level services needed to satisfy the usage goals. Brainstorming sessions can start at the Human Services business domain-specific application-level, then consider general support applications and platform-specific services. Correlate application-level automated services with the main business processes, such as intake, eligibility, and so forth.
- Review the existing IT Inventory produced during the Analyze the Situation activities to identify the types of application- and lower-level services that may still be needed.
- Phrase the technology elements in vendor-neutral terms as best as possible. Abstract and classify the vendor-specific implementation, or explicitly note vendor dependencies.
- Review the classification scheme used by standards organizations (e.g., the IETF ).
- Consider using one or separate models based on each distinct environment because each one may have different application needs, as well as lower-level technology needs.
- The categories at the upper levels should be resilient to change and reflect core functional or technology areas; the lower levels should reflect more specific (and possibly changing) technology areas.
- Consult the Promising Practices or the State Systems Profiles for insight into what other States are doing.
- The TRM is based on some assumptions about the underlying conceptual computing or application distribution models (thin client, peer-to-peer). Document these with the TRM or design notes or incorporate them into the Integrated Technology Blueprint activities.
- It is not possible to define a complete, all encompassing TRM in one effort. It should evolve slowly as the technology in the marketplace and within the Agency changes. The details of the platforms may not be of concern if they are hidden behind higher-level abstractions (e.g., process management core services hidden by the programming language).
Source material
The source material table identifies vendor-independent sources of information to consult when building an Agency-wide TRM and selecting standards to apply. In addition to the items listed in the table, consult vendors of popular platforms or applications, trade associations, and private consortia for additional sources of common areas.
Table . Example Sources for Reference Model Elements
| Advanced Information Technology IT Reference Model | The AIT IT Reference Model ( AIT 1997 ) is the basis for defining an integration platform for providing a "plug & play" environment that isolates business applications from the underlying basic IT infrastructure. The model has its roots in the automotive and aerospace industries and is organized into basic IT infrastructure, an integration platform, and application packages consisting of business support or common activity support services. |
| CORBA-based models | The CORBA is a suite of specifications issued by the OMG that address application interoperability across multiple vendor platforms. It is based on the OMA Reference Model ( OMG 1997 ), describing four categories of object interfaces and end-user, domain-specific object frameworks. Interfaces address common object services (e.g., life-cycle management), common facilities (e.g., printing, database, mail), common application domain-specific interfaces (e.g., finance and manufacturing). Nonstandardized, application-specific interfaces and frameworks are collections of cooperating objects categorized into groups by application, facility, or service object. |
| Department of Defense Technical Reference Model (DoD TRM) |
The DoD TRM ( DISA 1999 ) is a composite model derived from the TAFIM ( DoD 1996 ) and the SAE GOA. The TRM blends the structure of the POSIX ( IEEE 1996 ) conceptual model, the services viewpoint from the TAFIM, and the interfaces viewpoint from the GOA. The TRM is intended to provide guidance for a common conceptual framework and a common vocabulary to assist in the identification and resolution of interoperability and open system issues for the DoD and other government agencies. |
| Federal Enterprise Architectural Framework | The Chief Information Officers Council (an inter-Agency forum) oversees and supports the development of this framework ( CIO Council 1999 ). The framework serves as an organizing (segmented) structure into which Federal segments can integrate their respective architectures. The framework considers business, data, applications, and technology architectures. |
| Joint Technical Architecture (JTA) | The JTA is based on the DoD TRM ( DISA 1999 ). The JTA mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use, or exchange information. The standards encompasses three viewpoints: operational, systems, and technical. JTA provides a compiled set of references to standards for each JTA service area. |
| OpenGroup Technical Reference Model |
This is part of TOGAF ( Open Group 1999 ), a basis for the Architectural Design Method. It is organized around three primary entity types -applications, application platform, and communications infrastructure- and two primary interfaces- application platform interface and communications infrastructure interface. It continues to evolve. |
| Open System Environment (OSE) | The OSE ( Schulz 1995 ) refines the core POSIX model ( IEEE 1996 ) to address interoperation for a communications, computing, and entertainment infrastructure. A profile ( NIST 1996 ) identifies some standards that can be adapted to the identified OSE services. |
| Society of Automotive Engineers (SAE) Generic Open Architecture (GOA) | The GOA Framework Aerospace Standard (AS) ( SAE AS4893 1996 ) and accompanying guide ( SAE AIR5315 1998 ) establish a framework for application-independent hardware/software systems. This document defines nine interface classes across four functional layers.
See: http://www.sae.org/ |
Sample top-level service categories
A partial hierarchy of services is provided in the service index table . This sample is intended to seed the development of state-specific services. It is not intended to be an all encompassing list. The hierarchy is organized around major and subservice areas. The categories can be further decomposed or reorganized, as needed. Each set of services should appear only once. Services for each of the environments of interest are assumed to be described, either separately or integrated into a single list. Provide a statement describing each element in the hierarchy. The top-level categories for this example are:
- Application Services. These provide for the exchange of value-added services with external entities within the environments of interest. These can be application-specific services to support the external entities functional tasks (e.g., intake for a caseworker) or common application-support services that provide non-task-specific capability (e.g., e-mail). Application entities can provide services to one another as well, such as applications that allow programmatic manipulation of their objects (e.g., the Worksheet object available from Microsoft ExcelT).
- Common Platform Services. These provide generic services that are mainly independent of any end-user external (business) process. These can be accessed by applications to use the capabilities of the platform.
- Vertical Services. These provide generic services across the applications and common services, such as security services.
- Other Common Functions. This is a catch-all category to describe common routines, data types, or other atomic building blocks. These are generally context-free, that is, independent of any business or technology domain. These may include helper functions, such as those to manipulate data structures, or common patterns for techniques incorporated across all services, such as handling exceptions or wrapping legacy system interfaces. You may include language-specific bindings here.
Although the assumption is that these services are provided by automation, this is not a necessity. Some services may be partially implemented via manual procedures (e.g., media backup, access control, or configuration control). The service descriptions show these interactions, when necessary.
1.0a Functional-User (Business-Area) Application-Specific ServicesHuman Services business-domain-specific service subareas:End-User (Functional) Services
External System (Provider) Services
|
1.0b End-User (Development) Application-Specific ServicesSoftware Engineering Services
|
1.0c End-User (Operations and Support) Application-Specific ServicesUser support services
|
2.0 Common End-User/Application Support Services(All usage environments) Multimedia services
Communication Services
Business Processing Services
Environment Management Services
Database Utilities Services
Engineering Support Services
|
3.0. Platform Common ServicesUser Interface Services
Miscellaneous Core Services
|
4.0 Vertical ServicesInternationalization Services
|
5.0 Other Common Functions and ServicesCommon libraries or other items that do not necessarily fit in any other category. |