Consolidated Guidance: Architecture Project Management

Synopsis

This is a collection of guidelines to help with planning and managing the technical architecture tasks and the use of the A-TARS descriptions.

Planning and management guidelines

The following list provides some considerations for planning and executing the architecture tasks:

• Effective management practices that apply to an IT development or maintenance project also apply to the technical architecture project. Practices to consider adapting and incorporating into the project are identified in the Software Capability Maturity Model ( CMU SEI 1995 ). Specifically, those dealing with project planning and tracking are applicable. Additional management guidance can be found for resources that apply to the Planning and Managing the Technical Evolution activities.
• Review the architecture work plans against the IT Strategic Plan for long-range direction and against the HS Program for immediate needs.
• Synchronizing each release of the A-TARS with the plateaus that the Agency will establish. The Architecture Team will work with the IT Evolution Management Team to establish the plateau definitions. Change may involve factors other than technical, such as end-user skills or budget or regulatory mandates. Detail the next plateau definition to allow for reasonable work plans to be made. Identify and characterize the following plateaus but with less detail. Architectural studies and an initial application and system architecture may be necessary before defining the plateau, such as the need to provide scaffolding or adapters to work around elements that will not be available in the plateau's timeframe. Studies minimize technical, cost, and schedule risk when defining a plateau. Update architecture work plans to synchronize with the plateaus.
• Develop the design of the A-TARS and the description of the process by which it will be used early in the planning process and use it as a basis for detailed work plans. Stakeholders should buy into this usage concept, with executive management sponsorship.
• The Architecture team will generally be small and must manage commitments carefully to avoid becoming overextended. The formal work plans should be the basis of all commitments between the Architecture Team and the rest of the Agency. This requires discipline on the part of the team to keep these plans up-to-date and get buy-in from stakeholders.
• The list of elementary processes described in the Technical Architecture Guide can provide an initial description of the tasks that you should define and manage in the architecture work plans. Add configuration management, quality assurance, and other support tasks as part of the planned tasks.
• Although the Chief Architect has management responsibility, the team Facilitator or other administrator should maintain the plans and status. This allows the Chief Architect time to focus on technical issues spanning the team and oversee the plan and status.
• Funds for the architecture project may come from across the HS programs because the programs will all benefit from the technical architecture. A means to apportion costs across the projects may be needed.

Technical Coordination and Oversight

The following list provides some considerations for coordinating the use of the A-TARS:

• Architects should be proactive in supporting the projects to reduce the likelihood of IT projects not conforming to the A-TARS. Although conformance can be addressed during IT project design reviews, waiting until a formal design review may afford little time to deal with design issues effectively .
• Quality assurance functions can provide insight to the architects on project conformance to the A-TARS descriptions. These reviews should have objective criteria to judge conformance, based on the A-TARS descriptions.
• The Chief Architect should chair any groups formally established (chartered) to coordinate changes to the A-TARS, such as a Technical Architecture Change Control Board. The Chief Architect would be the owner of the change control process (from change request to closure). Agency stakeholders should be represented on the change board, such as the HS programs.
• Architects should participate in any group formally established to manage interfaces external to the Agency technical boundaries, such as Interface Control Working Groups.
• Waivers to allow deviations from the A-TARS should be granted on a case-by-case basis, limited to a timeframe or specific actions, and be accompanied by actions that will allow for compliance in the future. Agency technical policy that requires compliance to the A-TARS should be put into effect by the executive leadership of the Agency that has responsibility for both HS programs and IT projects. This establishes a mechanism to identify and allow deviations, for good business reasons, in a controlled fashion.
• The A-TARS should bridge the immediate technology needs of the Agency, as well as consider emerging technologies. This means that some technology in the A-TARS will be retired ( FIPS 1971 ) as others emerge ( Web services ). Some IT projects may be used as trailblazing projects to implement solutions using emerging technology in a controlled fashion. The lessons learned can be fed back into the A-TARS as a standard way for the Agency to work. In this way, the A-TARS does not become part of the critical path for high-priority, quick-response, new-technology projects. Those projects are coordinated, however, by the Architects and not completely outside the control of the policies governing adherence to the A-TARS.
• Reviews of the technical architecture development activities should be conducted periodically with the Agency executive management, including the HS program and IT division management. This allows for executive insight into the architecture activities, providing management an opportunity to address risks beyond the Architecture Team's control.

Top