6 Sep 96

SUBJECT: Intelligence Support Briefing

1. PURPOSE: Provide Information for Industry Day

2. KEY POINTS:

- The Software Support Division has built a client server network that supports locally developed applications along with DoD migration systems. This network supports intelligence production and development of supporting applications and services

- Our basis is JCS Pub 2.0 which defines infrastructure as three things-message

handling, communication, and support services. Support services are the linkage between functional requirements and technical solutions

- Technical solutions are based on DoD standards as defined in the "Technical

Architecture and Framework for Information Management (TAFIM)"

- The Department of Defense Intelligence Information System (DoDIIS) community

has selected a subset of the TAFIM and produced the DoDIIS Reference Model which is really the DoDIIS profile to the TAFIM

-- DoDIIS uses DoD standards in combination with common definitions/segments

of client/server environment and a common software development process as the basis for providing guidance to anyone developing applications for use within DoDIIS

-- Our primary objective is "any analyst-any workstation-any resources"

- Our next objective is to design/implement servers so that they are interoperable.

Extensive planning has been done to ensure building onto the network and future migration systems fit our objective

- In the '97 time frame we will have a number and variety of servers to support the

intelligence mission. We are building servers, holding developers to the same standards,

common software development methodology and common infrastructure support

services

PREPARED BY: LT COL VICKI A. COOPER, USAF

J6204, EXT. 4-0635

APPROVED BY: RADM P. D. MONEYMAKER, J6

COL LIBERTO, J62

GM-14 BAYSE, J62B

- Architecture '95 (A-95) was our plan to move support off the mainframe to the

client/server network. The transition period shows our efforts to lessen the impact to our customer. We have emphasized documentation. Along with the standard set of documents we are producing numerous documents to ease the security accreditation process. This is reengineering by the book-necessary for our goal of reaching Capability Maturity Model Level III as defined by the Software Engineering Institute

- One example of a system is the National Target Base System. We use replication server technology which provides backup and recovery for multiple data servers concurrently from a central location

- We have developed a tool called client/server application support services (CSASS) to help application programmers and increase software quality. Using CSASS, we introduce application program interfaces (APIs) to our developers to access object oriented libraries. CSASS supports three programming languages and a variety of services to promote interoperability. In the near term we are adding a Windows NT front end, an API for Oracle DBMS and APIs for Image Product Archive

- With distributed databases all operational on the same network, data definitions become extremely important. Also significant is our effort to build a common data dictionary between functional areas so applications can interoperate.

- In an attempt to improve our communications with our functional counterpart, we use functional areas as defined in JCS Pub 2.-0. We place each one of our data servers into one of the functional categories. This also helps us define the necessary interfaces

- We can look at our technical architecture projected out for five to six years. This allows us to better understand the necessary changes and make those changes incrementally, spreading the necessary resources out evenly

- Our plan for the network included an extensive view of the management process necessary to support the technical environment. This effort resulted in standard terminology for the project action officers, training to ensure the PAOs understand relationships and dependencies, and a quarterly baseline to provide developers detailed insight on what to build and the time lines

- Our quality assurance/configuration management (QA/CM) office has been a big player in our success. They control the cutover of any software into the production environment

- Communications have been taken seriously. We used technical exchange meetings to discuss different technical options. We also have system integration review for project actions officers, technicians, and management. The purpose of these meetings is to improve quality of our projects and continuity of our architectural configuration as we transition from old to new

- We have laid out our management process cycle. It includes a site transition plan and interface control documents

- Our migration is ahead of schedule and within projected cost estimates. Our architecture has accommodated ten years of change. The change management process we have in place works and is not unique to any functional area