Changing landscape: Application Integration

If you play in the application integration arena, you will have by now noticed the landscape is transforming itself and there is some interesting changes happening and forcing us to review our long held definitions on the subject. While some of the old school integration still plays a relevant part, things are changing and I thought I should take the chance to summarize them for my own benefit and understanding as well as (hopefully) starting a discussion with people out there possessing more expertise and experience than I do. Long live the Internet!

Cloud computing has been a big disruptor. Computing power is now available almost everywhere meaning 100x more applications being built and deployed. They all need integration in one way or the other but now the native integration environment is the Cloud. Traditional EAI technologies such as TIBCO, BizTalk and related are still relevant. However, they have two major drawbacks these days: a) they are very expensive and b) they are very complex. As you can imagine, expensive and complex do not fit in the current Cloud dominated landscape where business agility is the first thing demanded by organizations. On top of that, they are not Cloud native and while great efforts are being made to make them Cloud friendly, their old design and inherent complexity is still present. There is nothing wrong with complexity, provided it is not applied to a simple issue requiring a simple solution. Traditional EAI still requires an specialist for solution implementation.

The pervasive presence of PaaS has given birth to iPaaS, where integration capabilities are based on Cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and Cloud-based processes, services, applications and data within individual or across multiple organizations. In this context, API-led connectivity provides agility to integration efforts and unlike traditional EAI, there is no need for specialist skills although you still require technical people for solution implementation. This is what Gartner calls "ad-hoc" integrators.

Application Integration can also be found under different names and people may be using it without formally knowing they do. Common use cases include automating repetitive tasks into some sort of "process" (where two or more applications are involved) or enabling a given application to react to events coming from another one. This is more apparent on the consumer side of things (and less in the enterprise). While this consumer-based integration services is still evolving, there are already some players such as IFTTT, Microsoft's Flow or Zapier and they are by now considered to be iSaaS (Integration Software as a Service). Unlike iPaaS, the main actor here is what is called "Citizen-Integrators" - end-consumers making use of existing available software and able to put together integration workflows with minimal technical knowledge.

The above deals with solution implementation but the solution management landscape is also changing. Specialist vendors (such as Apigee) providing API-management software now have to compete with Cloud providers (such as AWS, Azure and IBM's BlueMix) providing comparable service as native Cloud services. Some iPaaS vendors such as Mulesoft and Dell Boomi also provide capabilities in that field so choosing one over the other is not easy business as one would wish.

So, we have EAI, iPaaS, iSaaS, API-management and related all competing in the same integration arena. Even the long held concept of canonical data models as a cornerstone for Application Integration is being challenged by context-aware representation models approaches. Who would have thought???

Certainly changing (and exciting) times.