When iPaaS Goes Awry – Don’t accelerate your point-to-point connections

The Shortest Way

A recent report from Mckinsey revealed that when companies pursue digital transformation, the complexity of IT architecture increases.  This complexity doesn’t happen immediately. Most companies start the journey to digital transformation by adopting modern cloud applications like Salesforce, Workday, and ServiceNow. In isolation, these apps reduce complexity — but they need to be connected to other systems to be valuable.  Creating this value typically drives an increase in point-to-point connections, a reduction in the quality documentation, and a decrease in service reuse,  which ultimately increases architectural complexity.

To increase the speed of SaaS connectivity, many organizations have onboarded a modern integration platform as a service, or . With an , developers can build, run, monitor and govern integration flows between cloud applications. The typical use cases are often less technical and easier to solve than those of traditional middleware. For example, a developer connecting SaaS applications via REST APIs will not care about transactions and compensation mechanisms — often the critical concerns of integration specialists. This same developer will face easy-to-understand data models described in JSON or XML instead of a legacy formats such as COBOL Copybooks or SAP BAPI Business Objects.  This allows developers across the enterprise to do work that typically bottlenecked within Central IT.

While there is nothing wrong with simplicity, there is a hidden trap in this logic: Many iPaaS systems accelerate the creation of the technical debt by helping developers build point-to-point connections faster than before.  Because point-to-point is so easy, work is often repeated over and over again, creating a lack of reuse in the enterprise. A lack of reuse creates a tightly-coupled architecture that makes downstream changes costly and time-consuming. Over time, this can create an accidental architecture orders of magnitude more complex when compared to the few on-premises applications you once connected via your traditional middleware.

As the scale of connectivity grows, iPaaS users are often confronted with complex integration projects. Not long ago, I talked to a customer who needed to copy data into an HR operational dashboard tool. This data originated from several sources, including Greenhouse, an applicant tracking and recruiting software, and Workday, a human capital management software. Complexity very quickly came to the picture: there was a huge amount of data which could not simply be transferred via HTTP due to constant timeouts, pagination with complex logic, and throttling limits which prevented access to Greenhouse beyond a certain frequency. Although these are things which an iPaaS can handle, it is hard for someone who is not an integration specialist to digest all of that and make it work in a proper way.

All in all, I say: connecting applications is good, but connecting applications in a reusable and robust way is even better.

Connecting applications in a robust yet flexible way require a balance. We don’t want to prevent people from getting their data by reverting back to the old IT model: enforcing complex governance models, using old-fashioned middleware tools, hiring developers with specialized skill sets, and using traditional waterfall models where only IT can deliver the end-to-end solution. At MuleSoft we believe that IT and other more technical groups must make all integrators successful without losing governance and control of their core systems and assets. They can do this by providing less technical developers with access to only the set of tools and resources (such as APIs and best practice templates) that are meant to let them become self-sufficient and to allow them to succeed.  

For those who are familiar with API led connectivity, you can think of it as like a less technical developer working with experience APIs. Sometimes they also work on system and process APIs depending on who owns the applications. A key characteristic of an API-led approach is to promote reuse and collaboration while keeping control and visibility.  

For more details about how MuleSoft is supporting integration across the enterprise, stay tuned for our release announcements or register for one of our MuleSoft Summits events across the world.


We'd love to hear your opinion on this post