August 22, 2010
The Workday architecture — a new kind of OLTP software stack
One of my coolest company visits in some time was to SaaS (Software as a Service) vendor Workday, Inc., earlier this month. Reasons included:
- Workday has forward-thinking ideas about SaaS enterprise applications and the integration of business intelligence into same.
- Workday has highly innovative ideas in how it manages data.
- Companies founded by Dave Duffield tend to feature smart, likeable people who talk to one pleasantly and forthrightly. Workday is no exception; CTO Stan Swete and the other Workday folks present were a delight to talk with.
- I’d invited Merv Adrian to come along with me. He asked great questions, and I could gather myself a bit despite how sleep-deprived I was for the first part of that trip.
Workday kindly allowed me to post this Workday slide deck. Otherwise, I’ve split out a quick Workday, Inc. company overview into a separate post.
The biggie for me was the data and object management part. Specifically:
- Workday’s applications run entirely in-memory, in a highly object-oriented structure. Persistence is mainly for the sake of data safety …
- … but not entirely. In earlier releases, Workday kept absolutely everything in RAM. However, certain things are kept only on disk, such as:
- Audit files.
- Certain documents (notably resumes).
- Workday’s whole database – data and metadata alike – is persisted to disk in <10 MySQL/InnoDB tables. MySQL is basically just being used as a key-value store, albeit one with ACID transactional support.
- There are 3 main tables: attributes, relationships, instances.
- When I suggested this might be like an entity-attribute-value model, Workday said it would be even better to think in terms of instanceID-attribute-value.
- As you might expect for a database that simple, its schema doesn’t change much.
- By way of comparison, Workday estimates that if its software were written relationally, there would be 1000s of tables, which would take up 10-100X as much disk space.
- All write transactions are banged immediately into the MySQL database. I.e., RAM and disk are never allowed to get out of sync.
- Workday’s database is append-only. This is exploited for effective dating (pretty heavily, it seems, perhaps because that’s a useful concept in human resources) and snapshotted reporting.
- Workday’s built-in BI doesn’t have a lot of choice but to do scans, traversing the object model. This turns out to be fast enough.
Other notes on Workday’s data and object management strategy include:
- Workday is object-oriented through and through – no object-relational mapping — turtles all the way down. On average, a class has about 2 attributes.
- 94% of requests are reads, traversing the object hierarchy.
- Workday databases are pretty small.
- The biggest database Workday supports uses 17 gigabytes of RAM.
- Workday databases are much smaller on disk than in RAM.
- Workday’s “dream” is to move from disk to solid-state memory.
- Workday uses GPLed MySQL/InnoDB. So there’s no software license reason to ever move away (e.g., to a pure key-value store).
- Disaster recovery is based on local and remote MySQL slaves.
Obviously, serious apps have been built before in object-oriented and/or key-value ways, with the resulting objects then being banged to disk (or in some cases kept in memory). Examples include:
- Numerous applications are built on object-oriented DBMS. Generally they go against disk, although memory-centric implementations can save a lot of pointer-chasing. Often they’re queried via SQL.
- Basho’s website says that its key-value store Riak was originally conceived in connection with a planned salesforce automation product, but I don’t think that the application part of that plan ever got built.
- SAP has longstanding doubts about relational dogma, although not nearly to Workday’s extreme.
- Obviously, some major internet applications just bang data into key-value stores.
Still, perhaps because it’s wholly object-oriented yet doesn’t even bother with anything like a real object-oriented DBMS, Workday’s approach seems particularly cool.
Other highlights of Workday, Inc.’s technical story include:
- Workday has settled into a schedule of three releases per year, and has pretty much lived up to that for >2 years.
- Every user is always on the latest Workday release.
- You can delay turning on significant new Workday software functionality if you want to.
- Pure UI changes to the Workday software are handled much as they are on various websites today. Sometimes you have no choice but to live with them; sometimes the prior version of the UI remains available to you for a while.
- Workday’s navigational approaches look pretty cool.
- The core concept is a list of actions you can perform now, rather than more standard menus.
- Roles/permissions are of course central to this.
- Reports have lots of actionable links in them. (More than just drilldown, although specific examples have slipped my memory.)
- Alternatively, you can navigate via a search box, searching both on names of objects (e.g. users, divisions) or on names of tasks. This is somewhat reminiscent of an approach SAP was considering a few years ago.
- Workday says it has four key design premises:
- Web-Familiar Experience. I’d say that’s true to to the extent it makes sense. In many ways, the web needs to catch up to Workday.
- Enterprise Reporting. The idea is that you get a report, then take actions based on it. Hence the report-centric options for navigation.
- Integration On-Demand. That’s a fancy way of saying “Plays nicely with others.”
- Configurable Business Processes. Duh. That’s pretty essential if you want to do serious SaaS applications.
- Workday maintains a strong separation between application logic and UI development. Developer do no screen layouts. Instead, Uis are automatically generated for:
- Flash/FLEX
- iPhone
- Mobile HTML
- PDF export
- Excel export
- Workday only talks to the outside world via web services.
- Workday is heavily into SOAP (Simple Object Access Protocol).
- The acquisition of OEM partner CapeClear gave Workday an Integration Service (i.e., enterprise service bus) that translates SOAP into whatever else might be needed for integration, and also does reliable delivery.
- All that said, Stan Swete sees integration among various SaaS offerings as an area needing significant future attention.
- Workday’s business intelligence ideas are interesting, but I think there’s a long way for that technology still to go.
- Workday’s BI seems to be focused on report/drilldown kinds of functionality.
- You can slice by up to 2 dimensions at once.
- Then you can keep slicing, however, by more dimensions, as many times as you like.
- While you can take actions straight from reports, some of the specific BI/app integration ideas we discussed are still futures. (E.g., analyzing spend at the time of expense report data entry or approval.)
- Of course, Workday’s web services interface lets you export Workday data into 3rd-party tools. Indeed, if you want to integrate data from Workday and some other source(s), that’s your only choice.
- Workday’s BI seems to be focused on report/drilldown kinds of functionality.
- Workday offers a clever metaphor to illustrate that your data may be more secure offsite than on – the bank vault. (I have no idea whether that’s a SaaS industry standard, but I hadn’t heard it before.) Of course, that metaphor does beg some issues specific to the remote data case, such as:
- When your data is on premises, you know whether the government has insisted on looking at it.
- More than cash, data keeps traveling back and forth to the remote location, which creates at least a theoretical risk of interception.
- Workday says the toughest part of globalization is the issue of which personal data is or is not maintained. For example, in the US you’re not allowed to not ask a job applicant’s religion, but in the UK you’re not only permitted but indeed required to.
This post is part of a three-post series
- Workday Inc. company overview (brief)
- Workday Inc. technology overview (detailed)
- Workday Inc. CTO Stan Swete’s comments on database strategy
Categories: Business intelligence, Data integration and middleware, Data models and architecture, EAI, EII, ETL, ELT, ETLT, NoSQL, Object, OLTP, Software as a Service (SaaS), Specific users, Theory and architecture, Workday
Subscribe to our complete feed!
Comments
13 Responses to “The Workday architecture — a new kind of OLTP software stack”
Leave a Reply
[…] my discussion of Workday’s technology, I gave an estimate that Workday’s database, if relationally designed, would require […]
[…] main post on Workday’s technology got really long, so I decided to split out a company backgrounder separately. Here […]
[…] I couldn’t make this important session to my regret, but I’ve tried to capture as much as possible of the twitterstream via RTs. Below is my twitterstream from this period, read as you know from the bottom up to get chron order. Following that are two sources (thus far) of the total twitterstream as captured by colleagues who were there using tools with which I’m not familiar. And I’m sure there will be a deluge of blog posts/analyst reports/etc. coming very soon. Already posted are Dennis Howlett, Brian Sommer, Mipro. A good backgrounder on Workday’s technology stack, written before the Summit is here. […]
Curt,
Sorry for posting late – I was just wondering about the distinction between the Entity-Attribute-Value vs InstanceID-Attribute-Value model as mentioned by Workday.
To me this sounds like this is actually a solution to implement a graph store inside MySQL, where the InstanceID is a node, and attributes are properties of the node, where some attributes represent relationships to other nodes, that is to say, edges. Is this correct?
Thanks in advance, and kind regard –
Roland.
Sorry, Roland. I was being a bit sloppy.
Anyhow, I’m going to duck the meat of your question, because I don’t find it particularly intuitive to call generic object models graphs, even when it’s theoretically very defensible.
The slide deck
http://www.monash.com/uploads/Workday-August-2010.ppt
seems to be corrupted. Is there a good version that you can put up?
Thanks!
The slide deck link is looking good to me. Please try again and let me know how it goes.
[…] guessing this isn’t an H-Store/VoltDB architecture, but rather something more like what Workday […]
Curt – I appear to have the same problem with the Powerpoint deck. Powerpoint asks me to repair it. Is there anyway to save it online, or another way to download it?
I just saved it, made some invisible edits, and re-uploaded it. If problems persist, please start noting what browser you’re using, whether you’re opening it as an Office 2003/compatibility mode file (correct) or trying to pretend it’s a .pptx (which it isn’t), and anything else you think might be helpful. Thanks!
[…] (Software as a Service) companies — such as Workday — often bring a particular tenant’s database entirely into […]
[…] feel abotu your old nemesis Dave Duffield? He is building something pretty exciting at Workday. As Monash also said, their applications run entirely in-memory in object oriented structures. Their interface […]
[…] feel about your old nemesis Dave Duffield? He is building something pretty exciting at Workday. As Monash also said, their applications run entirely in-memory in object oriented structures. Their interface […]