Construction principles for information professionals (2): Decoupling for complexity reduction and flexibility

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.

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