As your company or enterprise gets larger, it gets easier to lose track of all your environments. Different applications and systems teams may try to justify having their own spaces for development, testing, and operations. While it may be convenient for them, there may be hidden costs and complexities that are not good for the broader enterprise. It’s always a good idea to practice strong Environment Management and standardize your environments, only allowing exceptions for true exceptions.
Definition: In short, Environments are those controlled and configured spaces that IT organizations use to develop, install, configure, instantiate, test, train in, operate, secure and/or debug systems and software. (See the formal definition of “Environment” in the IT Glossary.)
Definition: In short, Environment Management is the IT discipline of proactively planning for, building, and running of Environments. (See the full definition of “Environment Management” in the IT Glossary.)
Examples of Common Environment Types
Examples of Environment types include but are not limited to:
- Research (RES) Environment
- Federated Developer Work Space (WS) Environment
- Common/Centralized Build (CDEV or BUILD) Environment
- Systems Integration Testing (SIT) Environment
- User Acceptance Testing (UAT) Environment
- Production (PROD) Environment
- Disaster Recovery (DR) Environment
You can refer to the Environment Management Best Practices for more examples of different Environments and for more details on each Environment type.
Best Practice: Inventory and Know Your Environments
It’s very simple, Environments cost time, resources, and money. If you don’t know your Environments, you’re not tracking your costs and complexities and you’re not planning for your efficiencies.
In short, knowing your Environments also allows you to secure, control, assess, and optimize them. For example, you may be able to create shared Environments that can be leveraged by multiple teams, or dynamically provisioned Environments that minimize setup time, resources, and costs.
A common example in many large enterprises is that they have many Environments that exist for the same reasons but for testing or operating different technical assets. Knowing that you have these redundancies allows you to consolidate systems and costs, across the Environments and even allows you to consolidate the Environments, themselves, to eliminate redundancies.
Best Practice: Standardize Your Environments
One of the most important things you can do to control repeatability and to implement automation to optimize such repeatability is to standardize your Environments. Once standardized you can create repeatable configurations that allow you to do things like:
- Automate your Environment builds (including which computers you build them on).
- Automate how you populate your Environments with the software and data you need to work in them.
- Automate what you execute and even how you execute those things, within your Environments.
- Automate how you clean up and even “tear down” your Environments (when you’re done using them).
- Collect metrics for all functions executed, both, within or across any Environments, for all systems and users that access and work in them.
Best Practice: Centralize Environments Wherever Possible
Far too many enterprises have many environments that, while uniquely built, fundamentally exist for the same reasons. For example, having many different UAT Environments for many different systems. A clear opportunity for greater cost savings, delivering optimization, and quality improvement is to consolidate such environments into Shared Environments. Where possible, this allows you to gain economies of scale.
Best Practice: Account For Environment Related Work In Your Project Plans
One of the simplest things you can do to raise the probability of delivery success is to ensure that all Environment related work is accounted for in your Project Plans. As work progresses forward, in your projects, your technical assets will move through each of your Environments, in alignment with your Systems Development Life Cycle (SDLC).
For example, if you know you need to deploy software to a User Acceptance Testing (UAT) Environment, your project plan should account for things like:
- The design of the Environment (or which existing configuration will be used), and who will be accountable for doing so.
- The time to set up the Environment, and who will be accountable for doing so.
- The design of the functions and tests that will be run within that environment, and who will be accountable for doing so.
- The time to clean or tear down the Environment, when all work is completed, and who will be accountable for doing so.
Read More: The IT Environment Framework
The IF4IT’s IT Environment Framework is a great way to learn more about Environments and their importance to, both, you and your enterprise.
The framework walks the reader through the different types of Environments (both common and uncommon) and how they tie to critical IT concepts such as SDLCs, Release Management, Deployment Management, and IT Project Management.
We hope you find it useful.