Change IS inevitable! So let’s be prepared.
Environment Management reflects the Change Management doctrine and the implementation of it typically looks something like this picture. Of course smaller companies might just have TEST and PROD, but that’s a minimum.
Everyone experiences the need for change in their Production system. Whether that change is tweaking pay rule configuration or adding pay codes or even implementing service packs, if you have a WFC system, there will be a need for change on a periodic basis. Because of those change requirements, there are things you can do and a structure you can create to give yourself confidence that the changes will not cause bad things to happen in to your production systems. Kronos provides Record Manager and the tool Setup Data Manager (SDM) to help you administer your environments, but to make the best use of those tools, you must have the right environments in place.
In order to provide a decent explanation here, we will follow a process through each of the environments described above to see what their role is and why it is critical. In a later article we might present an alternative setup just for fun.
Let's start with a common scenario: The HR department has just dreamed up a new pay practice and they want you to implement it in your Production Kronos environment.
SANDBOX Environment(s)
A common best practice on agile teams is to ensure that developers have their own "sandboxes" to work in. A sandbox is basically a technical environment whose scope is well defined and respected. The primary advantage of sandboxes is that they help to reduce the risk of technical errors adversely affecting a larger group of people than is absolutely necessary at the time.
So, the purpose of the Sandbox is to provide a Kronos playground to "practice" configuration and development. The Sandbox database is a copy of Production and often times it’s stripped of sensitive data. There isn’t a need for tight controls around what is being created or changed in this environment -- that is not the purpose. Use it to figure out what needs to be done at the individual or small team level. Some companies employ multiple Sandboxes for different teams and those get merged into DEV for integration testing.
For our scenario, when HR communicates that they want a new pay practice implemented, the developer would work here to figure how to configure everything that it will take to implement the new policy. And since it is just a playground, you can try different things, different approaches to make it work, until you are satisfied that you know exactly how you want to go about implementing the new pay practice. If you break it and can’t fix it, just refresh the database.
DEVELOPMENT Environment
Sometimes called ‘Project Integration’, the purpose of the Development environment is different depending on if you have Sandboxes. Without them, all development is done there and promoted to TEST for all testing and training. If you have a Sandbox, DEV is primarily used to integrate development from the other sources and make sure those changes don’t affect other parts of the system. Some might perform all simple changes directly to DEV and create Sandboxes for bigger or more intrusive projects.
Doing the integration testing here is great. We can’t really trust the sandbox to reflect the Production system after all those kids have messed up the Sandbox. So refresh DEV and promote your finished changes from the Sandbox to validate your work.
TEST Environment
This final non Production environment is where one performs formal testing and it’s often controlled by a separate TEST/QA group. I’ve seen this one called Pre-PROD, TEST and STAGE. Its purpose is to provide an environment that simulates PROD as closely as possible.
Understanding how it fits in with the other environments is what’s important here. In SAND, you have played with the configuration until you got it working the way you wanted. Then, you put that configuration in DEV and confirmed that it works the way you expected. TEST is used for two primary purposes. Testing that you can successfully migrate the changes, run though the full test scenarios required by your Change Control Process, and if these are the only environments you have it’ll be used for QA & UAT.
The final scenario step, of course, is to use SDM and move your configuration from DEV or TEST depending on your Change Control process, into PROD. Since you are just moving the configuration and not recreating it, you can control the timing of the move such that it has the least amount of impact on PROD and its users.
So could you have gotten your new pay practice into Production without each of these environments? Of course you could have. But not without more risk
-----------------
Thanks to Chris Flanders and many others for contributing to this and other articles in the series.