Many of you are probably familiar with the ISACA and Carnegie Mellon’s maturity models. You may have come across maturity rating schemes to assess the effectiveness of a capability.
This discussion is not about those, but it is related to and will use some of the same concepts. Instead, we’re going to talk about the practical informal application of those concepts to accomplish goals and meet requirements.
What is a Maturity Model, Anyway?
A maturity model is a framework used to assess and improve an organization’s processes, capabilities, or practices in a particular area. It provides a structured way to measure an organization’s current state against a set of predefined criteria or levels of maturity, typically represented as a continuum from initial or ad-hoc practices to fully optimized or mature practices.
Maturity models typically consist of several maturity levels or stages, with each level representing a higher degree of maturity and capability. Organizations can use these models to identify gaps, prioritize improvements, and track progress over time.
When to Use a Maturity Model as a Tool
When can a maturity model be useful? One situation is when a project is particularly complex or is going to be drawn out for reasons that are out of the engineer’s control. In the case of a configuration Management Database (CMDB), for example, if you already have:
- a tool available
- personnel with the required skill set to deploy that tool
- the data to validate the implementation
then a maturity model might not be overly useful.
However, if you need to purchase or develop the tool – which might take months to complete – then having a partial solution and solidifying your data in the interim can be a very useful thing. Let me give you a simplified example for configuration management.
The need for a CMDB is identified and you have not had any type of configuration management. Through research, you discover that a solution will be costly and as a result it has to be put on the back burner until the next fiscal year.
However, this long delay is unacceptable, so an interim solution has to be deployed. This is where a maturity model can be used.
First, define your goal as the highest maturity level in your model. For my example, I chose to use a 5-level model. The first step of creating a data repository is collecting the data, so we will make that maturity level 1.
Next, we want to improve the usefulness of that collected data, so we will standardize how it is recorded and begin consolidation.
An Example Maturity Model for a CMDB
End Goal: A fully implemented and tuned automated tool that monitors and reports any changes from approved configurations including the addition of devices that are not in the approved asset inventory.
- You want the tool to collect configuration data and compare it to existing information and report any differences.
Maturity Level 1: Collect all asset and configuration data into a single separate repository and require a periodic reporting of each device’s current configuration.
- Depending on the quality of your system documentation this may be just collecting what is already recorded into a single location that is protected from unauthorized changes, or it may involve actually collecting from the devices in the system the current configurations. Either way plan the project and when complete you will have a data repository you can identify for configurations. Document your processes at this step.
Maturity Level 2: Normalize the data and standardize the recording of configuration data across devices. Increase the frequency of reporting of the current configurations.
- Depending on how the data was collected for maturity level 1, it probably is not extremely useful yet. The next project should be started fairly soon after its completion. This level should also include recording the information in a single record (spreadsheet or a simple database). This will make it possible to compare the repository data to the periodic reporting of current configurations. This process is still fully manual, so the effectiveness of identifying changes is very low based on the possibility of human error, and the time span between change and discovery could be quite long. This maturity level will allow engineers to start to standardize actual device configurations because differences between devices are able to be identified. Update your documentation to include this step which may include updating documentation of other processes or procedures.
Maturity level 3: Begin to use scanning to verify configurations as recorded and create a feedback loop to engineers to update and correct misconfigurations.
- This is the first addition of automation. By adding the scanning, it will give that time back to your engineers, increase your accuracy and decrease your reporting period. The move from self-attestation to automated collection is a big step forward. It may be a significant project to implement scanning of all your devices, and some devices may stay manual until the next maturity level. This is a maturity level should be fairly effective in meeting the requirement for configuration management. Depending on the delay to acquire the tool you may be at this level for a while. If you are on a plateau here it should be used to further standardize and consolidate your configurations. Again, update your documentation.
Maturity level 4: Deploy your CMDB tool that you have selected to fulfill your maturity level 5 goal.
- I made the initial deployment of the selected tool my level 4. If you are performing the deployment inhouse, or using professional services getting the tool in place and accomplishing initial functionality is an important step. This implementation should be allowed to stabilize
Maturity Level 5: Fully automated and tuned system that monitors and reports any changes from approved configurations including the addition of devices that are not in the approved asset inventory.
- While technically level 4 meets your goal I like to have it one below max otherwise you run the risk of a fire and forget. By making the fine tuning an additional step it provides the chance to revisit your deployment after a period of time and review that it is still performing as intended. Of course you will be performing regular maintenance, but a defined reason to make improvements is handy in getting your tools to the next level. Review and update your documentation.
I would expect your maturity model to include more specifics for each level including additional completion criteria and expected dwell times at each level. What reporting you will be doing at each level and completion of documentation for each level. This was kept short without all the specifics of project development to fit the format and show the basic framework how this can be a useful tool.
Why should you have 5 projects to accomplish one requirement? Using a maturity model can be a useful way to implement, over time, large and complex systems or processes. By identifying an end goal and intermediate steps with increasing levels of automation, accuracy, and/or frequency.
A maturity model can allow an engineer to implement a simplified form of a process and build on the results to eventually get to the desired end goal. This incremental approach can promote good engineering practices, allow for extended purchasing timelines, refinement of subprocesses, and the continuation of ongoing daily tasks.
The federal space is using maturity ratings and models to assess agencies’ capabilities or define timelines for compliance in relation to the desired end goal of fully meeting NIST and other standards. This is demonstrated in OMB-21-31 relating to auditing.
