This third installment in our blog series on implementing DevOps in highly regulated environments (HREs), which is based upon a recently published paper, discusses the second step in a DevOps assessment: establishing the pre-assessment DevOps posture of an HRE. (Read the first and second post in the series.) The posture is the current DevOps implementation, if any, in an HRE's software development lifecycle (SDLC). Recall that the ultimate goal of the DevOps assessment is to improve an SDLC. In this case, the tool set being used to achieve that goal is DevOps. It is important to understand the maturity level of an SDLC and the presence of any DevOps principles that have already been implemented. This understanding will facilitate the DevOps assessment and concretely identify the amount of work needed to reach an ideal DevOps state.

In this post I will use the following three terms:

• DevOps assessment: the task of analyzing an SDLC and recommending improvements, primarily by using

- The pre-(DevOps)assessment posture: the state of DevOps usage in an SDLC before starting the task and

- The post-(DevOps)assessment posture: the state of DevOps usage in an SDLC after task completion

Establishing the pre-DevOps assessment is done in three steps:

1. Understand the development group's ideal DevOps environment.
2. Accurately capture their current SDLC.
3. Compare ideal with current and identify the differences.

After the pre-assessment posture is determined, make sure to document it in the final report and to use it after the post-assessment, which will be discussed in a future post. Now let's discuss the mechanics and considerations of each step.

1. Understand the development group's ideal DevOps environment. It is important to determine if developers have envisioned an ideal software development environment. As discussed in previous posts, folks requesting an assessment are typically only focused on getting rid of problems, but developers may see this assessment as an opportunity to reach an ideal SDLC state, or in this case, an ideal DevOps state. The way to understand this ideal environment is to sit with the developers and ask them outright to describe it. In our experience, this exercise has yielded excellent descriptions by asking the following questions:

• Do you want environment parity with production?
• Do you want a tracking system for all stakeholders?
• How often to you want to deploy to production?

Once the ideal environment has been captured, review it with the developers to assure no details were omitted. This description can be designated as the ultimate goal of implementing DevOps for this group.

2. Accurately capture the current SDLC. This step may intersect with the actual DevOps assessment: both identify obstacles in the current SDLC. As in the previous step, allowing the developers to describe their current SDLC will help to produce a clear understanding of the actual state. The process can be enhanced by asking the same questions as in the previous step, but in a slightly different manner:

• Do you have environment parity with other developer machines and production?
• Do you currently have a ticketing system to track projects? If so, can all stakeholders access it?
• How often do you deploy to production?

As in step one, after the actual state of the SDLC is captured, review it with the developers to assure its accuracy.

3. Compare ideal with current and identify the differences. After both ideal and current SDLC states are captured and mutually agreed upon, the final step is to compare and find the differences between them. This step can be done by taking each component of the ideal SDLC and comparing it to the current state of that component. This comparison allows HRE organizations to deduce how much work is needed (or not) to achieve the ideal state.

It is important not to view this comparison as a one-to-one mapping that is easy to assess. In many cases, a component of the ideal SDLC may exist in multiple components of the current SDLC. An ideal component may not exist at all in the current SDLC. The end result is typically a current component that needs significant maturing to achieve the ideal state. Of course, some of that maturing is achievable with DevOps.

In the past, we have seen multiple SDLCs that are in an intense state of disarray, with hard-to-follow processes and practices that are slow and archaic. In some cases, this disarray is the result of an old process that work[s] so why change it...until something bad happens...ok now let's change it. In other instances, it exists as a result of conforming to imposed policies (common in an HRE). If the current state of an SDLC is in disarray and needs a lot of work to mature to a point where DevOps can be considered, personnel should be told immediately.

One critical point to keep in mind when determining the pre-DevOps assessment posture is to communicate with actual developers and not management. We have seen scenarios where managers paint a picture in which all is well and no issues have occurred. This picture is in contrast to what the developers describe, which is a very sub-optimal SDLC. Talking to developers will yield the true current state of the SDLC. Unfortunately, some managers may see the assessors as a threat to their jobs and paint a wonderful scenario just to get them out of the way and not cause them problems. After the pre-DevOps assessment posture determination is completed, the assessment team can start with the actual assessment, which will be the topic of the next installment in this blog series.

Additional Resources:

Read the paper from which this series of blog posts is based upon, Implementing DevOps Practices in Highly Regulated Environments, which was presented at the 2018 International Workshop on Secure Software Engineering in DevOps and Agile Development.

Read other posts in the DevOps blog.

Listen to the SEI Podcast Roundtable, How Risk Management Fits into Agile and DevOps in Government.