SaaS in the enterprise (or the need of the external service bus?!)

After a couple of whitepapers and a few blog entries on how to successfully deliver SaaS (or as Fred would put it, taming the three-headed monster (scalability, configurability and multi-tenant efficiency) that haunts every SaaS ISVs.) We are in the middle of a whitepaper focusing on the impact of SaaS in the enterprise.

Although there are some very compelling scenarios for enterprises to deliver SaaS (especially if they have strong franchise/reseller networks, more about this in a different post), based on our conversation, the #1 concern of enterprises is how to successfully consume SaaS.

Many enterprises have embraced a service oriented architecture for their corporate IT, in other words they have decomposed (or in the process of decomposing) their IT in a portfolio of services (CRM, Payroll, Collaboration etc.) supporting the need of the business. It is fair to say that today, the vast majority, if not all, the services are run ‘on premise’.

The opportunity for enterprises is to “source” some of these services ‘in the cloud’.

At a high level, running IT services on premise gives you control, running IT on the cloud gives you a potential better cost structure as you can leverage the provider’s economy of scale.

The decision for the enterprise is therefore to find the right balance between cost and control.

Below is a slide that represent this model (we call Software + Services) where some of the services are running in house, others are in the cloud. One can think of this as an extension of the classical SOA model but where the boundary is not the internal firewall but the entire Internet.

If an enterprise service bus was required for connecting all the services within an enterprise, one could think that an external service bus is required in this scenario. (Note that I am using the external service bus more as a “pun” on the enterprise service bus than a term I want to push (at least for nowJ))

In this model, the goal for enterprise IT is to see its portfolio of services as if it was running on premise but some of the services are actually “projections” of services running in the cloud.

Decision on which one to run locally and which one run in the cloud will be based on financial, legal, political and technical reasons. The whitepaper I mentioned earlier will go deeper on this issue.

It is important to note that mastering the “SOA pillars” such as data integration, federated identity and all the other usual suspects is even more critical in this scenario.

Another point to understand is that there will be an increasing pressure on ISVs (Independed Service Vendors?!) to build their services in such a way that integration with internal IT is facilitated. Today a lot of ‘on premise’ integration is done through custom code, direct access to the database, in other terms somewhat bypassing the ‘official’ interfaces; this will not be possible when service will be ‘true black boxes’ running in the cloud. For example, custom reports created by hitting directly the database will not be possible as the database (not running in your datacenter) will not be directly accessible.

Successful ISVs will therefore run their services as black boxes in a multi tenant environment to maximize economy of scale, but will need to allow a degree of customization and integration hooks not available (or not as required) today in a on premise world.

The good news (at least for me) is that being successfully in delivering or consuming SaaS is all about proper architecture J

Update:
Chris Keyser (a great mind in the Microsoft ISV team, I wish he would restart blogging) pointed me to the fact that allowing more integration hooks is not something specific to SaaS, it is the more generic aspect of building better componentized service oriented logic in apps. Whether on premise or hosted, this is needed in order to achieve a clean SO based infrastructure.
This is absolutely correct, my point was that when on premise there are “workaround” if the logic is not perfectly SO (e.g. custom reports hitting straight into the database); when in the cloud you have less workaround, i.e. you have no other access than the one provided by the service interface, hence the motivation of having better integration hooks is IMO higher in SaaS.