Application integration or sometimes also referred to as Enterprise Application Integration (EAI) is a category of approaches of sharing of processes/functions and data among different applications in an enterprise. The integration can be between of on-premise programs at a customer’s end or programs on cloud or programs on cloud and on-premise. The set of technologies and services used to accomplish this task form a part of the middleware.
Over the course of the year, enterprises have accumulated a bunch of systems in disparate technologies, and platforms, as a result of lack of a single solution or a vendor catering to all the diverse business needs. Sometimes companies may also accumulate such system from other companies through mergers and acquisitions. A few examples of such systems are supply chain management applications, ERP Systems, CRM applications, payroll and human resource systems etc. These systems and applications may be on different operating systems, use different database solutions or computer languages, or different date and time formats or be legacy systems that are no longer supported by the vendor who created them. At the same time there may be a need to make these systems and applications communicate with each other to share data or business rules. A lack of communication between critical applications leads to inefficiencies with identical data being stored at multiple locations, lower degree of automation, higher costs and more operational overhead.
Given these requirements, any application integration software has to satisfy three main criteria:
- Interoperability: Allow different application systems to interact
- Data integration: Seamless and consistent integration of data
- Robustness, Stability, and Scalability: As these software stack are the glue that holds together modular infrastructure
Typical there are 4 main architectures for application integration, namely
- File transfer
- Shared database
- Remote procedure invocation
File transfer and Shared database help in exchanging data between applications while Remote procedure invocation and messaging integrate both data and functions
File transfer is where one application writes a file that the other application reads and visa-versa.
Shared database is use of a common database to share data among each other. In case, there are simultaneous data writes to the same area of the database then transaction management systems used with these shared databases help in managing the conflict.
Remote Procedure Calls (RPC) expose a business functionality via an interface definition and implementation of that interface using different technologies. This architecture applies the principle of encapsulation to integrating applications. If an application needs some information that is owned by another application, then it interacts with the application directly to get this information. Technologies such as CORBA, RMI etc implement RPC.
While encapsulation helps reduce the coupling of the applications by eliminating a large shared data structure, the applications are still fairly tightly coupled together. The remote calls that each system supports tend to tie the different systems into a growing knot.
Messaging helps integrate applications more loosely and allows data exchange in an asynchronous fashion. This is basically exchange data and invoke functionalities via messages and allows for as much of decoupling as we get in File Transfer architecture. (eg:SOA)
Integration software have been around for a long time and have evolved with evolving business needs.
It began with Custom development, which as you can imagine is cumbersome, point to point, propriety and hard to reuse.
The next was Enterprise application integration that offered more seamless integration of applications and was initially designed based on hub-spoke model and later evolved into a bus architecture.
With the advance of web services, EAI gave rise to SOA/ESB, “Service Oriented Architecture” / “Enterprise service bus” has been coined to describe a system that maps standards-based interfaces to business functions. Some EAI vendors rebrand EAI solutions as ESB while some vendors built ESBs from scratch: WSO2, Mule. However, SOA is primarily for on premise applications. Leading companies offering ESB are Fujitsu, Hewlett Packard, IBM, Microsoft, Mulesoft, Oracle, Redhat, SAP, Software AG, and TIBCO Software.
As one can imagine, ESB suites have become very popular and the market is expected to grow at nearly 5% CAGR.
The increasing platforms, such as social, mobile and cloud platforms, are further creating a strong demand for more hybrid platforms that allow for a mix of on premise, cloud, B2B, social, and mobile integration scenarios. This is realized with a combination of SOA and integration platform as a service (iPaas). Some common examples of iPaas based SOA software are IFTTT, Zapier, WSO2 Integration Cloud.
iPaas appears to be the architecture for the future as it provides a combination of some of the features found traditionally in on-premises integration platform software, such as enterprise service buses (ESBs), data integration tools, B2B gateway software, application service governance platforms, and managed file transfer products along with integration with cloud services.
Industry reports indicate that the iPaaS market is poised to dramatically grow over the next few years at a rate nearly twice of that of ESB due to several factors, including:
- The explosion of CSI, MAI, API and Internet of Things requirements.
- The emergence of the agile integration approach and citizen integrators, for which traditional integration platforms are unsuitable.
- Adoption by SMBs so far often unwilling to embrace integration middleware because of its high cost and complexity, but now interested in iPaaS offerings due to their low entry cost and ease of use
Above and beyond, Gartner has kindly rated all the iPaas companies providing EAI services to rate them in their famous magic quadrant table