Tenant Management in Workday

As many of us come from an ERP or non-SaaS HRIS environment, I'd like to highlight 'tenant management' as probably one of the biggest differences in going to Workday. 

What is a Workday tenant?

First--some terminology:  a 'tenant' is Workday's term for what many of us would call 'a database instance', such as your QA environment, Production, etc.  Workday has a pricing model as they host the customer tenants in their data centers.

Our HR Landscape

As an organization in the implementation phase, we've struggled a bit to get our arms around this concept.  As background information, we're a large (150k+ employee population) organisation.  Due to SOX in the US, as well as needing to manage systems, we have procedures of how implementation of changes happen in our current ERP.  It's a tightly structured process with defined roles and responsibilities; customers put in requests, they are assigned to developers, developers only have access to develop in a development environment, IT has an internal review before anything goes to QA, etc.  I'm sure it's similar to what many other companies are doing.

In the past when we've implemented, we had control over how many databases we needed and how we structured those.  So in an ERP upgrade we'd have various test copies for developers and configuration needs, we'd have a pristine test copy for payroll parallel testing, a separate database for training sometimes, etc.  Then, we'd have a gold copy where we'd copy or enter configurations and we'd migrate data and programs there.  If we want a database copy, we'd need to put in a request to our internal database team to make it (recognizing cost/space limitations).

 

How Workday updates databases

Here in the WD world, this seems to be a different procedure.  Not sure if it's WD or our WD consulting partner, but this is the first time I've seen migrations of code, configuration, etc. going in multiple directions, rather than in a linear fashion.  So we have a demo database.  We have 3+ copies of test databases, with our company test setup and employee data loaded into them.  We then have 1 for integration, so for the developers building our interface files.  We have another for solution testing.  We have one for the report team.  Then, configuration and programs are being moved to and fro, using EIB, iload, and solution migration.

I went to the Workday Community, so see what the WD delivered guidance on this task would be.  A few things I learned:

1. Customers in Deployment would have the following setup:
1. GMS tenant (demo data), Prototype tenant, Full dataload tenant, Testing tenant, Gold tenant.
2. So customers are typically provisioned 4 tenants during deployment.
2. Customers in Production would have the following setup:
1. Production, Sandbox, Update/Conversion
2. The Sandbox is to be used by both the customer+WD support.  It's not meant to be a training or implementation tenant though.  It's for testing out changes.

Workday provided the following visual, it's helpful as it demostrates the complexity of this topic:

 

 

 

So once we are in Production, then how do things work?  How are Workday Sandboxes updated? 

Workday updates the sandbox environments so that you can test out their new updates before production is updated.  It works like this:

1. Production is cloned.
2. Update to next version of WD.
3. Create WD Update sandbox for test environment.
4. Production gets updated to new version.
5. Sandbox gets deleted.

As a reminder, these updates happen 3 times per year.

Workday has a set procedure for managing these tenants, both during implementation and in production.  So you're managing online various tenant tasks, such as Convert tenant, Delete tenant, Exclude tenant (this one means that it is excluded from any upgrades).  There are set policies, such as requests must be entered by 2 PM Pacific time, etc.  All of those process details are clearly outlined by WD.

I recently noticed a position in London for a company who had implemented WD, and they had a newly created position called 'Tenant Manager'.  The person had responsibility of managing the above, as well as coordinating the testing processing during those 3x/year upgrades.  So while WD may be a source of cost savings as you don't need so many developers, there is hope for us IT folks that it will create jobs in other areas.  :-)