The Boomi Blog

"Inter-Cloud" Still Needs Integration

I've been following the development of the Inter-Cloud concept with interest over the past many months.  Popularized by Cisco (the network is the cloud), Inter-Cloud is described variously as a “federation of clouds based on open standards,”  an “elastic mesh of on demand processing power deployed across multiple data centers” (in this post by Greg Ness) or simply a “cloud of clouds.”

The posts I have read on the topic deal with issues such as standards for network protocols, virtual machine representation, and identity/security.  The vision, once these details have been worked out, is a completely ubiquitous computing environment that seamlessly blends all forms of clouds and their physical instantiations into what seems to me to be a single, massively parallel cloud computing environment.

But as awesome as that vision is, it won’t solve the pesky interoperability challenge of the business applications that run on these linked clouds.  And assuming we want to do something more interesting than host websites, email and excess storage, existing and new apps need to migrate to the cloud.  In the virtual layer cake in the sky, we talk about Infrastructure as a Service, Platform as a Service and Software as a Service.  But too many cloud "taxonomy" and “ecosystem” charts leave out the critical element of application integration.  It’s time for integration to take its rightful place on the layer cake!

What Inter-Cloud does for cloud computing (compute as a utility), integration does for SaaS (applications as a utility).  Inter-Cloud may make cloud computing environments interoperable but it is SaaS integration platforms (think "cloud middleware") that make SaaS (and on prem) applications interoperable.

I blog in another post about "the case for cloud middleware."  We have the opportunity with the SaaS industry to not repeat the mistakes we made in the enterprise era with hardcoded, brittle, essentially dead integration.  We have the opportunity with cloud middleware to implement living, breathing, scalable interfaces that will enable and drive the growth of SaaS and cloud computing.  After all, if business apps don’t make the transition to the cloud, the future of SaaS will certainly be in peril and the full potential of cloud computing will not be realized.

When Debating “The Economics of SaaS,” Lets Not Use Fuzzy Math

I recently read with great interest a story in BusinessWeek titled, “The Economics of SaaS,” penned by a group of writers known as the "Staff of the Corporate Executive Board.” In it they meticulously detail out the cost savings realized from SaaS solutions vs. the equivalent on-premise solutions. Personally, I am shocked at how this type of comparison continues unabated. Is this a last ditch effort from some of the die hard on premise hold-outs trying desperately to prove to the world that it actually makes more sense to install a separate copy of software at each customer site? I think it is important to look at the following considerations, to make sure they are being contemplated in this comparison:

1. Generally speaking, a SaaS solution that has a competitive on-premise offering will be priced around the same as the maintenance fees the on-premise vendor will charge. Yes, if you take Salesforce.com's published list price and do the math times 500 users it will look expensive, but it doesn't work that way. The unit price goes down as the volume of users increases.
   
2. Integration does not cost more when integrating SaaS, it costs less.  If you use legacy integration products, then yes it will cost more as you will have to code adapters to support the SaaS application(s) you are trying to integrate, install software into your DMZ, potentially spin up instances on Amazon, etc. However, some integration providers serving the SaaS market offer a product that is itself SaaS, driving the cost of integration down to a fraction of what it used to be in the on-premise world.
   
3. All bets are off if the approach of the "SaaS provider" is to install their single-tenant software in Amazon and call it "SaaS".  The primary principle of SaaS, multi-tenancy, is eroded.  This provider will have a much higher baseline of costs because they need to provisioning hardware (regardless if physical or virtual) for each customer they sign up, and they will simply pass onto the customer.  Contrast that with Salesforce.com, that claims 500 servers are powering its 60,000 SFA customers. That is the benefit of multi-tenancy realized.  

The favorite point that people like to make when comparing SaaS to on-premise is how in years two and three the cost savings for SaaS become marginalized against the investment made to "own" your on-premise software.  But what if we factored in to this math a comparison of the number of releases made by the vendor and utilized by the customer?  One of the top reasons on-premise customers move to SaaS is the "rev lock" they face, where due to the complexity and cost of the customizations and integrations made to their specific version of some on-premise application, the cost to upgrade to the latest release rivals the initial investment made in product in the first place.  Yet regardless of this, the customer must still pay their maintenance fees. Compare that to SaaS, where generally providers do four significant releases per year, and 100% of their customers get 100% of these releases.  That's because the SaaS vendor must build the product in such a way that they can upgrade it for their customers, and not break them or have any impact on their business operations at all.  This model works and is proven not just by the leaders such as Salesforce.com, but look at most well known SaaS ISV's and they will showcase how well this architecture works.

The Human Capitalist Nails the SaaS Test

In Jason Corsello's most recent post entitled Is Your Vendor Really Operating "In the Cloud"? The 3 Most Important Questions to Understand About SaaS he does a great job discussing pass/fail tests to give to a provider claiming to be SaaS.  We are very passionate about the benefits of multi-tenancy, which Bob covers very well here and here.  And the product update aspect is critical too; remember that many customers move to SaaS to unlock the chains preventing them from upgrading their on-premise software, mainly due to extensive customizations and custom coded integrations.  A multi-tenant architecture forces the vendor to implement processes that can be performed "once per instance" vs. "once per customer".  This means that while the customer must take the upgrade, the vendor must upgrade them seamlessly and not break their setup.  The customer gets the benefit of access to the latest innovations released by the vendor, and does no work to get them.