SECTION 3-Transition Methodology

3.1 Overview of the Methodology

The common site transition methodology is a standard planning approach for the acquisition and evolution of a site objective architecture (Figure 3-1) and is applicable to all DoDIIS sites. It emphasizes DoDIIS standards and the use of migration applications. The approach provides a common framework that accommodates planning for standard and unique applications.

Figure 3-1. Methodology Overview (click for full sized image)

3.1.1 DoDIIS Community Integration

3.1.1.1 Site Integration within the DoDIIS Community

In the past, many DoDIIS sites have supported unique activities connected by the DoDIIS network, but each site is currently becoming more integrated with the rest of the DoDIIS community. Remote access to distant applications and data is a routine activity on the network. Site access to national capabilities, such as the delivery of near-real-time (NRT) processed sensor data, requirements management, and use of national databases, is becoming more important. With the exception of a limited number of site unique components, the applications and components that will make this community-wide sharing of resources possible will be developed and maintained by the DoDIIS community. The Joint Worldwide Intelligence Communications System (JWICS) and SIPRNET are part of the DoDIIS infrastructure and are developed, maintained, and funded by the DoDIIS community.

This trend towards greater integration of the community calls for transition to the DoDIIS Client Server Environment Technical Architecture & Framework. and compliance with the DoDIIS Profile. Implementing the architecture will create coherent and unified information applications that facilitate the sharing of information and more effectively support intelligence collection, production, and dissemination.

3.1.1.2 Commonality Between Sites in Transition Planning

The major trends in DoDIIS described above, i.e., the increasing integration of the military intelligence community, the development of migration applications, and the promulgation of DoDIIS standards and a standard architecture, will standardize military intelligence site installations worldwide.

The DoDIIS Client Server Environment Technical Architecture & Framework results from the similarity of organization, missions, and functions at each intelligence activity. Although the specific missions and areas of interest may vary between intelligence centers, personnel use similar skills, concepts, and training based on common doctrine and worldwide U.S. military experience. These common concepts and skills are organized around a standard set of intelligence functions. These functions, or subfunctions, are used for the execution of every mission at every intelligence center or activity. Also, these functions support the transition planning methodology for managing, planning, and integration of the migration applications at all DoDIIS sites.

The similarity between the sites creates similarities in planning for site implementation. Use of a common planning methodology and the management tools including Intelink and Intelink-S will facilitate sharing of expertise, technology, and lessons learned. It will also improve tracking and status reporting at the military Service and DoDIIS community level and will facilitate the consideration of site issues in migration application transition planning.

Parts of site planning will remain site or Service specific. The resulting unique intelligence requirements may need a capability and/or component unique to a theater, site, or military Service. However, these unique components will (to the extent practical) evolve to DoDIIS Profile consistency and integration with the common infrastructure provided by the migration applications.

3.1.2 Four-Phase Approach

The DSTM is one of a series of documents prescribed by DoDIIS management to guide sites toward an open applications architecture. The overall methodology, shown in Figure 3-1, is performed in the following four phases:

• Phase I - Guidance Development, Baseline Description, and Initial Site Planning
• Phase II - Site Security Certification/Accreditation
• Phase III - Site Transition Activities/Migration Applications Implementation
• Phase IV - Operational Acceptance and Final Accreditation

The guidance and direction presented in this document is part of this four-phase approach. This approach to site transition identifies and delegates planning, management, and security responsibilities to various elements of the DoDIIS management as illustrated in Table 3-1. This methodology provides a site transition mechanism by documenting overall policy, procedures, and architectural guidance and compliance.

Phase I Transition Planning Guidance includes this document as well as all appropriate architectural and security guidance. Baseline description requires each site to prepare a formal description of the site mission and requirements, the current site configuration, implement an approved configuration management plan and procedures, and establish a Site ISSM and Site SIMO.

Preliminary Baseline Descriptions were developed for the Phase I Site visit by DoDIIS SIMO and Computer Security Office personnel. These descriptions will be updated by the formal baseline description presented in the STP. At Command or Service component sites that were not scheduled for a formal site visit by DoDIIS SIMO and Computer Security Office personnel, the STP documentation will substitute for the site visit and will provide all required site documentation. The Site Transition Plan should update all previous site documentation, especially the Site Baseline Description. The site must have a configuration management process (developed jointly by the Site ISSM and Site SIMO) in place and must have identified an ISSM and SIMO at this time. A small number of sites at the Command level have already received site accreditation based on the established Phase I baseline. In this case, the Site ISSM must approve the baseline description in the STP as representing the accredited baseline plus changes made in accordance with the site configuration management procedures. It should be noted that the security baseline that is required by the Site ISSM to accredit and control the site configuration is significantly more detailed than the baseline required by the DoDIIS SIMO. It is the responsibility of the ISSM to document and maintain this more detailed description of all site applications and interconnections.

Participants	Phase I		Phase II	Phase III	Phase IV
DoDIIS SIMO *	Initial Site Visit, Site Baseline, SIMO Identified		Baseline Verification and Transition Planning	Site Transition Planning Support STP Development	AUDITING SITE ARCHITECTURE IMPLEMENTATION
Site Accreditors	Initial Site Visit Security Boundary ISSM Identified		SITE SECURITY CERTIFICATION / ACCREDITATION	Security Transition Support	SITE SECURITY ACCREDITATION COMPLIANCE VALIDATION
ERB	Technical Assessment		Technical Validation	Site Transition Technical Support	Auditing Site Technical Activities
Resource Monitor	Site Resources Baselined		Site Resources Validation	Site Resources Evaluation / Support	Site Resources Evaluation
Service Certifier	Test Director Identified		Test Director	Site Security Transition Support	Site Compliance Validation
Site SIMO	Develop STP / Maintain Integration Status		Support Certification / Accreditation	Execute Transition Strategy and Status	Plan Next Generation Capability
Site ISSM/Site Configuration Manager	Define Baseline		Manage and Control Baseline	Manage and Control Baseline	Manage and Control Baseline
DoDIIS TEAM LEAD		* Service SIMO may also participate in any Phase

Table 3-1. Four-Phase Transition

The Phase II Site Baseline Security Accreditation is the security accreditation of the established baseline application together with approved changes; an accredited baseline must be achieved between initial baseline description and approval of the completed site architecture. This phase has already been completed for some sites, will be completed quickly for other sites but will require a substantial period of time to complete for all sites. The transition from the site baseline architecture to the objective architecture may overlap with Phase II security activities. It should be noted that the security accreditors may perform additional audits between Phase II and Phase IV to verify that a site is maintaining a controlled evolution from the baseline to objective architecture.

The Phase III transition process is the evolutionary replacement of the baseline configuration with the objective site architecture. The objective architecture is based on current DoDIIS architectural guidance, site requirements, preliminary migration application information, and when completed, the DoDIIS Master Transition Plan. This methodology provides a generic format for a site specific description of a DoDIIS architecture that should be used in each site transition plan. Other information in the STP will be used to coordinate the overall transition process between the sites and the migration application developers. Phase III is the overall process of preparing for and installing the applications that comprise the objective architecture and terminating the baseline legacy applications. Activities in the phase include review of the site architectures and security planning and the site Configuration Management (CM) process.

The STP objective, year-by-year architecture will be managed by the Site SIMO using a Transition Increment Process (see Figure 3-2, Transition Increment Process). This Transition Increment Process includes status reviews, configuration changes, updates to schedules, and dependencies. Continuing transition planning is supported by data entry and update of Intelink. This phase is complete at each site when the objective architecture for the site is installed and operational.

In Phase IV, operational and security testing, together with a site compliance and configuration verification audit, establishes the site as meeting functional requirements and security requirements for continued accreditation. The completion of Phase IV provides the final operational capability for the site objective architecture.

Figure 3-2. Transition Increment Process (click for full sized image)

3.1.3 Associated Management Concept

The DSTM prescribes the minimum set of site configuration that is required. Each STP will be written in accordance with this transition methodology and the guidance provided in the Appendix A of this document. This appendix, DoDIIS Site Transition Plan Template, provides a framework by which each site SIMO, in coordination with the Site ISSM, shall develop their own site transition plan incorporating this minimum set of data requirements. For transition planning, requirements in the DSTM are specified for two types of DoDIIS sites:

A DoDIIS Site (Type A) is a Command/Service/DIA organizational component that plans to install one or more of the DoDIIS Migration Applications and supporting infrastructure. All Type A DoDIIS Sites are required to prepare (or be included within) a full site transition plan including all DSTM requirements. (Note: This definition requires some collateral sites to prepare site transition plans; however, these sites are not required to provide the Security CONOPS and Security Architecture documents required for SCI sites.) Oversight of organizations that are not part of a Command/Service/DIA but satisfy the remainder of this definition are the responsibility of the DoDIIS SIMO.

A DoDIIS Site (Type B) is a Command/Service/DIA organizational component that supports the preparation and presentation of intelligence information to military commanders and national level decisionmakers. In order to support the exchange of information with Type A sites, that component has been authorized to purchase software products from the SASS contract. No utilization of migration applications is planned and other elements of the CSE infrastructure are optional. A STP is not required for TypeÊB sites, but these sites should be listed in the STP for the responsible Command or Service (see Annex C of the STP). Oversight of organizations that are not part of a Command/Service/ DIA but satisfy the remainder of this definition are the responsibility of the DoDIIS SIMO.

The management concept for the STP is based on a set of Intelligence Functional Categories defined by the Intelligence Systems Board (ISB) Migration Panel for the evaluation and selection of Migration Applications as part of the Intelligence Community implementation of the DoD Corporate Information Management (CIM) process. These Functional Categories are based on the Intelligence Functions for Joint Operations, as defined in JCS, Joint Pub 2-0, Joint Doctrine for Intelligence Support to Operations, 5 May 1995 and are listed in Table 3-2 and in Appendix A in TableÊA-1. The second column in the table identifies those areas that are derived directly from Pub 2; those categories not checked were added by the ISB during the migration application selection process. Appendix D to this document provides the list of Migration Applications and Site Unique Applications currently being managed by the ISB in each of the Functional Categories.

Table 3-2. Functional Categories

3.1.4 Baseline Intelligence Functions

The STP represent the schedule when the site is prepared to support migration application installation and operation. The final installation schedule will be coordinated by the DoDIIS SIMO and approved by the DMB based on site needs and priorities, migration application schedules, and overall resource availability. Sites must manage and control these application installations so that required infrastructure and supporting applications are operational for the scheduled installation of each migration application.

Legacy applications supporting the functional requirement will be scheduled to remain in place until the replacement migration application is operational. Determination of operational status will include sufficient operation by end users to verify that the migration application satisfies their requirements. Operation of legacy applications will be terminated when the planned capabilities are supported by the combination of available migration applications.

Sites must also control, promulgate early, and periodically review changes to the site configuration so that developers, integrators, and installers understand the future environment of their applications. The reviews must also consider the impact of proposed changes on all functional categories to assure continued interoperability and application stability.

3.2 Functional Model

Implementations of the DoDIIS site architecture must fully support the site's missions. This must also consider relationships with other sites and organizations, including incidental arrangements for support services. The functional model is intended to provide a basis for managing DoDIIS costs and requirements on a community-wide basis.

The description of Site missions and functions will be based on the set of Functional Categories used by the ISB to evaluate legacy and migration applications and listed in Table 3-2. Analysis will identify a subset of these categories that constitute the site mission. This analysis will consider requirements documentation as well as existing application support and will describe specific requirements in each category. This description will include site mission and function statements, external relationships with the command and other sites, and external data flows that are supported as part of a mission requirement. The site requirements statement will be used to support identification of the migration application configuration required at the site, prioritization of application installation schedules, and as a guide in scheduling legacy application termination. It will also provide a basis for tracking functional costs throughout the DoDIIS community and will be used for the site configuration audit to verify that the objective architecture satisfies all site requirements.

3.3 Technical Model

The site architecture is the collection of applications(systems) that support the set of site missions and functions described in the Functional Model. This includes GDIP-funded legacy applications that are designated to transition to DoDIIS migration applications, but also includes all other information applications/processing systems that are within the site boundaries established during the Phase I site visit or identified by the site ISSM. For security accreditation, all applications within the site boundaries must be accounted for as part of the configuration controlled baseline for the site and are therefore part of the site architecture described as part of the technical model. Note: The distinction between DoDIIS and Non-DoDIIS funded applications is being refocused on the real discriminator - funding source/types. In this revised DSTM, the term intel applications will be used to collectively refer to both. The term non-intel applications will be used to refer to those applications (Command and Control, etc.) that interface with intel applications or otherwise impact the intelligence architecture. These applications have been assigned to functional categories as part of the migration application selection process; however, for the purpose of describing the site baseline, other applications should be assigned to an appropriate category based on site usage of the application.

The Technical Model descriptions consist of three parts: (1) a narrative description of site requirements and how they are addressed by legacy and migration applications including details of the configurations; (2) a summary table showing application installation and termination dates; and (3) a functional site diagram that assigns applications to functional groups and shows the relationships between the functional applications and the supporting infrastructure. FigureÊ3­3 presents an example for a functional site diagram and Figure 3-4 shows a sample template for a multi-page layout since many larger sites will require multiple pages to describe the full site configuration. A page should show at least one (partial) functional category and the supporting infrastructure. Detailed instructions for preparing these diagrams are found in the DoDIIS Community SIMO Handbook.

3.3.1 Baseline Architecture

The description of the site baseline architecture will be organized by the Functional Categories identified in the description of the site missions and functions. The first step is to map the existing applications and components to these functional categories. The description of each category should clearly identify the specific support capabilities provided by each application in that category. As described above, all information processing applications should be listed that support the site mission, including both DoDIIS and Non-GDIP funded applications.

The description of the baseline should account for all operational applications at the time of the STP preparation and, hence, becomes the baseline for the configuration management process. At some sites, this information has already been prepared but must be updated for the STP using the Joint Pub 2 Functional Categories. If the site has already been granted Phase II accreditation, this updated baseline must be under configuration control and must be approved by the site ISSM as an accurate statement of the controlled site baseline. If the baseline has not been under configuration control, then the STP baseline must come under the control process defined by the site.

3.3.2 Objective Architecture

The description of the Site Objective Architecture will be organized by the Functional Categories identified in the site missions and functions. This description will identify an open systems architecture based on the DoDIIS Profile and planned DoDIIS infrastructure support elements. All legacy application operations will be terminated during the transition from the baseline to the objective architecture and the identified site functional requirements will be supported by DoDIIS migration applications and, in specific cases, by site unique applications.

Developing a site objective architecture is a process of selecting DoDIIS components (migration applications) to achieve an appropriate applications mix that supports site missions and responsibilities. The methodology does not generally require a classical, detailed study of requirements for support of each activity-that is done by functional control boards (FCBs) and the appropriate Defense Intelligence Functional Manager (DIFM). Instead, it is a process of identifying the intelligence functions supported by the current site baseline applications and the mapping of these functions to appropriate migration applications, as described below. The selected standard products are assembled in accordance with DoDIIS architectural guidance to create a site implementation of the DoDIIS architecture.

Each functional category that is included in the site mission is analyzed to determine the technical capabilities required to support that category. These capabilities may be expressed as functional requirements or as a migration application(s) that best satisfies these identified requirements.

The methodology assumes maximum use will be made of DoDIIS migration applications. Although these products are intended for use DoDIIS-wide, the suitability of each product must be verified for every site. Sites must examine functional capabilities and interfaces with Non-GDIP funded components that will continue to exist at the site. If the analysis reveals differences between site needs and product capabilities, an effort must be made to identify practical adaptations to meet those needs. Proposed adaptations should be discussed with the Migration Application DExA to determine practicality, cost, and schedule. A cost benefit analysis is then performed to justify the adaptation in terms of site mission impact. If the adaptations are not practical, a compelling need for the capability will require consideration of other alternatives.

(click for full sized images)

Some objective architectures will include site unique components for specialized capabilities not addressed by migration applications. The description should include a justification for the use of site unique applications and a clear rationale for why the requirement cannot practically be accomplished using migration application capabilities. A concept must be identified for the evolution of site unique components to remain consistent with DoDIIS architectural guidance at a level that allows the site unique application to be supported by the DoDIIS common operating environment. If this proves impractical or not cost effective, the component must somehow be integrated with the (DoDIIS Profile-consistent) balance of the site architecture. Possible solutions include use of servers or gateways for protocol translation. The best solution should be determined in a cost benefit analysis weighing development and operating costs against operational benefits.

Site architects should keep in mind the continuing evolution of the migration applications. The products will evolve from client/server implementations of near-stovepipe components to components of an integrated application consistent with the DoDIIS Profile.

3.3.3 Transition Planning

When the site has developed an objective architecture and a baseline description of the current architecture, a plan must be developed for the incremental transition to the site objective architecture. The Year-by-Year charts identify planned transition increments to be accomplished in each year. Together with the objective architecture, the baseline and transition charts contain a master plan for information application transition at the site. As such, they provide a configuration controlled view of the overall information application site configuration during each transitional phase from baseline to objective. The charts provide a basis for technical and schedule coordination between site requirements, migration application developers, and for coordination with the Non-GDIP funded parts of site planning.

The year-by-year charts are organized by the Functional Categories identified in the site missions and functions. Each category is supported by one or more legacy applications in the baseline configuration which will transition to migration application or site unique application support in the objective configuration. Each yearly chart will list the Functional Categories and applications supporting each category with the dates for planned installation and operation of migration applications and termination of legacy applications during the year. These schedules should include all elements of the site installation of the DoDIIS infrastructure as well as planned upgrades to baseline components. Non-GDIP funded applications identified in the baseline description should be included on the charts, and known changes in these applications should be identified in the transition charts for site configuration control purposes.

Supporting text should provide any additional details required for DoDIIS Management or DExA transition planning. This includes changes in the site mission, supporting capabilities, and available resources. Supporting text should also describe relevant site initiatives, goals and objectives, and transition strategies. The text must also describe the purpose, high level functionality, and standards used by site unique components.

Schedules for transitions will be based on site plans and requirements and any migration application schedule information available to the sites. The schedule must also identify application dependencies on infrastructure and other migration applications and plan for application installation accordingly. Legacy application termination will be scheduled based on operation of migration applications that provide the capabilities required by the site mission.

The discussion should identify the importance of specific dates to site planning for funding and legacy application operation and describe overall site priorities for migration application installation. Similarly, if the date identifies when the site is ready to support application installation but the application is not required until a later date, this should also be stated. Site mission requirements may dictate request of increased priority for component delivery, while site program delays might allow a decreased priority. Sites should realize that these represent preliminary planning dates that will require continued coordination through the STP, TIS, TIP, Intelink updates, meetings, etc., with the application (system) developers and DoDIIS management before actual installation dates can be scheduled. This will require on-going management attention to assure support for site requirements and planning for site funding.

Back to TOC

Next Section

Previous Section