Workday demo tenants

An interesting one I recently learned about...Workday offers what they term a 'Shared demonstration tenant' (to the named support contact at a customer site only).

It's basically a sample database with a limited number of user ids which is shared across the spectrum of Workday customers.  Workday provides this so that customers can see sample configurations, i.e. it's not for training or running a full business process, but rather for an occasional lookup, such as if you're thinking about implementing some new functionality.

Advantages:

• You can use this sample tenant to access sample configurations without having to pay for your own tenant.  Remember, WD (like most other Saas providers) charges per tenant.
• This is great if you're thinking about increasing your usage of functionality within HCM, for example, but as well if you only had HCM and were considering a complete expansion into another area such as Finance.  You can roam freely on your own, without being bothered by sales consultants filtering the information.

Disadvantages:

• As WD says, it's only a demo tenant with limited functionality.  It's not meant to prototype the full business process.  For example, it doesn't do proxy, nor can you make your own IDs!
• You're sharing it with lots of other customers.  If someone puts something ridiculous into it, you don't know if that comes from WD or another customer.
• It's refreshed every Monday and potentially during the week too, if things are broken.  Work quickly!

 

My take:

• I like it!  I come from a world where if you want a 'sample' set of configurations, then you're implementing a PeopleSoft vanilla database.  As we all know, databases take up space, i.e. cost, and vanilla is the first to go when we need to implement a training database.
• You're depending on the "Named Support Contacts" to not share this log-in info willy-nilly, which I think is a reasonable assumption for such a position.
• It provides value to customers.  You're not forced to take on the additional charges of an additional database when your usage is only going to be occasional.

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.  :-)