At Workday, a large part of my time is spent explaining how we are different by design. There is a long list of points we make to describe our different approach, but at the core the main difference between Workday and traditional enterprise applications is how we’ve made the object model the core of our architecture.
Having the application structure defined as metadata means the structure of Workday applications can be changed without having to restructure the database. Having application logic defined as metadata means that logic can be changed without coding or recompiling code. Not using the database to represent the structure of our applications dramatically reduces the number of tables needed to support them.
While the “how” part of the story is interesting, I’d like to focus more on the “why” questions behind our architecture. Why take a different approach, and why does it matter? The answer involves four critical areas for both Workday and our customers: speed, security, insight, and change.
When you think of what’s traditionally known as enterprise resource-planning systems (ERP), speed is probably not the first thought that comes to mind. But when you’re a startup that has decided to compete against large ERP software vendors, you do think about the need to move quickly. We launched Workday in 2005 using the object model, allowing us to significantly speed application development. To this day, developers can rapidly change Workday applications without having to worry about altering the underlying database, or performing any database administration operations as they build new features and products.
This is how we are able to provide customers with three Workday updates per year instead of the industry standard of 1½ years or longer for traditional software upgrades. We can quickly respond to new customer requirements, and the shorter development cycle lets customers more easily engage as design partners. (Waiting 1½ years or more to see your idea make it into production can put off even the most enthusiastic customer, and with Workday the payoff can happen within four months.)
Get practical knowledge on Workday from real-time experts at Workday Online Training
At Workday, a large part of my time is spent explaining how we are different by design. There is a long list of points we make to describe our different approach, but at the core the main difference between Workday’s cloud applications and traditional enterprise applications is how we’ve made the object model the core of our architecture.
We use the object model to define both the structure of our applications (classes, relationships, and attributes) as well as the logic of our applications (methods). All parts of the object model are defined as metadata. Instead of the thousands of relational tables and millions of lines of code used to define traditional enterprise software, Workday applications consist of millions of metadata definitions. Workday uses a relational database to store all metadata and all application data. To optimize application performance, Workday keeps all application metadata and most application data in memory.
At Workday, a large part of my time is spent explaining how we are different by design. There is a long list of points we make to describe our different approach, but at the core the main difference between Workday’s cloud applications and traditional enterprise applications is how we’ve made the object model the core of our architecture.
We use the object model to define both the structure of our applications (classes, relationships, and attributes) as well as the logic of our applications (methods). All parts of the object model are defined as metadata. Instead of the thousands of relational tables and millions of lines of code used to define traditional enterprise software, Workday applications consist of millions of metadata definitions. Workday uses a relational database to store all metadata and all application data. To optimize application performance, Workday keeps all application metadata and most application data in memory.
Having the application structure defined as metadata means the structure of Workday applications can be changed without having to restructure the database. Having application logic defined as metadata means that logic can be changed without coding or recompiling code. Not using the database to represent the structure of our applications dramatically reduces the number of tables needed to support them.
While the “how” part of the story is interesting, I’d like to focus more on the “why” questions behind our architecture. Why take a different approach, and why does it matter? The answer involves four critical areas for both Workday and our customers: speed, security, insight, and change.
Speed
When you think of what’s traditionally known as enterprise resource-planning systems (ERP), speed is probably not the first thought that comes to mind. But when you’re a startup that has decided to compete against large ERP software vendors, you do think about the need to move quickly. We launched Workday in 2005 using the object model, allowing us to significantly speed application development. To this day, developers can rapidly change Workday applications without having to worry about altering the underlying database, or performing any database administration operations as they build new features and products.This is how we are able to provide customers with three Workday updates per year instead of the industry standard of 1½ years or longer for traditional software upgrades. We can quickly respond to new customer requirements, and the shorter development cycle lets customers more easily engage as design partners. (Waiting 1½ years or more to see your idea make it into production can put off even the most enthusiastic customer, and with Workday the payoff can happen within four months.)
Get the best tips to increase the organizational speed at Workday HCM Online Training
This is a huge improvement to overall security in the enterprise space. Limiting the point of access to data to only the application server is not true of any on-premise ERP implementation, and likely not true for hosted enterprise application implementations, even if the vendors offering those implementations call them “SaaS.”
When running an analytics report, our system uses relationships to the primary object in the report (such as “worker”) to gather all data related to that object. The equivalent for a traditional ERP system would be to join all data across all tables relating to “worker” and send the results to the application server’s memory. Workday doesn’t have to do the joins and the data is already in memory. This allows Workday to quickly present the requested report and for customers to rapidly drill down on select dimensions of it.
For example, a Workday customer could run a report that shows not only information about all of its workers in R&D, but also how many of its senior developers work in San Francisco. This type of analysis can only happen in traditional applications when the data has been “pre-joined” and loaded into a separate reporting system. While that’s a common approach for business intelligence, it adds cost and complexity to reporting. Security has to be implemented for the separate system, and data loaded into it may be out of date by the time it’s viewed. Since our reports run on the same object structure where transactions are executed, we avoid the issues of separate reporting systems.
Maybe the most important driver for our different approach is the ability to build applications that are open to change. Even after 30 years, the requirements for enterprise software continue to rapidly change. Vendors must still deliver against longstanding requirements such as reliable transaction processing, scalable batch processing, and high volume data import, but we are increasingly challenged to address new requirements such as built-in analysis, configurable and collaborative workflow, and mobile access.
At Workday, we’ve proved our ability to satisfy the old requirements and to handle the new ones. In just two years, our iPhone application has received five new feature updates and a complete UI refresh. This level of change is unheard of in enterprise software but it is the standard for consumer technology, which is where most of the innovation is coming from.
Complex relational database architectures are not nimble enough to respond to the new requirements for enterprise applications. The path to new capabilities for applications written on these architectures is one of expensive integration and rewrites as opposed to smooth evolution.
Security
Workday’s architectural approach means that our developers and our customers—including anyone working for them—can’t access the database where customer data is stored. All customer data is encrypted and is accessed only by the application server.This is a huge improvement to overall security in the enterprise space. Limiting the point of access to data to only the application server is not true of any on-premise ERP implementation, and likely not true for hosted enterprise application implementations, even if the vendors offering those implementations call them “SaaS.”
Insight
Since Workday defines data relationships as relationships among objects, as opposed to the traditional way of culling data from across thousands of tables, we are able to provide reporting and analysis over transactional data that other enterprise applications cannot provide.When running an analytics report, our system uses relationships to the primary object in the report (such as “worker”) to gather all data related to that object. The equivalent for a traditional ERP system would be to join all data across all tables relating to “worker” and send the results to the application server’s memory. Workday doesn’t have to do the joins and the data is already in memory. This allows Workday to quickly present the requested report and for customers to rapidly drill down on select dimensions of it.
For example, a Workday customer could run a report that shows not only information about all of its workers in R&D, but also how many of its senior developers work in San Francisco. This type of analysis can only happen in traditional applications when the data has been “pre-joined” and loaded into a separate reporting system. While that’s a common approach for business intelligence, it adds cost and complexity to reporting. Security has to be implemented for the separate system, and data loaded into it may be out of date by the time it’s viewed. Since our reports run on the same object structure where transactions are executed, we avoid the issues of separate reporting systems.
Change:
Maybe the most important driver for our different approach is the ability to build applications that are open to change. Even after 30 years, the requirements for enterprise software continue to rapidly change. Vendors must still deliver against longstanding requirements such as reliable transaction processing, scalable batch processing, and high volume data import, but we are increasingly challenged to address new requirements such as built-in analysis, configurable and collaborative workflow, and mobile access.At Workday, we’ve proved our ability to satisfy the old requirements and to handle the new ones. In just two years, our iPhone application has received five new feature updates and a complete UI refresh. This level of change is unheard of in enterprise software but it is the standard for consumer technology, which is where most of the innovation is coming from.
Complex relational database architectures are not nimble enough to respond to the new requirements for enterprise applications. The path to new capabilities for applications written on these architectures is one of expensive integration and rewrites as opposed to smooth evolution.
Make your organization change from real-time experts at Workday Training
The pace of change in our industry makes the discussion about application architecture more important than ever. That makes it all the more satisfying to explain how Workday is different.
The pace of change in our industry makes the discussion about application architecture more important than ever. That makes it all the more satisfying to explain how Workday is different.
