Many software integrations are build on IPAAS (Integration Platform As A Service) technology because an integration platform makes building and maintaining integrations easier and better. While an integration platform may theoretically provide the benefit of an all-around better integration than a custom-coded solution, the final integration solution may look more custom than you’d imagine even using an integration platform.
Custom Code Integration Challenges
Custom code integrations aren’t necesarily bad. Custom solutions are often a great starting place for less experienced integration teams or for small projects. The single technology (coding language) that’s used keeps the number of technologies to a minimum. The good news ends there though, and there are many issues with custom-coded integrations. Developers are frequently disconnected from business needs and translating requirements becomes a headache. Developers often have long backlogs of tasks and deploying custom solutions isn’t intuitive. Debugging integration issues, reprocessing records, and overall resolving integration problems is surprisingly complicated. The solution is fully written in code and in most cases provides little visibility or control to non-developers.
The Integration Platform Advantage
Introducing an integration platform solves many of the biggest challenges of custom integrations. Inidividual components can be built and configured independently. Developers are only required to enable the IPAAS to connect to new platforms, and more functional users can now expedite the integration build and maintenance without the need for developer involvement. Because developers are often expensive resources and there is additional cost associated with translating requirements, eliminating the need for a developer in an IPAAS is a major win. The news gets even better over time as building new integrations to a platform that is already supported may require no developer involvement at all. Once the custom coding is in place to support the platform, new integrations don’t require re-creating the wheel.
Custom Code Trap
While an integration platform should solve the issue of custom code over-use, in practice, many integration solutions are implemented so that they end up moving custom coding outside of an IDE and into the IPAAS UI. The slippery slope begins when the IPAAS users ask the developers to build increasingly generic platform connectivity – the connector that allows connection to any platform. The IPAAS user then pieces together commands and parses out responses from the platform using complex functions inside the IPAAS, which effectively makes the IPAAS map builder a higher level programmer. And we’re back at custom coded solutions. Creating and maintaining integration solutions will now require a developer-esque skillset and significant knowledge of the connecting platform.
How To Reduce Custom Coding
Depending on which IPAAS you’re using, it may promote or discourage use of custom code in IPAAS solution builds. If your goal is reducing custom code in the IPAAS UI, platform choice should be your first consideration. Your team’s design philosophy and practices will also play a major role in how much custom coding makes its way into different parts of the solution. It may not always be easy to determine when custom code is being introduced. A good question you can ask yourself as you’re building and reviewing integration solutions is “would I need a developer to maintain this solution moving forward”?
Recap
While using an IPAAS gives you the ability to reduce custom coding in your integration solution, keeping custom code only in the layers you want will only be a reality with disciplined build habits. Different IPAAS platforms offer different controls and can lead to better or worse custom coding habits. While no IPAAS is perfect for citizen integrators, make sure you’ve got Datix’s Intelligrate™ – Integration Platform As a Service on your short-list to review.
