Working Up

by Dwayne Phillips

Systems are commonly built by connecting smaller systems. This requires that the systems are connect-able, and that requires a defined interface.

Most of the time, we build systems by connecting large boxes together in a system diagram. There are exceptions, and another post will discuss some of those. Still, connect the boxes with lines and arrows and such. The boxes may represent hardware, software, or persons.

To connect boxes, the boxes must be connect-able. This means the interfaces of the boxes must match. We can’t connect a 110-volt electric outlet to a water hose. The interfaces don’t match.

The systems engineer is the person responsible for ensuring the interfaces match. Each box needs to have a defined interface. This documentation can take many forms (paper, audio, video, etc.), but it must exist. In technical terms, the defined interface is called an Interface Control Document or ICD. Again, it doesn’t have to be a paper document, but it must exist.

Some people think of the ICD as a contract. Others think of it as a UML diagram. Others think of it as a service-level agreement. All these work fine in the appropriate circumstances. The ICD should be visible and usable. There are no secrets here. The secrets are inside the boxes (what is there and how it works). The services provided by the box must be openly visible.

This may seem obvious and common sense to most persons. It is not, however, common practice. Lots of angst on systems development occurs because the ICD is…well, it doesn’t exist and persons think it is bureaucratic nonsense.

This is yet another answer to, “Why do we need someone called a systems engineer?”