Unboxing Software Integrations

Software Integration is one of the most common practices in all types of software platforms. Instead of reinventing the wheel, it is always recommended to integrate with the available robust and well-proven partner/component.

It is important to follow the best practices in software integration to achieve quality. Otherwise, there are chances of fragile integration leading to production issues.

I will be discussing 3 types of software integrations

• Integration with third-party partners
• Integration with third-party components
• Integration between modules

Each one in the above list is different in nature. One common practice to follow is making it loosely coupled. The code related to integration should be abstracted from the main component or module.

Let’s understand a little more on the concept of loosely coupled in all of the integrations.

Integration With Third-Party Partners

Integration with third-party partners will have two-way communication with the consumer software system. In such cases, the logical architecture of consuming software system should have two components exclusively for the integration. One for the outgoing calls, it is called outbound, and another one for the incoming calls, it is called inbound.

Abstracting the integration code in consumer software system will avoid direct dependency with the integration partner. The communication between the two systems will involve various complexities like authentication, authorization, and other service communications. Such complexities must be separated from the core system and hand over them to outbound and inbound components. We will be achieving two design patterns here viz. Single responsibility and loosely coupling.

Integration With Third-Party Components

Similarly, the design principles like Single Responsibility and loosely coupling are also valid for the integration with third-party components.

Let’s take an example to understand this better. Software systems will use some third-party components or libraries like log4net to do application logging. In such scenarios, instead of directly referring the log4net library all over the places, it is important to put a wrapper (project/class) around that. All code related to application logging will be calling the wrapper project/class instead of the log4net library.

By doing this abstraction, application code is not directly dependent on Log4net library. In the future, it is an easy switch over from the log4net library to some other libraries.

Apart from log4net example, for other scenarios, the wrapper class gives the flexibility to add in more functionality in the overloaded method.

Integration Between Modules

This is one of the most often used integrations in all our software development. The software system will have many modules. The communication between the modules is a pretty common scenario. In such scenarios, avoid directly integrating another module function in multiple places. If we do so, it will create multiple direct dependencies on the integration module. Any change in the integration module method might impact all integration points in the consumer module.

The recommended approach is to have a wrapper class that coordinates the communication between the modules. All integration points in module 1 will always go through this wrapper class to communicate with Module 2 method.

As all integration points go through the single wrapper class/project, and it is possible to implement best practices like exception handling, instrumentation, and retry logic in a single place. It is better to integrate this wrapper class through an interface. This way, it is possible to support backward compatibility easily for the integration points, those who would want to use the old integrations.

All these benefits are applicable to all types of integrations explained above.

Dot Net core is one of the best examples for the design principles viz. single responsibility, abstraction, and loosely coupled. Dot Net core achieves this using dependency injection and CLEAN architecture. With the dependency injection, it abstracts the concrete class integration by injecting them at runtime using interface reference. Also, it achieves loosely coupling with concrete classes.

Using CLEAN architecture, the different layers like the Service, business, and infrastructure layers are not dependent on each other. Rather, all of them are dependent on the domain entity project, which is termed as the core of the project.

Also, it ensures all external communications like database, file system, and external services communication are grouped under “Infrastructure project.” It implies all external communication is isolated from all layers of the project. This way, the infrastructure project is made responsible to take care of the nitty-gritty things related to external communication.

Key takeaways for software integration:

• It is highly recommended to isolate the code related to external communication in separate projects.
• Put a wrapper for integrating any third party components or services integration.
• Ensure there is proper data exchange document for any third party partner integration. This should be maintained for all subsequent updates. It will be the system of record for all the communications between two software systems.
• Validate all incoming request data before proceeding further down the integration. If it does not match with data exchange specification document then abort it and return an appropriate error code.
• Ensure all data interchange communication events are logged.

I have tried to list a few best design principles and best practices above for integrating third-party partners, components, and modules. These will make your software integration more smooth and flawless.