This continues a series of columns from practitioners I respect. The category "Real Deal" describes them well.
This time it is Stan Swete, CTO and VP of Product Strategy at Workday. Besides being one of the best technologists in the enterprise world, he is also one of the nicest and most articulate.
“This week at Workday we have our auditors in to review the internal processes and controls related to development and delivery of our Software-as-a-Service solutions. This time around, the review includes an audit of how we implement multi-tenancy on the application and database server layers of our architecture. Prepping for this review as I’m trying to write this column makes me smile, because it reminds me of how little Vinnie and other analysts want to discuss the merits or importance of multi-tenancy. It took me more than one presentation to analysts to realize that while having a multi-tenant architecture is essential to being able to do what we do, my analyst friends would rather focus on delivered value. So I have made it a New Year’s resolution to focus my 2012 comments away from our approach to SaaS and toward the value it delivers.
The way to think about the value SaaS delivers is to step through all phases of the enterprise solution lifecycle and compare the old on-premise way of doing things versus the new way things happen with SaaS. Some of the obvious differences have been identified for these phases:
· Implementation. The ability to start a SaaS implementation as soon as the contract is signed because you don’t have to wait for hardware and software to be delivered and installed.
· Upgrades. Getting more frequent and cost-effective access to new functionality because the vendor manages updates and data conversions.
· Integration. Moving the execution and monitoring of integration to the cloud with solutions such as Workday’s Integration Cloud.
Two other areas of differentiation for the support and implementation phases get less attention, but data has emerged with more SaaS experience:
· Implementation. All mechanical tasks to support the implementation team are performed by the SaaS vendor’s operations staff that does them in production. This eliminates the risk and variability of having customers or their implementation partners figure out how they are going to do it themselves. It takes huge time and cost out of setting up, copying, and taking down the various environments needed during implementation.
· Support. Incidents that are fixed for one customer are fixed for all customers at the same time, allowing customers and the vendor to avoid more calls on the same topic. Also, since there is only one environment, neither the customer nor the vendor has to spend time trying to describe and replicate the customer’s specific environment.
Still, even after six years of experience, we continue to find additional ways the new model delivers greater value to our customers. The most recent example relates to how performance enhancements and performance benchmarking happen with SaaS vs. on-premise software. In recent months, we’ve developed enhancements to how Workday processes payroll for customers with large workforces. This work resulted in significant performance and scalability improvements, which we published in a benchmark featuring payroll processing for a 35,000-person workforce.
Consider how performance enhancements and the resulting published benchmarks happen in the on-premise software world. The vendor creates a new version of its software with performance enhancements, designs a benchmark to measure improved performance, and then executes it on very high-end equipment provided by its hardware partners. The benchmark is published, and existing customers get the information in a report. In order to achieve (or even get close to) the benchmarked performance, customers must upgrade their software to apply the performance enhancements, and/or update their hardware to benefit from the newest and fastest equipment used in the benchmark, and/or tune their database.
In the SaaS world it’s a little different. We benchmark on the same hardware and network configuration all our customers use. It wouldn’t make sense to speed things up by getting a higher-end box just for the benchmark. Also, we make the performance enhancements developed for the benchmark available to customers in our production environment. Our customers don’t get involved with upgrading software.
In the case of our work for large payrolls, the main capability we added was the option to run a single payroll across multiple servers for improved speed and scalability. The enhancement was tested with one of our customers on Workday 13 (the update all our customers went live on in April 2011). Our benchmark testing the enhancement was completed in July. The performance enhancement was made available to our production environments team starting in Workday 14 (live in August 2011). The customer that tested the enhancement began benefiting from it in the production environment in August. The customer’s investment in the process consisted of running payroll and observing that it completed correctly and much faster with the enhancement.
Interestingly, our customer let us know that members of its IT team were watching the initial test runs of our payroll optimization at the same time they were waiting for the arrival of a DBA consultant to help them begin a tuning project for an on-premise enterprise application they use. In their minds the contrast was striking.
It’s too bad “PaaS” is taken as an acronym. It could also stand for “Performance-as-a-Service.””
Stan can be reached at stan dot swete at workday dot com
