[Full disclosure: Workday is a client as are a number of their competitors. More importantly, I been looking under the covers of HRM enterprise software practically forever, and before that I was writing the code.]
I still haven’t digested every word in Workday’s recently released S-1, nor am I likely to do so before I publish this post. But I have been reading a ton of coverage of this event, some really excellent and some much less so. A major shout-out to @SAP_Jarret (and many others) for posting some of the best links on his discussion thread about Workday’s S-1 over at LinkedIn (free registration required). Hopefully others will contribute there so that we will have a fairly complete set of the relevant links in one place.
After some soak time (literally, I worked this out while swimming laps), I think there are a few points that haven’t gotten enough attention which prospects, customers and investors (as well as competitors and anyone thinking about working there) might want to consider. And many of these points may also apply to other true SaaS vendors, especially those which are fairly InFullBloom. So here I go, jumping into the fray, last but I hope not least.
There’s been a good big of discussion about the customer lock-in aspect of Workday having 3-5 year non-cancellable contracts per their S-1. But there’s been little mention of the fact that many true SaaS customers (and not just Workday’s) prefer longer contracts in order to lock in, for their own purposes, desireable pricing for as long as possible because they know that pricing may well change when that contract renews.
But real customer lock-in for enterprise software that’s being used and embraced by the entire workforce (not to mention by their dependents/beneficiaries and applicants and by the ex-wife of a former employee who is eligible for benefits under COBRA) has little to do with the contract. Rather, it’s all about the difficulty of getting 10’s of thousands of people who have adopted that UX to give it up, always assuming it’s a good one, which Workday’s is. And just imagine the outcry when these users think they’re going to lose a UX they use daily once it includes the type of intelligence, historical data, embedded analytics and so much more that comes with widespread and long use (think Amazon’s ability to recommend books based on what it knows you have purchased and not designated as a gift)?
The lock-in for true SaaS vendors is in delivering so compelling a user experience that customer leadership would be hung out to dry if they tried to take it away — and to keep on delivering it. That’s quite different from the various flavors of lock-in we’ve seen with the last generation of licensed/on-premise enterprise software.
There’s also been a good bit of discussion about the amount of revenue Workday derives from professional services. While not broken down completely, I think we can assume this includes helping customers through not only initial implementations but also with ongoing or periodic support as those customers turn on features in new Workday releases or change their configurations as their own business needs change.
Some of the comments have suggested that this is too large a % of Workday’s revenues or that this begins to look like true SaaS isn’t a silver bullet for eliminating ALL implementation work (which it certainly is not). But no one has even hinted at the importance of Workday (and the value to their customers) keeping at least a light Workday hand on many to most customer implementations, even when partners are taking the lead.
I think it is critical for any next generation enterprise software vendor to keep their hand on the tiller (also the till :-)) to ensure that systems integration partner-led projects aren’t using implementation thinking, methodologies, tools or business practices carried over from the mega-implementations of the last generation of licensed/on-premise (or hosted single tenant and 3rd party managed) solutions. No matter how good the intentions of SIs in developing their partnerships with true SaaS vendors, many of them retain a business model that thrives on mega-implementations.
Architecture As Competitive Moat
The best coverage of Workday’s S-1 release, and of Workday in general (as is true for the best coverage of other enterprise software vendors) does discuss the growing functional scope of Workday’s offering (there’s been a lot of good coverage of WD 17’s new Time Tracking application as well as big improvements in their growing financial applications), the usability of its UX, the range and capability of mobile Workday, its being SaaS and more. However, there’s been VERY little coverage of Workday’s underlying architecture and development methodology which I consider to be a very substantial competitive advantage.
Those vendors with which I’ve worked or am working (and others with whom I have not been similarly engaged) which have adopted correct domain object models (and getting to correct is no mean feat) as the foundation of their applications, a metadata-driven definitional development approach to writing a whole lot less code (so code only for the tools and NOT for the applications), and much more easily adapted applications, are able to achieve much better cost, time and capability to market with fewer errors and release to release perturbations of historical data. Those vendors which have achieved a set of preferred architectural behaviors, which I dubbed SaaS InFullBloom, deliver products that are inherently easier to configure and understand while reducing greatly not only their own efforts to add capabilities but also the effort needed by their customers to unleash and then use those capabilities.
Doing it right takes a ton more money and time up-front, and that’s time and money that very few entrepreneurs in our space have had available to them, but it pays huge dividends to vendor and customers over time. Doing it over is painful, but there are some major vendors in our space who are doing just that, and I applaud them. Doing it right also changes the mix of KSAOCs needed by the vendor (e.g. very specialized tools developers and subject matter experts who can express the domain in patterns) and by the customer (e.g. ability to rethink the domain from the perspective of business outcomes rather than replicating age-old processes and data). But what this also means is that, as the tools mature and the models are built out, R&D investments slow per chunk of capability delivered because so much of that new capability involves the reuse of known objects in new ways.
As you look at true SaaS (or even not so SaaSy) vendors who are practicing these newer development approaches and architectural designs in a domain as large and complex as enterprise class HRM, take a hard look at what they’re able to accomplish behind the scenes. It’s my opinion that Workday’s R&D investments (and that of other vendors following the same/similar path) are delivering more bang for their bucks, an opinion that will be tested very publicly once the bulk of their foundational build-out is behind them and all the leverage points of their approach are at scale.
There’s been a lot of discussion among the EIs privately and in the blogosphere/twitterverse/business and financial press publicly about whether or not true SaaS at the enterprise level can be profitable. One of the concerns that’s always raised, and a very legitimate one, is how can the true SaaS business model at the enterprise level support the marketing and sales costs of yesteryear. Well of course it can’t.
But what doesn’t get as much attention, or at least I’m not seeing it, is what various true SaaS enterprise vendors are doing to attack the costs, complexity and timeline of every aspect of their “gleam in eye” to “closed deal” to “in production” customer lifecycle. And attack it they are.
My small contribution to this attack has been interrogatory configuration, an approach on which I’ve been working almost since the beginning of my solo practice in ’87. Initially, this was envisioned as a means of reducing the implementation and upgrade costs/time/errors for the HRMSs of that era. Great idea in principle, but the architectures of the day couldn’t support dynamic configuration of the underlying applications. One of those early efforts led to a number of workbenches at Oracle, more current versions of which are still in use with EBS.
Architectures of the type described above not only create a competitive moat, but they lend themselves to the collection of techniques — and to the fully automated configuration — that is the fullest expression of interrogatory configuration (think TurboTax). A number of my clients (and I’m sure others) have embraced this approach in spite of the really heavy lifting it requires in understanding a domain, and I hope to be around long enough to see some of this work bear fruit. While there are many other ways to streamline/improve the marketing and sales of enterprise class true SaaS, I believe that interrogatory configuration (if only it gets a much better name) will have a significant impact for those able to accomplish it.
Everyone knows that I’m biased toward great HRM enterprise software. But great software is never enough to ensure a successful software or other technology-enabled business. Quality leadership, talent at every level, effective organizational culture, adequate investment resources, and many more business elements plus a ton of mazel are also needed to build durably successful businesses. No one was harder on PeopleSoft than I was because I felt it was a technical reincarnation of out-of-date HRM thinking and data design. What pleases me not only about Workday but about some other bright software spots in HR technology is that we’re now reinventing on every level — business model, deployment approach, development methodology, operational technology, user experience, configuration frameworks, applications architecture, object models, and so much more. One of the reasons I love working/talking/visiting/etc. with HRM software vendors is the change to learn more about the topics covered here.