A large amount of effort and resources in an IT organization is dedicated to create and manage the hardware and software systems which directly supports the business, generically called the "production environment." Probably even more effort and resources are used to manage the hardware and software systems used for application development, testing, support and training – the “non-production environments.”

There are several ways to classify non-prod environments. Based on what they is used for, there are: development, testing, training and production-support environments. Testing environments are further split in integration, functional, structural (non-functional) testing and user acceptance testing environments. Another classification is based on how many applications are deployed in the environment. There can be one-system, multi-systems and all-systems environments. For example a development team uses a development/one-system environment and an integration/multi-systems environment.

This article is about how to define the scope for a non-prod environment in terms of applications deployed, application versions and application data.

Scope definition starts from the inventory of all the applications managed by the IT organization. This inventory is a component model extended with the following stereotypes: component – same definition as in UML; application – a set of components administrated together; system – a set of applications that satisfy a large business function. The app inventory is based on the Telecommunication Application Map (TAM), but different in several ways. TAM is a classification system, in that sense is a meta-model of the app inventory that helps defining the component semantic. Ideally the app inventory will contain one component for each TAM function. In reality the association is many-to-many and evolves in time. The app inventory tends to grow through acquisition and new business initiatives and shrinks through business or IT consolidation. To be effective, the app inventory must have good names for components. Wrong names are: Mainframe, AS/400 (the hardware platform where they are deployed); Sun, Oracle (the vendor that provided the component); ESB, ALSB, WLI, e-commerce (the technology used to build the component). Good names will clearly identify the component and give a hint about the functionality. A few methods for naming that proved successful are: qualified TAM classification (e.g. Residential Customer Manager, Wireless Billing, Internet Service Order Manager); generic names within the context of an application/system (e.g. Sales Channels/Wireless Wholesale/Sales Portal) or acronyms if the components are annotated with the TAM classification.

Application data is another dimension of the environment scope. Most of the applications have a datastore to keep state. For the environment to be operational, all the datastores need to have a consistent snapshot of the reference and transactional data. Tools are required to populate the application data from an image of production with randomization techniques to protect privacy.

At one point in time an environment must contain applications with a consistent versions. This means that the application lifecycle must be coordinated to achieve environment consistency. This requires an IT release plan with milestones where development groups and vendors align. For example, the release 2009-10 contains the functionality F1, F2, F3, … and all the applications involved must have their lifecycle aligned with the 2009-10 release milestones. The timebox-ed release strategy puts a pressure on the business and IT departments, but proved to be the only way to bring new functionality into a large system. From an environment perspective, it means that an environment is build for a specific IT release. Once the decision is made on what is the release for an environment, the application build team retrieves from the source control system all the components for that release and deploys them into the environment.