How will the move to software-as-a-service (SaaS) affect enterprise application integration (EAI)?
Subscribing to software-as-a-serice (SaaS) applications is all very well and good, but you still need to connect the software to your other applications, both those that you run in-house, and other SaaS.
This is a much harder problem that internal EAI. Internally, you can set standards for what data means, how it is formatted and how it is sent. Once you are dealing with external software, you have to fit in with what the SaaS provides. You have to maintain your automated and business processes across a much more heterogeneous set of technologies and providers. In the same way that architecture and governance become much more important, EAI becomes much more important too.
It is hard to know how to respond to this challenge. I specialised in EAI/systems integration for many years. There are some common traps that people fall into when doing EAI internally to the organisation, and it is worth considering how these might impact external EAI.
The biggest problem is that people set the wrong objectives for integration. Integration is of course about connecting systems. However, very importantly, it is also about preserving the separation between systems so that you have freedom of action in the future.
Given the technical challenges of connecting externally, many will fall into the trap of adopting the first method that they can get to work, without thinking through the long-term implications. This is of course even more important when part of the purpose of SaaS is to make it easier to adopt and swap software. Bad integration will quickly give you "legacy SaaS"; you do not want it, but you can not unpick it.
Another big problem is abdication. Integration looks hard, and purchasers will be tempted by SaaS providers who say they already provide interfaces into your other applications, both internal packages and other SaaS. In my experience these are never good. There is a lot of different between demonstrating that you can send simple data between two systems as a one-off exercise, and a long-term commitment to support your changing business processes across all combinations of versions of their software and those of another provider. Like it or not, you have to take charge.
There is also a big problem with tools. Well-designed integration is not that hard to implement. However, there are sometimes problems and it is useful to have a tool kit to solve them. The problem is that these tools then take over. People standardise on tools, rather than fitting tools around standards. All integration is then shoehorned into complicated architectures that problem connections need, rather than letting the majority of connections use something simpler. Inevitably you end up with a specialist team to support the tools, and knowledge of and accountability for the integration is split from those with direct knowledge of the business systems.
It is possible to avoid these problems, but it is challenging technically and is challenging to get management support because the right approach looks harder than the wrong approach. Next week I will outline what I think is an appropriate response to the challenges of EAI and SaaS.