In the last blog post, I described the three main levels of AIOps maturity; reactive, predictive, and proactive. In this blog post, I will primarily describe the application code changes and their impact on the AIOps maturity level. Note that I will be using the term application code changes to include new applications as well as changes to existing application because at the end of the day, both will introduce a change in the production environment.

The application code change journey goes through these phases: requirements, design, development, test, and deployment to production as shown in Figure 1. I am simplifying the phases here as I am cutting out the build, functional test, system test, integration test, performance test, UAT test, regression test, endurance test, resiliency test, and the various deployment phases to the various pre-production environments. This journey is clearly driven by a number of reasons such as simplifying certain business operations, introducing new awesome products to stay ahead of the competition, etc. The drive to deploy this change in production is naturally opposed with another drive from the Operations team as this is the team that is tasked with ensuring the production environment stays healthy and a change to the production environment carries a risk to the environment health. Although there has been a lot of progress to help Development and Operations teams work more collaboratively together, there are many organizations where only little collaboration happens between the two teams.

Figure 1: Software Solution Events and Relevant Human Groups

If you look into the application code change journey, you will find there are many roles needed to make this journey successful; the business analyst, architect, developer, tester, infrastructure engineer, middleware engineer, business user (to validate code behavior against functional requirements), test case engineer, automation engineer, performance test engineer, Operations engineer, and various other subject matter experts. All these roles perform critical functions that will impact the production health negatively if not done properly. Below are these critical functions:

1. Validation of Functional Requirements: There are a number of activities that are performed by various teams here before the validation takes place. These activities which are often iterated a number of times are:
   1. Communicating requirements to Development – business analyst
   2. Implementing these requirements (developing code) - developer
   3. Building the code – build engineer
   4. Authoring functional test cases – test engineer
   5. Authoring functional test automation scripts – automation engineer
   6. Functional testing – test engineer
   7. Making changes – all roles
2. Validation of Non-Functional Requirements: Once the activities in the previous function are performed, the following activities, which are often iterated a number of times, are performed by various teams before the validation takes place:
   1. Provisioning the necessary infrastructure to conduct the non-functional testing such as performance and security testing – infrastructure engineer
   2. Provisioning the necessary test tool infrastructure – test engineer
   3. Authoring non-functional test cases – test engineer
   4. Authoring non-functional test automation scripts – automation engineer
   5. Running test cases – test engineer
   6. Making changes – all roles

The delivered application code change must be fully validated against these requirements. If the code change makes it to production without such a validation, there will be a potentially huge risk to the health of the production environment. This will place the production support team in a reactive mode which is the lowest AIOps maturity level.