It started out innocently enough with my saying:
MyPOV - Not a good time for verticals when the core gets shifted. #wdayrising
— Holger Mueller (@holgermu) October 10, 2017
I made that assertion based upon the fact that
- Workday was showing nine verticals and
- That customers I have spoken with in recent times have told me that Workday worked with them as industry lighthouse customers to ensure that industry specific needs were met.
Mueller was not impressed but his answer left me a tad confused so I asked for clarification.
I'd check with @InFullBloomUS but the object model they've designed *should* not present that problem.
— (((Den Howlett))) (@dahowlett) October 10, 2017
I hoped to get a more definitive answer from Naomi Bloom who I know has given Workday a LOT of advice about the object model upon which Workday is built. Keep with me on this one as it gets a tad technical but has a serious business application impact.
Enter Naomi Bloom and True SaaS
Ms Bloom is a fierce defender of what she calls 'True SaaS,' a concept that embraces configuration, multi-tenancy, the object model and in-memory computing.
The object model matters in HRM because the notion of a static object (the person) has fundamentally changed as the nature of work has changed. Workday went many steps further than this by abstracting the database away from the application objects and logic such that changes to the application have no impact on the database. Workday was able to do this for a variety of reasons far too technical for me to explain (sadly I know enough to be dangerous.) Instead, I encourage you to watch this video Naomi recorded for Workday that explains this model.
That is not the end of the story and to leave it there would be unhelpful. Instead, I refer readers to a recent interview that Stan Swete, the brains behind Workday architecture gave to Tiernan Ray at Barrons in response to a claim that Workday had built its own database. Here is the critical part of the text, emphasized at important points:
The typical vendor uses that not only to store data, but also to describe the shape and form of the app. Workday doesn’t use the database to describe the applications. That was a purposeful choice."
Swete explains that Workday’s having not placed the application definition inside the relational database “leads to a simplified schema in the database that we can maintain across all our updates."
“Typically the database becomes complex with the complexity of the app; we wanted to be able to have a database that was relatively unchanging from a structural standpoint."
Instead, the application’s definition is in a set of Java language objects that are managed “in-memory”:
Rather than have the structure of our apps mapped to table, it’s in some other structures we have. We’ve committed since day one to be an in-memory application. For reporting and most processing we need to do, we don’t need to go to the database. People think we are an in-memory database, but we’re not using an in-memory database. The reason we did in-memory was to have our applications be more responsive for reporting and analysis. So don’t have to do a bunch of SQL or go to disk to generate reports.
Developers can "describe applications” in Workday "as an object model” without recourse to SQL, the query language used to managed the database. “They can describe a worker class, say, and an org class” without SQL, he notes. “That allows customers to make change without having to incur the large upgrade projects that have been money sinks for companies for a long time."
That approach leads to applications that are “easier to own over time," and that can be updated “without being a major IT project” for the customer.
It's the database problem
The key part here for application extensibility is that the business logic is divorced from the database. In legacy software, when you change the logic, you have to change the database schema. Given the fact that rule changes alone, so-called 'Legs & Regs' can end up looking like an upgrade in traditional software development models, it is no surprise that Workday chose a different approach. Here is Microsoft's take on vertical application development:
Because vertical applications usually require certain functionality, such as scrollable cursors or transactions, they rarely support all DBMSs. Instead, they tend to be highly interoperable among a limited set of DBMSs. Typically, vertical application developers choose to support those DBMSs that represent a large fraction of the market and ignore the rest. They might even choose to support specific drivers for those DBMSs to reduce their testing and product support costs.
Because vertical applications can support a known set of DBMSs, they sometimes contain driver-specific or DBMS-specific code. However, such code is best kept to a minimum because it requires extra time to maintain.
Does Workday's approach actually work in practice? Yes it does. And just for completeness, Workday didn't build a database. It uses MySQL.
Speed to results
I recall having lengthy discussions with Workday about reporting for finance. It is a fact that the way you build applications for transactional purposes is fundamentally different to that for reporting and analysis. Workday's initial approach turned out to be restrictive and slow. Swete understood this and said that he wasn't particularly concerned because he believed Workday could re-engineer the entire reporting stack inside 12-18 months. It was done in 10 months. This blew me away as I had never seen a vendor able to build enterprise class reporting as an integral part of a finance application.
There are a myriad of other complexities involved with reporting and analysis that continue to represent challenges for those who have to build transactional systems and in Workday's case, one of its answers has been to make technical acquisitions that could be refactored or re-engineered into the Workday platform. The most obvious example is the acquisition of Platfora in July 2016 which has morphed to Prism Analytics, an application that provides numerous detailed and actionable scenarios for decision makers and business planners. All in less than 18 months and with a long road ahead for new applications.
To my knowledge, that level of development and coplete product availability is unprecedented at the kind of scale at which Workday operates. It is a further proof point that Workday's early investment in a modern architecture where everything sits inside a single codeline and in line with MsBloom's True SaaS strictures is the right strategy.
Let's bring this back to my discussion with Mueller. Ms Bloom pinged the Workday development folk and they came back:
our OO "meta-data" DSL architecture is built for this change. We have and continue to change our core as we grow with our customers.
— Joe Korngiebel (@JoeKorngiebel) October 11, 2017
As a side note, Mueller made the point that Workday didn't make any real noise about verticals in the main keynote presentations and that's true. I sat virtually through all the ones in which I have interest. Aneel Bhusri, CEO said that attendees would hear more in the detailed sessions. I can certainly make a case for saying little about vertical market applications when you're trying to communicate a ton of other, more sexy and broadly appealing content.
I have not heard reports back that specifically cover my vertical markets point and I have to agree that Joe Korngiebel's reply is a tad vague, referring to core rather than verticals.
For and against Workday vertical markets - my take
However, at the risk of massively over reaching, there's six threads I'd like to pull together in asserting that Workday has a much better chance of fulfilling vertical market need at greater speed than competitors and without the spaghetti code to which Mueller is alluding:
- Customers I've spoken to in a variety of Workday verticals tell me they have gotten what they need. I have focused upon finance related customers but some have HR as well, all are using analytics. If Workday didn't have relevant capabilities then the verticals would not exist and I would have no customers with which to speak on industry specific topics.
- The speed at which Workday pushes substantial code enhancements is frighteningly quick. 319 on financial apps alone last year.
- The architecture is built primarily for configuration but opening up the Workday Platform for entirely new sidecar applications developed by design partners today and expected to go into general availability inside 6 months is again, evidence of a pace I don't see elsewhere.
- I'm not seeing any push back from customers about functionality for their industries.
- The fact Workday regularly refreshes the UI, normally a horribly difficult job in other applications, tells me that the architectural model Swete described, absolutely does support rapid change while preserving flexibility and all the other goodness of the Workday environment such as speed and shrinking downtime.
- In the main keynote, the company made reference to an inside joke that Workday is moving to Workday V2. That wasn't just a reference to the emphasis on Data as a Service or the dazzling analytics capabilities being rolled into the HR application.
However, I do have a couple of caveats.
- Mueller's point about a lack of focus on verticals in the keynotes may be a sign that Workday is not as advanced in its functionality as it would like or would wish to present on a main stage.
- Mueller's other point about complexity and the draw of horizontal application building may be correct but for me, it does not quite fit with what I have seen and what customers tell me. It is perfectly possible that because none of us have truly seen the Workday 'secret sauce' to which Swete carefully alludes, there are techniques in use that have yielded something for developers we don't see. The fact I've been told by ex-Workday developers that getting your head around Workday technology is not easy suggests a lot to me.