The Information Technology (IT) Environment Framework

Abstract:

The IT Environment Framework is used to help IT Professionals identify and understand the most fundamental concepts associated with the design, delivery, operations and support of the various different IT Operating Environments which are considered critical to most IT Organizations. It is frequently argued that highly controlled and repeatable Operating Environments are the foundation for all successful IT Delivery in enterprises of any size, regardless of their industry. This Framework helps identify the similarities and differences between such Environments, in an effort to shed light on common patterns that, ultimately, lead IT Organizations and their enterprises to higher levels of efficiency and quality, while simultaneously assisting in the reduction operating costs.

 

Table of Contents

Introduction to the IT Environment Framework 
Disclaimers 
A Basic Decomposition of the IT Environment Framework 
Key SDLC Based Operating Environments 
Different Environment Management Disciplines 
Test Environment Management 
Typical Activities That Are Performed Within Environments 
Environment Specific Roles 
Environment Security 
Understanding Why Environment Management Disciplines Are Important To An Enterprise 
Federation of Environments vs. Centralization of Environments 
A Hybrid Environment Strategy to Meet the Need for Exceptions 
Deployment of Systems and Assets to Operating Environments 
Environment Change Management or Operational Change Management 
Sequential vs. Nonsequential Environment Representation in an SDLC 
How to Leverage the Environment Framework for Better IT Project Plans and More Successful IT Delivery 
Support Services and Activities for SDLC Based Environments 
Environment Specific Metrics 
Important Summaries and Conclusions 
Learn More 

 

Introduction to the IT Environment Framework

Before getting into the Environment Framework, itself, it is important to first identify and understand the definition of the term "Environment" (a.k.a. "Operating Environment"). An Environment, which is the enterprise noun that is critical to the IT Discipline known as Environment Management, is defined as:

1. A controlled and often repeatable Configuration or set of Configurations that are perceived to act as a contained, bordered or surrounding operational context and that allow one or more Entities such as Resources or Systems to perform one or more controlled functions or activities.

To elaborate, this definition focuses on what could be considered "bounded and controlled Configurations" that allow a Resource or a System to perform one or more controlled functions that are often tied to a specific context that such an Environment represents. This is telling because it implies that an Environment is created to create boundaries, enable certain functions or activities, and to do it all within a specific set of constraints and/or specifications that act as a "context."

In many cases, the creation of a specific Environment acts as a means for fostering "repeatability." However, this is not a requirement and we'll see later that there are cases where some Environments are created for one time use, with the explicit intent to be destroyed after they've been used.

The IT Environment Framework is a decomposition of what it means for IT Professionals to create, deliver, operate and support such Environments so that functions can be performed in such Environments by an IT Organization's Resources and/or Systems.

It's important to understand that the IT Environment Framework is a subset or component of the greater Systems Development Life Cycle (SDLC) and is applicable throughout various stages of the SDLC, as will be discussed further on.

It's also important to understand the differences between such concepts as IT Technology Services and IT Operational Services, as well as the roles they play in facilitating IT Operating Environments.

NOTE: The content within this document will continue to evolve, over time. Therefore, the IF4IT recommends you check back regularly, to keep up with changes.

Disclaimers

This document is not intended to cover all information related to all possible Environments that any and all IT Organizations may use. For example, it will not cover all types of Environments nor will it cover all activities and purposes for all Environments. Instead, it is intended to be a descriptive framework that covers what are considered to be the most common and most useful Environments that are typically leveraged by most IT Organizations, especially those who provide services for enterprises that are typically mid-sized and up.

Because this document represents a framework of information about Environments, readers should be able to seamlessly transfer the concepts mentioned within to any Environments of interest that are not covered within this document.

A Basic Decomposition of the IT Environment Framework

To understand the IT Environment Framework, we must understand that it is composed of four (4) key sections that make up the whole...

1 - IT Systems Services: This area or section of the framework represents all technical solutions and services put in place around Systems, big or small, that are considered critical for the purpose of meeting a set of functional or behavioral goals within one or more specific Operating Environment. Examples of such technical solutions or Systems could be as small as those considered to be Atomic Systems, such as Computing Devices, Storage, and Software, or as large as those considered to be Composite Systems, such as Document Management Systems, Application Monitoring Systems, Business Intelligence Systems, or even business related Systems, such as Accounting or Payroll Systems. Big or small, a System is a System is a System and no Environment is complete until all relevant Systems are completely accounted for, made available, made stable, made repeatable, and are properly supported for the Environment or Environments that leverage such Systems.

2 - IT Operational Services: This area or section of the framework represents all Operating Services that are put in place to help maintain or use any and all Systems made available in one or more specific Operating Environment. This includes, both, the Services that are directly related to specific Systems, such as Release Management and Deployment Management, as well as those that are more general in nature and non-System specific, such as Project Management, Incident Management, Problem Management, etc.

3 - IT Operating Environment Services: In addition to the previous two components of the framework, this area or section represents the controlled and bounded Operating Environments, themselves, that enable System and Technology related work to occur in contained areas that do not impact other areas of work, as well as all the relevant Services put in place to support such activities. Such Services include but are not limited to the work necessary to construct or reconstruct an Environment, the work necessary to tear down an Environment, the work necessary to Deploy to an Environment, and the work necessary to support an Environment. These Services obviously become even more complex when the owners and managers of such Environments must deal with many Organizations trying to run multiple types of work, simultaneously, throughout a common Environment, in a manner that allows what the industry often refers to as a multi-tenancy model for operations.

4 - The Systems Development Life Cycle (SDLC): This area or section of the framework represents the SDLC for which a specific Environment is a part of, including all the policies, standards, procedures, and work necessary to move a System through such an SDLC in an effective and productive manner. It is the SDLC that drives the purpose of a specific Operating Environment and, therefore, all the work necessary to create, deploy to, operate, support and/or tear down an Environment. A well defined SDLC not only defines what Environments must exist but also helps an Organization and its Resources understand how best to move Systems and other relevant Solutions through such Environments and, ultimately, through the SDLC, itself.

The rest of this document will help elaborate upon each of the above in order to give the reader a better understanding of Environments, their purposes, how they are used, and how best to manage and support them.

Key SDLC Based Operating Environments

As stressed repeatedly, the most critical Operating Environments are those associated with an enterprise's Systems Development Life Cycle (SDLC). The reason for this is because, as Systems evolve within and throughout the different phases of the SDLC, these Systems get constructed, verified, and promoted from one working location to another. These locations are what the industry calls SDLC specific "Environments (or "Operating Environments"). They are, most often, virtual locations in nature and are not necessarily physical locations, although they can be physically separated as well."

Every SDLC has at least some clearly defined (and sometimes some not so clearly defined) Operating Environments. The IF4IT has identified the following six (6) Environments to be the minimum set of viable required Operating Environments for defining a successful and highly repeatable SDLC:

1. Research Environment (RESEARCH or RES)
2. Developer Work Space Environment (WS)
3. Centralized Build Environment (BUILD)
4. Integration Testing Environment (INTEG)
5. User Acceptance Testing Environment (UAT)
6. Production Environment (PROD)

Figure: Standard SDLC Environments

As we will see in further discussions, there are multiple other Environments that an enterprise can use in its SDLC. However, the above six Environments represent the most common Operating Environments found throughout most enterprises that manage IT Systems and other related Products, Services and Assets, regardless of their industries. (That's the beauty of a solid SDLC... It's industry agnostic!)

The following elaborates, further, on these basic Operating Environments:

	Isolated Research Environment: Used as an isolated sandbox for researching the viability of technologies and solutions, often implemented in the form of a Proof of Concept (PoC), a Study, or an Experiment. Such research solutions are often implemented with the knowledge and intent that much of the outcomes will be discarded and considered "throw-away," in light of the fact that the quick nature of how solutions are constructed in such an Environment are rarely stable and polished enough for true Production Environment utilization.
	Developer Work Space Environment: The secluded development Environment used by coders or technicians to do the work that will later be merged into a greater, unified solution. This Environment is provisioned (populated) with the tools and technologies needed by coders or technicians that allow them to fulfill the details specified by the designs they work against. Such an Environment exists to allow coders and technicians to work on their sub-areas of a specific solution (i.e. a Product, System, Software, etc.) without being impacted by the work of other coders or technicians and without impacting the work of other coders and technicians.
	Centralized Build Environment: Represents an isolated Environment where all coders or technicians working on a common Product, System, or Software Release will merge all their Changes for that Release, from their individual and private Work Space Environments, together, specifically for the purpose of generating a single, unified, and correctly working build.
	Integration Testing Environment: An isolated Environment that is used to test the Integrations (i.e. the data communications connections, channels and exchanges) between the Product, System, or Software Release being worked on and those of other Products, Systems or instances of Software that the Release is intended to work and communicate with during its operation in other downstream Environments, such as Production.
	User Acceptance Testing Environment: An isolated Environment that exists to allow human interaction with a Product, System or Software Release, for the purpose of obtaining final approval and "sign-off" for the features and functions of the Release before allowing it to be promoted for distribution to a Production operating Environment.
	Production Environment: The final targeted Environment where a Product, System or Software Release will operate for business use. This Environment is deemed to be the most critical, as failures in this Environment can potentially disturb or even shut down a line of business, depending on the importance of the Product, System or Software being used by its consumers (i.e. End Users).

As can be seen in the following figure, each of these basic Operating Environments directly aligns with corresponding phases in the SDLC and in the Canonical IT Model:

Figure: Alignment of Operating Environments to SDLC and Canonical IT Model Phases

In the above figure, each Operating Environment (3rd Row in the figure) aligns with a specific and corresponding phase of the SDLC (2nd Row in the figure) and, ultimately, also aligns with a corresponding phase in the Canonical Model for IT (1st Row in the figure). If an enterprise were to add Operating Environments to their SDLC, it would be reflected as a new chevron in the figure (either in a sequential pattern or in a parallel pattern, which will be discussed further on).

Alternate Environments: In addition to the most common and basic SDLC aligned Environments, listed above, enterprises will often create alternate Environments to address their own needs or those needs that may be outside of the standard SDLC, itself. Examples of such Environments include but are not limited to:

1. Performance Testing Environment
2. Disaster Recovery Environment
3. Training Environment

	Performance Testing Environment: An isolated Environment that exists to allow for measurement of Product, System or Software Release performance against an expected set of criteria, such as "Expected Performance Metrics." There are multiple reasons for why an enterprise would want such a dedicated Environment. However, like all other dedicated "testing" Environments, a Performance Testing Environment often exists to ensure that performance testing of a Release is isolated area that will not impact Production Environment operations. Depending on the enterprise, performance testing may be done in parallel to other testing, such as in parallel to User Acceptance Testing or sequentially, such as after Integration Testing but before User Acceptance Testing.
	Disaster Recovery Environment: An isolated Environment that is used for critical recovery of the Production Environment, in a different physical location, in the event there is a disaster that shuts down a primary Production Environment or a piece of it. Different enterprises have different strategies for this. Those that can afford it will keep simultaneously mirrored copies of their Production Environment in a separate Disaster Recovery Environment and physical location. Others will have parallel running Production Environments, with distributed loads across both, with the intent that if one shuts down the other(s) will seamlessly take over. Those enterprises that can't afford parallel Environments will plan to use their User Acceptance Testing Environments as their Disaster Recovery Environments, with the intent to refresh such an Environment, on-demand, in the event of a disaster.
	Training Environment: An isolated Environment that is specifically dedicated to and used for training and education of key stakeholders, such as End Users, Consumers, and Administrators.

What Environments an enterprise standardizes upon is really up to the needs of that enterprise. However, it is considered a best practice and a sign of maturity when an enterprise does, in fact, standardize its Environments, the offerings within them, the shared services around them, and their explicit integration into the enterprise's documented, published, socialized and governed SDLC.

The following image highlights a modified SDLC that incorporates a Performance Testing Environment and a Disaster Recovery Environment.

Also, as will be discussed later, there is no hard and fast rule that says all Environments must be dealt with sequentially, in their SDLC. In fact, mature enterprises that have eliminated manual work in each Environment, by automating as much as possible, often deploy to multiple Operating Environments simultaneously (i.e. in parallel).

A mature enterprise understands the highly negative impact of manual operations and, therefore, aggressively works to eliminate manual work or operations within all Environments, wherever it possibly can, through the automation of processes. Another sign of maturity comes with understanding the concept of installing "Shared IT Services" that operate within and across appropriate Environments. This concept of Shared IT Services will be explored later.

Different Environment Management Disciplines

The core IT Discipline associated with managing one or more Environments is identified as "Environment Management" or "Operating Environment Management." This discipline can be broken down, further, into many Environment-related sub-disciplines, including but not limited to:

• Centralized Build Environment Management
• Developer Work Space Environment Management
• Disaster Recovery Environment Management
• Integration Testing Environment Management (also known as Systems Integration Testing Environment Management)
• Module Testing Environment Management
• Performance Testing Environment Management
• Production Environment Management
• Research Environment Management
• Training Environment Management
• Unit Testing Environment Management
• User Acceptance Testing Environment Management

(Note: The above are presented in alphabetical order and not in any sequence that may be relevant to an SDLC.)

Test Environment Management

It becomes obvious from the definition of the term Test Environment and the details and definition of the IT Discipline Test Environment Management that their use is, most often, considered to be vague and unspecific. These terms do not specifically call out the types of testing that are intended. It is, therefore, considered more accurate and more useful to explicitly call out the type of testing Environment, such as Integration Testing Environment or User Acceptance Testing Environment. Therefore, the only time it clearly becomes meaningful to use these vague or general terms is when "generally" referring to one or more individual Test Environments or one or more individual Test Environment Management disciplines.

Examples of Test Environments include but are not limited to:

• Disaster Recovery Testing Environment
• Integration Testing Environment
• Module Testing Environment Management
• Performance Testing Environment
• Security Testing Environment
• Unit Testing Environment
• User Acceptance Testing Environment

Given the above, correlating examples of Test Environment Management sub-disciplines include but are not limited to:

• Disaster Recovery Testing Environment Management
• Integration Testing Environment Management
• Module Testing Environment Management
• Performance Testing Environment Management
• Security Testing Environment Management
• Unit Testing Environment Management
• User Acceptance Testing Environment Management

Often, Test Environments are buried within or abstracted by other larger Environments. For example, Unit and Module Testing Environments are often handled within Developer Work Space Environments (WS) and Centralized Build Environments (BUILD).

Typical Activities That Are Performed Within Environments

The purpose of having a well-defined Environment is to allow for controlled and bounded activities to be performed in an isolated or semi-isolated manner. When it comes to IT related Environments, there are very common activities that are performed in most Environments. Some of these activities include but are not limited to the following:

• Administration Management Activities
• Break Fix Management Activities
• Build Management Activities
• Change Management Activities
• Configuration Management Activities
• Distribution Management Activities
• Execution Management Activities
• Incident Management Activities
• Initialization Management Activities
• Installation Management Activities
• Instantiation Management Activities
• Package Management Activities
• Problem Management Activities
• Release Management Activities
• Security Management Activities
• Service Management Activities
• Verification Management (or Test Management) Activities

(Note: The above are presented in alphabetical order and not in any sequence that may be relevant to an SDLC. More specific Environment activities are documented in the following Roles section.)

Environment Specific Roles

Like all IT Disciplines, Environment Management and all permutations of this discipline for each specific Environment, such as Integration Test Environment Management or Production Environment Management, adhere to the IF4IT Capability or Action Driven Roles Framework. The roles that are specific to each Environment are documented within each distinct IT Discipline section of the IF4IT platform and can be found in the following specific locations:

• Centralized Build Environment Management Roles
• Developer Work Space Environment Management Roles
• Disaster Recovery Environment Management Roles
• Integration Test Environment Management Roles (or System Integration Test Environment Roles)
• Module Testing Environment Management Roles
• Performance Testing Environment Management Roles
• Production Environment Management Roles
• Research Environment Management Roles
• Training Environment Management Roles
• Unit Testing Environment Management Roles
• User Acceptance Testing Environment Management Roles

Environment Security

Environment Security means many things to many people, however, in short, it is actually about two very fundamental concepts:

1. Ensuring that nothing outside a specific Environment will contaminate or corrupt the Environment in a manner that will keep it from performing the way it is intended to perform.
2. Ensuring that nothing inside a specific Environment escapes or is shared with Resources and Systems that operate in other Environments, without explicit knowledge and approval.

A System is a complex combination of people processes, tools, technologies, etc. An Environment, therefore, can be thought of as a System (more like an ecosystem). Protection of things within the System or from leaving the System's ecosystem represents a great deal of the responsibility and work that is associated with Environment Security.

Some key types of Environment Security include but are not limited to:

• Environment Access Security (or Environment Accessibility Security): This type of security represents the control of what Resources, Systems, and Roles have access to a specific Environment, with the intent to minimize outside influences and/or corruption.
• Environment Role and Responsibility Security: This type of security focuses on ensuring that only the appropriately entitled Roles can perform controlled and sanctioned work in an Environment, helping to keep the right things in or out of it.
• Environment Data and Information Security: This type of security focuses on ensuring that anything which has a level of confidentiality is protected and maintained, with the intent that Data and Information is shared only on an appropriate "need to know" basis.

Environment Security usually becomes an issue for enterprises when Environments grow to a point of complexity that can only be defined and/or identified by the Organizations that use them. At such a time, the enterprise or some piece of it will make a move to start locking down and protecting Environments, only strengthening the need for solid Environment Management as a Service.

When it comes to security one of the most applicable and fundamentally appropriate words is "separation." Separation is the baseline for achieving Environment specific security, and it starts with the separation of Environments, as shown in the figure below...

As can be seen above, Environment separation allows for work to be performed in different areas without cross-contamination. It's also this type of Environment separation that allows for containment of such things like Data and Information.

In the IT Industry, there are many different "Separation Strategies" that help achieve isolation. Some examples include but are not limited to:

• Separation of Accounts: This type of separation focuses on the creation and separation of, both, human User Accounts and System Accounts that ensure that logging on to any System or into any Environment is transparent, trackable and isolated from each other. Enterprises will often put Account naming standards in place, so that there is context in the name, such as what System or human Resource it belongs to, what Environment it is specific to, etc. This would allow, for example, distinguishing between a System related Account that accesses a Database vs. another that accesses a File Repository.
• Separation of Changes: This type of separation, often referred to as "Change Layering," represents isolating Changes in such a manner that they can be pieced together or rolled back in a manner that is clear and efficient, making Changes act as building-blocks for an Environment or System.
• Separation of Configurations: This type of separation is very much like Change separation, with the difference that a Change is composed of one or more Configurations that define or make up the Change. Like Change separation, Configuration separation for a means to isolate Configurations from one another and also allows each Configuration item to be used as a separate building block in a bigger solution.
• Separation of Data: This type of separation focuses on ensuring that Data of one type or that is located in one Environment does not comingle with or corrupt other Data that may coexist in the same or in a different Environment.
• Separation of Environments: This separation strategy is based on creating isolating working or operating Environments, where different Systems and/or Resources can perform tasks that are not corrupted by things outside the Environment and where things inside of the working Environment do not corrupt or interact with things outside of the working Environment. Refer to any SDLC to see clear examples of isolated Environments that are defined and put in place to support that SDLC.
• Separation of Facilities: This separation strategy is most often used when physical Assets are involved and need to be separated. The separation of facilities, such as keeping things in different rooms, allows for tangible or physical Assets to be kept away from each other and eliminates things like comingling. Examples of isolated physical locations include "Clean Rooms," which are used in the research, manufacturing and testing of semiconductors.
• Separation of Identifiers: This separation strategy focuses on identification of anything that can, in some way, shape, or form, be "labeled" or "tagged" with data that helps such things be uniquely identify at a later time. This includes a wide range of solutions, such as Globally Unique Identifiers, demographic or profile data, etc. In such a case, anything that is important to an enterprise and that needs to be tracked in some Document or System will get a label or set of descriptive data that will help uniquely identify, track and manage it, throughout its lifecycle.
• Separation of Permissions: This separation strategy focuses on things like ensuring that human Resources, Roles and Systems have specific and controlled permissions that tie to what activities any one of them can or cannot perform. Examples include most Role-based permissioning solutions that sit within Directory Servers or within the administrative portion of many runtime Applications. (Note: The term "permissioning" is one that has been created by IT Professionals that refers to the granting new or editing of existing "permissions.")
• Separation of Roles and Responsibilities (a.k.a. Separation of Duties or Separation of Activities): This separation strategy focuses on ensuring that System and human Roles are clearly defined and isolated from each other so that there are no collisions or corruptions between them. Examples include the key roles associated with Deployment, such as Builder, Packager, Distributor, Installer, etc. Each Role performs very specific functions and, therefore, can be controlled, monitored and measured, independently.
• Separation of Software, Systems and their Releases: This separation strategy focuses on the isolation of versioned, installed, and operating Assets, allowing them to coexist, either within common or different Environments, in such a manner that they do not interfere with each other's operation.

It is any appropriate combination of the above Environment Separation Strategies that makes up what IT Professionals call "Environment Security."

The implementation of each of the above is not always necessary. However, done correctly, implementing just a few of the above separation strategies can go a long way to helping enterprises develop and isolate each of their Environments. However, it's important to not that each of the above is handled differently in each organization, which is one of the many reasons that the industry has a hard time standardizing. To take "Separation of Accounts" as an example, many enterprises will create different User Accounts and System Accounts for different environments but how they create the accounts, how they name the accounts and how they use the accounts will, very often, be different among enterprises.

It's also important to understand that separation of Environments can be physical and completely isolated, such as working in different rooms with no connecting networks or channels and with closed doors, or the separation can be virtual, such as in the case of different Virtual Machines that are collocated on common Computing Devices and which each host separate and unique Instances of common Software.

Understanding Why Environment Management Disciplines Are Important To An Enterprise

Environment Management, as an IT Discipline, and all of its related Sub-Disciplines that are identified above are critical to the success of all IT Organizations that deliver solutions for their Customers, Clients and End Users. As is the case with all areas of manufacturing, controlled Operating Environments allow the design of Systems and other constructable solutions to be implemented, deployed, verified and used by the End Users of such Environments in the most efficient and effective manner that is possible. As a result, mature and experienced enterprises spend almost as much, if not more, effort to define, standardize, and optimize their key Operating Environments as they do the Systems and Assets that get deployed and used within them. The proactive and constant management of such Environments is equivalent to sub-areas of Industrial Engineering, which constantly strives to improve any and all areas of an enterprise's operations.

A common and highly comparable example is that of manufacturing a vehicle, such as a new car. In the case of manufacturing and delivering a new car, the car is built on what most people perceive to be an "Assembly Line." However, anyone that has ever been involved in such complex manufacturing understands that a car actually moves across many Assembly Lines (or sub-Assembly Lines of the master Assembly Line). Such a vehicle progresses from design through to final delivery by passing through each and every sub-Assembly. Each sub-Assembly Line correlates, indirectly, to the different IT Operating Environments that have been identified and communicated as part of this Framework, by the Foundation, where each sub-Assembly Line represents a highly controlled and highly repeatable "Environment" for different work to be performed in the assembly and deployment of such a vehicle. The Environment to build the chassis is different than that of building the engine. And, the Environment of building the engine is different than that of building the body. And, the Environment of building the body is different than that of painting the vehicle. And, so on. Each isolated and bounded Environment is enabled by the key Tools, Technologies, Systems, Resources, and Skill Sets that are required to perform specific types of work within that Environment. Each Environment provides isolation for the work and "hooks" to both previous and future Environments. The movement through Environments is fluid and efficient. And, the work and costs to operate and deliver across such Environments is "constantly" scrutinized and optimized for maximum efficiency and effectiveness.

Experienced and mature enterprises that get the value of solid Environment Management, like manufacturing enterprises, will "constantly" work hard to achieve the following (in no particular order):

• Highly Repeatable and Efficient Environment Set Up
• Highly Repeatable and Efficient Environment Tear Down
• Highly Repeatable and Efficient Deployment To/From Such Environments
• Quicker, More Efficient and More Effective Work Within and Across Environments
• Less Expensive Work Within and Across Environments
• Higher Quality Work Within and Across Environments
• Maximization of Automation Within and Across Environments
• Minimize Human Labor Within and Across Environments

Reviewing the two figures, above, allows us to visually identify and distinguish between some of the obvious and key differences between enterprises that employ unstructured, non-standardized and non-centralized Environments (Figure 1) and enterprises that employ strictly structured, standardized and centralized Environments (Figure 2).

(It is important to understand that Figure 2 does not imply "shared" Environments for all Systems. Instead it is meant to imply consistent or templated Environments that look and feel the same for each System. The issue of whether to run all Systems through shared vs. unshared Environments is a different topic, altogether.)

Immature Enterprises	Mature Enterprises
Many Environments to manage.	Fewer Environments to manage.
Lower costs to manage Environments.	Higher costs to manage Environments.
Redundant and uncentralized Environments.	Unique, non-redundant, and centralized common Environments.
Far less standardization.	Far greater standardization.
More chaos throughout the enterprise.	Less chaos throughout the enterprise.
A greater number of people performing redundant, less unique, and lower value-add work.	Greater number of people performing more unique and higher value-add work.
High levels of redundant and fragmented hardware, storage, software, data, licenses, etc.	Far lower levels of redundancy and fragmentation in hardware, storage, software, licenses, etc.
Inconsistent and different work is performed for each System release through its own SDLC with its own Environments.	Far more consistency and common work is performed across all Systems and their releases, as they use a common SDLC with common Environments.
Higher probability of lower quality, throughout the enterprise.	Higher probability of higher quality, throughout the enterprise.
Longer average solutions delivery time (due to moving through the chaos).	Shorter average solutions delivery times (due to order, clarity, repeatability, and automation).
Lower average delivery-related quality ratings.	Higher average delivery-related quality ratings.
Lower levels of delivery efficiency.	Higher levels of delivery efficiency.

Federation of Environments vs. Centralization of Environments

Often, it is required to provide multiple instances of the same type of Environment for simultaneous usage by different Environment End Users or End User Communities. In doing so, an enterprise must understand what it means to have Federated vs. Centralized Environments and when it does or does not make sense to federate or to centralize. To assist with this the Foundation has identified two separate types of Federation and two different types of Centralization that help enterprises be successful in implementing their SDLCs for efficient and effective delivery of Systems, via their Release Management processes. These four permutations are as follows:

• Intra-System Environment Centralization
• Inter-System Environment Centralization
• Intra-System Environment Federation
• Inter-System Environment Federation

Intra-System Environment Centralization: This scenario represents the routing of all common work that is associated with all Releases of a single System through common and centralized Environments. In this case, all common work for all Releases of a given System is routed through a single common and centralized Environment that has a controlled purpose or set of purposes. The work performed for all Releases of such a given System is routed to and performed in one common Environment and, assuming multiple Releases for a common System (whether they be Sequential Releases or Parallel Releases) they all funnel into and through the same common Environment. The most common example is the Product Environment, as most enterprises usually have only one. However, some other common examples would be centralized Integration Testing Environments and centralized User Acceptance Testing Environment. The most common reason for creating such centralized Environments is to leverage common solutions to achieve economies of scale, making it faster and more productive to deliver solutions.

Inter-System Environment Centralization: This scenario represents the routing of all common work that is associated with all Releases of more than one System into and through a common Environment. In this case, all work for all Releases, regardless of the System it's associated with, will route to one common Environment or set of Environments to achieve economies of scale across multiple Systems. The most common example is the Production Environment, as most enterprises usually only have one and many Systems are deployed to and run simultaneously within such an Environment. Other examples include common testing Environments that are shared by many Releases of many different Systems. Of all the different Environment Federation and Centralization permutations, this permutation is often considered the most desirable and the most efficient, when implemented and supported properly for larger and more complex Environments, such as Centralized Build Environments, Centralized Integration Testing Environments, Centralized User Acceptance Testing Environments, and Centralized Production Environments.

Intra-System Environment Federation: This scenario represents the routing of all common work that is associated with the Release of a specific and unique System through multiple Environments that are federated and localized so that workers performing work for a common System do not affect each other in uncontrolled manners. The most common examples of such federated Environments are the Research Environment and the Developer Work Space Environment. For example, within one Release for a single System, many developers will all have their own localized Developer Work Space Environments, so that they can work on their own tasks without impacting other workers working in the same Release. This scenario is often most desirable when an Enterprise has very small, cheap and volatile Environments that must be torn down and reconstructed very rapidly and very frequently, within the boundaries of a single System and all of its Releases.

Inter-System Environment Federation: While usually undesirable but sometimes needed to handle exception situations, this scenario represents the case where different Releases of different Systems have their own redundant versions of the same type of Environment. In this case, a common example would be when different Systems each have their own isolated User Acceptance Testing Environment. This scenario offers the most isolated Environment solution for any System. When dealing with bigger environments, this type of federation is usually associated with much higher costs for an enterprise and much higher levels of complexity, since it requires more resources to build, deliver, operate and support each redundant Environment. However, when dealing with smaller and more volatile Environments that required constant tear down and rebuild, this scenario can often be the most ideal.

In summary, a mature enterprise is often composed of different permutations of the above four Environment Federation and Centralization scenarios. No one is completely right or wrong. However, each has its strengths and weaknesses and it is considered unwise to apply any one federation or centralization solution to all Environments, across all Systems.

A Hybrid Environment Strategy to Meet the Need for Exceptions

As enterprises grow to be upper-mid-sized and larger, they invariably run into situations where some Systems can justify exceptional circumstances that require them to not fit into the standardized Environment Framework. As a result, the enterprise will be required to address these needs by coming up with a solution or set of solutions that can accommodate a different migration path through custom Environments. The goal in this situation is to leverage standardized, centralized and structured solutions, wherever possible, in order to provide a Hybrid Environment Strategy, with the goal of minimizing exceptions and impacts to the enterprise while still meeting the need for legitimate exceptions.

The following figure represents a composite example of a Hybrid Environment Strategy where System 1 and its Releases uses what often represents a common standard Environment strategy and where System 2 and its Releases is set up to have custom Environment solutions for Centralized Build and Integration Testing.

It's important to note that just because an Environment is federated, as opposed to centralized, doesn't make it an exception case. So, for example, Developer Work Space Environments are almost always implemented as Inter-System Federated Environments. An exception case, therefore, is a scenario that falls outside of the standard Environment strategy that is put in place by an enterprise.

It's also important to note that an exception is just "that"... an exception. Everyone wants to believe that their situation is "different" and they warrant exceptions. However, when skilled professionals decompose different problem areas, it's more common to find that most people fit into the norm and rarely ever warrant exceptional solutions.

Deployment of Systems and Assets to Operating Environments

Deployment of Systems, various Assets, and Services to different SDLC based Operating Environments is at the very heart of what every IT Organization in any enterprise does. It is for this reason that the Foundation has dedicated an entire section called the IT Deployment Framework, to this topic.

In short, as Systems and other important Assets move through their Release cycles and, more specifically from Phase to Phase within an enterprise's SDLC (often through formal promotion procedures), such Systems and Assets get "deployed" to their targeted Operating Environment or Environments. The aggregate of the key activities or functions associated with getting such Systems and Assets to their targeted Operating Environment(s) and getting them to the point where they are ready for use is called "deployment."

The above figure summarizes the layout of key Environments across a common SDLC and shows that "Delivery" represents a Release Cycle and happens across all Operating Environments (i.e. horizontally in the diagram), while "Deployment" happens within a specific SDLC phase (i.e. vertically in the diagram) and within its correlating Operating Environment.

The diagram, below, summarizes the key repeatable Deployment functions or activities that are performed by IT Organizations within each Operating Environment.

NOTE: One of the most effective way to learn about and understand different Operating Environments is to study and learn the IT Deployment Framework. The Foundation highly recommends that readers spend time reading and understanding the key concepts highlighted within it.

Environment Change Management or Operational Change Management

When dealing with one or more Environments, the issue of managing Changes that are applied to such Environments invariably becomes an issue for IT Professionals, regardless of the industry they serve. It becomes critical to understand the implications of Change and to manage the deployment of Change to mitigate any negative impact to such Environments. As a result, there is an entire sub-profession within the Information Technology (IT) Industry called "Change Management."

When talking about Change, there are usually three (3) key categorical types that are most commonly referred to:

1. Strategic, Organizational or Cultural Change Management, which deals with the types of Change most leaders are concerned with.
2. Application, System, Product or Entity Change Management, which deals with the types of Changes to existing deployable entities that must be proactively managed "through" a Systems Development Life Cycle (SDLC) and which ultimately gets delivered and deployed to one or more specific Operating Environments. Such Changes are usually most important to Designers, Developers, Architects and Engineers, who are accountable for forward delivery of Solutions.
3. Environment Change Management, also known as Operational Change Management, which deals with the Changes to an Environment as a result of deployments or post deployment modifications to the Environment. Such Changes are usually most important to Environment Owners, Managers and Operators, who are accountable for the Services associated with one or more specific Operating Environments.

While it's definitely important for IT Professionals to understand all three areas of Change Management, this framework is specifically concerned with the third or last category, listed above, which is that of Environment Change Management or what is also referred to as Operational Change Management.

The figure above helps highlight four (4) common categories of Changes that are often applied to an Operating Environment. These key changes are detailed as follows:

1. Releases of Deployable Assets or Entities That Move Through the SDLC With the Intent to be Delivered to a target Environment and audience: These types of Changes represent those that result because of deploying Systems and Software to Operating Environments as a result of forward delivery. In other words, these Changes come from the delivery of new Releases. Releases originate at the beginning of an SDLC and march their way forward, on their way to their final destination, usually in some Production Environment. However, before getting to that final state, they get deployed repeatedly in many Environments that precede the Production Environment (not to mention those that also might follow), causing many Changes to occur and be managed. For example, if an IT Organization is delivering a new Release of an Accounting System, everything that is a direct part of this System, for example all things that would be packaged together and delivered together, modifying the Environment they are being deployed to, would fall into this category of Changes.
2. Pre-Deployment Dependencies for Deployable Assets and Entities That Are Moving Through the SDLC in the form of a Release: This represents the Changes that result in order to help set up, maintain and balance the different technical dependencies that are required for the successful deployment of a Release that is moving through the SDLC. This represents those Systems, Software, Technology and Solutions that are not part of the deployable Release, itself, but which must exist for it to be deployed and operate properly. For example, if you are deploying an Accounting System and it depends on an existing Human Resource System, the Human Resource System must pre-exist in the Operating Environment before the Accounting System can work properly, even though the Human Resource System, itself, may not be changing as part of the new Accounting System Release.
3. Post-Deployment Engineering Related Changes: This category of Changes represents those that are usually the result of activities such as modifications in capacity. Examples would include but not be limited to activities such as the increase of memory or storage on an existing Computing Device that pre-exists as an enabler for one or more Systems or Solutions, or the upgrade of existing Software Versions or Computing Device Versions for existing Systems or Solutions.
4. Post-Deployment Administrative Changes: These Changes represent the types of modifications that are performed on pre-deployed Assets and Solutions as a result of administrative work that is performed during normal operations within a given Operating Environment. Examples include but are not limited to things like the creation and/or modification of User Accounts, Administrative Accounts, Identifiers, Roles, Administrative Rights, etc.

Some common reasons for performing Environment Change Management include but are not limited to:

• Reducing and/or avoiding the potentially negative impact of Changes on Users of one or more specific Environments.
• Reducing and/or avoiding the potentially negative impact of Changes on other Systems that share an Environment.
• Maintaining an audit trail of Changes to comply with any Legal and/or Compliance regulations that may exist for an Enterprise or any of its Organizations or Systems.
• Maintaining an audit trail of Changes made and work performed that will allow for more efficient Incident and/or Problem resolution, within one or more specific Operating Environments.
• Establishing transparency into what work is commonly performed by IT Professionals, within an enterprise, and which Roles are related to such work.

Changes to Environments, like changes to Entities such as Products or Systems, are usually managed through what is called a "Change Request (CR)" or a "Request for Change (RFC)." Some Enterprises explicitly track and manage data objects that represent Requests for Change, through the use of Change Management forms, processes, policies, and systems. Others use implied Change Management solutions, such as Requirements Management solutions, Issue Management solutions, and Problem Management solutions, where the word "Change" is not explicitly used. There is no right or wrong way, so long as Changes are being proactively captured, tracked, and managed for better transparency, consistency and quality of the work being performed.

Environment Changes really represent a set of Change-specific or Change-related "Configurations" that are applied to an Operating Environment in an ordered and controlled manner. This ordered and controlled manner is what most is known as "Change Dependency Layering" or "Change Layering." One of the most critical reasons for Change Layering has to do with the idea of undoing or rolling back Changes, in the even there is a problem with one or more of the Changes that have been applied. The following figure shows how Changes and their related Configurations can be ordered, when applied to a targeted Operating Environment:

Each of the above Change Configurations or Changes can be specific to one or more Systems or Software and it is this concept that makes Environment Change Management so important. Environment Change Management is performed for two key reasons:

1. The Obvious Reason: To ready a targeted Environment for one or more Systems that will Operate or be leveraged in said Environment, in a manner that simultaneously will not impact other Systems and Software that share the same Environment.
2. The Not So Obvious Reason: To leverage economies of scale when applying Changes to a targeted Environment. In other words, performed or applied correctly, one Change may efficiently handle the work needed to ready multiple Systems and/or Software, simultaneously, therefore reducing the work and/or the costs to apply Changes to a given Environment. This reason becomes especially important in very large enterprises that deploy many Systems, Software, and ultimately Changes to a given Environment, frequently. The danger in common Changes is that, if applied incorrectly, many Systems and/or Software will be impacted and, therefore, their impact is considered to be greater.

When enterprises grow to the point where the teams designing and implementing the Changes can't effectively manage the impact of their own Changes on other Systems and Software that share their Operating Environments, such enterprises will often resort to creating teams or organizations that will review Changes, before they are applied to a targeted environment. These teams can be dedicated or non-dedicated, centralized or non-centralized but their goal is common, to review, question, and understand Changes, before approving their application or deployment to a targeted Environment. The name of such a group of professionals varies from enterprise to enterprise but they, fundamentally, all do the same things. Examples of common names for such an organization include but are not limited to:

• Change Approval Board
• Change Approval Group
• Change Approval Organization
• Change Approval Team
• Change Control Board
• Change Control Group
• Change Control Organization
• Change Control Team
• Change Management Board
• Change Management Group
• Change Management Organization
• Change Management Team
• Change Review Board
• Change Review Group
• Change Review Organization
• Change Review Team

As surprising as it may seem, enterprises will engage in heated arguments over the naming of such an organization. Your best bet is to simply pick one and move on. They're all the same, really. The key is to make the team productive, efficient and as cost effective as possible. Remember, this group is an expense and a drain on revenue and, like Change Management itself, is considered a necessary evil that should not be allowed to grow into an uncontrolled monster.

Again, it is important to note that there is no one right or wrong way to capture, review, track and manage Changes to an Environment. The level of rigor applied to Change Management solutions is usually tied to an enterprise's tolerance for the Risks associated with or due to Change. For example, in an Operating Environment where human safety is an issue, Changes to such Environments are rigorously scrutinized, evaluated, tested and reviewed far more than those that might be applied to an Environment where the only Risks are associated with nothing more than financial losses.

Best Practice Note: It is considered a best practice to automate as many Changes (i.e. Change Deployments or Change Applications) as possible that are made to any Entity or Operating Environment. This is specifically meant to achieve things like a reduction of the time it takes to apply Changes, the elimination of manual errors that are often associated with manual Changes, and higher levels of consistency across frequently performed common Changes.

Best Practice Note: Mature IT Organizations, with experienced IT Professionals, perform some level of Change Management in all critical Operating Environments, not just in their Production Environments. Given that most Deployable Entities, such as Systems and Software, that move through an SDLC for delivery find their way through multiple Environments before they ever get to a Production Environment, it makes complete sense that some level of rigor be placed on managing Changes to the Environments that precede (as well as those that follow) to assess and understand Changes and their impacts, long before they ever make it to Production. Performing Change Management only on a Production Environment means that you're waiting until the end of the SDLC cycle to understand and manage Changes. Think about it, some Systems or Software can be in development for years before they make it to Production. If your enterprise waits until the end of the SDLC cycle to deal with Changes only to its Production Environment, it runs the risk of unnecessary negative impacts that could, more often than not, have been identified and addressed far earlier in the SDLC.

Warning: Most Change Management functions are considered to be "expenses" and necessary evils for most enterprises. It is important to appropriately weigh the investments in Change Management and the return for such investments. Many enterprises mistakenly go down the path of over-investing in Change Management and, as a result, create slow, anti-delivery-oriented Change Management governance processes, policies and solutions. It is extremely important to keep your Change Management implementation lean and mean, and with the best interests of forward delivery of solutions in mind. Not doing so can mean slowing down your delivery cycles to the point where you're enterprise will have more Projects and Releases that fail, meaning that the can come in far over budget, far past expected dates, and can be abandoned, altogether.

Sequential vs. Nonsequential Environment Representation in an SDLC

It was mentioned, earlier, that there is no hard and fast rule that requires all Environments to be laid out and managed in a sequential manner, as part of an enterprise's SDLC. In fact, mature enterprises that have eliminated manual work in each Environment by automating as much as possible often deploy to multiple Operating Environments in simultaneously (i.e. in parallel).

However, this being said, it's important to note that no matter what an enterprise tries to do, there are always certain cases where sequential layout of SDLC based Operating Environments is natural. For example, no competent IT Professional would ever risk deploying a System to a Production Operating Environment before first performing some level of User Acceptance Testing in a User Acceptance Testing Environment. This, therefore, implies that there are certain pieces of the SDLC that will always be sequential, meaning that they will be laid out and used in a "waterfall-like" manner.

In the following visual examples, the first figure presents the common SDLC, with all SDLC-based Operating Environments laid out sequentially. The second figure shows a modified SDLC where, after promotion from the Integration Testing Environment, systems would start to be deployed simultaneously (i.e. in parallel) to different Operating Environments, as part of SDLC Phases IX and X.

How to Leverage the Environment Framework for Better IT Project Plans and More Successful IT Delivery

The Foundation cannot stress enough that one of the most common mistakes Organizations make, when it comes to IT Delivery, is to heavily weigh down its IT Delivery Projects with low value tasks or activities that many IT Professionals call "Administrivia." In other words, IT Organizations load their projects with administrative tasks that cater to the desires of Management, Program and Project offices and move further and further away from the types of tasks or activities that are truly related to the delivery of Software and Systems. The facts are simple. The more time IT Delivery teams like software developers and engineers spend on activities that don't focus directly on delivery, the more difficult it will be to successfully deliver IT Solutions quickly, with a high level of quality, and (most importantly) under budget. Smart IT organizations consistently evaluate their IT Program and Project Management processes, always looking for ways to minimize low value activities and maximize their high value activities. The IT Deployment Framework, used correctly, becomes a very powerful tool for ensuring that "High-Value Activities" are identified, accounted for, tracked and communicated. It does this by helping Project Managers, most of whom have very little SDLC based Design, Implementation and Deployment experience, understand what is or isn't important to focus on, when building their IT Design, Development and Delivery Project Plans.

The following diagram highlights three scenarios that are very typical of IT Project Management, across all industries...

In the first Scenario, #1, IT managers and team leaders load their project plans with far more low-value activities than they do high-value activities. For example, filling out forms to meet requirements for your Program Management Office may seem to be high-value activities for your Program Office but in reality it takes away from valuable time, effort, and money that could otherwise be better spent on higher-value activities, like IT Deployment activities (i.e. Building, Packaging, Distributing, Installing, Instantiating, Initializing, and Executing).

In large enterprises, where there are tens of thousands of people, at a minimum, and where Program Management Offices are pervasive, it's pretty fair to come to the conclusion that the best case hope for efficiency is Scenario #2, which shows a balance of performing work that makes non-delivery stakeholders as happy as possible, while still allowing for Delivery to occur. In this case, Delivery happens but it's far from being as efficient as it could be, such as in a case where there were little to no low-value activities associated with a Project.

The final Scenario, #3, is considered to be the most efficient form of Delivery. In this case, the balance is shifted toward the maximization of high-value activities. This final scenario is typical of smaller to mid-sized enterprises, where corporate overhead and bureaucracy is minimal.

If you're an IT manager or leader in a large enterprise, by looking at the above scenarios you can see and understand why it's so difficult for large enterprises to be nimble, efficient and cost effective. They have organizations like PMOs, Legal, Compliance and Records Management Organizations that are always imposing constraint based activities that are not focused on IT Delivery but more on enterprise administration (i.e. "Administrivia!"). The advantage of small enterprises is the lack of bureaucracy and red tape, allowing for focus on activities that are mostly about delivery and not administrivia. In other words, small enterprises have less demand from management and other Organizations that are outside of the immediate Delivery Team to perform what are considered to be lower-value activities and, therefore, are free to deliver fast, frequently, and ultimately at lower costs than IT Delivery teams in larger enterprises who must deal with such impositions.

The following diagram shows an example of how experienced IT Project Managers might often lay out IT Environment specific Tasks and Milestones, as part of a System Release schedule or Project Plan, in order to support the delivery of such a Release...

In the above, Environment specific Project tasks and activities often include but are not limited to the following:

• Environment Specific Set Up Tasks\/Activities
• Environment Specific Tear Down Tasks\/Activities
• Environment Specific Deployment Tasks\/Activities
• Highly Specific Environment Related Tasks (Prototyping Tasks in Research Environments, Software Development in Developer Work Space Environments, Integration Testing in Integration Testing Environments, etc.\/Activities

Note: A key permutation of this section that focuses more specifically on IT Deployment functions and activities, as they pertain to individual Operating Environments, can be found in the IT Deployment Framework. This section will help readers with more details about how work within any Environment is often broken down, with respect to real delivery of IT solutions and the Foundation highly recommends reading and understanding it.

Support Services and Activities for SDLC Based Environments

In a mature IT Organization, support for each Environment is structured, formalized and made repeatable. Therefore, if a mature IT Organization performs Incident Management for it's Production Environment, it will also provide Incident Management Services for all other Environments because it understands that the workers in those Environments also need support services. This does not mean that Service Levels will be the same for each Environment but implies that the Service is, in fact, consistently performed in a structured and repeatable manner for all Environments.

Examples of the different types of support functions, such as Incident Management, performed for specific Environments would include but not be limited to:

1. Isolated Research Environment Incident Management (or Research Incident Management)
2. Developer Work Space Environment Incident Management (or Work Space Incident Management)
3. Centralized Build Environment Incident Management (or Build Incident Management)
4. Integration Testing Environment Incident Management (or Integration Testing Incident Management)
5. User Acceptance Testing Environment Incident Management (or User Acceptance Testing Incident Management)
6. Production Environment Incident Management (or Production Incident Management)

The above would imply that each Environment has its own support Service Level Agreements (SLAs), Service Level Targets (SLTs) and Service Level Objectives (SLOs), along with its own Escalation Policies and Procedures. This pattern would be repeated for any other support related functions that were performed in each Environment.

It's important to keep in mind that, to the people who are required to perform specific work within a specific Environment, the Environment in which they are working is a Production-like Environment to them. This means, for example, that to Integration Testers, the Integration Testing Environment is "their" Production Environment and to User Acceptance Testers, the User Acceptance Testing Environment is "their" Production Environment.

One of the most common mistakes many IT Organizations make is to establish Support solutions for their Production Environment, alone, and not for their other Environments, leaving the workers in those Environments with no hope of being productive, when things go awry. Even worse, because such Organizations do not have formal Support Services established for non-Production Environments, they fail to track critical support information that occurs and is relevant "outside" of their formal Production Environment. Mature and successful IT Organizations and IT Leaders know that most of the work performed by their Resources is performed during Delivery phases of their SDLC. This means that such work is performed in the Environments that precede their Production Environment. Therefore, these Leaders and Organizations will do whatever is in their power to support such Environments and track whatever relevant data they can about such Environments, in order to understand and asses all areas of their own Delivery, long before Systems ever get deployed to Production Environments.

Always remember that formalizing Support for your Production Environment, alone, and not for other Environments is a partial and, therefore, incomplete Support Solution. Strong IT Leaders always do their best to avoid partial and incomplete solutions, wherever possible.

Environment Specific Metrics

Given that the majority of the work performed by most IT organizations across the world is either within or across controlled Environments, it becomes absolutely critical for these IT organizations to measure the work performed within or across such Environments. Given that an Environment is like a virtual container, it makes sense that the most obvious areas to collect metric data is at the boundaries (i.e. the inputs and outputs) of such containers.

The above diagram shows the key boundary specific touch points for the Environments associated with a common SDLC.

Metrics categorization and collection for Environments leverage the Foundation's Metric Framework, which highlights the following key types of metrics:

• Quantitative or Quantity Metrics (e.g. How many or what percentage of?)
• Qualitative or Quality Metrics (e.g. How good or bad?)
• Cost Metrics (e.g. How much?)
• Frequency Metrics (e.g. How often?)
• Duration Metrics (e.g. How long?)

Examples of Environment related metrics that align with the above Metrics Framework include but are not limited to:

Duration Metrics:

• Time to construct or reconstruct an Environment
• Time spent performing specific work in an Environment
• Time to tear down an Environment

Frequency Metrics:

• The number of times an Environment is constructed or reconstructed
• The number of times specific work is performed in an Environment or for an Environment
• The number of times an Environment is torn down

Quantitative Metrics:

• Percentage of work that is automated vs. manual when it comes to constructing or reconstructing an Environment
• Percentage of the work performed within a specific Environment that is automated vs. manual
• Percentage of work that is associated with tearing down an Environment that is automated vs. manual
• The number of Critical, High, Medium, and Low severity System Releases per Environment
• The number of Critical, High, Medium, and Low severity Changes per Environment

Cost Metrics:

• Cost to construct or reconstruct an Environment
• Cost to perform specific work in an Environment
• Cost to tear down an Environment

Qualitative Metrics:

• The number and\/or percentage of Critical, High, Medium or Low severity Incidents per Environment
• The number and\/or percentage of Critical, High, Medium or Low severity Problems per Environment
• The number and\/or percentage of Critical, High, Medium or Low severity Risks per Environment
• The amount of down time for a Resource or Organization, due to Incidents, Problems or Changes per Environment

The above begins to touch on the types of measurements that help all IT organizations understand and manage their costs to deliver and operate IT. Further measurements are tied to the detailed work that occurs "within" Environments. Most of this type of work and its associated metrics are covered in the IT Deployment Framework.

As a reminder, the IT Deployment Framework focuses on the key IT Deployment Functions that are performed by IT Resources in each and every Environment. The IT Deployment Functions are:

• Building
• Packaging
• Distributing
• Installing
• Instantiating
• Initializing
• Executing

The figure to the right summarizes the various data collection touch points that are IT Deployment Function specific. In leveraging, both, the IT Deployment Framework and this IT Environment Framework, it becomes clear that the type and number of valuable metrics that can be collected grows to be an expansive and very comprehensive list, when all Metric Types are applied to each and every IT Deployment Function. As a result, the types of Deployment specific metrics that can be collected and managed, which are specified in the IT Deployment Framework, can be collected and managed for each and every Environment. This means that Build Metrics can be collected and managed in every Environment, and that Packaging Metrics can be collected and managed in every Environment, etc.

Important Summaries and Conclusions

The following represents what the Foundation believes to be a minimum set of summaries and conclusions that an IT Professional should take away, after reading about the IT Environment Framework...

• An Environment is defined to be a controlled and often repeatable Configuration or set of Configurations that are perceived to act as a contained, bordered or surrounding operational context and that allow one or more Entities such as Resources or Systems to perform one or more controlled functions or activities.
• The IT Environment Framework is composed of four (4) key sections or areas that are represented as sets of Services and which represent the most important aspects of Operating Environments.
• There are multiple types of Operating Environments and some are more common than others.
• Many Environments are dedicated to Testing and Verification activities.
• Those Environments that are least common are often called "Alternate Environments."
• Operating Environments exist to meet the needs of Systems Development Life Cycles (SDLCs) and are, therefore, aligned to SDLCs and to the Canonical Model for IT.
• Environment Management is a critical IT Discipline and involves the explicit sub-Disciplines associated with providing for, supporting and managing each individual Operating Environment.
• There are multiple specific forms of "Environment Management," each of which correlates with a specific Environment that exists as part of an SDLC.
• There are many activities that are performed for or within an Environment and most of these activities are common across all IT Operating Environments.
• Environments have key Roles and Responsibilities associated with them.
• Formalizing Environment Management and all related Services and activities has clear purpose and benefits for any enterprise that repeatedly delivers Systems and Software through SDLCs.
• An enterprise must consider the benefits or detriments of Federated and\/or Centralized Environments as part of its Environment Strategy.
• Delivery represents the set of activities that help Systems and Solutions move through Environments, while Deployment represents the set of activities associated with setting up and operating any specific Environment and all Systems and Solutions used within such an Environment or by such an Environment.
• Environment Change Management (also known as Operational Change Management) is critical to successful Environment Management.
• Environments can be laid out in a sequential or non-sequential fashion, when attempting to meet the needs of an SDLC, however most enterprises need no more than a sequential model for most Environments.
• Used correctly, the IT Environment Framework helps Project Managers define and develop SDLC aligned Project Plans, where work within and across Environments is explicitly tracked as Tasks and Milestones that show up as explicit line items in System Release related Project Plans.
• Mature enterprises set up and offer the same types of Support Services for each and every Operating Environment, not just for their Production Environments.
• Successful and ongoing management of IT Operating Environments requires the clear definition, collection, tracking and management of Environment related Metrics.