Just because you can, does not mean you should

As a product manager I get questions passed to me from customers and partners to help with particular use cases or a particular technical requirement. One of the most common threads of questioning is efficiency in managing the portfolio of installations at a particular site. Each installation of a product is considered an environment or part of an environment. Common environments are development, testing, training, production etc.

Customers establish a number of copies of the product to manage their implementation, maintain their portfolio or perform upgrades. The license for the Oracle Energy and Water solutions is flexible enough not to restrict the actual number of copies of the product installed at the site but now that causes another issue. Customers tend to carry more environments than they need which drives up maintenance costs. In some cases, the number of environments can get so excessive that the maintenance costs can soon become unmaintainable.

Note: Even if the Oracle Energy and Water license is flexible, other licenses used in the installation may be less flexible and increase your licensing costs if used excessively.

Each of those environments consumes resources, both technical and non-technical. They need to be maintained including backing them up and patching them. While you can use things like Enterprise Manager (with the relevant packs) to automate a lot, it can still be inefficient to have all these environments available.

When I was in consulting and subsequently in the "black belt" team, I would witness excessive amounts of environments and try different techniques to help IT groups reduce the amount of them to reduce costs. Even Oracle internally regularly reviews the needs for environments to reduce costs. We internally have found huge cost savings in reducing the need for excessive environments to maintain our product lines efficiently.

So how can you do this for your site to ensure you streamline your costs? Luckily, we have some guidelines in the Environment Management paper as part of the Software Configuration Management Series (Doc Id: 560401.1) available from My Oracle Support.

Here are a sample of the guidelines you can consider:

• Your implementation plan is your guide. Most implementation and maintenance teams have plans which outline the activities to meet their goals. Environments need to support those activities on the plan to be successful. Conversely, if an environment is not supporting a task or item on the plan, it should not exist.
• Environments need a owner. One principle I inherited from my early days is that everything should have an owner. For the purposes of this discussion, an environment should have an owner. That is a person, or group of people who are the key users of that environment and control all aspects of that environment such as who has access, how often it is available, how often it is backed up, when it should be removed etc.. Those owners do not necessarily do the work on that environment but have the last say on its management. Conversely, no owner than the environment should not be there.
• Environments need a lifecycle. If you have a plan, then you know when you need the environment and when it will go away. The latter is the kicker. You should always put an end date on an environment, even if that environment is needed "forever".
• Reuse to save. This is something that applies universally to almost all aspects of our lives. Reuse has been shown to reduce costs and reduce waste. This equally applies to environments. If you can combine users, use cases, repurpose an environment that is going to be removed for a new task and other reuse techniques, then this will drive efficiency.
• Learn to share. This is one of the common causes of growing environments. People want specific environments, and sometimes multiples, for dedicated tasks. In itself it is not invalid but the idea of multiple tasks sharing an environment seems too far. In most cases, tasks have common goals that can mean they can share an environment with some accommodation of techniques. A common use case is testing environments. Some implementations have a dedicated testing environment per testing resource. This is excessive as testers can share environments, using various techniques supported by the solutions, and in fact it makes sense as you only tend to have one production environment so testing in different environment does not really represent your production scenario.
• Ask for justification. One of the first ways of combating this as when a new environment is requested, ask questions about its use, ownership, tasks it is supporting and other aspects. Ascertain whether it is worth another installation or you can simply reuse one you have already.
• Monitor usage. One of the techniques I like to use is to see how often an environment is actually used. If it has not been used for a while, it probably can be removed with little or no impact. You should not keep environments running for "just in case" scenarios.

It is important to be vigilant when maintaining a portfolio of environments as if you don't it will get out of hand.

My recommendation is regularly review ALL your environments and see what you can remove. We do this regularly and save human and non-human costs.

For more information and techniques refer to the Environment Management paper as part of the Software Configuration Management Series (Doc Id: 560401.1) available from My Oracle Support.