Next
Workday Grants
Workday Expenses & Procurement
Workday Cloud Connect for
Third-Party Payroll
Workday
Recruiting
Workday
Financial
Management
Time Tracking
Payroll U.S.
Compensation
Cost center
Dependence
Benefits
Payroll
Single
Platform
Continuously Evolving
Object Relationship Mapping
Allowance
Worker
Stocks
Equity
Video Placeholder
Click 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.
Another fundamental principle behind Workday is how we work with data for transactions and analysis. 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, loaded into 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, analysis, and reporting in Workday to be in 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.
Let’s look at an income 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 a number of dimensions—customer, product, location, division, project, campaign—and the list goes on.
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 that brought greater scalability without disruption.
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 the many loosely coupled distributed services, or microservices, that we have today.
This, again, validates our approach to adaptability: not only is the Workday architecture promising on paper, but it has also been tested and proven through many deployments and iterations.
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 Java virtual machine (JVM) memory 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 technology 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.
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. And methods define the behavior of the application, while the business logic is defined by declarative relationships without the need to write any procedural code.
The Workday foundation is built around the concept of metadata. We created a metadata abstraction layer to simplify development—a language we call XpressO. This means that we define the functionality of our applications—forms, required fields, workflow actions, and so on—as metadata stored in our in-memory database rather than as programming code. This allows application developers to insulate themselves from deployment-specific details, such as persistence, scalability, and our public cloud locations. Instead, they can focus on the functional aspects of the applications and the user experience.
We are on a mission to continually place people at the center of the enterprise, so when we designed our architecture originally, we ensured it was flexible enough to accommodate the constantly changing world of technology, 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 rapidly evolving business requirements.
To accomplish this, we kept the different layers of our architecture insulated from each other so
a change in one layer would not require a change in another. Let’s take a look at what that means.
In-memory computing.
What metadata means to development.
The core of the Workday architecture.
The Workday architecture.
The Core of the Workday Architecture
What Metadata Means to Development
In-Memory Computing
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.
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 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.
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.
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.
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.
Tap to enlarge
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.
Equity
Stocks
Worker
Allowance
Object Relationship Mapping
Continuously Evolving
Single
Platform
Payroll
Benefit
Dependence
Absence
Compensation
1
21
Expenses & Procurement
Payroll U.S.
Time Tracking
Cloud Connect
3rd Party Payroll
Payroll Canada
Big Data
Analytics
Human Capital
Management
Financial
Management
Next
22
23
24
25
26
Recruiting
Student
Recruiting
Payroll U.K.
Projects
Inventory
Student Admissions
Payroll France
Next
PREVIOUS
27
28
29
30
31
Learning
Planning
Student Suite
Financial Performance Management
Prism Analytics
Data-as-a-Service
Workday Cloud Platform
Live Pages
PREVIOUS
The Workday Architecture
22
23
Recruiting
Student
Recruiting
Next
PREVIOUS
Workday Cloud Platform
Live Pages
Recruiting
Student
Recruiting
The Core of the Workday Architecture
What Metadata Means to Development
In-Memory Computing
We are on a mission to continually place people at the center of the enterprise and enable them to succeed in a changing world by delivering a superior enterprise application experience. When designing our original architecture, we had to ensure it was flexible enough to accommodate the constantly changing world of technology, 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 rapidly evolving business requirements. To accomplish this, we had to keep the different layers of our architecture insulated from each other so that a change in one layer would not require a change in another layer. Let’s take a look at what that means.
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 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. And methods define the behavior of the application, while the business logic is defined by declarative relationships without the need to write any procedural code.
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.
Another fundamental difference in the way Workday is designed is how we work with data for transactions and analysis. 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 an income 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 a number of dimensions—customer, product, location, division, project, campaign—and the list goes on.
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 deep-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.
Tap to enlarge
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 technology 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.
Equity
Stocks
Worker
Allowance
Object Relationship Mapping
Continuously Evolving
Single
Platform
Payroll
Benefit
Dependence
Absence
Compensation
1
21
Expenses & Procurement
Payroll U.S.
Time Tracking
Cloud Connect
3rd Party Payroll
Payroll Canada
Big Data
Analytics
Human Capital
Management
Financial
Management
Next
22
23
24
25
26
Recruiting
Student
Recruiting
Payroll U.K.
Projects
Inventory
Student Admissions
Payroll France
Next
PREVIOUS
27
28
29
30
31
Learning
Planning
Student Suite
Financial Performance Management
Prism Analytics
Data-as-a-Service
Workday Cloud Platform
Live Pages
Workday Cloud Platform
Skills Cloud
PREVIOUS
Next
32
33
Extended Enterprise
Workday
for Slack
Worksheets
Org Studio
PREVIOUS
The Workday Architecture
Workday
Human Capital Management
Meta Data
In Memory
Microservices
Integration Cloud
iPhone
Android
HDFS
Payroll Canada
Workday
Workday
Payroll UK
Workday Student Recruiting
2006 - 2013
2014
Workday Student Admissions
Workday Prism Analytics
Workday
Inventory
Worday
Connect
Workday
Learning
Workday
Data-as-a-Service
Workday
Skills Cloud
Workday
Worksheets
Workday
Content Cloud
Workday Payroll
France
Workday Connect
2015
2016
Machine Learning
Natural Language Processing
Analytics
Next
PREVIOUS
Workday Student Suite
Workday Extended Enterprise
2017
2018
Org Studio
Workday People Analytics
Workday for Slack
Credentials
Workday Assistant
Workday for
Microsoft Teams
Workday
Help
Workday
Accounting Center
Workday Extend
Workday Talent Optimization
2019
Blockchain
People Experience
Spend
Next
PREVIOUS
Workday
Journeys
2020
Workday Orchestrate
Workday
Success Plans 2.0
Workday Success Plans
Workday
Messaging
Workday
Scheduling
Workday Extend App Builder
Workday Candidate
Engagement
Packaged Solutions
2021
2022
Blockchain
People Experience
Spend
Next
PREVIOUS
2023
Packaged Solutions
Packaged Solutions
8
33
11
33
8
Workday Planning
Workday Prism Analytics
Workday Credentials
Workday
Projects
Workday Payroll Canada
Workday
Time Tracking
Workday Payroll U.S.