|Glossary Quick Links|
|Glossary Master Index|
|Discipline Quick Links|
|Disciplines Master Index|
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.
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:
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.
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.
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.
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:
|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:
|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.
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:
(Note: The above are presented in alphabetical order and not in any sequence that may be relevant to an SDLC.)
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:
Given the above, correlating examples of Test Environment Management sub-disciplines include but are not limited to:
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).
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:
(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.)
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:
Environment Security means many things to many people, however, in short, it is actually about two very fundamental concepts:
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 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:
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.
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):
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.|
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: 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.
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, 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.
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:
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:
Some common reasons for performing Environment Change Management include but are not limited to:
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:
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:
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.
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.
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:
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.
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:
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.
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:
Examples of Environment related metrics that align with the above Metrics Framework include but are not limited to:
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:
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.
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...