Chapter 2 - Workday Architecture MB

The Workday Architecture

Live Pages

Workday Cloud Platform

Data-as-a-Service

Prism Analytics

Financial Performance Management

Student Suite

Planning

Learning

Payroll France

Student Admissions

Inventory

Projects

Payroll U.K.

Student Recruiting

Recruiting

Financial Management

Human Capital Management

Big Data Analytics

Payroll Canada

Cloud Connect 3rd Party Payroll

Time Tracking

Payroll U.S.

Expenses & Procurement

Compensation

Absence

Dependence

Benefit

Payroll

Single Platform

Continuously Evolving

Object Relationship Mapping

Allowance

Worker

Stocks

Equity

Video Placeholder

All of these parts of the object model (classes, relationships, attributes, and methods) are created through a forms-based interface. The resulting application is a collection of metadata definitions for each part of the application object model. These definitions are stored as collections of simple Java objects in the memory of the Java virtual machine (JVM) that is the runtime environment for all Workday applications. The Java runtime interprets the metadata definitions into the transactions (tasks and reports) that make up the application. Different services in the Workday architecture and platform collaborate to interpret the application metadata that XpressO creates when it processes application transactions and manual or automated requests. By clearly separating how applications are defined from its deployment platform details, new applications can be brought online quickly, without disrupting existing customer business logic, as Workday has demonstrated since the early days. We’ve continually delivered new applications while improving existing ones.

Tap to enlarge

Workday believes that continuously enhanced in-memory data management is the path to continuous scale for our applications. It is no longer a problem to be solely addressed by databases on disk, serving data to applications via SQL. Our in-memory data services are an essential part of a highly optimized multilevel caching approach to managing application data. More on that later, as well as a deeper dive into how the different services of our architecture work together. For now, let's turn to security and how it is embedded into everything we do.

Another fundamental difference in the way Workday is designed is how we work with data. In traditional ERP systems, the transactional data is stored in a relational database. If a user wants to perform analysis on that data, it must first be extracted from the database, copied to another system, and then formatted for analysis. Doing so results in analysis based on stale data, as it leads to multiple sets of data in disparate systems. That’s because the transactional system is continuing to receive updates not reflected in the copy of the data being used for analysis. Unlike traditional enterprise applications, we designed transaction processing and reporting in Workday to be real time so the system could work at the speed of thought. To accomplish this, we put the application data in memory, in the same area in which the applications were running. This gives us instantaneous access to application data and enables us to have transactions and analyses operating off the same data in the same place. So, if you’re performing analysis on data in Workday, you’re doing so off live, transactional data. And because we store data using an object model that features a rich network of relationships between classes, Workday reports can offer multidimensional analysis along with data presentation. As transactions are approved, the results are immediately reflected in all analysis and reporting. Specifically, let's look at a P&L (Profit and Loss) statement where you have revenue and expenses. If you drill into a revenue balance, Workday retrieves all transactions associated with that balance into memory. Here you're able to analyze by customer, product, location, division, project, campaign—and the list goes on.

Having the application logic defined as metadata enables us to evolve our applications and underlying technology independent of each other. We can add technology services to the platform that become immediately available to all applications. Conversely, we can add new applications to the Workday portfolio without having to rewrite or change the underlying technology services. How the Workday services model has evolved toward microservices over the years is a good example of how our metadata-driven model benefits customers. In the beginning, the supporting Workday architecture was a single monolithic architecture with a small number of services for processing UI requests and transactions. As demand for our services increased, we needed to evolve the underlying architecture to continue to deliver the performance and scale needed by our customers. Because we had abstracted the technology platform from the applications, we were able to refactor individual services and adopt new technologies without disrupting our customers. For example, by splitting up our transactional service into a read service and an update service, we were able to optimize the services to the type of request it was processing. This enabled us to move beyond the monolithic design to a services-based design, where additional services were introduced to optimize usage. As demand increased, we evolved the architecture further to be based on many loosely coupled distributed services, or microservices, that we have today.

The metadata object model is used to describe the structure and behavior of Workday applications. Here is where XpressO comes into play. There is no code-based procedural logic in a Workday application. Instead, Workday developers define the structure of an application by defining classes for the key business objects in the application. Classes can have relationships to other classes, attributes, and methods. Methods define the behavior of the application, and the business logic is defined by declarative relationships without the need to write any procedural code.

The Workday foundation is built on Java, but we created a metadata abstraction layer to simplify development—a language we call “XpressO.” What this means is that we define the functionality of our applications—forms, required fields, workflow actions, and so on—as metadata stored in our database rather than as programming code. This allows application developers to insulate themselves from deployment-specific details, such as persistence, transactions, scalability, and data center locations. Instead, they can focus on the functional aspects of the applications and the user experience.

The Workday mission is to continually place people at the center of the enterprise, which we make happen by delivering a superior enterprise application experience. When designing our original architecture, we had to ensure the architecture was flexible enough to accommodate technology changes, the growth of our customer base, and regulatory changes—without disrupting our customers. We had to make sure our customers continued to have a superior experience with Workday in the face of continuous change and evolving business requirements. To accomplish this, we had to keep the different layers of our architecture insulated from each other, so that a change at one layer would not require a change at another layer. Let’s take a look at what that means.

In-Memory Computing

What Metadata Means to Development

The Core of the Workday Architecture