Describe Services

Define the functionality to be reused across the HS Agency's systems.

Introduction Activities Roles and Responsibilities Artifacts Additional Resources

A-TARS: - Technology Boundaries Descriptions - HS Agency-Wide System Properties - Integrated Technology Descriptions - TRM Description - Services Reference Set - Technical Architecture Work Plans and Direction - AIS Design and Implementation Info. - Ancillary Design Information - Strategic Analysis and Data - Changes Develop Service Descriptions Update Service Descriptions - A-TARS: Services Reference Set - Ancillary Design Information - Changes - Status - Service Area Specialists - Other Technical Specialists

Introduction

These activities create and update the Services Reference Set descriptions. This portion of the A-TARS specifies the elementary services on which the HS Agency's distributed applications are composed. The elementary services are partitioned according to the application architectures. Services, when implemented, will be allocated to processing nodes. They are accessed in accordance with the system architecture, as noted in the Describe Integrated Technology Blueprint activities.

Software that implements the services is packaged to allow services to be reused across the HS Agency. This may include deploying services as stand-alone application executables, components, Web-based services, procedure/function/class libraries, or providing them by commercially purchased solutions or through service providers (e.g., Application Service Providers.

The service definition provides the service interfaces, execution behavior, reference implementations, and other information essential for consistently procuring, building, and deploying common, reusable, and interoperating services. The services are organized according to service areas in accordance with the enterprise TRM.

Top

Activities

Consolidated guidelines are available to perform the following key activities:

1. Develop Service Description. These actions build descriptions of the services by performing the following:
   • Review the boundary descriptions, the TRM, the application architecture, and the system architecture to identify the types of services, the functionality they should provide, and how they will be packaged (e.g., as a.dll or.exe file). The Technical Architecture Work Plans and Direction guide which portion of the architecture will be elaborated for each plateau.
   • For each unit of functionality that is encapsulated, a service description will be developed. The Service Area Specialists identify the standards on which the service will be defined. This may include existing HS Agency assets, such as reused software application modules. Architectural Studies may be necessary to investigate and identify the best approaches for defining a service.
   • A description of the service is produced, detailing the interfaces and the behaviors a user needs to understand to build and use an implementation of it. These users are primarily other IT application developers.
   • Create reference implementations to reduce design risk, when needed. These can be used to indicate how the service can be implemented and used and to confirm that it can satisfy the properties indicated by the Establish AGency Systems Properties activities. The reference implementations may help remove ambiguity in the definitions and provide a basis of generating functional tests for implementations. The reference implementation may not exhibit all the properties of a robust implementation of the services, such as error recovery.

   • Compile, review, and publish drafts and final versions of each description. Formal technical reviews such as peer reviews ( CMU SEI 1995) can be used to review the descriptions. The individual descriptions should be placed under a version control process to track changes.

2. Update Service Descriptions. As technologies, standards, and APIs from vendors evolve, the items described in this guide will change. New services will be defined, existing interfaces adapted, and some services retired when no longer needed, such as those that act as connectors to a legacy system that will be retired. Changes may ripple through to other parts of the A-TARS and should be evaluated. Changes to the description must be evaluated, dependencies between definitions made, and changes synchronized between this and other parts of the A-TARS. A versioning scheme and maintenance approach to allow for multiple versions of the service interfaces and implementations to exist should be described in the Guidelines.

Top

Roles and Responsibilities

The key roles and their responsibilities for these activities are:

• Service Area Specialists. These individuals are responsible for producing the service descriptions, either as authors or technical managers. They are members of the Core or Extended Technical Architecture Team. They are knowledgeable in the areas that each service addresses.
• Other Technical Specialists. These individuals support the definition of the services, either as authors or Subject Matter Experts, or produce reference implementations and prototypes. These specialties may be obtained from within the IT Division or external (consultants), as needed.

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 end-user services provided and the environment and platform capability to deliver them.
  • Agency-wide System Properties. These properties are used to guide the design of the services, such as performance or scalability.
  • Integrated Technology Descriptions. These descriptions provide the context for the services, showing how they relate to one another at the application and system level. These descriptions guide the definition of the individual services.
  • TRM Description. This description guides the identification of the required services. It can be used as an application and system architecture independent index into the service descriptions.
  • Services Reference Set. These descriptions are the main product of these activities, updating the previous version, if it exists.
• Technical Architecture Work Plans and Direction. These work plans guide the execution of these activities, coordinating the individuals performing these activities with other Technical Architecture tasks and the IT projects.
• AIS Design and Implementation Info. An understanding of the existing technology is used when defining the services, especially if the legacy systems will be retained in the next version of the A-TARS. This provides a ready source of detailed design information, such as interface documentation.
• Ancillary Design Information. Information associated with the design is retained, as needed (e.g., results of architectural studies such as performance appraisals). This information may be used to produce guidelines that users of the descriptions can reference for additional understanding.
• 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 A-TARS descriptions that must change. Changes for other parts of the A-TARS also can be generated, such as updates to the TRM, boundary, integrated descriptions, 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 page portion of the IT Planning and Management Guides. Resources specific to this activity are cataloged below.

Top