Design principles for the computer scientist: No hidden interfaces (13)

Interfaces are unavoidable and often even desirable in order to be able to decouple and divide complex systems into manageable components ("minimum linkage, maximum coherence"). But it should always be clear to the person who wants to make a change to component 1 what the consequences of that change will be in the linked component 2 and beyond. So there must be insight into the interfaces made. A well-installed decoupling point ensures independent components that can work independently of each other. The internal workings of the component are invisible to the linked outside world and can be changed without consequences for the environment as long as the function to the outside remains the same. But whether the change has an impact on the function to the outside world must be clear. This can be done through good documentation about the interfaces in a system and/or testing and scenario analysis.

Invisible interfaces are present in many application landscapes. The Dutch system of government master data administrations is one of them. Does every owner of an administration realize the consequences for all customers of changing the data model (an object, its meaning, attributes or relationships)? The internal coherence of the data in the system is crucial to the outside world because the interconnectedness is so great. This requires meticulous documentation of data models and connection conditions and a well-controlled change process.

The frequent application of the modularity principle in the application landscape also raises the issue of insight into the coherence of the landscape as a whole. After all, the cohesion of the domains (CRM, financial, HRM, transaction systems) remains if you make domains modular. Changing the CRM module can have an impact on the financial module. The interfaces must therefore be visible!

From an audit perspective, it should be possible to trace from the output, the input that led to that output. This is also the starting point for many applications for making BI-reports and analyses. But that requires a lot of the recording of metadata when registering the source data and processing it. With the current techniques for Big Data analysis and certainly AI algorithms, this is becoming increasingly difficult. In fact, the use of AI goes against the principle of avoiding invisible interfaces because you are dealing with a probabilistic processing process instead of a deterministic process.

The fact that regression testing is still required in the construction of (complex) code underlines that documentation alone is not enough to avoid invisible interfaces. Testing remains necessary to bring them to light in complex systems. It always turns out to be difficult to develop truly independent components that continue to meet the interface characteristics as it was documented to the outside world. And so with a new release, certain functions "fail" because the impact of a change elsewhere in the landscape was insufficiently visible.

Documentation makes things visible by describing them. A interface must be documented in order to know how it works and to assess the impact of a change in the component. Anyone who has ever drilled into the wall near a socket or water pipe knows the value of knowing where those pipes run. Wall and water pipe are independent components, but they are physically linked. That is why there is a yellow sign with the letter K on it at waterways along the side. So that when dredging the canal, it is clear where the connection to that cable is located.

It cannot be overemphasized; Document all interfaces and maintain this documentation!

In addition, agreements are needed about the changeability of the interface itself once it has been realized. Think of backward compatibility, being able to run two successive versions side by side and the like.

As a computer scientist, you have to make all interfaces visible and documented, because you cannot foresee how the interface may be affected by a new development in the future. In order to be able to determine the impact on the system as a whole in the event of changes, insight into all interfaces is essential.

1. Meaningless identity designation
2. Decoupling points for complexity reduction and flexibility, maximizing independence of components
3. Language consistency
4. Clear distribution of responsibilities and functional separation for administration
5. Delegating decision-making authority as low as possible
6. Detaching authorization from identification/authentication
7. Single registration of master data
8. Separating data and metadata in storage and processing
9. Applying standard patterns without deviations
10. Separating application function from data storage
11. Device-independent development
12. Choose a Storage Structure