Planning and Supporting Growth: Scalability at Workday, Part 1

Jon Ruggiero and Jim Stratton spend a lot of time thinking about the future. As team leaders in the Workday Technology Architecture Group, Ruggiero and Stratton are among those responsible for ensuring that Workday’s products meet customers’ growing needs.

To do that effectively, they’ve led a discipline around scalability in the Workday software development process. Using a services-based development model, their team helps create Workday applications that are optimized to scale and offer flexibility for process automation, integration, and delivery.

In the first of this two-part blog series, we talk with Ruggiero and Stratton to learn more about the foundation of Workday’s architecture and how it offers customers a scalable application environment.

What does scalability mean for Workday?

Ruggiero: As an 11-year-old company, some have asked whether the Workday technology platform is due for a rewrite or a refresh. Inside the engineering organizations at Workday, the concept of scalability is embedded in how we design and develop our applications—it is a philosophy that we embraced from the beginning of the company, and it has shaped our approach to platform and application scalability.

How did Workday evolve its growth and scalability strategy?

Stratton: When we set out to build the Workday architecture in 2005, we aimed to serve some of the largest companies in the world. The first step was to put working software into the hands of our customers as early as possible to get feedback and experience with a running system.

The early Workday architecture and applications offered a balanced approach that met the needs of our customers and had an architecture that could evolve over time as those needs changed. We didn’t want to lock ourselves into an architecture that was inflexible or that couldn’t scale as both the number and sizes of our customers grew.

One key decision we made early on was to cleanly separate platform development from application development. We wanted to be able to protect our investment in our application business logic and enable our platform teams to keep Workday on the latest technology innovations. This approach allows us to make sweeping changes to our platform technology without having to rewrite or refactor any of our business logic. This has been important because we are able to simplify many scalability challenges by distributing them down to our platform teams, and allows our application development teams to focus on their core business domain.

Can you describe some early lessons learned that have made an impact?

Ruggiero: I think the biggest thing we realized early on is that taking a services approach was critical to overcoming scalability challenges. This means that we split our services apart or introduced entirely new services to meet business needs.

Here are a couple simple examples from the early days. Back around 2006, our first customers didn’t have many end users on Workday so concurrent user workload was not a problem. However, customers did have administrative users with a lot of large reports that they wanted to run frequently as they were developing confidence with a new system. The reports exposed some issues that we addressed by separating out reporting workloads from the transactional workload.

When our first payroll customer went live, we saw a large increase in concurrent user volumes on paydays as workers rushed to see their pay stubs online and generate a printable format of their checks. We addressed this problem by splitting out a print service that is dedicated to handling these types of requests, whether it’s for payroll or another application. These early lessons gave us confidence that a services approach was the right one.

Read the second part of this series, where we talk with Ruggiero and Stratton about the role of scalability in meeting customers’ needs and how Workday keeps up with the demands of different types of customers.