Frank Guerino had a thing or two to say about SaaS and integration after reading last week's post on "The SOA, SaaS, Web 2.0 Connect."
In that post, I shared how many SaaS vendors are moving to or already use service-oriented architecture and how this can help client companies address integration issues.
Guerino introduces himself as a former SaaS practitioner in a large and very well-known financial firm and now as a vendor of SaaS solutions -- specifically, he's the CEO of TraverseIT. He agreed that SOA is great for low-level data integration -- as long as you're doing the ETL-level integration. However, he contends SOA is "slow and clunky" for what he calls "Reporting & Business Intelligence" integration -- or sharing information between systems and people.
His case is compelling. Though he posted his remarks to the original blog entry from Aug. 21 (last Wednesday), most people don't go back to old posts to read comments, so I thought it'd be worth reviewing his comments in this post.
Here's his case against SOA for reporting and BI integration:
SOA tends to break down when you have to look across or deep into large volumes of data. As an example of proof, try and bring 10 sets of unique data from 10 unique systems, using SOA, to create On-Demand, Real Time Dashboards, with live and up-to-the second data. It will take a very long period of time to generate them, let alone interact with them. A good architect will tell you that SOA has its place(s), however it is not the right answer all the time. SOA is simply one of many paradigms to leverage, and one should be cognizant of when to use it and why they're using it.
He also made these points about SaaS vendors and integration in general: 1. I'd written previously about a CIO Update article claiming companies were having integration problems with SaaS because they had implemented different SaaS solutions in a siloed fashion. Guerino noted this integration problem isn't unique to those using SaaS, since it exists within the traditional model of companies owning their own software. Fair enough. He goes on to argue that it's unfair to consider the integration or complexity of integration as a risk of using a SaaS, since the issue also exists for most companies internally. The only difference, he points out, is that now you have to integrate with a third party outside your network.
Personally, from my arm-chair IT perspective, I would think that one factor in and of itself would add enough complexity to give one pause, but what do I know? He says no.
2. Guerino also noted that SaaS can actually aid integration. In the olden days, a SaaS offered one tool that solved one problem. Now, though, companies offer a range of tools and technologies, all pre-integrated, Guerino points out:
New SaaS helps to effectively drive your cost of tool ownership down AND helps to effectively drive your cost of integration down. For larger firms who already spend a fortune on integration, this will be the next significant differentiator in the SaaS value chain.
You can read his full comment here.