It’s definitely worth reading. He believes that one of the few remaining alternatives to address the complexity is to….
Choose the right tool for the right problem, e.g. the WebPart adapter if you’re using Sharepoint. Use REST when appropriate, e.g. when you need a lightweight way to send some JSON or XML across the wire between nonstandard or homegrown apps. Use JSR 168/286 for your Java applications. Even use SOAP if the backend application already supports it. Keep things loosely coupled so that you can plug different components in and out as needed. This requires a lot of development — the glue — but, I don’t think there’s any way around that.
Which is exact what we’ve been saying for a long time.
Inside the enterprise where you’ve got tightly coupled, low latency EAI requirements, use a reliable messaging infrastructure or ESB, if its Java or a portal, lots of good JSRs to help you out. SOAP is unavoidable whenever you interact with modern apps inside or outside the firewall. And for SaaS, it makes sense to use something that resembles the web.
His point about ‘lots of development’ and the ‘glue’ would be true if you had to code it all yourself. But if you’ve got a way to leverage past work, and take advantage of highly productive dynamic programming languages, you’d be able to contain that complexity.
Taken together, it begins to explain why interest in SnapLogic is really taking off. Integrating SaaS apps is a bit of a mismatch for many of these alternative middleware technologies and the skills gap within the typical SaaS subscriber only makes it worse.