Construction principles for information professionals (2): Decoupling for complexity reduction and flexibility
In this series of blogs, I will focus on the enduring construction principles of information science that ensure better "information structures." These principles have sometimes been forgotten in the rapid progress of technology, resulting in unstable or poorly maintainable and extensible "information structures." In this second blog, I will delve into the art of decoupling.
A well-designed system has so-called decoupling points, imaginary divisions in the complexity of the whole, which allow the parts to be developed, implemented, and (eventually) replaced as independently as possible. This promotes interoperability without central control. In its ultimate form, this is known as "service-oriented architecture (SOA)," which has been developed in various forms.
At the organizational level, this can be achieved by thinking in terms of services. For example, consider the service that PostNL provides to BOL.com in the logistics chain. Through service orientation, you can decouple the processes and business functions that deliver an end product in a production chain or network. The internal production of the service itself is a "black box" for the service recipient, and as a recipient or chain, you can combine services into chains of services as long as the interface conditions are clearly specified, often in the form of a contract. This principle of decoupling through service orientation has been applied in the criminal justice chain architecture, where the independence of the chain parties is essential, but a common goal must be achieved (Jan Dietz's DEMO methodology [1] has been utilized in this context).
The architect must pay particular attention to avoiding bottlenecks or single points of failure. What are the alternatives for a service (flexibility)? And are the contracts binding enough to keep the production chain running (considering the unhappy flow and exceptions)?
An example of a chain where this seems to be challenging is the immigration chain. Is there sufficient decoupling between the services provided by the Royal Military Police (KMAR), Immigration and Naturalisation Service (IND), Central Agency for the Reception of Asylum Seekers (COA), and municipalities to achieve the common goal?
At the level of information, communication, and meaning (semantics), achieving interoperability usually involves translations between different domains or organizations to avoid the need for everyone to speak the same "language" (which often requires significant effort). Information exists within a specific context, which determines its meaning. Without context, information is merely data and is usually not interpretable in a consistent manner for everyone. For example, the financial accountability domain uses XBRL as its language, while the healthcare domain relies on the HL7 standard to ensure consistent meaning. However, aligning semantics is a time-consuming process. An alternative solution is Linked Data, which enables information to be interpreted in context, regardless of the domain [2]. Linked Data effectively decouples data from its domain.
At the technology level, decoupling is seen in the separation of layers (presentation, application, data storage) and the emergence of technical interfaces, APIs, to which anyone can connect without further coordination, enabling various data services to be technically decoupled. Microservices are an implementation of the SOA idea. Technical decoupling also prevents vendor lock-in by establishing agreements on open standards and data migration possibilities.
As we increasingly collaborate in networks and chains nowadays, the art of decoupling has become more critical to reduce dependencies and complexity. The design of a solution must, therefore, be evaluated based on these dependencies and provide logical decoupling points and alternative "suppliers" to minimize them.
Gerelateerde insights
