IT Operating Environments Best Practices - Establish Environment Types

IT Operating Environments Best Practices

Chapter 7. Establish Environment Types

Authored and Published By: The International Foundation for Information Technology (IF4IT), LLC

Executive Summary: Chapter Overview

IF4IT

The Bottom Line

This chapter explains how to establish Environment Types as part of enterprise IT Operating Environment Management. It clarifies the governance expectations, ownership model, control discipline, evidence needs, and operating practices required to manage this topic consistently. Applying the guidance helps improve environment quality, security, operational reliability, cost transparency, and auditability across the environment lifecycle.

Core Concepts

Chapter Focus Area	Practical Governance Intent
Establish Environment Types	Establishes the governance expectation, operating discipline, or decision criteria needed to manage this aspect of IT operating environments consistently.
Controls and Accountability	Clarifies the ownership, evidence, access, lifecycle, risk, cost, or compliance practices needed to make the guidance enforceable and auditable.

Quick Q&A

Question: Why does this chapter matter to Environment Management?

Answer: It matters because establish Environment Types affects whether Environment Instances are known, owned, secured, cost-managed, and aligned to their approved purpose. Without this discipline, teams create inconsistent local practices that increase delivery risk, operational instability, security exposure, compliance exposure, and unnecessary cost.

Read More Below

Overview

Many hardware and software systems, such as products, applications, services, platforms, and tools, often have their own locally defined Environment Instances, where the names of specific Environment Instances may vary both within a system and across different systems. For this reason, it is important to establish clearly defined Environment Types that act as broader environment super-categories and allow system-specific Environment Instances to be mapped consistently to those super-categories.

Figure: Canonical Environment Types — This figure presents a standard enterprise taxonomy of canonical Environment Types, from lower environments used for research, development, engineering, integration testing, user acceptance testing, and training through upper environments used for production staging and live production operations. It illustrates how Environment Types provide a consistent vocabulary for governing Environment Instances across the full solution lifecycle while allowing each instance to be configured according to its approved purpose, risk, fidelity, controls, and stakeholder needs.

Best Practice

Clearly establish the enterprise’s approved Environment Types. For example, common standard Environment Types include the following:

Environment Long Name	Environment Short Name	Abbreviation	Definition
Research Environment	Research	RES	This Environment Type should have a short operational lifespan, should be highly isolated from internal enterprise resources except for minor approved exceptions, and should exist only for rapid research, exploration, and prototyping. Anything constructed in this environment is intended to be destroyed and discarded; therefore, users should have no expectation that its contents will be retained for extended periods of time. Example uses include evaluating new technologies, building volatile algorithms that could corrupt enterprise data, or building algorithms that are not approved to run against sensitive enterprise resources.
Software Development Environment	Software Development	DEV	This Environment Type is where software developers and engineers build, unit test, and component test software. This Environment Type should be tied to Source Code Control Systems (SCCSs) for version control of environment contents. Because this environment changes frequently, activities such as Systems Integration Testing, User Acceptance Testing, and Education and Training should not be performed here. Example uses include new software development, enhancements to existing software, and defect or bug fixes for existing software.
Engineering Environment	Engineering	ENG	This Environment Type is similar to the Software Development Environment but is intended for engineers who need to work with assets, configurations, or constructs that are in addition to, or outside of, software development, such as hardware (for example, laptops, servers, and network devices), networks, firewalls, routing, storage, appliances, and other infrastructure components. Example uses include new laptop, server, storage, network device, or network topology construction; firewall rules development; infrastructure configuration; and baseline testing for such constructs.
Systems Integration Testing Environment	Systems Integration Testing	SIT	This Environment Type exists for systems integration testing so that solutions built for one system can validate their integrations with other systems. Direct modifications to software, systems, data, infrastructure, or configuration must be governed. Changes should occur only through approved deployment, configuration, data, or operational procedures, with appropriate validation and evidence where required. Example uses include testing API integration between software systems, testing ETL processes between software systems, and testing data-event generation and consumption between software systems.
User Acceptance Testing Environment	User Acceptance Testing	UAT	This Environment Type exists for users and business stakeholders to validate that software systems satisfy approved functional requirements, business workflows, acceptance criteria, and user expectations. Direct modifications to software, systems, data, infrastructure, or configuration must be governed. Changes should occur only through approved deployment, configuration, data, or operational procedures, with appropriate validation and evidence where required. Example uses include end-user testing of User Interfaces (UI) and User Experience (UX), business-function verification, and human-role-specific testing.
Education and Training Environment	Education and Training	EDU/TRN	This Environment Type exists to train people who will be users, administrators, operators, or support staff. Direct modifications to software, systems, data, infrastructure, or configuration must be governed. Changes should occur only through approved deployment, configuration, data, or operational procedures, with appropriate validation and evidence where required. Example uses include training business end users on how to use the system based on specific roles, training administrators on administrative features and functions, and training support staff that will support business users of the system.
Production Staging Environment	Production Staging	PSTG	This Environment Type exists as a final preparation, validation, and staging area for software systems, deployable assets, configuration, data changes, infrastructure changes, or operational procedures before deployment or promotion to the final target Production environment. Direct modifications to software, systems, data, infrastructure, or configuration must be governed. Changes should occur only through approved deployment, release, configuration, data, or operational procedures, with appropriate validation and evidence where required. Example uses include final change-management coordination, deployment rehearsal, release-readiness review, rollback or recovery preparation, and preparation for scheduled Production deployments.
Production Environment	Production	PROD	This Environment Type exists for the execution of systems in the final business operating environment. Direct modifications to software, systems, data, infrastructure, or configuration must be governed. Changes should occur only through approved deployment, release, change, data, recovery, or operational procedures, with appropriate validation and evidence where required. Nothing from lower environments should be able to directly influence this environment during Production operations. Example uses include allowing business workers to perform their day-to-day work, allowing external stakeholders such as customers, vendors, and partners to interact with the enterprise, and allowing business data to be created, read, updated, and deleted according to business operating rules and regulations.

NOTE: Security Penetration Testing, often called Pen Testing, and Smoke Testing are validation activities, not standard Environment Types. They are commonly performed against approved target environments, including Production, Production Staging, or other controlled environments, and do not normally warrant separate standing environments.

IMPORTANT: The above Environment Types act as environment super-categories for more specific Environment Instances that tend to be system-specific. Not every system needs every Environment Type, and a system may have multiple Environment Instances that map to the same Environment Type for different purposes. An enterprise can have many different systems, and each system may have specific Environment Instance names and approved permutations according to its needs. However, every Environment Instance should map back to an approved Environment Type, and each instance should conform to the policies, standards, and controls established for that super-category.

Example 1: System X has a single Development Environment Instance, multiple Systems Integration Testing (SIT) Environment Instances, multiple different Education and Training Environment Instances (one for each key stakeholder group), a single User Acceptance Testing Environment Instance, a Production Staging Environment Instance, and two separate Production Environment Instances that it uses for ping-pong deployments…

System X Environment Instance	System X Environment Abbreviation	Environment Type (i.e., Super-category)
Development	Dev	Development
Systems Integration Testing 1	SIT1	Systems Integration Testing
Systems Integration Testing 2	SIT2	Systems Integration Testing
User Training	TRN	Education and Training
Administrator Training	ADM	Education and Training
User Acceptance Testing	UAT	User Acceptance Testing
Production 1	PRD1	Production
Production 2	PRD2	Production

Example 2: System Y may only have a Development and Production environment because it is considered a very low risk web application like the company intranet.

Benefit(s)

Establishing Environment Types as environment super-categories allows system-specific Environment Instances to be mapped consistently back to those super-categories, further facilitating better Enterprise Model development, better Application Portfolio Management, and, ultimately, better IT Governance.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Establish Environment Types | IT Operating Environments Best Practices. https://if4it.org/best-practices/it-operating-environments/establish-environment-types/ (accessed 2026-07-21).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers

💡 The Bottom Line

📝 Core Concepts

🤖 Quick Q&A