The Enterprise Cloud: A Unified Architecture Means Unified Experience

At Workday, we believe we are different by design. Building enterprise applications is not for the faint-hearted, and many of the things that make Workday different are rooted in the technical details of databases, in-memory computing, and metadata, none of which are easy to explain. The way a vendor builds an enterprise system, however, can have profound implications for the usability and flexibility of the products it delivers to customers. That’s why it is important to point out how the technical details of Workday result in a better experience for our customers. Many of these details can be grouped together under a single rubric: Unified.

So what exactly is “unified,” and is it different from an “integrated” system? In a word: absolutely. An integrated system is composed of multiple components that must be carefully fitted together to achieve the required functionality. This implies running many different servers and databases alongside some middleware that ties the whole thing together. A very basic yet classic example of this is an application suite that requires a separate “mobility” server in order to render those applications onto mobile devices.

At a deeper level, an ERP system implemented on-premise for an enterprise may have 20 to 30 separate servers and databases. It is typical for a human capital management module to run on a different set of servers from a financial management module. Apart from the fact that these systems tend to be very fragile—a small change to any one server can lead to strange errors—the more prosaic problem is their upkeep. Keeping 20 or 30 complex servers on the same patch version of different OSes and databases is a task involving a small army of IT professionals. This is the opposite of the current anti-fragile thinking.

Unified In-Memory
Workday’s approach was to design an enterprise cloud architecture specifically to allow applications and data to exist together as a unified whole. Internally, Workday is partitioned into many servers that perform individual tasks, but these all operate off a single, in-memory version of the entire application logic and data. Specifically, there is no separate on-disk representation of all Workday data structures. There are no SQL or other database data definitions in Workday. There is only a single, in-memory representation. Unifying our data structures and our business logic this way fundamentally impacts the flexibility of our system and delivers benefits to our customers that aren’t possible with traditional ERP.

In a traditional ERP system, when human capital management and financial management are separate modules sitting on top of different databases, there are separate definitions of data structures that are shared between the two modules. For example, something like a “worker” may be defined in a very different way inside the HCM module than inside the financial management module. This may sound trivial, but it has far reaching consequences. First, it introduces problems while trying to synchronize information between these two distinct data structures. This synchronization problem is not merely one of exchanging values between two disparate systems—those values also have different meanings in the two systems, resulting in a classic data-impendence mismatch. This problem is amplified when you add in a third system—say CRM—that needs to talk to both systems. How does this third system deal with two definitions of “worker”?

Beyond the issues of data integration, there is the whole hornets’ nest of data security. In classic enterprise applications, security is enforced at the database layer. Therefore, each database needs to enforce a consistent set of policies over very disparate data. Taking our worker example again: The HCM module will have one set of security policies for fields inside the HCM worker data structures that will be different from the security policies applied to the financial module’s worker data. Also, once data is extracted from these systems and imported into another database, yet another set of security policies is applied to that data!

It quickly becomes next to impossible to apply a consistent security model across disparate databases. This is a problem if end users expect each of the separate modules to generate reliable reports. These reports are, by definition, limited views of the data, thereby reducing the effectiveness of the systems. There is little chance of getting the right data to the right person at the right time.

This may all sound a little boring, but enterprise applications deal with a massive amount of very boring detail—detail that typically has a regulatory and statutory need to be accurate. When you scale up the issue of data integrity across large, complex systems, you quickly begin to understand why traditional enterprise applications are extraordinarily expensive to own. A typical enterprise application will have millions of columns spread across thousands of tables in multiple databases.

Let’s consider what happens when a large enterprise implements an integrated on-premise ERP system. As soon as the system goes fully live there is another nail-in-the-coffin problem with this integrated picture. What if changes need to be made? First, all the data structures are defined “on-disk.” Changing these disk-defined structures is very expensive. And once a change is made, every other application that was using those data structures must be changed, too. An integrated system is not just fragile—it is change phobic.

The Workday architecture allows for data structures to be defined in one place, so there is just one definition of a worker object. Furthermore, specific individual instances of a worker object are shared between the Workday HCM and financial modules. If a customer decides to change some aspect of the security policy in relation to any specific instance of a worker, then that change will take immediate effect for all users.

As this worker object only has an in-memory representation, it is also much easier to change. All those changes are instantly propagated to all the other application components that avail of it. By adopting this architecture, Workday has turned enterprise applications upside down. Instead of data and applications distributed over many databases, we have a unified whole. The unified nature of Workday reveals an architecture that is designed to be radically cheaper to support and specifically well-suited to supporting change.

Bridging the Divides
There is another major advantage to a unified, in-memory architecture: the ability to easily gain business insight from your enterprise application.

When ERP was first created over 30 years ago, the driving need was for a system that automated transactions (buy some materials, update a general ledger, hire an employee). Only later did the need come along to analyze that transactional data (How much material have we bought and from whom?). There was no way to bridge transitions, analytics, and actions within the system.

That need launched an entire market for software to provide business intelligence and on line analytical processing (OLAP) for mining information from a large amount of transactional data.

Workday specifically set out to unify these disparate worlds to deliver a whole new way of interacting with information. From the earliest days we spoke about “actionable insight”: The ability to take a “transactional” action based on some “analytic” insight.

This is an important—and carefully thought through—impact of having information described in-memory and not on disk. In the classic ERP world, transactional information is described in a particular on-disk representation that optimizes for high volumes of online transaction processing (OLTP). To run analytics on transactional data, it has to be extracted and batch uploaded into a different on-disk format, classically a star schema, so the right analytic questions can then be asked of that data (OLAP). This migration from transactional formats to analytical formats is the cause of many headaches, expense, and complexity. A good example of these problems is security: once you take the transactional data out of its database you lose all the security policies that were being applied to it by the transactional database. The analytical database now gets to apply a different set of security policies on the data, which inevitably means some loss of security fidelity.

With the Workday in-memory model, this picture is utterly transformed. On-disk representations are meaningless and both the transactional system and the analytical system operate on the same in-memory graph. Analytics operate on the live data, not a batch uploaded, out-of-date version. There is just one unified security model.

Furthermore, in Workday there is a whole closed-loop effect. When you run analytics on the data, you can then start a new transaction based on the analysis presented to you. This ability to take actionable insight is now contextual. You get the right set of choices—drilling down into more analytics, or starting new transactions, depending on what you are doing—based on coherent and live data. This unified core means that when using Workday Financial Management and Workday HCM, all the data is right there for gaining business insights and managing your financial performance and your human resources—both of which are closely linked, of course, as we’ve illustrated in this fun video.

Avoiding ‘Franken-soft’
We believe there are important technology issues at stake here, but it’s not just technology for technology’s sake. A unified architecture is important because it is the engine house of the thing our customers care about: the total product experience. Brian Sommer wrote a fantastic piece describing the Workday approach to acquisitions. In particular, we don’t want to replicate what others are doing in acquiring disparate products and creating ever more complexity for the customer to manage.

A unified customer experience, where all parts of the application are coherent and avail of all the capabilities of the underlying platform, is a very precious thing that needs to be lovingly curated. This is such a powerful concept that many enterprise vendors are trying to figure out how to do this for cloud-based systems. The problem for anyone trying to deliver this same user experience is that you have to start in the right place. (Architecture is Destiny, as the analyst Dana Gardner likes to say). If a vendor’s starting point is one or more distinct systems—several for transactions and one for analytics—then it just can’t deliver a unified experience. There is all the difference in the world between “integrated” and “unified”—or as we say in Ireland: You can’t get there from here. 🙂