The Evolution of Enterprise Integration

By Ross Garrett in Enterprise Integration Posted May 30, 2017

Integration is all about making different apps and systems work together. Allowing them to share data, orchestrating business workflows, and by coordinating how employees work across growing number of apps. Initially, that meant connecting one on-premise software to another. From 1999-2001 a number of integration companies like TIBCO, BEA Software, and WebMethods went public, validating the first integration market. This burst of integration tools was fueled by the growth of core enterprise software, like ERP, HR, and CRM that businesses were installing at their companies.

Evolution of Enterprise Integration

But the landscape has so much changed since then. SaaS has dramatically changed how we purchase, consume and adopt software - making business apps easy to buy, use, and maintain. As a result, software has become a differentiating part of every business, not just a tool. And all enterprises and businesses are adopting SaaS/Cloud and Mobile applications at a much more rapid pace. Today, an average enterprise uses 1,427 cloud apps across its entire organization (source: Skyhigh Networks Cloud Adoption Report Q4, 2016). This is a stark contrast to 1999 and early 2000 where an average enterprise used 5-10 enterprise apps.

Now, 15 years later, the second wave of integration is being fueled by “Digital Transformation”, a top priority for many companies today. Digital Transformation is centered around adopting best-of-breed apps and systems and enabling smart, fast, adaptable integrations and automations across all a company’s apps, APIs, data, people and devices to deliver innovative, personalized, multi-channel experiences.


Enterprise Service Bus (ESB)In the 1980s the first “Information Bus” was born out of a company we know today as TIBCO. In this era, everything revolved around big, monolithic pieces of software. They were standalone and could not interact with other software. TIBCO was revolutionary at that time since software simply could not communicate with one another at all and this “Bus” let them plug into each other to share data.

Much value was derived from these early integration products, but the business world was very different then. There were primarily a few large suites of apps - like Oracle and SAP  - which were expensive, complex and highly technical. So technical that IT had to implement them on premise which only Global 1000 type of companies could afford to do. Today, a company no longer has to settle for a monolithic suite of apps. Instead, they can pick and choose the most innovative, modern and powerful apps that fit their requirements from the hundreds of options available to them. It no longer matters what size a company is. They can implement a new cloud app within days with very low startup costs.


For integration platforms, that means the way businesses work has drastically changed from the days when the traditional integration tools were created. Business apps have become consumerized, mobile-centric, self-service, and low cost, but the Integration tools to connect these apps, often remain complex, technical and, at times, more expensive than the apps they are integrating.


[1] Integrations must be easy to build

It should be easy enough to use that even non-developers can build integrations. With the SaaS adoption in lines of business, it is imperative that lines of business are able to build their own integrations and workflows without any fear.

For example, Sales / Marketing / Customer Support Ops should be able to integrate applications and automate their workflows without having to worry about the underlying technology, including security, scalability, error handling, duplicate record handling, being able to easily undo errors, and more. IT should still be able to govern and manage the integrations in a company, but not necessarily be the one building all the integrations in the company.

[2] Integrations must be agile and flexible

Integration tools should be flexible, allowing integrations to be changed at any time. In the past, integrations were ‘built-to-last’. Once you have your Order-to-cash process going between your SAP and Salesforce, you don’t go back to change it often – the requirements were more stable and, besides, the consultants that did these integrations have moved on. This is no longer the case. Business apps and the processes and workflows around them are constantly changing as new apps are added and existing apps are changed. Constant change is the norm.

An integration platform must be simpler to use, agile and flexible so that anyone, from business analysts to app admins can roll out new integrations quickly and not depend on IT / developers.

[3] Integrations must scale to 1000s of apps, not 10s

In the early days of integration, most of the integrations were done between a few functional app suites. Traditional integration tools are primarily optimized for a few heavy duty integrations between such suites. Today companies use more than one thousand apps, which must work together.

For example, a marketing team will be using an entire  stack of applications around core marketing automation apps like HubSpot - connecting to WordPress, MailChimp, EventMobi, Slack etc. To be able to integrate and automate your marketing workflows, the platform needs to support all of these apps. 


In short – traditional integration platforms may be powerful, but they are limited by the apps they support, the number of use cases they support, and who can use these platforms. These limits are the reflected on the entire organization, making it impossible to enable business users to build integrations to support their line of business. Or making it impossible to offer embedded integration experiences your customers need. Or making it impossible to build the products your organization needs to survive in the digital era.

Today’s integration challenges need more than middleware - organizations need an integration platform that scales for the future. 

Check out our latest research on the “State of API Integration”.