If we assume that the likelihood of global conventional war is minimal, the fleet of tomorrow (within 15 to 30 years) will not differ significantly from that of today for several reasons. First, platforms generally have an actual service life of 20 to 40 years or longer (despite the service life advertised at procure- ment). Although they may be modified with newer equipment from time to time, the basic platform with most of its original systems will remain intact.
Second, the current Department of Defense procurement cycle, for all but the most simple, inexpensive, and mundane of systems, is on the order of 10 to 15 years. Barring a major technological breakthrough (reminiscent of the atomic bomb), that could seriously tip the balance of power; it is virtually impossible to propose any significant improvements and expect them to be in place in a shorter timeframe. Existing platforms and systems thus form a base upon which to build. The following architectures are defined and established for reference:
94 Building A Global Information Assurance Program
䡲 Baseline architecture: The hardware that is actually operational today.
This category includes all deployed sites, platforms, and systems and their associated functions, and is identical in content to the baseline architecture discussed previously. The baseline is the generic architec- ture that forms a basis for the development of all future architectures.
䡲 Current architecture: At any one time, there are several approved, funded, “viable” equipments in varying stages of the development and procurement cycle. By virtue of the fact that these systems have already been approved through a lengthy chain of endorsers from the individual program office, up through the Secretary of the Navy (SecNav) and Congress, they are virtually impossible to impact significantly. Though most are not rigorously integrated into the overall architecture, they can be shown to be answering a threat that already exists. Except in very extreme cases, interference with these programs is counterproductive, and quite possibly (politically) pointless. Each has associated with it a target date for initial operational capability (IOC), i.e., the date by which the first unit is expected to be installed, tested, certified, and deployed on an operational platform. All such equipments whose IOC falls within the timeframe defined by the Five Year Defense Program (FYDP) are added to the baseline with appropriate removal of replaced, obsolete equipments, and the result is titled current architecture. This document is the basis for establishing current force performance assessments.
䡲 Current-plus architecture: As one might suspect, not all approved, funded, “viable” procurements are scheduled to IOC within the next five years. Though these may be important systems with significant impact on the war-fighting capability of the fleet, they are also at the mercy of Congress and budget cycles for a prolonged period of time, and their prognosis for successful completion, therefore, is less rosy.
Though their eventual procurement is not sufficiently reliable to count on, the capabilities of these systems are deemed indispensable, and their inclusion in the architecture mandatory. To cover this class of system, the current-plus architecture is established to include these systems superimposed on the current architecture previously described, and is intended as a point of departure for the notional system.
䡲 Notional architecture: The final product, the ultimate goal for the entire process is the development of a notional fleet architecture for some future date. As previously explained, that date is generally 15 to 20 years in the future. For purposes of further discussion, it will be assumed that one such document is to be produced, although several alternative notional architectures could (and probably should) be developed to give decision makers an alternative.
Similar “architectures” or categorizations of systems can be defined for any organization. The names and definitions will, of course, change to fit the context, but within any organization, it is important to establish the current state of the organization, the goal state of the organization, and possibly one
of platforms, sensors, weapon systems, and communication links required to fulfill the needs of naval forces. It includes the macro-assignment of functions to platforms and systems, and the categorization of like functions together for purposes of commonality, as well as addressing the needs of individual platforms to operate both autonomously and within the context of the battle force. It is a systematic, structured approach to determining the composition of hardware and software systems for naval forces.
The systems architectures, then, are developed by segmenting the force into platforms, platforms into systems, and functional systems into semiauto- nomous sections (subsystems). Each segment is allocated specific functions and is configured to fit together with other segments along well-defined boundaries (interfaces) in order to perform the functions of the total system.
Exhibit 13 depicts the elements of an architecture; Exhibits 14 and 15 are examples of how an architecture might be represented.
Accurate, logical segmentation at the outset is probably the most-important single element of the system design. Failure to do well is seldom correctable and, at best, extremely expensive.
Exhibit 13 Architecture Elements [Wiersma, 1987]
96 Building A Global Information Assurance Program