Software Engineering Institute Carnegie Mellon

Open Systems
FAQ
Bibliography
Glossary
Promises & Pitfalls

Frequently Asked Questions (FAQ) for Open Systems

At the Software Engineering Institute (SEI), we have been working in open systems since 1993, developing courses, related products, and other sources of open systems information. As part of this work, we have come across questions that people frequently ask about open systems. We developed answers to this collection of questions and put them together for you in the following pages.

If you have any questions or answers you would like to see added, please contact Tricia Oberndorf po@sei.cmu.edu.

Open Systems Defined
NDI, COTS, and Open Systems
Standards and Open Systems
The Impact of Open Systems
Promises and Realities
Why the Move to Open Systems?
Reference List

Open Systems Defined

What is an open system?

Put twenty people in a room, and you will find at least twenty different definitions for this term. The DoD's Open Systems Joint Task Force (OSJTF) defines it as:

A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability.

An open system is characterized by the following:

This definition provides a good high-level vision of what open systems are all about. For a more operational definition, we can turn to this one.

An open system is a collection of interacting software, hardware, and human components

What is an open system architecture?

As with the definition of open system, there are various definitions of the concept of open system architecture. A simple one comes from the OSJTF:

One definition that is consistent with the more operational definition of open system given above is:
An open system architecture is a representation of a system in which there is

1 An open systems approach is a business approach that emphasizes commercially supported practices, products, specifications and standards. The approach defines, documents, and maintains a system architecture that depicts the lowest level of customer (e.g., military) system configuration control. This architecture clearly identifies all the performance and interface characteristics of the system including those that will be accomplished with an implementation that references open standards and specifications. [OSJTF]

NDI, COTS, and Open Systems

What are the differences between commercial off-the-shelf (COTS) products, open systems, and non-developmental items (NDI)?

Non-developmental item (NDI) is defined as the following:

A commercial off-the-shelf (COTS) product is a product, such as an item, material, component, subsystem, or system, sold or traded to the general public in the course of normal business operations at prices based on established catalog or market prices [FARs].

You can see from these two definitions that COTS is a subset of NDI. The general point of NDI is that it is something that your program does not need to pay to develop because it already exists. COTS products are that subset of NDI that not only already exist but are for sale to anyone from vendors.

Open systems is an approach rather than a classification. COTS products and NDI may be used to help accomplish open systems goals, and that is the relationship between these terms.

Standards and Open Systems

What is a standard?

The common English definition says a standard is something set up and established by authority, custom, or general consent as a rule for the measure of quantity, weight, extent, value, or quality or as a model or example. The formal (accredited) standards community defines a standard along the lines of this definition from the IEEE.

A document established by consensus and approved by an accredited standards development organization that provides, for common and repeated use, rules, guidelines, or characteristics for activities or their results, aimed at the achievement of the optimum degree of order and consistency in a given context [IEEE 91].

For the purposes of open systems, however, there is a need for a definition that is more specific to our topic but more pragmatic than these are. So the following definition best suits the purposes of open systems:

A standard is a publicly-available (2) document defining specifications for interfaces, services, protocols, or data formats, established by consensus.

2 "Publicly available" means that anyone is free to acquire a copy of the standard, to implement a product to its specifications, and to sell that product without restriction. There may be some fees involved, such as a fee charged by a standards organization to cover the cost of reproducing and distributing the standard or a small license fee for its use, but such fees must be minimal and reasonable so that widespread use of the standard is not discouraged.

How do standards and open systems relate to each other?

Interface standards are the cornerstone of an open systems approach. The goal of open systems is affordable acquisition of systems, which often translates into affordable acquisition of system components. In some cases it is possible to buy a whole system that suits your needs; more often, it is necessary to put that system together from existing components. You can try to go out and buy those components from commercial sources, but how will you integrate them into the system you need? Interfaces are the glue, and standards are the key to being able to buy existing components that have some chance of being successfully integrated.

What standards should I use?

There is no one answer to this question that will suit every system's needs. In each case, you must select the standards that are needed by your system and that meet your system's requirements.

When selecting standards, remember that not all standards are created equal. You should strive to use standards that are "mature," but not too mature. A standard is mature if it has reached its full natural growth or development.

However, it is sometimes hard to know when a standard has reached maturity. Some indicators of standards maturity include the availability of products, the approval of some appropriate consensus group, stability, and user interest. Standards maturity brings up the cost-and-schedule challenges of an open systems approach. Immaturity has risks, but sometimes it is not possible to wait for the full completion of an accredited standards approval process. In each situation, you must trade off the cost-and-schedule impacts with the risks.

Some organizations have tried to catalogue the standards that are currently available to help you decide which ones you might want to choose for your system. In some cases, these organizations make certain recommendations or even give approval to only some of the available standards.

The following resources provide lists of standards that may be helpful to you:

In addition, standards-producing organizations typically publish lists of their standards.

The Impact of Open Systems

What are the differences between how I do business now and how I do business with open systems?

Differences between current business practices and open systems include the following:

Table 1: Today Compared to Using Open Systems

    

Aspect

Today

Wide Open Systems

Visibility of system internals

Greater

Reduced with NDI

Systems engineering

Created whole by one source using unique interfaces

Usually created of parts from multiple sources using interface standards

Integration

Necessary

More complex with NDI

Interoperability

Only if designed from the start

Better, especially for "after the fact"

Sources

Limited

Opportunities for greater competition

Testing

Whole system at all levels

Emphasis on interfaces and functional integration testing

Configuration management

Good knowledge and control

Less depth and more external influence

Changes

Internally guaranteed

Internally and externally generated

Supportability

Sometimes left until the end

Considered earlier, more commercial sources

Control

Direct

More indirect

Risks

Many familiar ones

Some new ones, some old ones, some reduced

Cost/schedule estimates

Often inaccurate

Opportunities for improved accuracy

Cost and schedule

Overruns common

Opportunities for reduction

If I use open systems, will I have to continue testing?

Using open systems may affect the approach to testing and evaluation, but it doesn't eliminate the need for them. If you purchase products that are commercially available, it may be that there are many other users who have tested them, although you cannot be sure that they have exercised all the parts that your system will. There may even be commercially available conformance test suites you can use, but these will only confirm the fidelity with which the product meets the standards and not how "good" that product is.

You still must test your system. You cannot assume that because a product is commercial you don't have to test it. You must be certain that when you have this product installed it behaves the way the vendor promised, which doesn't always happen. In particular, you must test the product's behavior in the context of your unique system.

Furthermore, testing done by vendors or product customers is not predictable. For example, you must be aware of conformance testing. You can hope that something has already been conformance tested for you; but if it hasn't, you may have to decide how to address conformance for yourself.

What are the advantages to using open systems?

The commonly held beliefs about the advantages to using open systems include the following:

However, these are only "common sense" advantages. We do not have enough documented evidence based on real open systems experience in the DoD to prove them.

How much money will using open systems save me?

Since there is no cost model yet to evaluate this, it is hard to speculate on how much money is saved by using an open systems approach. The answer may be "none," especially in the short-term or from the perspective of only one program or system.

What cost savings are proven with open systems?

No cost savings have been proven as of yet. This is due to many factors, including: the short time that open systems have been in development, especially within the government; a lack of clear indicators of the costs to be tracked; and difficulties in separating costs associated with open systems from those associated with other aspects of a comprehensive approach.

Promises and Realities

Does using open systems guarantee interoperability?

No, the use of an open systems approach does not guarantee interoperability. You only get interoperability to the extent that you base your system on standards whose goal is achieving interoperability. Skip choosing the right standards and specifications to address interoperability and you've skipped over interoperability. In addition, other factors besides interface standards may affect your ability to realize interoperability.

Will using open systems help me to insert technology faster?

Although not guaranteed, it is likely that a shift to open systems will enable you to insert technology faster. The key is that a (standards-based) open systems architecture affords you the flexibility to take advantage of new technology that comes along, provided it is compatible with the open systems architecture you have selected. This is not possible with rigid, custom-built, or proprietary systems.

Will using open systems cause problems with conformance and certification?

Say you want to choose a standard and purchase an implementation of that standard in the marketplace. How do you know that the implementation (product) you purchase conforms to the specifications of that standard? This is the whole area of conformance.

Sometimes there are conformance tests you can apply to a product to confirm that it meets the specifications of a standard; however, more times than not, there are no such conformance tests.

One strategy may be to fund an impartial organization to apply an existing conformance test capability to the product. In other cases, you may need to fund the development of a conformance test for the standard and use that test to verify a product's conformance.

Will using open systems decrease the possibility of schedule delay?

To illustrate the decreased probability of schedule delay when using open systems, compare these two situations. In one situation, you pay for someone to develop a product and in the other, you go out and buy a ready-made product.

Why the Move to Open Systems?

Why is there pressure to move to open systems?

The trend in government is clear. The federal acquisition laws are becoming progressively more oriented toward non-developmental items. This metamorphosis is affecting all manner of government systems, from management information systems to weapon and other mission critical systems.

The main force behind the pressure to make the change is mainly economic. With reduced budgets and downsizing, the government must find a more cost-effective way to do business. Although there are no proofs as yet that there will be cost savings resulting from a government change to an open systems approach, there is evidence from other industries that have gone through this transition that gives reason to believe it will work here as well.

The DoD can't afford to do its own thing as in the past. The necessity of maintaining our technological edge (historically our real advantage over our enemies) forces us to move to systems that can evolve more readily, as technological advances keep pushing ahead. Open systems can offer an orderly way to succeed in the new paradigm.

Reference List

The Open Systems team has composed an Annotated Bibliography.