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.

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.

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.

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

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

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

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?

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!

[…] 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 […]