With the advent of easier and easier techniques for creating and maintaining Oracle Utilities environments, the number of environment will start to grow, increasing costs and introducing more risk into a project. This applies to on-premise as well as cloud implementations, though the cloud implementations have more visible costs.
An environment is a copy of the Oracle Utilities product (one software and one database at a minimum).
To minimize your costs and optimize the number of environments to manage there are a few techniques that may come in handy:
- Each Environment Must Be On Your Plan - Environments are typically used to support an activity or group of activities on some implementation plan. If the environment does not support any activities on a plan then it should be questioned.
- Each Environment Must Have An Owner - When I started working in IT a long time ago, the CIO of the company I worked for noticed the company had over 1500 IT systems. To rationalize he suggested shutting them all down and seeing who screamed to have it back on. That way he could figure out what was important to what part of the business. While this technique is extreme it points out an interesting thought. If you can identify the owner of each environment then that owner is responsible to determine the life of that environment including its availability or performance. Consider removing environments not owned by anyone.
- Each Environment Should Have a Birth Date And End Date - As an extension to the first point, each environment should have a date it is needed and a date when it is no longer needed. It is possible to have an environment be perpetual, for example Production, but generally environments are needed for a particular time frame. For example, you might be creating environments to support progressive builds, where you would have a window of builds you might want to keep (a minimum set I hope). That would dictate the life-cycle of the environment. This is very common in cloud environments where you can reserve capacity dynamically so it can impose time limits to enforce regular reassessment.
- Reuse Environments - I have been on implementations where individual users wanted their own personal environments. While this can be valid in some situations, it is much better to encourage reuse of environments across users and across activities. If you can plan out your implementation you can identify how to best reuse environments to save time and costs.
- Ask Questions; Don't Assume - When agreeing to create and manage the environment, ask the above questions and more to ensure that the environment is needed and will support the project appropriately for the right amount of time. I have been on implementations where 60 environments existed initially and after applying these techniques and others was able to reduce it to around 20. That saved a lot of costs.
So why the emphasis on keeping your environments to a minimal number given the techniques for building and managing them are getting easier? Well, no matter how easy keeping an environment consumes resources (computer and people) and keeping them at a minimum keeps costs minimized.
The techniques outlined above apply to Oracle Utilities products but can be applied to other products with appropriate variations.
For additional advice on this topic, refer to the Software Configuration Management Series(Doc Id: 560401.1) whitepapers available from My Oracle Support.