Workday’s Technology Platform and Development Processes:The Need for a New Appro

Posted by Ramesh on August 1st, 2019

The Need for a New Approach

Delivering against new requirements demands fresh thinking about enterprise application architecture development processes.

A brief review of legacy architectures is helpful. Traditional enterprise applications have employed an architectural approach that can be described as “relational client-server.” Developers create a relational model in the database layer to describe the structure of the application. Then, they write code in the business logic layer to store and retrieve data from the database, and to present data and transactional pages in the presentation layer.

https://drive.google.com/open?id=1J8yyIu1iRhlq1UeBXG6apu_Ch2BNwHHS

This type of traditional architecture allows you to reliably capture transactions at scale and to produce reports of transactional history.

We had three concerns with this architectural approach when we started Workday:

1. Complexity: Complex applications require complex database schemas with many tables to describe application structure and many lines of code to describe the application behavior. Typical enterprise applications end up being millions of lines of code talking to thousands of tables. Any significant change to the application requires making and coordinating changes at both of these levels.

2. Integration: Integration to other systems is accomplished either by getting exports and imports of transactional data (typically in files) or by interacting with an application programming interface (API) at the business logic level. While it is easy to get data out of a relational database, doing this directly circumvents the security and business logic built into the application. Using APIs to interact with the application can be complicated because APIs are typically built after the fact and have to interact with business logic that assumes that it’s talking with a user, not another system.

3. Business Intelligence (BI): These architectures feature detailed transactional reporting, but they do not report in a way that business users care about. Most applications built on these architectures transfer data to separate BI tools to get acceptable reporting and analytics for business users. Once a copy of the data is made, you have to secure access to it and worry about how out-of-sync it is with the live data in the application.

Workday also had concerns with traditional development processes. Traditional development was designed to support large and infrequent releases. Development is done on a separate code line from production. Programs to convert existing customers to the new release are typically built after the release is built. The infrastructure to run the application is either the responsibility of

the customer (for on-premise deployments) or an infrastructure team that is not part of development.

These concerns led us to adopt a different architectural approach for Workday’s development and runtime platform. We decided to pursue development processes that would support frequent updates and continuous change.

To get in-depth knowledge on the workday , you can enroll for live workday online training by OnlineITGuru with 24/7 support and lifetime access