A key element of architecture is the establishment of technical standards. Such standards define common elements, such as user interfaces, system interfaces, representations of data, protocols for the exchange of data, or interfaces accessing data or system functions. Examples of standards include UNIX, Windows, TCP/IP, structured query language, and the Defense Information Infrastructure-Common Operating Environment. Technical standards offer a number of advantages for a system architect:
- They make it easier to exploit changing
2.5). For example, standardized interfaces facilitate interoperability because a component that conforms to a given standard can "plug" into a standard interface without concern for how the component on the other side of the interface works internally.
- They provide an understanding of data or a platform that is common to all component developers.
- They facilitate interoperability because they are accepted by multiple vendors and thus increase the likelihood that a collection of systems from diverse sources will be able to interoperate.
As advantageous as standards are, an approach to interoperability based on standards and/or standards-compliant common products must deal with certain realities and issues:
- In some areas, capabilities or services of interest are not covered by standards, although de facto standards, instantiated in broadly used products, can be an attractive option.
- In other cases, there are standards but no existing, mature products (e.g., standards "holes" in functional areas or relative to features such as security).
- Even when there are accepted standards and products compliant with these, interoperability is facilitated but not assured; there are options within standards, different releases and versions of products, and so on. The devil of assuring interoperability is in the detail of implementation. For example, the definition of an interface standard might not specify allowed and disallowed sequences in which a connecting component may call on different system functions. Thus, a component that issues a particular sequence of calls may cause a malfunction in the other component if that sequence was not properly anticipated. Vendors may also add additional capabilities or features to distinguish their products from those of their competitors; systems that rely on these features may not interoperate with systems that more closely follow the standard.
- There is a natural tension between adopting standards and taking advantage of the continuing stream of improved capability offered by technology, now dominantly driven by the commercial marketplace.
- Finally, it is important to realize that technical standards are, by themselves, necessarily incomplete from the standpoint of a system or component designer. The important thing is the operational scenarios that a system is expected to support. This range of scenarios defines the context in which a system is to perform specific desired functions and thus provides a meaningful reference for testing and evaluation.
As a general rule, some standards gain widespread acceptance in the commercial computer and communications industries and thus tend to have a long lifespan. The marketplace tends to weed out weak standards before they become widely accepted. And once a standard is widely used, industry is often motivated to maintain compliance with this accepted standard. Standards created by niche players in the market tend not to survive.
DOD, despite its size, is a small force in the overall marketplace, which suggests that if DOD attempts to create its own standards, the standards will not be viable in the long run except where they are relevant only to military applications and do not have to compete with analogous standards in the commercial sector. DOD is more likely to be successful if it exploits well-articulated and tested commercial standards wherever possible in C4I systems. An example is the use of TCP/IP. Although TCP/IP lacks certain features that would be helpful in the military environment, it is widely and successfully used by DOD. Even in those cases where today's commercial technology is not sufficient to satisfy DOD needs, a DOD-specific development is not necessarily justified. It can also be useful to project where commercial technology will be, in terms of its capabilities, in the time frame in which a DOD-specific product would realistically become available.
However, deficiencies in the security of many commercial
technologies represent a special case and deserves special attention.
Frequently, the best approach is to accept an 80% compromise solution that meets the bulk of DOD requirements.
When essential capabilities are missing from a standard, the best approach to dealing with the shortcoming is to either work to extend the standard or develop extensions to the standard. Because the use of commercial standards is such a powerful tool for ensuring ongoing interoperability, supportability, and upward evolution, designers may be well advised to use such standards even when they may lack certain features. If the lack of certain features is critical, then a custom development or an effort to have such features included in the commercial standard may be necessary. In other cases, work-arounds may be possible that enable the final product to meet the vast majority of its functional requirements. Program managers must have both an explicit strategy for developing such work-arounds as well as a credible analysis that indicates that the use of a commercial standard is tolerable. Section 4.3 discusses approaches to the use of commercial technology.