Iterative Solution Operations
The prior sections on Iterative Solution Implementation and Testing are highly dependent upon the Operational capabilities supporting the Solution. Ideally, the Operational capabilities employed for any Solution should work within any existing enterprise DevOps framework. However, other ITM functions, require some aspects of this Operational model. If there is an existing framework, it may need to accomodate some additional features. Conversely, if there is no existing framework, then this model provides an initial one.
This section provides an introduction into some of the main operational drivers, including:
- Environments
- Version Control
- Work Management System
- Test Management System
Together, these can either enable, or constrain, Solution Delivery.
After the Overview below, explore the following in more detail.
Section Overview
Introduction
Many sections within the ITM rely on implied operational capabilities. For example, if a Solution has but one environment, there can be no separation of Production from non-Production activities. If it has two environments, separating Production and Pre-Production, then a single Pre-Production environment cannot segment development from testing, or build activities from QA activiites.
Similarly, a Solution with a single Pre-Production environment cannot manage work on both a Build Release, and Candidate Release, at the same time. Further, there can be no segmentation of changes between development, test, and QA environments, when they are all one and the same.
Balance in the (Work)Force
The challenge is to strike a balance between having too many moving parts, and having too few. Too many, increases workload, creates redundancy, and enables inefficiency. Too few, and there is also increased workload, along with an inability to complete work in a timely manner, and promotes ineffectiveness.
Each Solution must find its own balance. Many Solutions benefit from a QA cycle; but not all. Many Solutions are able to make myriad changes to tailor the Solution to suit Customer needs; but not all.  Working towards such balance is accomplished through the Solution Strategy & Architecture. There are many drivers to consider, including:
- Capabilities of the core, "as delivered", or "out of the box", Application or Technology;
- The Type of Solution to deliver - Product, System, or Service - and its anticipated scope;
- Organizational capabilities available to the Solution (e.g., number of Teams, whether or not QA is required, etc.; and
- Whether there are internal and/or external groups (e.g., 3rd Party Service Providers) delivering the Solution, and the agreements each is following;
- Available budgets, timelines, infrastructure, and so on.
Allow some lee way over time to adopt improvement opportunities, or to remove what seemed like a good idea, but did not turn out that way. Furthermore, seek alignment with any enterprise DevOps framework. The more inconsistency there is, the more difficult implementing, and maintaining, individual Solution's becomes. Operations should be an enabler of Solution Delivery, not a constraint.
Objective
There are simply too many permutations to describe each possible Solution. With this in mind, this section describes a recommended operational model that is suitable for Solutions with the following characteristics:
- The core Solution is a large, or complex, enterprise Product, such as Oracle EBS, Salesforce, SAP, Teamcenter, or Dynamics 365.
- The Solution must integrate with other enterprise systems;
- The Solution requires both Delivery Teams, and QA groups.
- Multiple Teams, potentially from multiple 3rd Party Providers, and/or a mix of in-house and contracted resources, will implement the Solution.
This is about as complex as most Solutions come. Most other Solutions are simpler. They can either replicate this model, or to pick and choose the parts which are suitable for their Solution's delivery. For example, most Systems can be delivered without a QA group, and without any of the implementation steps, test cycles and environments associated with them.
Regardless of pieces used, again, try to abide by, or establish, valid capabilities within an overall, enterprise DevOps framework. Everyone must recognize that, ultimately, any Solution will have to be deployed along with all other systems and Solutions within the enterprise. If you're not following the prescribed methods for doing so, expect plenty of delays, and challenges, anytime additional changes are desired.
Model Content
The initial parts introduce more common operational capabilities that typically apply to multiple Solutions within an organization. This include the:
- Work Management System (WMS), including Features, Stories and Bugs, Kanban & Scrum boards; and Workflow;
- Test Management System (TMS), including Test Components, Test Data, and Defects;Â and
- Collaboration System, to organize and facilitate the sharing of Solution-related information.
The next part introduces Environments. These are the means to segment work, and to support multiple, concurrent, objectives. Not all Solutions will use Environments, but many will.
The final part looks at a common model of Version Control. If making change to a Solution is possible, then controlling what has changed, when, and by whom is critical. Get this part right and the overall process of change becomes much easier to manage and use.
Key Point:
The tools used to support Solution Delivery, as well as their configurations, are key to driving alignement, consistency, efficiency and effectiveness. When the operational model is too tight, it constrains delivery capabilities. When it is too loose, the power to guide productive work dissipates. The ITM provides a practical, achievable balance which enables individual productivity, and guides overall Solution success.
About Operational Tools
The ITM's iterative approach depends upon a few Operational tools.  This Section delves into a few core tool types that facilitate iterative transformation. Most of these applications offer significantly more functionality than is defined for the ITM. Of course, that additional functionality can be quite valuable when applied appropriately. However, the ITM only requires some basic functions. If the tools in question do not support these basic functions, look to better Solutions.
There are many tools available, from basic freeware options to top-of-the-line enterprise systems. Each has strengths and weaknesses. None is clearly better than alternatives when looked at as stand-alone tools.
Where differences become clearer is in considering the capabilities provided by any one tool along with how well that tools works with, or integrates to/from, related systems which also support the given Solution.
Many organizations have settled upon an single (preferably) or a few (less optimally) enterprise standards for Work Management. Other organizations have yet to reach that level of maturity.
If using established tools within your organization, ensure their configuration allows for the features and functions the ITM expects. You may need to work with the team supporting the tool to do so.
If using brand new tools, the basic configuration recommended by the ITM will go along way towards standardizing work, even it relates to inititiatives that are not following the ITM.
Regardless of the tool(s) chosen, the sections below describe how the tool needs to be configured in order to support the ITM. If the tool chosen does not have the capabilities described below, then it's probably not suitable for the scope and scale of work for which the ITM is designed.
There is a vast difference between a tool designed to "make your team more productive!", and one that can support something as large and complex as an enterprise-scale transformation or implmentation.
Of course, it is impractical to delve into the details of all possible tools. Thus, the topics below offer a brief orientation of how this Section will present its information.
Fundamentals
Tool Selection
The ITM does not prescribe any particular tools. Rather, it merely requires that any tool(s) selected can, in fact, support the basic configurations outlined in this Section. Appropriate tools may be on-prem, cloud-based or a service. The functionality described in this Section may reside within a single product, may result from a combination of tools from a single Vendor, may be met by several tools each from a different Vendor.
In many organizations, the tools discussed in this Section are already available internally. If that is the case, it is best to try working with established standards.
In cases where an organization, or a specific initiative, does not already have such tools available, their selection, installation and configuration is a prerequisite to implementing the ITM.
Tools Are Solutions
Operational tools are themselves Solutions. They share the same characteristics as any other Business system. Like any ERP, CRM or PLM, these tools support defined processes. They need similar types of analysis and design, as well as build, testing and deployment. Working through the Iterative Transformation Model is a good way to select and implement Operational tools.
It is not uncommon for organizations to have multiple tools supporting various Operational functions. Sometimes, this arises through acquisition. Other times it is because individual deparments or projects procured their own tools to suit their own needs. Regardless, any one Solution should one, and only one, tool for each function discussed in this Section. Preferably, a corporate standard is used. Like other Business systems, fewer is better.
Integration Advantages
As noted, the Operational functions covered by this Section may be provided by a single product. More often, they are provided by multiple products. While it is possible to mix and match tools from multiple vendors, the advantages of integration cannot be overstated.
Having tools which cooperate with one another will remove many opportunities to introduce problems. Having to manage integrations manually is difficult, time consuming and non-value add.
Arguably, the most important integrations are between Work Management and Collaboration, and Work Management and CI/CD. If these integrations are automated, then the Solution using those tools stands a much better chance of avoiding pitfalls.
Working Through this Section
Concepts vs. Terms
Vendors who produce software that supports ITM work sometime describer it as an Agile Work Management application. Alternatively, many refer to it as an Agile Project Management tool. Regardless, as long as it offers functionality which enables the WMS Items described in this Section, then it is a viable Work Management System (WMS).
Of course, these are not the only terms that vary from one Vendor to the next. For instance, within Jira each Solution is represented by an individual 'Project'. In other words, within Jira there are Projects. In the ITM, each 'Project' corresponds to one Solution.
Do not make the mistake of assuming a 'Project' in Jira corresponds to a "Project" within the organization. A single Jira Project may have multiple PMO led projects working on it. Conversely, a single PMO project may work on multiple Jira Projects. Alternatively, a Jira Project may have no "projects" working on it. 'Project' is a term used frequently across various tools. Rarely is the context consistent from one tool to the next. Similarly, they rarely correspond to what most people would associate with an IT "Project". Do not get hung up on the terminology. Understand the concepts.
Many tools share common terminology for some functionality, such as Stories and Sprints. Most do not have such consistency throughout their applucation. Thus, it is important to differentiate concepts from terms.
ITM Example Tools
To more effectively convey the concepts defined in this Section it is helpful to most consumers to provide actual examples. To provide consistent, holistic illustrations, this Section uses tools from a single vendor - Atlassian.
- Work Management - Jira Software
- Collaboration - Confluence
- Version Control - Bitbucket
These options were chosen primarily because of their impeccable integrations. With proper configuration, a change made in one tool is quickly reflect others. Additionally, the Atlassian tools are widely used and readily available. Moreover, they generally follow industry terminology and standards.
Concepts vs. Terms Mis-Match Example
As an illustration, Jira offers a good example where a Concept and a Term are misaligned. Jira includes three levels of hierachy, Epic > Story > Sub-Task. A Jira Story aligns to an ITM Story.
The ITM stongly recommends a three-level hierarchy of Epic > Feature > Story.  The vendor (Atlassian) describes their Epic as "typically a very large user story". The ITM describes an Epic much differently. So, the term is the same. However, the concept is different. In the ITM, the concept of an Epic more closely aligns to an Epic as the Scaled Agile Framework (SAFe) describes.
Without getting into too much detail at this point, the adjustment for this is to re-lable 'Epic' within Jira to be 'Feature'. Then, to add a "SAFe Epic' field to those Features. This causes some occasional confusion depending upon whether one is looking at the front-end or back-end of Jira. It also affects several Reports.
The important part is that the tool's configuration is aligned to the model. Not the other way around.
Installation & Setup
Each WMS Tool includes its own, standard Objects. Hopefully, the WMS Tool chosen follows conventional terms. If it does, then many of the Objects described below will map to a corresponding Objects in the WMS.
However, many WMS Tools will not have out of the box Objects for each one listed below. Further, most WMS Tools are, themselves, their own Solution. Previously, they underwent an initial Solution Definition and Solution Delivery in order to support delivery of other Solutions.
If the initial WMS configuration is consistent with the descriptions below, then much of the setup described should already be done. In this case, existing Objects can simply be reused for each Solution following the ITM. Alternatively, if this is the first time the WMS is being used, or if its initial setup is inconsistent with the descriptions below, then setup new Objects to suit each type.
Defaults
TBD
Each Object type the WMS Tool offers has a basic, default configuration. Some set of fields is associated with each Object type. It is best to use those defaults when possible. Although, it is common practice to add specfic fields when necessary. Typically, a WMS used to support multiple Solutions has a default set of Objects. Aligning WMS's default Objects with the descriptions below means they are always available for use on any new Solution.
HOWEVER, ... if the Tool's initial configuration established Objects
This is the final section of the Iterative Transformation Model. Return to the Model's main page to explore other subjects.