Aircraft Carrier Called the "CM"

Note: Based on the CVN 77 Concept Design

The key to a successful aircraft carrier is to have a properly operating runway, including procedures, staff, and technology. The runway of an aircraft carrier has similarities to what is needed to get the releases of an application deployed. When the runway of an aircraft carrier is built effectively, project releases can “take off” into production, much like jets can take off from the runway of an aircraft carrier.

Configuration management (CM) acts as that runway for applications. It provides the procedures and technology to control and migrate the code off the runway and into the customers’ realm (production). CM also provides a mechanism to ensure all pieces of an application release are accounted for to ensure a successful take-off. A good CM runway can enable quick releases and allow the pilots (the developers/ engineers) to focus on building the jets.

CM Support of the Application Lifecycle
When we look across an application lifecycle, it is important to determine what infrastructure is needed to ensure that the application stays afloat and can be readily deployed (or released). The base level infrastructure should include hardware (e.g., servers and desktops), the network, and the system or network administration to setup and maintain each. This may be considered the hull and engine of the aircraft carrier. We can then focus on the software engineering disciplines such as project planning, requirements engineering, architecture, testing, and CM. What is the role that CM plays and how important is it? As mentioned, one analogy is that CM can be the runway for an application. How well structured, trained, and aware of the parts we are can make a difference in the success of the application release. If you are only looking to prototype an application without formally releasing it, then having little or no CM process and technology is worth the risk. When a company is building an application, however, they typically expect it to last as many years as possible and to also contribute to the profitability of the company. This implies that if they can sell it, they hope to have numerous releases of the product. Immediately after the first release, the onerous task of maintaining an existing release in the field while developing a new release of the application internally begins. In order to stay in business, it is critical that the regression of application functionality does not occur. The focus becomes establishing a good way to handle supporting multiple releases while reducing regression in the application. CM provides that solution.

Getting Started: CM Infrastructure for an Application
A question that many new application development teams face is how soon they should begin  establishing their CM infrastructure and how robust does their CM have to be? The ideal scenario is being allowed to share an existing CM infrastructure. This implies that a company has been in operation for a while. However, a full CM infrastructure may not be feasible for most startup companies who do not have the resources to do this work and, initially, is focused on getting an application to market. To answer the question on how quickly the CM infrastructure should get set up, let us examine two scenarios: setting up CM at the beginning and setting CM up after release 1.

Building CM infrastructure prior to (and during) release 1 involves investing effort to establish an effective CM infrastructure before beginning an application lifecycle. This has many advantages. The CM processes can be tailored specifically to the application needs and all CM controls can be available during the first release. In addition, once a full infrastructure is in place, any type of development methodology may be applied. The disadvantages of this approach mean that resources are applied to infrastructure tasks versus focusing on getting the application to the marketplace. This can be critical to startup companies. If they do not get a product to market and establish market share soon, the company will go bankrupt

Building CM infrastructure after release 1 has the application team focusing on developing release 1 then establishing the CM infrastructure thereafter. As mentioned, often times CM is not focused on until an application team nears the completion of the first release or thereafter. The advantage is that if the immediate goal is to get the product to market, then resources and funding are focused on development. Therefore, there is little effort focused on CM and other software engineering disciplines. The disadvantage of this approach is that a lack of CM can impact subsequent releases. While this model may not be exact, it illustrates that the project release schedule for release 2 (or subsequent releases) may be extended. Typically, in this approach when the second is underway, the focus on CM becomes serious since a branching and merging process is needed to focus on release 2 while maintaining and patching fixes to release 1. If key elements of CM are not in place, it can take more time to solve problems and get the release out due to the risk of overwriting code increases, risk of losing bug fixes increases, and therefore causing regression in functionality that can impact the market share of the application.

Some CM is Better than None: An Alternative Approach
Now that we have seen two broad approaches to introducing CM, we can add a third. This focuses on introducing the high priority CM functionality prior to or during release 1 and focus on the lesser priority CM functionality at a later release. As mentioned above, a company or application team often does not have the means to implement full CM, so they end up implementing very little. In order to reduce some of the project risk, introducing some elements of CM prior to or during release 1 can be a wise decision. This may be considered the “just-in-time” approach. With this in mind, what CM functionality is typically included in a robust CM infrastructure? This may include (but not be limited to):

·         Version control technology

·         Checkout/check-in procedure

·         Build technology

·         Build procedure

·         Branching and merging procedure

·         Change control procedure

·         Problem management technology (e.g., defect tracking, etc.)

·         Problem management process

·         Audit procedure

·         Reporting/status accounting procedure

·         Release technology

·         Release procedure

Next, you should prioritize which of these CM functions are important for release 1 of an application and deploy this CM functionality first. Version control technology, checkout/check-in procedures, build technology, build procedures, and release procedures may be important for release ,1 in order for the code to be controlled and released in an effective manner.

For release 2, you continue the prioritization and deployment. For example, branching and merging procedure, change control procedure, problem management technology (e.g., defect tracking, etc.), and problem management process are deployed for release 2, and so on. This is an example of incremental deployment of CM functionality that focuses on allocating CM tasks over a period of time so they can be more easily accomplished.  These can be offered to the application team on a just-in-time basis and ultimately provides a balance between funding, resources, and risk management.

Lessons Learned
In an era where many lifecycle methodologies are utilized, where focus is faster releases, and agile methods deliver releases more frequently to the market, a fully enabled runway can be advantageous. Having been involved in numerous CM infrastructure implementations under various scenarios over the years, I have learned some lessons.

In one scenario, I was involved with a new application development effort a few years ago where the application development team decided to use Scrum, a form of agile methodology. This involved producing monthly release deliverables, effectively implying that the project lifecycle per release would be no more than 30 days. The issue we encountered almost immediately was that there was no CM infrastructure to support our needs. After deploying the first release late, the development team began the second release. Critical issues arose immediately because there was no CM in place:  there was no branching and merging process to support the next release and to apply bug fixes to the previous release; there was no change control for new requirements; and there was a very limited problem management process to effectively manage the defects coming in. This initiated a CM project to establish this CM functionality.In another scenario, many years ago, I was involved with establishing a shared CM environment. Initially, we did not create standard CM processes and it quickly became challenging to maintain the environment. Common locations for repositories and standard structures made it very hard to establish dependencies. This also made it hard to automate since there were no standard naming conventions. This initiated a CM project to establish common CM processes, naming conventions, and eventually automation.

Summary
When entering into an application development venture, it is important to apply software engineering disciplines to help control and manage the effort. An effective CM infrastructure can provide an effective runway in which releases of an application can take-off. It is important to consider when to establish a CM infrastructure. While it is preferable to establish the CM infrastructure upfront so that CM processes can be tailored specifically to the application needs and all CM controls can be available during the first release, this may not be feasible to younger companies. An alternative is to apply a just-in-time approach. While this requires some forethought for prioritization, it can be the most efficient use of resources, particularly when CM resources are limited.