Establish Agency Technical Reference Models

Identify and organize the types of technical elements to be incorporated into the HS Agency's systems.

	A-TARS - Technology Boundaries Descriptions - Agency-Wide System Properties - TRM Description - AIS Design and Implementation Info. - Technical Architecture Work Plans and Direction - Strategic Analysis and Data - Changes
Create TRM Update TRM		- TRM Description - Ancillary Design Information - Changes - Status
	- Technical Architecture Team - Other Analysts

Introduction

These activities create and update the Agency's TRM descriptions. This portion of the A-TARS identifies and organizes the types of technology elements that are the basis of the HS Agency's automated systems. The TRM becomes the basis on which the technology descriptions in the A-TARS are organized (see background).

The TRM reflects the technology position of the HS Agency, identifying those technologies that are emerging, in wide use, or in decline. This guides architects in selecting technologies when creating the A-TARS descriptions. A technology in decline may find itself hidden behind an abstraction layer that allows it to be replaced with a newer technology. This allows the HS Agency to mange its technical direction and new technology adoption risks, as technology to meet new needs surfaces, or legacy systems are retired.

TANF Example:

The TRM can initially be structured around the HS Agencies current business processes and the automated applications and platforms in use by the Agency. Candidate items to consider were identified during the IT Strategic Planning Analyze the Situation activities, when the baseline and assessment of the current IT inventory was created. IT Strategic Plan migration decisions will determine what items to include or exclude for consideration.

The TRM is a logical model, and should not have specific vendor platforms or applications identified. It should identify the essential characteristics, of which an existing vendor solution is one of possibly many solutions. As many states have established "preferred" platform or application product lists, the categories in the TRM can therefore be built by abstracting these to specify the essential characteristics required of those items. For example, automated functions to support the caseworker can be identified and allocated to the top-level of the TRM (Functional User, Application Specific Services).

Vendor products already in the State inventory that provide generic office productivity tools can also be abstracted. and allocated to a lower level of the TRM (Common End-user, application support services) such as word processing). For example, Word processing applications establish the need for document production and exchange. HTML 4.0 support can be specified as the technology format for cross organizational document exchange, while any vendor product that can read and write these formats is acceptable.

Top

Activities

Consolidated guidelines are available to perform the following key activities:

Create the TRM. The architects perform actions to identify and describe the types of technology elements that the HS Agency must address. They create top-level categories (e.g., application, platform, or networking) and identify the suite of services needed in each area, decomposing, as necessary, to identify individual technology elements.

The TRM co-evolves with the activities to establish the Technology Boundaries, the overarching Agency Systems Properties, and the Integrated Technology Blueprint. Drafts of the TRM can be released early, although the TRM should not be considered complete until the three mentioned items are reasonably stable. The Technical Architecture Work Plans can be updated as elements in the TRM are identified. Subteams can be formed to complete the descriptions the TRM identifies, such as for the individual descriptions in the Describe Services activities.

The TRM can be documented as part of the guidelines portion of the A-TARS and integrated into the overall design and organization of the A-TARS.
Update the TRM. The TRM must be maintained to reflect the technologies in use within the HS Agency. The TRM depends on the boundaries and the system property descriptions and is a main source of input to help identify and organize the other parts of the A-TARS. This makes the TRM a key link between technology needs and the creative technical design process.

The descriptions in the TRM summarize technology areas and therefore should be fairly stable, changing only if the technology areas they identify significantly change. The higher-level parts of the TRM should change less frequently than the lowest levels. Changes generally reflect:
- Adding new technologies for use in the HS Agency, such as migrating to wireless or peer-to-peer computing technologies, or major shifts in the business functions supported
- Withdrawing technologies that are no longer in use, such as retiring a legacy system and its unique technologies or removing the need for a business function if a service is no longer offered
By establishing what technologies the HS Agency can consider, the architects can influence when emerging technologies can be incorporated into the HS Agency-wide systems or when to retire technologies from use. The absorption rate depends on the level of technology risk the organization wishes to undertake, such as being an early adopter. Technologies can be withdrawn as systems that depend on those technologies are designated for retirement or replacement.

Top

Roles and Responsibilities

The key roles and their responsibilities are as follows:

Technical Architecture Team. These individuals are responsible for producing the TRM, either as authors or technical managers. A member of the Core Team has the lead for these activities and involves experts to detail the TRM technology areas.
Other Analysts. These individuals support the technology definitions by providing application domain knowledge for the functional-user/business-area application-specific services.

Top

Artifacts

The following information is used or produced by these activities. Templates, examples, and checklists for identifying and documenting items are available through the Additional Resources section at the end of this page.

A-TARS. The previous version of the A-TARS (if it exists) is used to determine the scope of the changes for an iteration of these activities. The following key parts are used:
- Technology Boundaries Descriptions. The descriptions of the usage environment guide the decisions about the types of end-user services provided and the types of technologies required at the application or lower levels.
- Agency-Wide System Properties. These properties are used to guide the selection of the types of technologies, such as those that will promote or detract from a achieving a property.
- TRM Description. These descriptions are the main product of these activities, updating the previous version if it exists. It can be used as an application and system architecture independent (logical) index into the service descriptions.
AIS Design and Implementation Info. An understanding of the existing technology is used when defining what types of technology should be incorporated into the systems, especially if legacy systems will be retained in the next version of the A-TARS. This provides a ready source of detailed design information, such as existing application and lower-level services.
Technical Architecture Work Plans and Direction. These work plans guide the execution of the activities, coordinating the teams with each other as well as with other individuals developing or maintaining other portions of the A-TARS.
Ancillary Design Information. Information associated with the TRM is retained, as needed. This information may be used to produce guidelines or add insight into why some technologies were selected or not selected.
Strategic Analysis and Data. The strategic direction, specifically the decisions to keep, replace, renovate, or build on existing IT assets, guides the choice of technology and the integration of legacy system applications into the overall Technical Architecture.
Changes. Changes provided to these activities represent those things in the current TRM that must change. Changes for other parts of the A-TARS also can be generated, such as updates to the boundary, integrated descriptions, services, data stores, equipment, or networking.
Status. Progress and issues in developing the descriptions are forwarded to the management activities to ensure coordination between these activities and other Technical Architecture and IT project activities.

Top

Additional Resources

Items that can be used to perform these and other activities are consolidated in the Resources portion of the IT Planning and Management Guides. Resources specific to this activity are cataloged below.

Consolidated Guidance: Technical Reference Models
Guidance for developing descriptions for a TRM, including sources for examples and a sample top-level TRM organization. 7-30-01

Consolidated Information: Standards Organizations
A list of some organizations that promote or verify IT-related standards. 7-30-01

Top