Definition: Interface management includes the activities of defining, controlling, and communicating the information needed to enable unrelated objects (including systems, services, equipment, software, and data) to co-function. Most new systems or services require external interfaces with other systems or services. All of these interfaces must be defined and controlled in a way that enables efficient use and change management of these systems or services. Therefore, the practice of interface management begins at design and continues through operations and maintenance.
Keywords: change management, coupling, interface
MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the general principles and best practices of managing interfaces for Information and Communications Technology (ICT) systems. They are expected to identify the most efficient and effective processes and methods for implementing them and to understand the complexities that result in an increasingly interoperable world.
Interfaces are the functional and physical connections at the boundaries of ICT systems that are designed to interoperate with other systems. There are many types of interfaces, including communications interfaces, signaling interfaces, service interfaces, data interfaces, hardware interfaces, software interfaces, and application program interfaces. Interfaces are critical elements supporting the complex nature of today's systems, which are becoming more geographically distributed and interconnected with other independently developed systems. Strong dependencies on external interfaces require that special attention be given to how they are designed, managed, and publicized beyond what programs typically control within a traditional configuration management process.
The practice of Interface Management (IxM) is related to requirements and configuration management, but it is applied more specifically to the management of interfaces as a subcomponent of ICT systems. IxM is a technical systems engineering activity focused on the architecture, design, and implementation of the interface. As such, the lead or chief systems engineer typically has primary responsibility for this life-cycle management process . The major inputs and outputs might include:
- Inputs: Interface management plan, interface requirements, and interface requirements changes
- Outputs: Interface specifications, interface control documents/drawings, and interface action control sheets
For this article, the purpose of interface management activity is to:
- Provide all necessary design information needed to enable co-functionality of items, such that separately designed and produced items will be able to work together.
- Use the interface performance, functional, and physical attributes as constraints to design changes, ensuring sustainable use of that interface by an increasing and changing body of users.
Interface Management in an Enterprise Engineering Service-Oriented Environment
Interoperability requires a minimum of two items, each with its own interfaces configured in a way that enables effective joining. A plug and an outlet is an example of that interface. In ICT, interfaces need to be characterized along multiple dimensions, including function, performance, behavioral process, and data. Multiple public standards exist to help with this characterization (such as WSDL , SOAP , XML , and KML ), but these alone are insufficient. It is necessary to understand how the interface will behave and function, how it can transmit or consume data, and what sequences are required for the exchange of data. Interface management addresses this complexity through the use of an engineering management process that is well defined in various engineering bodies of knowledge, such as Software Engineering Body of Knowledge , Software Engineering Institute , International Council on Systems Engineering , and the Defense Acquisition Guidebook .
In a service-oriented environment, the key to successful system or service usage lies in the ability to effectively publicize the requirements to users in a way they understand and need. In addition, users will want some level of assurance or understanding of how that service provider plans to mature and evolve the interface so that users have some level of configuration control over their side of the interface. From a provider's perspective, it may become difficult to understand who is using the service, and the provider may not recognize the scale of the larger set of users who will be affected by any interface changes.
Best Practices and Lessons Learned
The following rules of practice can be used for both internal and external interfaces, as part of the interface management process.
Don't underestimate the need for governance. Interfaces play a crucial role in all systems, which, by definition, consist of multiple components that must interact to deliver a collective capability. Complex systems consist of numerous interfaces of various types; loosely coupled architectures entail higher degrees of abstraction than tightly coupled architectures. In the absence of proper governance, interface sprawl and variation can quickly devolve into degraded system performance, maintainability, and sustainability. Therefore, IxM, which is always important, is considerably more challenging in systems characterized by loosely coupled architectures. The need for comprehensive governance throughout the interface life cycle is essential, and early, deliberate planning is necessary.
The major IxM activities needing governance include build-time and run-time contexts. Requirements management, architecture and design standards, technical reviews, and testing are some of the major build-time governance areas, and they tend to come from a system development life-cycle perspective. Release management, configuration management, and change management are focus areas for run-time governance, and they tend to come from an information technology service management perspective. Though it is customary to distinguish between build-time and run-time governance activities, it is clear that life-cycle management spans the two, as change management tends to fold back onto requirements management and testing unfolds into release management. How an enterprise elects to organize and categorize the governance processes is not as important as the need to ensure that such oversight is executed. Also, recognize that good governance structures mature and change based on the needs of the activities being governed. Deliberately plan a mechanism for periodically reviewing the governance construct for opportunities to improve.
Establish an interface characterization framework and IxM processes early. Often, the creation of the interface characterization framework does not occur until after interfaces are developed. As a result, end users are not engaged, the framework is lagging based on information that needs to now be captured as opposed to created during the design phase, and other priorities (such as delivering the system or service) compete for the systems engineer's time. This results in interfaces that are not well documented, controlled, or publicized. The best time to start is during design, when everyone is thinking about what the system or service should or will be. Create the framework and begin capturing the planned interface information when it is being decided. Establish the teams that are responsible for executing IxM processes to give them time to determine the most efficient way to engage in the systems engineering life cycle. Allocating sufficient time to planning improves the opportunity to deliver good results.
Implement the simplest IxM approach possible. Always choose the simplest and most straightforward approach that will satisfy the objective(s). Complex interface management processes or tools should only be employed when other methods do not meet the needs of those trying to use or manage the interfaces. Why create unnecessary overhead? Engineering resources are scarce and should be used where they are most needed.
Always adhere to standards. Interoperability depends on the use of standards to successfully promulgate and grow a service-oriented environment. The use of standards-based interfaces helps minimize the amount of specialty development and therefore improves the likelihood of service reuse.
Establish service level agreements for interfaces. Trust is earned. Users need to understand what performance to expect from the interface and its underlying system. Establish service level agreements (SLAs) to document the performance parameters for the interface and underlying systems, then report performance against those measures. Remember that SLAs are as much about the provider of the interface as they are about the user. If the service level will vary based on the volume of use, clear articulation of that expected performance variation will help users understand up front, before performance begins to degrade. It will also trigger various management activities to manage that degradation in a thoughtful and planned way.
Use a well-defined framework to describe the interfaces. Having different sets of information attributes for different interfaces complicates and raises the cost of achieving interoperability. It is critical that each system or service categorize and describe the interfaces under its control consistently. In addition, this framework must focus on communicating at different layers of abstraction about how other systems/services need to use the interface. There is resistance to providing additional information beyond that required by some common repository, such as a Universal Description, Discovery, and Integration registry. It is critical that the framework address attributes of using the interfaces (e.g., business process or data flow, SLA, functionality, data map) and not just technical aspects of the interface itself. ITIL  suggests using the service catalog as a type of framework to describe services and their interfaces. An interface specification is another alternative. Regardless of which mechanism or framework is used, it is important to include information on current and future versions, their deprecation dates, the technical specification, standards, and other use-related information or tools in one logical place for user access.
Simplify the end-user development challenge with tools where possible. Develop, deploy, and manage development and implementation tools where possible. The best way to support end users is to help them understand when they have correctly configured their end of the interface. For example, conformance test kits can significantly help during the development phase to ensure that inadvertent configuration problems do not arise. This will improve end-user satisfaction and increase interoperability and usage. Sample code and even configuration schemas for commercial-off-the-shelf–based interfaces are other tools to consider providing.
Ensure persistent, active engagement of all stakeholders in the IxM process. Users or customers really like to be heard, particularly when they are being asked to make their business dependent on a system or service that is not within their control. So, provide them with that user forum and engage them in IxM activities. Interface Control Working Groups (ICWGs) can be effective mechanisms to publicize and manage interfaces with customer/user participation. Where multiple end users depend on your external interfaces, an ICWG may encourage active and constant participation, which will in turn promote consistency, prevent development of unnecessary interfaces, and reduce the risk associated with interface changes. An ICWG is a specialized integrated product team comprising cognizant 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.
Plan to deprecate prior versions. It is important not to withhold prior versions of the interface from users; however, there is a limit to which backward compatibility should extend. Backward compatibility requirements can constrain future flexibility and innovation and create maintenance and management headaches. However, it is critical for end users to have some level of stability in the interface so they can manage their own development life cycles and mission objectives. Create an opportunity to discuss an interface deprecation strategy and establish a core set of business rules that drive that plan. Ensure that cost/price considerations are understood from both perspectives, provider and end user. Then, publish the business rules in the service catalog or other mechanism in a widely visible and accessible location, alongside other user-related information. This enables users to manage their side of the interface in a way that does not strand them and also supports growth and innovation.
Publish interface information in an easily accessible and visible location. Often, users do not have ready and easy access to the information they need to use a system or service. Accessibility is required not only for the government but also their supporting contractors who may or may not have access to particular networks or knowledge centers. Interface information must be readily available from a known location accessible to all resources responsible for making decisions about and developing to the interface. Too often, system and service developers forget that users have different competency levels, and they misunderstand the depth of information users need to be able to effectively configure their systems to interface properly. Good interface management includes understanding the various types of use for the interface information and presenting the data in a way that supports getting that information easily to the user.
References and Resources
- Per DoDI 5000.02, Enclosure 12, Section 4.1.6, each Program Executive Officer, or equivalent, shall have a lead or chief systems engineer in charge of reviewing assigned programs' System Engineering Plans and overseeing their implementation.
- World Wide Web Consortium (W3C), June 26, 2007, Web Services Description Language (WSDL) Ver. 2.0 Part 0: Primer.
- W3C, April 27, 2007, Simple Object Access Protocol (SOAP) Ver. 1.2, accessed August 21, 2017.
- W3C, Extensible Markup Language (XML), accessed August 21, 2017.
- Open Geospatial Consortium, Keyhole Markup Language (KML), accessed August 21, 2017.
- Software Engineering Body of Knowledge (SWEBOK), accessed August 21, 2017.
- Carnegie Mellon University, Software Engineering Institute, accessed August 21, 2017.
- International Council on Systems Engineering (INCOSE), accessed August 21, 2017.
- Defense Acquisition University, Defense Acquisition Guidebook, accessed August 21, 2017.
- Axelos, ITIL (Formerly Information Technology Infrastructure Library), accessed August 21, 2017.
Additional References and Resources
DoD Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System, January 7, 2015, accessed August 21, 2017.
DoD Instruction (DODI) 8320.02, Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense, August 5, 2013, accessed August 21, 2017.
Military Handbook Configuration Management Guidance MIL-HDBK-61A(SE), February 7, 2001, accessed August 21, 2017.
National Information Exchange Model, accessed August 21, 2017.
Software Engineering Institute (SEI), Service-Oriented Architectures as an Interoperability Mechanism, July 31, 2009, accessed August 21, 2017.