The Dell 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.

Structure '09: Real-Time Cloud

I had a chance to sit in on Marc Benioff’s keynote address entitled “The Real-Time Cloud” during the GigaOm’s Structure ’09 conference yesterday (Boomi was an exhibitor).  It was an interesting session with Om Malik asking Benioff a wide range of questions about origins, maturity and future of cloud computing. 

Benioff spent a lot of time talking about cloud integration. He noted systems like Twitter, and the benefit if integrating with it which is basically that you get access to information as it happens in real time, and can act on it.  In legacy enterprise applications this is not possible because when these applications were built Twitter did not exist.  It’s a great and important point.  Cloud and particularly SaaS applications make possible for the first time a new level of real time, app to app integration that was not possible with enterprise applications.  Obviously at Boomi this is the core to how we operate, but it was refreshing to hear other people in the SaaS space highlight the critical role integration plays in the evolution of cloud computing.

And of course because it’s Benioff, you know you’re going to get some good advice and even better quotes.  He even took the time to tweak Oracle chief Larry Ellison.  Here’s a sample of some of my favorite call-outs from the address:

On recent comments Ellison made about cloud computing:

“Only 6 months ago Larry made caustic remarks about cloud.  Then, on a recent investor call he says, ‘the key to on demand is on premise, and the key to on premise is on demand.’ It is very Zen.  If you can understand that, then you will understand why the cloud is what it is."

On why Oracle and others are rushing to embrace the cloud:

"They don’t have a choice. Their overall enterprise apps revenue has declined, what else will they do?"

On what SaaS start-ups should do if they are trying to convince large enterprises to turn to the cloud:

“I think the number one thing is you have to get your customers selling for you.  Customers don't listen to the vendors anymore.  If you can get the gravitas around customers recommending you and referring you, you are golden.  If you can't you are in trouble.” 

When Om asked how he defines the cloud, Marc went through what he calls the 4 generations of the cloud:

1. Acknowledged Diane Greene for starting VMware, predicated on the problem of underutilized servers burning way more energy then they needed, and inventing the concept of virtualization to dramatically increase this efficiency. 
2. Acknoledged Amazon for taking this to the next level and offering a public version of this virtualized environment, allowing you to transfer LAMP stacks into their compute environment and pay for only what you need.
3. Acknowledged Microsoft launching "aZUNE" (Azure) where you can move .Net applications onto their servers. 
4. He then refers to Force.com a pure play environment, or "4th generation".  He says this is not just salesforce.com doing this, but also Google with App Engine.  In his opinion, these pure plays offer a much greater base of efficiencies.  As an example he cites salesforce.com's own SFA application, stating that SFA has approx. 60k customers and 2 million users.  In their primary data center they deliver four 9's of availability, and have only 500 servers in it powering all these customers.  He concludes by stating this is possible because you are operating within their managed environment: you get much greater efficiency vs. in amazon where you can run anything regardless of how efficient that application may or may not be. 

I’d be interested to hear what else jumped out at folks, or if they heard any interesting conversations in the hall or at the other presentations.  I thought it was a great show with a great group of people, and look forward to participating in future events.

Boomi @ Gluecon

Boomi recently attended and presented at the first Gluecon event in Denver, CO.  It was a great event, and Eric Norlin did a great job putting it together.  As the name implies, the focus is on integration in the web/cloud paradigm, everything from data portability, identity mgmt, cloud integration, etc.

I had a session, embedded below, that really represents the culmination of the types of conversations Boomi has with both customers of SaaS as well as the providers of the SaaS applications themselves.  Please check it out and let us know what you think!

A 360 Degree View Of SaaS Integration

View more presentations from Boomi.

Please leave us your comments below.

Demystifying SaaS vs. Cloud

I was asked to participate on a panel a few months ago on the topic of SaaS versus the Cloud and explore the question of whether SaaS would ultimately be “subsumed” by the cloud.  To be honest, I had to study up for this one because I didn’t even realize it was a question.  What I found was this was much more a marketing issue than a technical one. 

The technical distinction in my mind is clear: cloud delivers computing as a utility, SaaS delivers an application (such as CRM) as a utility.  (A much more fun topic is the difference between grid computing and cloud computing but there are a plethora of posts dedicated to that one!)  A SaaS application can be delivered in a range of models from the vendor’s own datacenter, to a third-party, “hosting” vendor, to a true cloud computing environment (ala AWS) which takes advantage of the latest technologies such as virtualization to maximize resource utilization (again the distinctions and pros/cons of each of these models has been well covered so I won’t go into them here).

However it is provisioned, SaaS (application delivery model) is quite distinct from Cloud (compute delivery model).  So why all the confusion?  As I said, I think it’s largely marketing.  Cloud has simply become a very handy, very trendy way of describing all things that occur “outside the firewall” as it were.  If it’s not happening on premise, it’s happening in the cloud – whether you’re talking apps or compute.

There is however one HUGELY important distinction.  Just because an app is hosted in the cloud does NOT necessarily make it SaaS.  Why is this important?  As a consumer, if the application is not truly multi-tenant, you’re not getting the great benefits of SaaS, you are getting an ASP delivery model.  Someone is simply running your copy of their application somewhere in a datacenter.  Even if it’s “virtualized.”  That’s not multi-tenant.  That’s not SaaS.

But, I’ve heard it argued, what does it matter to the end user?  Why do they care how the functionality is being delivered?  True, the typical end user probably does not care.  However, end users generally aren’t making the purchasing decisions and paying the bills or responsible for the information technology strategy for the entire enterprise.  Those folks tend to care a lot more. 

There is a reason why SaaS eclipsed ASP for application delivery.  It is hands down a superior delivery model from cost to technology to scalability.  Multi-tenancy is what makes all the benefits of SaaS possible: rapid time to deployment/value, faster innovation cycles, infinite scalability etc.  And it has a dramatically reduced cost structure because it leverages one platform.  Vendors who deliver their application via SaaS have a competitive advantage over those who do not.

There are some simple tests you can do to see if your vendor is using SaaS.  For one, sign on to their website and start using their app immediately.  Doing something like provisioning a trial account, which is a trivial matter with a true SaaS application, becomes a scaling and maintenance nightmare for ASP vendors – even using new technology such as virtualization.  There are vendors who have had to withdraw their “free trial” because it simply cost them too much to actually provide it.  Another simple test is to see if you can buy and provision your account without speaking to the vendor’s sales personnel.  Again, trivial for SaaS vendors, not so much for ASP vendors.

If you’re an end customer, I encourage you to ask questions when selecting your “SaaS” applications.  Go beyond “we’re in the cloud” to understand exactly how your vendor delivers its application.  Presumably, you’ve come to the cloud because you want to exploit the economics and advantages of utility computing and applications.  Caveat Emptor – if it’s not multi-tenant, it’s not SaaS.

More Myth Busting – Why APIs Don’t Solve the SaaS Integration Challenge

Most folks familiar with the SaaS industry would agree that integration is a leading (if not the #1) barrier to SaaS adoption.  Many of us worked in the enterprise space prior to SaaS and endured the pain of integration for years.  We had all hoped that SaaS would somehow be different.  And so it’s no surprise that as an industry, we want to believe that APIs are the magic that will finally, once and for all, eliminate the headaches of integration.  I’ve actually heard it said by folks in the industry that once all apps are “webapps,” integration will no longer be an issue.  Unfortunately, it’s not true. 

To be sure, well constructed APIs are essential to enabling integration.  An API opens secure access to application data through a predictable interface.  You know when you call the API what to expect, what data gets returned, in what format etc.  Sticking with my favorite analogy, it’s an electrical outlet in a wall.  Until you plug something into it, it just sits there.

That’s actually the good news and unfortunately where the analogy ends.  Even though there are web services “standards,” everyone implements the standards in a different way.  Things like authentication, session management, protocols, meta data browsing, and exposing customizations are rarely implemented the same way from application to application.  Hence all the “outlets” look different, require different plugs and run at different voltages.

But even if all APIs were standardized, there would still be a need for integration.  Why?  APIs are only one end of the equation – they do not complete the end-to-end integration process between applications.  Two apps with APIs still need a cord with plugs to connect them together. 

For example, APIs don’t handle the transformation of data between applications (required because every app describes data in a different format, even when multiple apps are describing the same thing such as a Customer).  They don’t handle the validation, business logic and error processing of the data as it moves between apps.  And they don’t handle the interaction with the API of another application that’s being integrated.  Even two apps built on the same PaaS platform are not natively integrated with one another.  That probably bears repeating…  Even two apps built on the same PaaS platform are not natively integrated with one another. 

But can’t SaaS ISVs just code direct integration between their apps and save us all the hassle?  Sounds great on the surface.  Unfortunately, most users customize their particular tenant of a SaaS application.  Hard coding an integration process cannot account for customizations made to tenants on one end of the “wire” or the other.  You would need to code a separate instance of the integration process for every combination of customized tenants – raising maintenance costs exponentially.  And hard coding in general leads to maintenance issues as APIs and schemas (file and record formats) change regularly.  Integration processes become brittle and will invariably break.  Sound familiar?

Fortunately, we don’t need to repeat the integration mistakes of the past as we scale the SaaS industry.  SaaS integration solutions exist that eliminate this complexity and remove integration as a barrier to SaaS adoption and scalability.  With Boomi, we have thought about the integration challenge deeply from the perspective of the SaaS industry.  We didn’t just ask how we could integrate SaaS applications but how we could use the inherent advantages of SaaS technology itself to integrate SaaS applications and eliminate the challenges typically associated with integration. 

Launched well over a year ago now, AtomSphere was built from the ground up as a pure SaaS platform for integration.  With AtomSphere, we natively handle the challenges associated with integrating SaaS applications such as multi-tenancy, customizations, changing APIs etc.  We abstract all of this complexity away from users so they can focus on easily connecting their apps.  And SaaS ISVs can now build their own connectors and on board to AtomSphere in a totally self-service model.  Once connected they have instant interoperability with every other app in the AtomSphere network.

If you’re an end customer, I encourage you to ask questions when selecting your SaaS applications.  Go beyond “we’ve got an API” to understand exactly how your provider intends to achieve your integration requirements.  If you’re a SaaS ISV and not already connected to AtomSphere, click here to check out how to get on board.

Multi-Tenant Integration – Busting the Myth of “Hosted” versus SaaS

I’ve noticed a trend recently of conventional integration vendors offering a “hosted” alternative to their on prem products and appliances. Unfortunately, those offerings are then marketed as “SaaS” or “on demand” simply because they are hosted “in the cloud.” To be clear, that is an ASP model – a model that did not fare so well. Just because something is hosted does not make it SaaS. (Nor does leasing or offering monthly payments make it SaaS either.)

So what’s the difference and what’s the big deal? The chief characteristic of SaaS that separates it from the old ASP model is multi-tenancy. Multi-tenancy simply means there is only one copy of an application deployed in the cloud (single instance) but that all customers can use that copy (multi-tenant) and even customize it to meet their unique requirements. Multi-tenancy is what makes all the great values of SaaS, such as rapid time to value, faster innovation cycles and ultra-low cost structure, possible.

It is particularly important in the world of integration because integration is such a fundamental building block for the SaaS community. Think of any common infrastructure system such as electricity as an analogy. It only makes sense to build common infrastructure systems once to the benefit of the entire community.

In his book “The Big Switch,” Nicholas Carr describes how one hundred years ago, companies stopped generating their own power with “dynamos” and plugged into a growing national power grid of electricity. Looking back today, the benefits are obvious: dramatically lower cost, greatly reduced maintenance, and ubiquitous distribution. It also made the process of upgrading technology much easier as changes made to the common grid were immediately available to the benefit of all users. But most importantly it addressed the scalability issue that was created by the limited reach of isolated dynamos and in the process unleashed the full potential of the industrial revolution.

We are in the midst of a similar revolution today with the advent of SaaS and cloud computing and integration has become the modern-day version of electrical power – call it digital electricity. Conventional integration products and appliances are single tenant – they were designed and built to support individual enterprises much like the electrical “dynamos” of yesteryear. In the single-tenant model, the burden and cost of building, implementing, and maintaining integration is shifted to the end customer. Every business must generate its own digital electricity at great expense. And attempting to grow the multi-tenant SaaS ecosystem with single-tenant integration products will result in sky-rocketing maintenance costs and greatly limited adaptability and scalability.

When we built Boomi On Demand, we recognized that the industry needed a “universal power grid” to unleash the full potential of the SaaS revolution. We built the Boomi platform from the ground up as a true, single-instance multi-tenant SaaS platform. It was designed and built to natively handle the complexity of multi-tenant SaaS applications. ISVs and end customers alike can now plug directly into Boomi’s “power grid” and have instant access to integrate with the industry’s largest network of interconnected SaaS, Paas, on-premise and cloud compute environments.

This is not a perfect analogy but I think it makes the point. Multi-tenant platforms such as Boomi unite and power the growth of the SaaS ecosystem. Single-tenant integration products simply weren’t designed with SaaS in mind – they were built for conventional on-premise implementations.

So yes, multi-tenancy does matter. We have the opportunity as we build out the SaaS ecosystem to avoid the integration mistakes that plagued the enterprise era. Adopting a common, multi-tenant architecture for integration is imperative to support rapid growth and expansion.

SaaS Apps and Conventional Integration Products - Oil and Water

Most analysts covering the SaaS industry today would agree that integration is the number one barrier to the adoption of SaaS technology. The problem lies not in SaaS technology itself but in the attempt to use conventional integration products and appliances for SaaS integration. It’s a technology mismatch. Conventional integration products were built for traditional on premise software implementations – not SaaS.

The fundamental limitation of conventional integration products (whether hosted on prem or “in the cloud”) is that they are single-tenant. As such, each customer must buy, install and maintain its own copy of the product and must do so at every location where integration is to occur. As a result, using conventional integration products to integrate SaaS greatly increases cost, complexity and time to deploy while also greatly limiting scalability. To date, ISVs have had little choice but to pass that cost and complexity on to the end customer. The underlying premise of this model is that integration is the customer’s problem to figure out.

There is a better way. On-demand integration solutions are themselves built using SaaS technology. Just like SaaS applications, they are a single instance, multi-tenant platform hosted in the cloud. There is only one platform and all customers use that platform for integration. As such, they natively deliver all the great values of SaaS: rapid time to deployment, faster innovation cycles, ultra-low cost and infinite scalability. And they have a dramatically reduced cost structure because everyone leverages one platform.

On-demand integration solutions also eliminate the cost and hassle of maintaining and upgrading each instance of a conventional product. In the on-demand world, upgrades and enhancements to the common platform are continually released to the user community and everyone enjoys the benefits immediately. On-demand integration solutions finally align integration cost with that of on-demand applications – an issue which has been a major barrier to sales for SaaS ISVs.

But most importantly by employing an on-demand integration solution, ISVs can lift the burden of integration off the shoulders of the end customer. On-demand integration solutions allow SaaS ISVs to offer bundled and pre-built integration as a service – solving integration on behalf of the customer. Since the customer is buying the application as a service it only makes sense to buy the integration as a service.

SaaS ISVs have the following options in developing their strategy for integration:

1. Continue to resell conventional integration products and appliances
2. Sell professional services engagements and build custom integrations
3. Build an on-demand integration infrastructure on their own
4. Partner with on-demand integration vendors to package integration for their clients

It’s a classic build/buy/partner decision, but partnering has the advantage of allowing the ISV to stay focused on its core business and to take advantage of an existing on-demand integration solution and get to market quickly with a bundled integration offering.

Forward thinking SaaS ISVs are already moving in this direction. Integration is quickly becoming a strategic imperative and source of competitive advantage. Consumers are flocking to the SaaS paradigm because it saves them time and money, and by providing integration as a bundled part of an application, ISVs can offer a great service to their customers while increasing win rates and accelerating sales.

Integration IS the Application

Integration Is the Application

 

Ok – that statement may be a little over the top but I make it in the same spirit as Sun’s vision for so many years that “the network is the computer.” Using that analogy, I absolutely believe that integration is the application in the SaaS paradigm.

 

I was speaking with the CEO of one of our partner companies last week. He was excited because they had an interesting prospect for their SaaS application and were very close to closing the deal. The prospect liked the functionality of the application and felt it was a good fit for their business. So, the CEO said, all we need to do is integrate them with a few things and we’re all set… 

 

Well the few things turned out to be the prospect’s website, several online trading marketplaces, an on prem point-of-sale system, an on prem financial system, and an online third-party shipping system. Oh and of course the partner’s SaaS application. And please deliver all of that without adding any appreciable cost to my solution such that I get priced out of the deal. Sure – no problem!

 

In the SaaS world of APIs, web services, and interoperability, it is increasingly common to see highly specialized applications focused on solving a specific business requirement but with very deep and rich functionality. That’s the beauty of a service oriented approach. However, this approach relies heavily on the ability to integrate with other highly specialized apps to deliver a complete and holistic solution to the end customer.

 

We get calls almost weekly from SaaS ISVs who have built really ingenious and innovative applications for the Web assuming there would be a way to solve their integration needs. They need to get data from multiple disparate data sources both in the cloud and behind the firewall to make their application “sing” and find that traditional on premise integration software packages or hardware appliances have become a sales and implementation hurdle as well as a long term scaling issue.

 

Integration, and the ability to deliver integration as a service, is quickly becoming a competitive imperative. It’s not enough to just offer APIs to your customers. Increasingly consumers of software as a service also want to buy integration as a service as well. They want a complete and integrated solution that works “out of the box,” can be deployed rapidly, and begins delivering value immediately. When you buy appliances for your house, they come with cords and plugs – you don’t need to be an electrician to use them. Integration is the application…