Integrate, Review, and Release the A-TARS

Compile the individual descriptions into a consistent set and transition them into uses.

Introduction Activities Roles and Responsibilities Artifacts Additional Resources

- A-TARS - Ancillary Design Info. - Technical Architecture Work Plans and Direction - HS IT Strategic Plan Integrate Descriptions Into a Release Review and Approve Transition to Use - A-TARS (approved) - Changes - Technical Architecture Team - Other Reviewers - Approval Authority

Introduction

These activities integrate the descriptive materials from the other Technical Architecture activities and assemble them into a complete release of the A-TARS. This is a final check to ensure that the individual descriptions are consistent with one another; to gauge technical progress against the strategic IT direction; and to formally approve, release, and transition a version of the A-TARS into use. Actions to support the release are initiated, including the need to train and advise the users of the A-TARS. Actions also are established to check adherence to the A-TARS and to address inevitable defects in the descriptions through a formal change control process. All this takes place while the next version of the A-TARS is underway.

A major release of the A-TARS should be timed to met the HS Agency's program needs. Major releases can occur as the technical architecture is adjusted to address the plateaus. Computer systems, applications, and practices may be significantly changed, such as migrating from one technology base or another. Minor maintenance releases can be periodically released, as needed. These generally correct defects in the A-TARS descriptions, improve them to make them easier to use, or introduce other less global changes. Each IT project has to indicate which version of the A-TARS they are using and maintain plans to evolve with the A-TARS. This is key to reducing the risk of a large legacy migration steps. This allows for transforming large leaps into a more manageable set of small, evolutionary steps controlled by evolving and releasing the A-TARS descriptions.

Top

Activities

The following key activities are performed:

1. Integrate Descriptions. These actions assemble the individual architecture descriptions into a coherent and consistent release. This includes identifying and marking changes; adding front matter (e.g., Table of Contents and executive overviews); and producing cover letters, approval pages, and other items to form a complete documentation reference set. This may include:

   • Compiling and consolidating the list of standards into the Agency Standards Reference Set. This places the list of all standards in one convenient place. The relevant version of all referenced standards should be made available to anyone needing them.

   • Compiling and consolidating reserved technical terms across the descriptions in a glossary.

   • Performing technical editing across all sections.

   • Marking changes from previous versions and creating versioning information, as needed.

   • Placing the release under configuration management control.

2. Review and Approve. These activities perform a formal technical and management review of the release. Individual descriptions are assumed to have gone through appropriate technical reviews ( CMU/SEI 1995) to ensure technical accuracy. This review is concerned with integration and assumptions across elements of the A-TARS as well as issues in transforming them into use. This may include:

   • Selecting individuals for review that represent the authors, users, HS program, and IT Division management perspectives. The release Approval Authority or designee should actively participate in the review.

   • Distributing the materials and providing ready access to reference materials. Providing a checklist of what to review and noting whether there are some concerns that must be addressed.

   • Reviewers should review the materials separately, providing comments to the Architecture Team's Facilitator. Individual comments should be consolidated and then reviewed with the entire group. From that review, the consolidated list of issues can be agreed upon and actions scheduled to address them. Issues should be provided to the original authors for consideration and changes should be made, as needed. The Facilitator should coordinate any follow-up. Issues should focus on what is incorrect in the document set, not suggest improvements. A decision on the release should be solicited from the Approval Authority, such as:

     • Release when issues are incorporated; no further review required.

     • Schedule another round of review when changes are incorporated.

   • Initiate planning to transition the A-TARS into use. This includes when to phase the release into the IT projects, public announcements, training, establishing advisors to the projects, and technical oversight responsibilities. These plans should be initiated and agreed to by the release Approval Authority.

   • The release is formally endorsed by the Approval Authority.

3. Transition to Use. Once the A-TARS is approved, individuals are provided assistance in using it. This may include:

   • Publishing the A-TARS where all stakeholders can easily access it.

   • Holding communications events to describe the release and how it will be used. This may include announcements, training sessions, or orientation briefings.

   • Advising and working with the projects on any detailed transition plans.

   • Having members of the Technical Architecture Team consult with the projects.

Top

Roles and Responsibilities

The key roles and their responsibilities are as follows:

• Technical Architecture Team. The review and approval process should be managed by the team Facilitator. Individuals that have produced descriptions should participate as technical reviewers, as appropriate. They are responsible for looking across the descriptions to uncover technical inconsistencies.
• Other Reviewers. These are significant stakeholders in the use or enforcement of the A-TARS, such as key members of the IT Project and HS Program teams.
• Approval Authority. Minimally, the Chief Architect, the Agency Decision Makers, and the IT Manager must endorse each release. Others can be added, as needed, to ensure that the A-TARS is put into effect, where 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. This is an approved release of the A-TARS, updating the previous version, if it exists. The previous version is used to identify the changes made to each release.
• Ancillary Design Information. Information associated with the design is retained for each release. This includes any trade studies or notes that can be archived for later use, if needed.
• Strategic Analysis and Data. Progress in achieving the strategic direction should be furthered with each release. This reviews alignment with the strategic direction and identifies any need to change that direction.
• Changes. Changes are generated for portions of the descriptions that must be modified before release. The notion of changes also implies the need to go back and reconsider the strategic direction as the technical architecture evolves.
• 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.
• Status. Progress and issues in reviewing and approving 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