Loose coupling in system integration is defined by having two or more systems that achieve an integration goal with minimal knowledge of the individual components of the other system. Tightly coupled systems are the opposite – they must have intimate knowledge of the other system to achieve the integration goal. Finding the balance between these two extremes has played a critical part in making TOTUS a successful platform to handle both internal component and external system integrations across a wide array of integration goals.
The TOTUS platform uses many different integrations to achieve its overall systemic operation, including:
- Print vendors’ job submission and status
- Email service providers’ email sending, status, and tracking
- CRM contact synchronization, including unidirectional in, unidirectional out, and bidirectional
- Asynchronous and scheduled order processing
- Order archival notification and storage
Over the years of integrating with many different vendor-, customer-, and service-specific systems using vastly different technology stacks and communicating over several different transportation types, we have learned how to integrate our platform in a scalable, maintainable, and efficient manner while being able to conform to the needs of our integration partners instead of forcing our way upon others.
For all integrations, the easiest way for a given side of the integration to operate is to simply provide the other side with “the way” that they must conform. The problem is that unless the second system was built specifically to handle “the way” as defined by the first system, the two systems are unable to integrate.
In theory, the technological community could band together and determine a standardized “way” to integrate disparate systems together, but in practice, it is not even closely feasible while keeping a reasonably low level of complexity. We tried to define this ultimate standard with SOAP, but the market has shown that the extensibility provided by SOAP has been outweighed by the need for simplicity that is provided by other methodologies. Even with a standard like SOAP, we still have the infinite complexity beyond just the transport layer, starting with how is the data modeled, defined, and expressed within one system versus another – communicating things as simple as a person’s name can be difficult to define in a globally acceptable way.
Without this ultimate standard, we are left with accepting this reality: if you want to be able to integrate with a wide number of systems, you will need to be prepared to be the flexible side of the integration while also having a concrete way on your side too. Your goal is not to overly generalize your system but instead make it so that you can achieve your goal with as little integration-specific code as possible.
If you can achieve this goal, you’ll find your initial integration calls going one of a few ways:
- “We have this endpoint/location/system that you can get/put the information from/to. Are you able use that?”
- “We don’t have anything that provides/receives that type of data yet. Do you have any predefined methodology that we can use?”
For both, the answer is hopefully “Yes!” let me get/send you the documentation and that is the end of the call.
How to be Flexible without Compromising
To be a good integration partner, you need to be flexible; however, this does not mean that you should compromise on design decisions within your application to meet the needs of others. Just because your integration partner has a methodology that makes sense for their system doesn’t mean that it makes sense for your system.
In TOTUS, we have found that flexibility by employing some simple tactics that enable but do not force extensibility.
Do not tightly couple your main application(s) with external systems
Create loosely coupled hooks in your main application that other applications can tap into instead. These hooks can manifest themselves in different ways, from using dependency injection for code-level hooks to pub-sub messaging queues for broader communication. By making loosely coupled hooks into the code, you will keep the amount of integration-specific code in your main application to a minimum while still enabling all the extensibility needed for a range of integrations.
Make all communications asynchronous.
Calling external systems synchronously will inevitably cause quality of service problems—whether it is because the other system is down, having load issues, or just has a slower response time than desired. The benefit of having the separation from the external system will outweigh the added complexity of kicking the real communication to a separate process.
The primary way this is achieved is through use of messaging queues to reliably submit messages to be processed by other, secondary applications. These have an additional benefit of providing a place to horizontally scale your integration processes.
Have a separate integration-receiver application.
This integrations application is specifically for brokering the communication from the hooks in your application to the system to be integrated and back. It is perfectly acceptable to tightly couple this application to other external services.
By using this application as layer between internal and external systems, you are localizing the code that will need to be changed when either side of the integration needs to be updated. In its simplest form, the integration may just be a pass-through from one system to another. In more complicated forms, you may be normalizing, denormalizing, or aggregating data to go from one side to the other. The most important part is that you’re not having to iterate updates to your primary application because of external factors.
To learn more, explore our complete capabilities or contact us today!