Part II: The More Things Change, the More They Stay the Same

In part one of this three part series, I reflected on the challenges of integration in the 90s, most of which remain today. But it’s actually even worse now. Think about today’s modern architectures vs. times past. In the 90s, integration was mostly focused on a few big on-premise applications – SAP, Oracle, Peoplesoft, etc. Further, the integrations were done over a private network, where you controlled the bandwidth and latency, and systems didn’t move on the network without a long list of approvals.In the 2010s, companies want to take advantage of even more technologies, many of which leverage a cloud model. People want to pay as they go, and maintain the ability to switch when they want. Nobody wants to sign up to multi-year, multi-million dollar projects that involve customizing large monolithic applications anymore. Instead they are looking for lightweight solutions that can be stitched together to provide a more dynamic computing environment, make their organization more agile and flexible, and let them harness new cost or capability advantages with minimal switching cost or effort. 

 

 

However, doing this kind of flexible integration over the public Internet has many important and divergent design requirements that the integration industry hasn’t addressed because traditional commercial product architectures are not well suited or even capable of handling them. With more applications in the mix, the ability to share data across many systems becomes even more important, as well as the ability to bring data from multiple sources into a single neutral format. However, over the Internet, we can’t integrate database to database connections, because cloud providers will not allow us to simply tap their APIs endlessly – they want to be sticky, and retaining your data is a good way for them to accomplish that.

While the ESBs of the 90s provide many great attributes to solve some of these problems, their cost per end point and the highly specialized skills they require are daunting. No wonder the public software companies in this space earn 3-4 times more revenue from consulting than from software sales. This single data point scares off even the most ambitious of technologists from ESB projects.

And in the setting of increasingly large and diverse business application portfolios, IT simply cannot manage full-blown projects for every change or enhancement. We need to consumerize IT and empower business analysts to manage day-to-day application integration and reporting work, much in the way Salesforce.com has done for sales organizations.

So where does this leave us? Integration is still hard, but there are huge opportunities for IT organizations that overcome these latest obstacles. Stay tuned for my last post in this series with a perspective on how SnapLogic is attacking these hurdles in a new and unique way.