Best Practices for SaaS Upgrades as Seen in Workday's Approach

If you're involved with enterprise software, you need to pay attention to what Workday is doing--even if you're not interested in HR or financial systems. Because Workday is one of the best examples of how enterprise applications can and should be delivered in the cloud.

This was one point I took away from Workday's annual user conference in San Francisco and from a day-long series of briefings for industry analysts earlier this month. 

The differences between Workday's practices and the approach of traditional enterprise software vendors are striking. There are several points of contrast, but in this post I'd like to focus on how Workday delivers software upgrades and some new twists in how it does this.

Traditional Approach to Software Upgrades

In the traditional enterprise software model, vendors develop new versions and provide them to their customers that are under maintenance agreements. The customer takes delivery of the new version, installs it on a test copy of the system, migrates data from the existing production version, retrofits any customizations or interfaces with other systems, revises its user procedures, performs system testing,  and migrates all of its users to the new version. In the process, if there is any time left in the schedule, the customer also may investigate how it would like to use any new functionality offered in the new version.

The bottom line is that in the traditional model, software upgrades are both a technical exercise as well as a business exercise. The technical challenges of data migration, retrofitting of customizations, and reworking system interfaces can be significant and can encourage customers to stay on older versions of a vendor's system for many years. When such a customer finally wants to get current on the latest version, the upgrade process can rival the time and expense of the original implementation. The technical aspect can be so much work that companies often retain outside service providers to manage or assist in the effort. The business aspects--accommodating changes to business processes or embracing new functionality--are often jettisoned for the sake of simply getting the new version installed from a technical perspective. As a result, customers often do not realize the benefits of the new functionality that the vendor offers.

The Workday Approach

Workday's approach to upgrades, from the beginning, is simple: it takes responsibility for all technical aspects of the software upgrade, allowing the customer to focus solely on the business aspects. There are at least three reasons that Workday can do this:

• Workday's object model allows most customizations to be brought forward to new versions of the system with little or no retrofitting.
• Likewise, Workday's Integration Cloud, based on technology it obtained through its acquisition of Cape Clear,  allow most custom integrations to continue to work with new versions of its system.
• Since Workday operates the system on behalf of the customer, Workday takes all responsibility for migrating the customer's data to the new version. 

The impact of this last point should not be underestimated. Last year, Workday's CTO, Stan Swete, wrote about how important it is for the SaaS provider to take full responsibility for migrating customer data to new versions: 

[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.

When it comes to version upgrades, not all SaaS providers are created equal. Some are little more than single tenant hosting providers. Others are multi-tenant SaaS providers, but they deploy new versions as separate instances of the system and allow customers to stay on older versions for long periods of time. This makes version upgrades considerably more difficult if and when customers do decide to upgrade. Workday, as discussed, is at the other end of the spectrum, keeping all customers current on the latest version. Salesforce.com, NetSuite, and Plex, are similar to Workday in this regard, though they may differ in the details of how they do it.

Further Improvements in Workday's Approach

This year, Workday has further refined its approach to version upgrades in three ways:

1. Single production instance for all versions. Previously, Workday would deploy a new version of Workday as a system instance that was separate from the previous version, and Workday would migrate customers in waves from the old version to the new version over a three week period. Workday's new approach is for the current version and the new version to exist simultaneously on the same system instance. Workday will now move customers to the new version by means of a set of "switches" that dictate which features of the system the customer will see. This new approach is possible because of Workday's object orientation discussed earlier.
2. Continuous development and deployment of new functionality. Instead of holding all functionality enhancements for its periodic version upgrade, Workday is now introducing smaller changes on a weekly basis. This is especially important for small but high-priority changes or for tax and regulatory updates. Contrast this to the traditional vendors, who required many months or years between the time customers request changes and the time they actually see them in updated versions.
3. Continuous conversion of customer data. As Workday develops new features that require changes to its data model, the single production instance now allows Workday to convert customer data in the background in advance of actually migrating customers to the new version. This reduces the amount of downtime required during the when the customer is moved to the new version. 
4. Preview instance. Now that there is a single production instance and continuous conversion of customer data, Workday is now able to offer customers a preview instance of the new version, giving customers a longer time-frame in which to evaluate and plan for the new version. Under the traditional model, customers only get a hands-on look at the new version when they take delivery of the upgrade, install it, and convert their data to it in a prototype environment. Workday's approach gives customers much more time and encourages them to make use of the new functionality.

 Swete summarized these changes in a blog post during the user conference:

Probably the best example of embracing continuous change is happening on the service delivery side of our business. Workday has moved to continuous deployment of new features to a single code line. This move, along with the continuous background conversion of data for new features, enables us to complete updates for our production customers with less scheduled downtime. Application of changes to a single code line reduces the expense of maintaining multiple code lines around each update we do. Moving to continuous deployment also gives us the flexibility to continue to respond to our customers’ requirements when it comes to the number of updates we do each year.

As Swete indicates, the single production instance, continual development approach, and continuous conversion of customer data allow Workday to scale back from three new major versions a year to just two. The conference audience applauded when co-CEO Aneel Bhusri made this announcement, perhaps indicating that many companies have difficulty absorbing three major upgrades a year. At first blush, the reduction in the number of new versions a year would imply that Workday is slowing down the number of new features per year. But in an sidebar conversations with Workday executives the next day, it became clear that these most recent improvements actually mean that Workday will be introducing more new features each year. The difference is that the smaller changes will be trickled-in on a weekly basis, while major new features will be held for the twice-yearly updates.  As indicated earlier, this approach also allows Workday to accommodate regulatory or tax-law changes on short notice, which have become more common in recent years.

Workday's core strategy of reducing or even eliminating the technical burden of version upgrades is a best practice for SaaS providers, allowing customers to focus exclusively on business improvement and maximizing the value of their system investment. More SaaS providers should follow this example.

Postscript: Over at Diginomica, Phil Wainwright has two good posts covering some of these same points:

• Workday Bows to Enterprise, Reins in Release Cycle
• Straddling the Chasm at Workday Rising: Innovation vs. Continuity. 

Note: Workday covered my travel expenses for attending its user conference.

Update, March 19, 2014: This Workday post by David Clarke provides a detailed explanation of Workday's single codeline development process.   

Related Posts

The Simplicity and Agility of Zero-Upgrades in Cloud ERP