In the last entry for this blog, I wrote about how Workday’s technical architecture allows us to develop new products and updates with speed. Today I want to spend a little more time on the topic of speed because there is much more to the story than I shared last time, especially when it comes to the delivery of three updates to our suite of enterprise cloud applications a year. Moving with speed in enterprise software is as much about service delivery as it is about technical architecture.
Various teams at Workday have spent the last five years focused on the execution and improvement of application development, customer data conversions, and deployments as a single, integrated process with each update. The process is as innovative for enterprise software as the technology and products I love to write about. Consider some facts behind the process that made Workday 17 available to all of our customers in August:
The people who drive this process at Workday are perfectionists who are reluctant to talk about anything but the ways we can continue to improve. But when I pushed them to think about what we are able to do at Workday today compared with what we were able to do in past lives in the on-premise software world, they identified three key concepts that improve service delivery, quality, and speed.
First, the Software-as-a-Service (SaaS) model improves service delivery quality by letting the provider own the end-to-end process of development, conversion, and deployment. In the on-premise software world the vendor controls development (and associated QA), but there is a hand off for conversion and deployment. At Workday, the update process is not done until every customer is on the new version. The same team that project manages our development also project manages conversion and deployment.
Second, for speed, we think of it as a single process and not three sequential steps. This means thinking about customer data conversions while we are developing, not after. It also means thinking about impacts of the new update on operations while we are developing, not after.
Third, the combination of SaaS with agile development techniques is the secret to continuously improving the quality and speed of the update process. The problem with 1½ years (or longer) product cycles for traditional enterprise software is not only are they too slow, the resulting upgrade is too monolithic to be consumed efficiently. They key is breaking up new functionality into smaller, more consumable pieces.
SaaS offers value to customers by just getting them into the cloud. But the enduring value of SaaS comes from delivering in the cloud. That means delivering frequent updates and keeping all customers on the latest release. That’s easy to say but hard to do (and keep doing). It requires an architecture that supports rapid change, but there’s more to it than that. To go beyond just getting to the cloud to delivering in the cloud, a SaaS provider must organize for and invest in the end-to-end service delivery model that SaaS allows.
In a world where there seems to be an increased premium placed on the ongoing ability to access exciting new innovations (such as social and mobile), the competition increasingly will be about service delivery speed and quality. As an industry, it’s time to start talking about the second “S” in SaaS.