Workday CTO Swete Corrects Larry Ellison, Talks New Software FrontiersWorkday CTO Swete Corrects Larry Ellison, Talks New Software Frontiers https://c-suitenetwork.com/wp-content/uploads/2017/08/workday-cto-swete-corrects-larry-ellison-talks-new-software-frontiers.jpg 800 800 C-Suite Network https://c-suitenetwork.com/wp-content/uploads/2017/08/workday-cto-swete-corrects-larry-ellison-talks-new-software-frontiers.jpg
Recently, I spoke with phone with Stan Swete, the chief technology officer of Workday (WDAY), the cloud computing company that competes with Oracle (ORCL) and other traditional enterprise software vendors.
The conversation was prompted by my having noticed a comment by Oracle’s founder, chairman, and CTO, Larry Ellison, back in September, during Oracle’s annual analyst day meeting, regarding Workday and its technology. I set out to ask Swete about Ellison’s remarks, and what ensued was a fascinating discussion of where software is headed.
Ellison, who is rather obsessed with defeating Workday, more so than he seems to care about defeating Salesforce.com (CRM), chided Workday back in September for what he said was their attempt to build their own database, as he put it:
They [Workday] decided not only were they going to build an HCM suite which they did, they are going to also build an ERP suite, much bigger job, 10 times bigger job, easily, but they are going to build their own database. Does everyone know that Workday built their own database? Are you kidding me? It sounds like you’re talking to the guys at SAP except you are a startup.
Is Workday building a database? I asked. In response, Swete told me he has gotten the question “quite a few times,” and he made clear that the company is not building a database.
In fact, Workday runs its cloud software on MySQL, an open-source database owned and managed by Oracle. “There’s a ton of things we did differently” in designing Workday’s software, he says, but building a database is not one of them.
“It is difficult to write your own reliable ACID transaction processing database, we agree with that,” he says, referring to the acronym for “atomicity, isolation, and durability,” features that come with a relational database management system like MySQL. “That’s what we get out of the database.”
He observed that “this conversation is a little ironic,” given Workday is a customer for Oracle’s MySQL.
Workday uses MySQL for so-called online transaction processing, or OLTP, engine, the bulk of all relational database work.
“We do use an RDBMS to store all customer data,” he says. “If someone’s saying we are not, they’re wrong. It’s all persisted in an RDMBS. We actually use MySQL.”
But, “We use that in a different way from any other vendor,” he continues.
“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 actually central to what we are doing. If you can simplify the architecture, you offer the hope of having applications that can be more dynamically maintained on a consistent basis for customers.”
There are so many benefits. Simplified use is one benefit. We’ve abstracted away the notion of what database we are using from applications developers. With Peoplesoft where I was for ten years is we embraced RDMBS and SQL. That was fantastically powerful in the 80s. We completely tied ourselves to that…