During the last year I have worked with many ISVs from all over Europe & Middle East helping them to (re)architect their solutions for a Software-as-a-Service (SaaS) delivery model.
One thing stood out very clear. There’s a gap that needs to be bridged between the classic application hosting provides (hosters) and the ISVs. The ISVs where expecting the hosters to provide far more than what most hosters actually could deliver. In Gianpaolo’s blog post about the SaaS ecosystem, what the ISVs are looking for is referred to as a “SaaS hoster”, but what does it actually take for a “classic hoster” to become a “SaaS hoster” and what does it take for an ISV to move from an on-premise to a SaaS delivery model in terms of hosting, re-selling etc? I found that there’s a need to define clear interfaces between the two parties as well as providing guidance and reference architectures for both sides.
From the ISV side we invented the fictitious logo program “Designed for Hosting” (DfH) to describe a SaaS application that well architected (such as the Litware sample), well described in meta data, easy for hoster to re-package and re-sell as well as easy for a hoster to provision, manage and monitor.
ISVs need to focus on building competitive application functionality and therefore, in many cases, prefer to rent a “SaaS Hosting Platform” (SHP) that provides scalable, available, secure and interoperable application and platform services. Offering such SHP for rent provides a new business opportunity for hosters to “move up the stack” to become a “SaaS hoster”.
Many hosters also act as aggregators or re-sellers of ISV applications so the DfH must, in addition to the operational aspects, also include the sales, aggregation and billing aspects.
I have, together with my virtual team, had many whiteboard discussions with solution architects (mainly from the ISV side), infrastructure architects (mainly from the hoster side), business owners/managers (from both ISV and re-seller and aggregator side) about what exactly DfH and SHP is (or rather should be). My colleague, Fred Chong, takes a stab at defining it here (even if we used the term SDP instead of SHP back then). We realize that this is a known concept in the Telco industry and that similar hosting and re-seller platforms exist as “carrier grade”. However, our target was the ISV embarking the SaaS journey (after potentially spending decades in the on-premise world) as well as hosters moving from traditional web site hosting to SaaS application hosting. The consistent feedback from these groups is that they want to start small with a bare minimum of servers, and grow their infrastructure as their business grows. ISVs often also want to have a running instance of the SHP for internal use and testing so a light-version of provisioning, catalog etc is often asked for.
Finally we decided to invite a real ISV (www.sitecore.com) and a real hoster who operates both as aggregator as well as a platform provider under two brands (www.cohaesio.com and www.surftown.com) to do a joint three week hands-on Proof of Concept (PoC) with us. The goal of the project was to build a sample implementation of the central concepts of DfH and SHP (as we defined them). We discussed what it would take to make Microsoft’s Litware sample and Sitecore’s SaaS edition “designed for hosting” and what Cohaesio and Surftown’s SaaS Hosting platform offering should look like to be able to host and re-sell Sitecore as well as any other SaaS application.
In a series of blog posts over the next 1-2 weeks, I will go through some initial thoughts, my findings from the engagements and the six main scenarios we ended up implementing in the joint lab:
1. Defining the application platform run-time instances and its capabilities
2. Defining the application meta data and adding a new ISV (or platform tenant) and its application and modules (or just “software items”) to an new or existing platform run-time instance
3. Managing the re-sellers hosting plans in the store front to include software items from the new application
4. Order fulfillment and order management in the store front and provisioning for new application tenants (subscribe)
5. Usage metering and billing for the application tenants
6. Accessing the application with web single sign-on and federated web single sign-on
Expect to see ISV and Sitecore specific aspects of this session at Lars Fløe Nielsen’s (Solutions Architect at Sitecore) blog as well.
Thanks to all the great minds that have provided feedback and/or directly contributed to the various architectural design sessions and proof of concepts engagements over the past year:
· The folks at Microsoft (Gianpaolo, Fred, Yuriy, Kevin, Mario, Jimmy & Bo).
· The entire team from Sitecore, Cohaesio and Surftown.
· The CxOs, architects, developers etc from all the “anonymous” ISVs that have visited me in the Innovation Centre with interesting SaaS offerings or otherwise inspired me along the way.