MIL-HDBK-61A: Configuration Identification

5.8 Interface Management

Another aspect of configuration identification to be considered during development is interface management, also referred to as interface control. Acquisition program managers responsible for new systems may have interfaces with other systems. Those interfaces constitute design constraints imposed on the programs. As the system is defined, other interfaces between system components become apparent. All of the interfaces between co-functioning items need to be identified and documented so that their integrity may be maintained through a disciplined configuration control process. In some cases a formal interface management process must be employed in order to define and document the interface.

Interfaces are the functional and physical characteristics which exist at a common boundary with co-functioning items and allow systems, equipment, software, and data to be compatible. The purpose of all interface management activity is that:

The detailed design of each of the co-functioning items contains the necessary information to assure that the items, when individually designed and produced will work together (as the 115-volt plug to the 115-volt electrical outlet), and
If either item needs to be changed for any reason, its performance, functional or physical attributes, that are involved in the interface, act as constraints on the design change.

During development, part of the contractor's design effort is to arrive at and document external interface agreements, as well as to identify, define, control and integrate all lower-level (i.e., detailed design) interfaces. Figure 5-5 illustrates many (but not all) of the possible interfaces that may exist between systems and within a system. Interfaces include external interfaces with other systems, internal interfaces between CIs that comprise the system, and internal interfaces between CIs and other components of the system (e.g., personnel, non-developmental items (NDIs), facilities); as well as the interfaces between acquiring activities and supplying activities. In some cases, interfaces between two or more acquiring activities must be established (See Interface 3 in Figure 5-5 and Table 5-15.), typically by means of a Memorandum of Agreement between service components or commands with in a service component that are acquirers of or users of interfacing equipment.

To understand how a particular interface should be defined and managed, it is necessary to categorize the interface in a number of ways:

Contractual relationship - Are the items supplied by the same contractor or by different contractors? If different contractors, is there, or will there be, a contractual relationship (such as a subcontract or purchase order) between the parties to the interface?
Customer relationship (Acquisition activity(ies) - Is the same acquisition activity responsible for both interfacing entities or are different activities or even services involved?
Hierarchical relationship - Is the interface at the system, CI, assembly, or part level?
Type(s) and complexity of technical interface attribute(s) involved - Is the interface a mechanical, electrical, electronic, installation, data, language, power, hydraulic, pneumatic, space, operating range, frequency, transmission rate, capacity, etc. (to name a few)
Developmental status - Is one both or none of the interfacing items a non-developmental item (NDI)? Do the interfacing items require parallel design and development?

Categorizing the interface in this manner defines the context and environment of the interface, and enables the appropriate measures to be taken to define and control it. Each interface must be defined and documented; the documentation varies from performance or detailed specifications to item, assembly, or installation drawings, to interface control documents/drawings. Some interfaces are completely managed within the design process; others require specific types of formal interface management activity. The simplest and most straightforward approach that will satisfy the above objective should always be chosen. Extravagant and complex interface management activity, should only be undertaken when other methods are inappropriate.

Whether formal or informal interface management is employed, it is necessary that there be a legal responsibility on the part of the interfacing parties, since even the best intentioned technical agreements can break down in the face of fiscal pressure. If there is a contractual relationship, including a teaming arrangement, between two or more parties to an interface, there is already a vehicle for definition and control. However, where there is no contractual relationship, a separate interface agreement may be necessary to define the interface process and provide protection of proprietary information. When the agreement involves two or more contractors, it is referred to as an associate contractor agreement; when two or more Government activities are the parties to the agreement, a Memorandum of Understanding (MOU) is generally used.

Within an organization, and often with subcontractors, integrated product teams may be used to establish interfaces. Some interfaces must be defined through a formal interface management process involving interface control working groups (ICWGs). An ICWG is a specialized integrated product team comprised of appropriate technical representatives from the interfacing activities. Its sole purpose is to solve interface issues that surface and cannot be resolved through simple engineer-to-engineer interaction.

Once interfaces have been agreed-to by the parties concerned, they must be detailed at the appropriate level to constrain the design of each item and baseline the configuration documentation so that the normal configuration control process will maintain the integrity of the interface. Then it may be necessary to convene an ICWG or other mechanism on rare occasions to resolve change issues in a satisfactory manner. The Government is the arbitrator of issues that cannot be resolved by an ICWG or IPT, such as those issues which involve contractual issues requiring contract changes and agreement between different acquisition activities.

The following guides, Tables 5-14, 5-15 and Figure 5-6 provide information concerning the appropriate selection of interface documentation and methods of managing the interface. Acquisition program managers can use the guides as an aid in establishing appropriate relationships with other acquisition activities responsible for interfacing systems or items, and for assessing the adequacy of contractor's interface management approaches.

Activity Guide: Table 5-14. Documentation Defining Interfaces

Activity Guide: Table 5-15. Interface Management Process Matrix

For correct application of this information, see NOTE on Contents page