«DEFENSE SCIENCE BOARD SUMMER STUDY TASK FORCE ON INFORMATION ARCHITECTURE FOR THE BATTLEFIELD DTlC OCTOBER 1994 S ELECTE APR I 0 1995' G i 95-01137 I ...»
The word "architecture" is currently used in many contexts. Dictionary definitions are insufficient to resolve differences in current usage; consequently it is possible for two or more people to engage in a conversation about architectures for substantial periods of time without realizing that communication among them has been inadequate. A major contributor to the confusion is lack of standard usage for what issues or topics must be included in a description of an architecture. For the traditional building architect, the blueprint offers some relief (it contains objects, their spatial connection relationships, and constraints on how a building will be constructed); however, for disciplines other than building design, the essential pieces of information to convey architecture are undefined. In concept, the word is used to describe something. The "something" being described may be as tangible as a building, or as
and intangible as a system for organizing people.
The two words "architecture" and "design" have interrelationships which make it difficult to clearly distinguish one from the other. In general usage, architecture refers to concepts or descriptions which are considered more generic than design. However, it is commonly observed that an architectural detail in one description becomes a specific design in another context. For example, the architecture of an office building is a specific design with respect to the architecture of a city. Similarly, the architecture of an office might be a specific design with respect to the architecture of an office building.
The distinction refers to the scope of influence intended by the presenter. The city architect has concern over the domain of the city. To the extent that there are city issues to be addressed and constraints placed on participants of the city which benefit the aggregated participants, city-wide architectural rules and guidelines are established. Those rules constrain options for individual Suildings, but benefit the overall collection of buildings. Similarly, there may be more constraining rules applied within individual buildings for the benefit of their occupants. Designers are expected to follow architectural guidelines, but are permitted to make more detailed implementation decisions. The distinction remains in the intent of the presenter.
D-10 Popular Definitions Of Architecture 3.3 There are at least a dozen substantially different uses of the word architecture in respect to information systems. None is better than another, just more convenient for discussions of how information systems are used or developed. Regardless of the view presented, it has been suggested by Dr. David Luckam that at the most abstract level architectures can be defined in terms of components, connections, and constraints. If this criteria is used to test whether a description of an "architecture" is complete, there may be an opportunity to bridge the gap between proponents of one architecture over another. Sometimes there are different words used for the same concepts - such as is shown for the "organizational" perspective on architectures in Figure D-6, but the basic underlying concepts are similar.
For the three views represented in Figure D-5, the organizational perspective is that held by someone involved with performing a mission, the system perspective is that held by someone involved with the collection of personnel, equipment and methods organized to accomplish a set of specific functions, the software perspective is that held by someone involved in defining software that works within a system.
FigureD-5 When the word "architecture" is used by organization oriented people, they tend to be referring to how an organization and its supporting systems are structured to serve the mission. Consequently, when C4I For The Warrior architectures are discussed, organization oriented people are thinking in terms of the functions to be provided, the logical connections between those functions - both flow of information between functional organizations and rules of decision making in the chain of command, and lastly, the physical resources (people, computing systems, weapons, etc.) needed to perform their mission.
When the word "architecture" is used by system oriented people, they tend to think in terms of the information technology elements that make up a system and the environment in which it must perform. These may include the computing resources, the sensor systems that detect and act as sources for information, etc. The connections are provided by the communications systems or networks that connect comrputing resources, and the constraints are established by performance capabilities, rules for who can exchange information with whom, etc.
D-11 The definitiont -Pd by software people involve concepts more closely allied with the structure of software.,. mponents include user interfaces, operating system services, application interfaces, etc.; connections describe movement of data and control throughout the system; and constraints capture behavior, attributes, layering styles or interface protocols, and the hardware allocations necessary to execute the software.
3.4 Current DoD "Architecture" Initiatives The DODIIS Technical Reference Model was one of the earliest instances of an organized attempt to characterize information system structures such that commonality across multiple systems might be exploited for interoperability. Although the Technical Reference Model (TRM) form of architecture description doesn't provide connectivity properties, it has become a powerful model for more recent efforts to define architectures.
The Navy Copernicus architecture is more devoted to the manner in which information is managed among C41 resources and the organizations that need access to information.
The Air Force Science Advisory Board (AFSAB) addressed information system architectures, but never formally defined the extent of coverage for the architecture. The AFSAB Information Systems architecture emphasized communications protocols between systems thereby encouraging connectivity between systems. Activities by the Air Force since its summer study have emphasized interoperability as it might be facilitated by the adoption of conformance rules for the interconnection of different C4I systems, but adoption of techniques to foster semantic consistency between systems or behavioral consistency remain to be started.
Interoperability is more than the ability to exchange bits, the bits must have the same semantic meaning on both sides of the interface. In addition, the expectations of behavior need to be consistent on both sides of the interface.
The Army Science Board (ASB) made a concerted effort to distinguish between Operational, Technical, and System architectures. The Operational architecture is an instance of organization architectures described earlier and the System architecture is an instance of the system architecture described earlier. The Technical architecture provides a set of "rules" for interoperability based on Internet compliance and captures the notion of "building codes" to ensure compatibility among systems which are built in conformance. Although the Army Science Board addressed several of the issues associated with managing information, and represents a significant advance over previous efforts; it does not include provisions for managing access to information (push, pull, broadcast, etc.), nor does it include provisions for managing vulnerability of information. There is also some useful overlap between the ASB Technical Architecture and the AFSAB Information Systems architecture As is indicated in Figure D-6, full and unambiguous agreement on the definition of "open" has similarly not been established among the services. There is much similarity, but acceptance of proprietary products which are both open and popular is a key to being able to follow and exploit the advantages touted by adopting commercial practice. Once acknowledged, there will need to be sound practices for managing systems acquired with proprietary components and protocols. These are yet to be established.
D-12 Current DoD "Architecture" Initiatives There are several initiatives to exploit architecture
- Intelligence agencies have developed the DODUS model to provide some design commonality among intelligence systems
- The Navy has developed the Copernicus system to provide a structure for the interaction of various Navy C4I systems
- The Air Force has begun to implement the Horizon concept in response to advice from the AF Science Advisory Board
- The Army has established the Enterprise effort and has recently been advised by the Army Science Board to consider adoption of a "Technical (Information) Architecture" Most of the initiatives include provision for adopting "open" systems - the definition of "open" varies but these are emerging as common properties
- Open means system interfaces are widely known.
- Desirable open components or standards are ones which are widely accepted and there are many conforming products
- Proprietary is okay Open, even proprietary open, has become the new commercial market norm. The DoD needs policX and strategies for using it FigureD-6
3.5 Information Architecture "Information architecture" is another form of architecture. To be complete, its definition must also characterize components, connections, and constraints as depicted in Figure D-7. This is particularly important, since the benefits of conformance to an architecture will not accrue if all three aspects of an arcitecture definition are not addressed. Some early efforts at defining the data consistency aspects of information systems only address subsets of the full definition and therefore have not been effective. In particular a catalogue of the many different data elements in use in the DoD wii. not promote interoperability until there is also semantic consistency among those data elements. Further, how the elements are used and managed significantly affects whether or not information can be effectively managed operationally. Too much data, outdated data, compromised data, and insufficient data can each jeopardize information dominance of the battlefield. Consequently, an information architecture is needed to describe how information should be managed in the DoD.
What the Architect Does "* Identifies the appropriate components, connections, and constraints "* Analyzes alternatives for inclusion in each category "• Publishes a description of the architecture to be implemented * Reviews the progress of systems being implemented in accordance with the architecture guidance Endorses adherence Approves variations proposed to meet exigencies Draws lessons learned, evaluates emergent technologies, and analyzes new alternatives which can be incorporated in revisions to the architecture guidance "* Addresses challenges:
- The current system suffers many limitations based on past approaches to managing information, and The system must meet a diverse set of information needs with rather sophisticated constraints Figure D-8 Architects identify the constituents of the architecture. In the case of an information architect, component definition involves the data elements critical to overall DoD C41. NOTE that this does not mean "all" DoD data needs to be defined and architected, rather, in the sense identified in the architecture definition, only the data definitions relevant to achieving some globally DoD relevant behavior. For example there may be only a few critical data elements that need to be defined in order to satisfy fundamental interoperability objectives for C41 systems. The architect's challenge is to select and define the appropriate data elements. Similarly, in the case of connections, there may be only a subset of data that needs to have semantic relationships defined. In the case of constraints, information architects will face the greatest challenge. Various schemes for managing data security, redundancy, accuracy, etc., will need to be evaluated. There may be a need for different classes of data to receive more or less stringent treatment. There will be a need to similarly evaluate alternatives for managing the distribution of data. There may also be communications bandwidth limitations and storage limitations that prevent optimum treatment of the other constraints - so architects will need to make choices relative to which data is given the most preferential treatment. Lastly, architects will be expected to seek, evaluate, and publish improvements to the architecture.
The C41 Architect faces many challenges. The current system suffers from insufficient communications connectivity and bandwidth. Systems in the field are non-compatible, noninteroperable and/or non-reprogrammable. User terminals have significant operation and maintenance costs as well as investment costs which limit their proliferation. Current information management operations concepts involve passing information step by step down the chain of command with consequential delays, errors, and omissions. There is a prioridetermination (in some cases by the suppliers) about who needs what information. Compounding the challenges is a concern over supplying users with too much data resulting in sending too little information.
4.2 Guiding Principles and Architectural Tradeoffs Figure D-9 lists many architectural trades that will impact refocusing R&D investment decisions.
D-14 eoffs Architectural mniations Ir ut * Possible logical communications approaches to guide DoD migration. Need system scalable in bandwidth and number of active/passive users (Imagery,requires instantaneous bandwidth up to low Gbps). However, there is never enough bandwidth to avoid network saturation during crises and increased bandwidth means increased vulnerability. Must evaluate trades between bandwidth and access control - as on freeways, network management schemes to handle physical reconfiguration, bandwidth allocation and network health and troubleshooting * The proper mix of DoD vs. commercial communications * Modernize site internal infrastructure (including deployable and mobile forces)
- DoD-wide established Common Operating Environment
- Local Area Networks (LANs) sized to type of information accessed
- Servers/storage, workstations, printers, scanners Security and Protection * Advances in security hardware and software components to provide:
- Secure, reconfigurable, logical circuits from windows on one workstation to windows on many workstations