Vendor native and point-to-point integrations, as we discussed last week, are not the only data and integration solutions to hit the scene. Other common integration strategies that have long ruled are SOAP/SOA and ESB. Both of these come with their unique advantages and, naturally, disadvantages. What they have in common, though, is that neither of them is quite suited to organisation’s current data issues and integration needs. While promising at their respective peaks, neither of these integration strategies have stood the test of time and are only found in legacy applications—ultimately slowing down the business processes they linger on. 

Let’s review the underlying issues behind SOAP/SOA and ESB, two integration strategy predecessors that introduced benefits at the time but, ultimately, have proven themselves ill-equipped to scale with growing companies and a changing data landscape. 

 

A good start, but costs later: SOAP/SOA

 

SOA did introduce the concept of service, a self-contained unit of work that has well-defined capabilities. However, while SOA also introduced loose coupling, SOA was complex. It had high upfront costs, it took long to implement, and it was slow to realize value. By then the relevance of those reusable services also became questionable.

As shown in the above diagram, SOAP, WSDL and UDDI form the foundational element of SOA. To implement each of those, organizations need to invest in highly skilled resources to deliver the SOA projects.  

Some additional challenges with SOA were service governance, security, real-time communication, making services work together (interoperability), testing, and reliability. 

All these flaws ended up causing endless capital drain without delivering any clear ROI.

 

More possibilities but unable to scale with the future: ESB

After a painful phase of custom integration, ESB became promising. It eliminated poin-to-point integrations and provided more pluggability. However, with rapidly changing infrastructure, complex microservices-based architectures, and increasing endpoints, ESB became inadequate, reducing the effectiveness of enterprises. 

Some of the challenges ESB created are the following:

1. Organizational challenge: Different parts of the business move at different speeds. ESB became a bottleneck for those variances. For example, if finance, HR, and assets all wanted to add new features, IT could not handle changes fast enough. This often resulted in delays to the initiatives as the business had to wait for their turn in the queue.

2. Monolithic architecture: ESB became a single point of failure and outage. It also encouraged monolithic architecture and increased costs due to hardware resources, different tooling, and the specialist skills needed to maintain it.

3. Unable to adopt cloud-first motion: With the widespread adoption of cloud and SaaS applications, it became imperative to adopt hybrid and cloud architecture in middleware, too. ESB was not designed for this.

4. Slow to respond to changes: ESBs supported SOA/SOAP well, but it came with all the downsides of SOA previously discussed as well. It did not promote reuse inherently. Service discoverability was a challenge.

5. No self-service: ESB promoted a mindset where IT builds every asset instead of IT being an enabler through self-service.

 

Now that we’ve spent time understanding what fell short with previous integration strategies, we can better understand the advantages to a new solution built to grow and encourage innovation in your company: iPaaS. Stay tuned for next week’s installment.