Can Software Help Employees Enjoy their Workday (more)? - Part 2

Part 1 of this blog series described the genesis and current state of affairs of Workday – a novel company that was founded in March 2005 and launched in November 2006 by two great IT minds and notable PeopleSoft alumni: Dave Duffield and Aneel Bhusri. For a few years now I've been listening to a slew of otherwise hard-to-please analysts and bloggers raving about this software company that has purportedly finally overcome the traditional shortcomings of enterprise resource planning (ERP) systems of the 1990s.

One of Workday’s earlier marketing slogans said that it was the first new business management solution to come to market “since the Web turned 2.0, Sarbanes met Oxley, and the world became flat.” In fact, Workday is a younger company than Facebook. The vendor says that its biggest distinguishing factor over traditional ERP platforms is its inherent flexibility, most notably its ability to logically reorganize personnel in a global organization on the fly as required.

Although the integration of finance and accounting modules with human resource (HR) and talent management tools is an important benefit of comprehensive ERP systems, increasingly companies must be able to decouple dynamic people from more static financial organizational constructs when necessary. This is especially true as employees perform in the  increasingly dynamic and flux environments of virtual teams and shared resources that make up workplaces today.

Three-legged Stool of Workday’s Differentiation

In summary, compelling user experience, unified global human capital management (HCM) functional capabilities, and modern flexible architecture are the three key tenets of Workday’s success thus far. Needless to say, these three key factors are highly interdependent, and no one of them would be as effective without the help of the other two.

As a user experience, Workday offers rich user interface (UI) technologies for the Web browser, including Ajax and Adobe Flex, which allow the vendor to provide a more interactive experience while still running in the browser. Workday employs these technologies in a way that yields not only interactivity, but also consistency in the “look and feel” by having the system generate the UI.

This approach should also give the vendor the ability to react relatively quickly to new UI customs and technologies as they emerge. In fact, Flex’ slower performance might become an issue once Workday reaches thousands of customers (à la, Taleo, and SuccessFactors), but Workday is not overly fretting over the replacement of the UI layer if and when the time comes

In terms of functional capabilities, in her multiple In Full Bloom blog posts, Naomi Bloom, an HCM authority, talks about Workday’s integrated strategic talent management and administrative HR (global from the start), embedded actionable analytics, graphical dynamic organizational changes, systemic effective-dating and retroactive processing, and many more mission-critical features. The final piece (leg of the three legged Workday stool) is the object-oriented, model-driven architecture (MDA) that has definitional services at its core (as mentioned in Part 1).

Codeless Programing: Utopia or Nirvana?

While model-driven development is certainly architectural, getting those models right is not easy. Workday thus uses objects in two entirely different ways to provide solutions that are contiguous and work the way modern global companies really operate. First, it has modeled the entire functional domain in objects and their attributes in metadata, which introduces a major leap forward in the understanding of the complex realm of HCM.

Second, Workday delivers these objects as mini-applications without writing code per se, because it is able to execute objects at runtime as though they were written in code. Workday was able to accomplish this by first creating a class diagram where its developers can model the relationships with other object classes. One can enhance the definition of classes by defining attributes, relationships, and methods.

The key differentiator is the definitional creation of objects, attributes, relationships, and methods, which is the application logic in itself. In this way, all of the processing steps get defined down to the lowest level. The end result is that Workday has ended up with about 20,000 method definitions to perform the create, read, update, delete (CRUD) database processing it needs to do in its HCM application and in its tools.  That is one to two million metadata objects without a line of code. Compare that to the hundreds of thousands if not millions of lines of “spaghetti” code talking to thousand of tables one typically finds in any other enterprise application with the client/server heritage.

What’s Wrong with Relational Databases, SQL, and 4GL?

Why has Workday decided to go the object-oriented database (which are much less popular commercially) and metadata route? Basically, object-oriented databases get rid of constraints that on-disk (hence slow), fourth-generation programming language (4GL) and structured query language (SQL)-based relational databases impose; constraints that show up in any and all application systems written between 1990 and 2002 (or so). At the core of Workday’s technologies is an object-oriented approach (and a proprietary database) that severs the dependence on SQL relational database tables that are at the heart of much of the brittleness of current ERP software.

As Phil Wainewright eloquently describes in his 2007 ZDNet blog post, at the time of relational database’s novelty, this was a breathtakingly elegant and powerful way to map a business’s data. Yet he couldn’t help wondering what would happen if some business need came along that required a table you hadn’t defined into the original SQL database structure.

He noted that in ERP environments, "there are certain super-entities, such as 'account', 'department', (and) 'region' that are the master-definitions that every other entity has to be defined in relation to. Those choices, once made, cannot be undone; they can only be worked around. While it's true that there are some highly sophisticated workarounds available these days, each one that's added brings further complexity to the system."

These constraints of relational databases are really only visible to people that have worked with the systems and understand what one has had to do to get around them for global workforce management. But there are some issues that are (at least) kind of visible. In object oriented database, you simply don't need to have multiple tables, each with data that is normalized, such as people tables and address tables.

Namely, constructing a “people plus address” report or screen traditionally requires running down one relational database table for the person, using the person's identifier to run down the other table to find that person's address, then pulling both out of the database.  This is how all 4GL relational databases work, and it is cumbersome. You get performance that you couldn't otherwise get, but at a very high cost in accessibility of anything meaningful.

In contrast, object-oriented databases require no prioritized ways of organizing data, as in a 4GL/SQL database. So, for instance, if you want to organize people by geography in a relational database, you have to create an index field that identifies their geography (otherwise, it is too slow), and that index field makes it a prioritized form of organization.

This makes it very difficult to change the record, particularly, if the notion of geography changes for some reason. So, for instance, if a person is hired in the US but working in England, is he/she in the US geography or the UK/Europe geography? There is no right answer, so what one may need to have is two different geography indexes, locations, and wages, or something similarly complicated and non-elegant.

In-Memory Helping Object Databases’s Slowness

In contrast, Workday’s developers do not think about relational data modeling, object-to-relational mapping, or any kind of SQL access when they design and build applications. They do not map the data to a relational database and its fixed database structure. Being unconstrained by the relational data model enables Workday to truly encapsulate both the business logic and the data, and take full advantage of all of the capabilities of the object-oriented design. To be accurate, Workday technically does not use an object-oriented database per se but rather the approach. It does a lot of database-like actions to its objects such as to group them into collections and index them.  But it doesn’t expose a generic query language to its objects or a general way to group them.

The SQL database in a traditional business management application defines the meaning of data into a tabular structure, and that is its achilles’ heel in terms of future changes. Conversely, Workday’s database tables reflect the needs of the object-oriented application architecture--there are just several tables such as ‘instances’, attributes’, ‘references’, etc. The data and definitions stored in the tables are instantiated only when the application runs. In other words, the database has a relatively straightforward structure (i.e. closer to ten tables than the thousands you’d find in traditional ERP databases) that is designed to efficiently store data, meta-data, and the relationships behind the application object model.

In other words, all parts of the application are defined as metadata, which is interpreted by Workday’s Object Management Server (OMS) at runtime. The definitions are therefore as easy to change as the data. When the Workday application runs, it scoops up all of the data and definitions stored in that three-table database, and turns them into meaningful data that can be accessed and manipulated. Changing the business logic, even at a very fundamental level, is simply a matter of changing a few definitions and re-running the application.

Because of this capability, Workday does not even utilize, to Brian Sommer’s understanding in his ZDNet blog post, subledgers for general ledger (G/L) in its in-core database. The vendor keeps source transactions in memory and can sort, parse, and restate the data in almost infinite combinations without any real effort. Moving relational database content to solid state memory without eliminating redundancies is not only inefficient but it cuts down on how easily data can be re-stated into different views (for example, creating a daily set of books out of monthly sub-ledger data can be hard unless the software goes all the way back to source transaction data and picks up adjustments made to all other subsystems along the way.)

Workday’s favorite demonstration of its flexibility is showing how it is possible to reorganize the structure of a global business on the fly, without re-coding. In fact, Workday’s application developers never write code. They simply work with the 40 or so object types that have been built into the application, then define and instantiate them as required.

What this means is that the application works much better than comparable products. It is easier to find data, easier to navigate, easier to use, easier to enter data, easier to change data, and so on and so forth. Having the geographic characteristics built in from the start means that it is actually possible to have a single, global database of employees, which basically is not available in any of the other systems (though possibly in the novel Oracle Fusion HCM product).

Some examples are that the system is smart enough to detect that an ex-employee in this office, that role, and that region has just been re-employed (after several years) in another office, etc. Even better, how about handling a project in India, where a US-based employee is temporarily assigned? He/she gets paid in India and is temporarily covered by Indian health care, but his/her family in the US is still getting the US benefits. Trying to resolve these workforce issues is still a major nightmare for many global companies.

Different In-memory Approaches

Obviously, an object-oriented database organizes information in a way that is different from the way 4GL/SQL databases organize information. The benefit of an object-oriented database is the data persistence layer where knowledgeable developers can change and add whatever they want, but the original relationships between objects remain intact (see figure 1).

Object-oriented databases have been around for a long time, but previously they couldn't be used for commercial systems because they were dog-slow. But with in-memory capabilities, though, it becomes possible to use one. To be fair, the aforementioned OMS is a Java kernel that runs as an Apache Tomcat process, entirely in-memory.  OMS interprets Workday application objects to create the transactions and reporting behind applications. Workday also uses a relational database technology but predominately as a backup storage media.


Figure 1

But, contrary to SAP HANA or Oracle Exadata, where in-memory technology is used to crunch up data quickly against static reports and analytics, Workday object oriented model and in-memory database (IMDB) drive embedded analytics against process flows. Workday uses its IMDB to support its aforementioned "models are the application" secret sauce and for all data management. These are really different architectures, purposes, and implications for vendor and customers.

For its part, has a basically equivalent IMDB, which it has built with the TimesTen technology by Oracle, and runs on top of/in front of a relational Oracle database. But has exploited the in-memory capability in a completely different way than Workday, so to the average user/administrator, it just looks like an ordinary 4GL relational database (but one that has really fast access times and is enormously scalable).

The actual data persists in a traditional relational/4GL database at both and Workday, but what storage database it is almost irrelevant. At both companies, the runtime databases have only a few tables rather than the tens of thousands that would be required if their applications were actually running on a relational database.

Embedded Analytics and Security

In Workday suite, online reporting and in-line analytics are built right into the system and can be accessed from the main UI on-the-fly (like drill-down and drill-around capabilities on steroids of a sort). The so-called "Speed of Thought Navigation" allows users to be more productive and focused. The system also has a readily accessible and user-friendly audit trail mechanism where authorized users can see all of the changes to records of an employee over time.

These features will be important to the business managers who want to drill down into histories and details on employee status. For example, from a manager's “My Team Page” a manager can see all the specific information related to his/her team. Moreover, there is an actionable organization chart that allows managers to take action on any person in his/her organization, while actionable reporting allows managers to run reports from anywhere.

Last but not least, because everything is managed by OMS, Workday has a single approach to security. The vendor can secure all communications and encrypt the database since it is never accessed directly from outside the OMS (i.e., there are no opportunities for harmful SQL injections). Workday also provides nondestructive updates, which allow authorized users to see who has changed what and when.

The final part of this series will discuss who should be a good fit for Workday and who might not, and why. In the meantime, your comments, thoughts, suggestions or individual experiences with global talent management in general, and Workday in particular, are more than welcome.
comments powered by Disqus