SaaSCon Reminiscing

I was co-presenting with Gianpaolo at SaaSCon last week. The event marked a highlight in my presentation career: we ran out of time and the organizer was running down the aisle trying to stop my presentation. I turned and saw the audience still frantically writing down notes of the slides that I’m rapidly flipping. I looked into their eyes that told me they wanted more… I agree with Dan’s comment about the session – it was too short. I also noticed that a few other sessions ended early with the 45 minutes allocated slot – if only we are able to do some cycle stealing…

At the event, some attendees told me that they were especially interested in a couple of slides:

The subject of our SaaSCon session was “Understanding SaaS Architecture” and we spoke on three key architecture areas. The slides above are from the portion on service delivery architecture which describes the capabilities that SaaS ISV will need in order to deliver, operate and market their SaaS applications.

SaaS changes the way ISV have to think about running their businesses. A traditional software development shop that sells shrink-wrapped software must now also consider how it can bulk up on operational best practices, which is usually not the company’s core competency. The amount of work it takes to operate a data center is non-trivial. Having to monitor for 24x7 availability, guarantee that application performance is maintained at sub-seconds response rate and the vigilance to keep hackers and viruses at bay, all require different skill sets and mastery with management and operational tools. In fact, the operational aspect of software as a service is a major road block for many software vendors, especially the smaller ones.

The Chinese phrase for crisis is “wei ji”（危机). It literally means that in every crisis also lies an opportunity. Therefore this barrier of entry for the SaaS ISV also creates the opportunity for other players to offer the service delivery platform as their core business offerings. We call these players service delivery platform (SDP) providers. Existing telcos and hosters have a lot of experiences in related types of service delivery and are best positioned to “move up the value chain” so to speak to offer such services. The outcome is all good - the high-tech industry and consumers benefit through specialization and economy of scale.

Getting back to the slides shown above, the SDP provides a set of common services that SaaS application providers can depend on to deliver their services:

· Identity management – There are two main categories of identities that the SDP provider manages – the identities of the SaaS application provider who are being hosted, and the identities of their customers (in other words, the SaaS application provider’s tenants). Given that single sign-on is a frequent integration requirement from enterprises buying SaaS solutions, it is conceivable for SDP providers to be the identity federation points for which enterprise tenants can federate with. In this sense, SDP providers also act as identity providers for the SaaS application providers and their customers.

· Order management – Like above, the SDP can provide facilities to manage the ordering pipeline for both the SaaS application providers and their customers. Taking order from the SaaS application providers means having a system that allows application providers to sign up for the SDP services, which include hosting, operating and possibly marketing the software services of the application providers. In many cases, the application provider will also look to the SDP provider to provide the channel infrastructure for signing up new customers. The customers may be end users of the applications or resellers of the applications. The order management infrastructure will need to interact with the CRM, identity and monitoring systems to provision new customer information.

· Metering – this component tracks the usages of the applications. Usage may be tracked in a variety of ways, for instance, according to transactions or number of licensed users. The usage information is then used to generate invoices and the SDP provider may bill the end customers on behalf of the ISVs.

· SLA monitoring – Management information is supplied through management agents. In order to monitor for application performance at fine granularity, the SaaS application will have to be instrumented with the right performance counters to indicate vital signs such as the current application response time. The instrumented data may be pushed to or pull by the management agents and sent to the monitors for analysis. Corresponding performance rules are configured at the monitoring stations to trigger management alerts when an SLA condition is violated (for example, if the response time has gone beyond a 5 second responsiveness threshold). Availability rules can be similarly configured to monitor for collected “heart beat ping” responses from the application. A monitoring rule can be set to fire off a “not-available” alert if the monitor did not receive 3 consecutive ping responses from the application.

· Call center support system – SaaS presents an opportunity for application providers to improve the quality of their customer support service. With on-premise software, it can be difficult for application vendors to gather diagnostics information when software glitches happen at the customer site. When an application exception occurs within the SDP, the application vendor could implement the application to offer an opportunity to open a trouble ticket with the customer support call center. At the same time, the application can also save all the application exceptions and diagnostics information referenced by the trouble ticket number to a log used by the customer support system. Such troubleshooting support features allow the call center to better diagnose the problems and help the customers.

Practically speaking, SaaS application will need to be modified to take full advantage of the SDP capabilities. For example, to measure application availability, the application may need to implement a “syntactic transaction” interface that will respond to periodic heart beat pinging requests from the network monitor. Another example is when using the SDP provider as the identity provider. The application will need to be modified to accept security tokens issued by the SDP’s identity provider. Therefore, the SDP runtime will need to interact with the SaaS applications through a set of programming interfaces (represented by the lollipops sticking out of the SDP runtime). Most likely, some kind of SDP SDK offered by SDP providers will facilitate such interfacing needs.

The above are what I consider to be rather traditional operational services. The second slide shows some additional capabilities that are not directly tied to everyday service operation, but are sensible capabilities for SDP providers to offer.

· Testing and certification - SDP providers are taking some amount of risks hosting third party applications. Therefore, they may want to subject these applications to a testing and certification phase before agreeing to host these applications. At a minimum, these applications should be tested for security and reliability, to ensure that application faults can be isolated and not adversely affect other tenants that the SDP provider are hosting. In addition, the application will need to be tested to ensure accurate implementation of the SDP interfaces if the applications are going to take advantage of the SDP capabilities (like SLA monitoring).

· Ranking and feedback - From the market development angle, the SDP provider can also provide end-user ranking and feedback services. Such data can better inform the application consumers and providers about the good and bad of the application. Such a feature promotes competition and helps improve the quality of the software industry.

At the end of this month, I’ll be visiting a few customers in Europe to work out more architecture details on the SDP. Meanwhile, please email me if you have requirements or architecture thoughts about this area. I’ll be publishing an architecture paper on this topic in the next couple of months so I definitely welcome your input.