Solution Environments
This part of Iterative Solution Operations describes the set of standard Environments used to support and enable Iterative Solution Implementation, and Iterative Solution Testing. In other words, they support the iterative Solution Delivery approach.
After reviewing the content on this page, check out the additional infomation on the following topics.
A Place for Everything and Everything in its Place: Solution Environments
For clarity let's begin by defining 'Environment'. In the context of a Solution an Environment is a single instance, comprised of the Solution's Logical Components, intended to serve specific purpose(s) for specific set(s) of users. The most obvious example of an Environment is that which will be called 'Production', the Environment which Customers will access for their ongoing use. Additional Environments are used for Solution development, testing, and possibly other purposes such as training.
As a described in the Section Overview, the model being described is one recommended for large-scale Product Solutions. While some may scoff at the number of Environments listed, it is a proven model.
Other Solution Types, or those with a single Delivery Team, or those not using a separate Certification cycle, can select parts suitable for a scaled-down approach.
The objective for Environments is to strike a balance between the needs of multiple groups and competing interests, each with constrained timeframes, without incurring a prohibitive amount of Environment maintenance and overhead. For example, it's not pragmatic to expect testing which uses Controlled Data to occur in the same Environment, at the same time, as testing which uses Uncontrolled data. If these competing needs cannot each function in a single Environment within the timeframe available, more than one Environment should be considered. It is cheaper, easier and will provide better long-term outcomes to use multiple Environments rather than trying to shoehorn competing needs into a single Environment. Conversely, it's also not recommended to create another Environment for just any whim. There are costs and overhead associated with each. There is no need to create multiple Environments to support the same purpose for multiple groups. No team or group needs it's own Environment - regardless of how much they insist they do. Focus each Environment's purpose, and direct those whose needs align with the purpose to the proper Enviroment.
Purpose & Use
The diagram below depicts the standard path of progression for the vast majority of changes made to any Product following the IT Business Product Solution delivery approach. Refer to the corresponding PowerPoint slideshow section below for an animated description which provides additional information and a better explanation for the sequence of events. For additional information on how changes process, also refer to the Reference Materials for Code Set Management.
Build Environments
To support ongoing development of a single Build Release over a number of Sprints two environments are used: DEV1 & TST1.
NOTE:Â *RICE = Reports, Integrations, Conversions & Extensions (i.e., custom development).
Candidate Environments
Once each Build is complete a new Candidate Release is created which then undergoes a number of Quality Assurance tests. Some amount of defects should be expected, and while time and effort allows these are fixed. To support the QA testing, and to allow for defect remediation, three environments are used: DEV2, TST2 and QA2.
Production Environments
Once the Candidate Release has been certified it is ready to move into Production (PROD). Should some unforeseen and urgent change be needed, there are two additional environments which allow those changes to be made without needing to impact either the next Candidate Release, or future Build Release.
Other, Supplemental Environments
The environments described above are required to enable ongoing, iterative build and release cycles. For a variety of reasons other environments may be desired. Some may be needed for just a short period of time; others may be longer serving. But in general environments should serve a specific purpose that cannot be addressed by another, existing environment.  Some sample are provided below.
Content & Sizing Guide
In general, the following guidelines should apply to the environments. There may be exceptions.
The Production (PROD) and pre-Production (QA2) environments should each be sized to support production-level access and performance. Ideally, the QA2 environment should be a mirror of PROD, using the same type and amount of underlying infrastructure (i.e., servers, storage, etc.). This ensures the ability to always: handle a refresh from Production; conduct Performance Testing of new functionality; provide a representative "look & feel" during System & UAT testing. The QA3 environment (Production Support) needs to be capable of supporting a copy of PROD (size) but does not need to support the same performance characteristics of PROD (i.e., it can operate on much smaller infrastructure).
Both the PROD and QA2 environments should contain similar (or the same) content of: a) Objects (i.e., Vendor Delivered Code + RICE - Reports, Integrations, Conversions & Extensions); b) Operational Data (i.e., application Configuration); and c) Transactional Data (i.e., the data generated and managed by Objects & Operational Data). The QA2 environment is refreshed from PROD at the beginning of each System or UAT test cycle. The actions taken during this refresh are intended to mirror those that will be required when the next Release is eventually deployed to PROD. There are very few instances where an additional copy of PROD should ever need to exist.
All other environments can be smaller and may reside on smaller and/or shared, infrastructure. DEV and TST environments should contain source versions of Objects and representative levels of Operational Data (but full Production levels should not be needed). Most Transactional Data should be sourced from managed data sets, designed to support Regression, Functional and Integration testing. Additional Transactional Data will be generated as part of development and/or testing. At any time, any DEV or TST environment should be capable of having its Transactional Data purged and reloaded (i.e. reset).
Origin & Refresh
The environments described above are required to enable ongoing, iterative build and release cycles. For a variety of reasons other environments may be desired. Some may be needed for just a short period of time; others may be longer serving. But in general environments should serve a specific purpose that cannot be addressed by another, existing environment.  Some sample are provided below.
Code, Test & Work Progressions
- The diagram below depicts the standard path of progression for the vast majority of changes made to any Product following the IT Business Product Solution delivery approach. Each Release is identified by a Product ID + a 'YY.S' indicator showing the year targeted for deployment, and the sequence within that year of the given Release. In the example below, the 4th Release of the Product during 2018 (18.4) is now in Production. It will soon be replaced by the next Candidate Release being certified which will be the 1st Release of the Product in 2019 (19.1). In parallel, the 2nd release of 2019 (19.2) is now being built. Refer to the corresponding PowerPoint slideshow section below for an animated description which provides additional information and a better explanation for the sequence of events. For additional information on how changes process, also refer to the Reference Materials for Code Set Management.
- The diagram below depicts the typical sequence of work used to progress changes to any Product following the IT Business Product Solution delivery approach. Refer to the corresponding PowerPoint slideshow section below for an animated description which provides additional information and a better explanation for the sequence of events. For additional information on how changes process, also refer to the Reference Materials for Build, Certify & Deploy.
- The diagram below depicts the sequence of test execution that is followed to ensure the quality of any Product following the IT Business Product Solution delivery approach. Refer to the corresponding PowerPoint slideshow section below for an animated description which provides additional information and a better explanation for the sequence of events. For additional information on how changes process, also refer to the Reference Materials for Testing Approach.