Config Managment Maturity Levels
Config Managment Maturity Levels
Join the DZone community and get the full member experience.Join For Free
Config management is a big deal for any IT organization that intends to scale up its operations, and it's certainly getting more attention and broader application with the DevOps movement. I found an interesting CM crossroads blog by Joe Farah that tries to codify the current state of Configuration Management into 4 generations of maturity. Here's my summary of his four generations of CM (for you TL;DRers) followed by Farah's descriptions:
1G: Still using a command interface, but keeping it simple. Tools work together reliably.
2G: All functionality can be simplified or automated with tools that take care of tedious commands and save you time. This what tools like Puppet and Chef do, and it's the type of thing that you should have been doing all along.
- The toolset will now act as a communications hub for different roles in the product team (but only the product team).
- You can tailor your toolset to your process and not the other way around.
- An interface is always available on many machines that gives you traceability for all the product team's actions
- Now the traceability and reporting is available and communication is happening among executives, suppliers, customers, and other people outside of the production team.
- Traceability and communications dashboard is easy enough for business folk to use.
- Various inter-department meetings get captured as well.
Hope I understood that right. Here's what Joe said:
1G: You're trying to get the tools to work consistently with no gotchas, while keeping the command interface simple.
2G: You're trying to make all functionality available without having to memorize commands. You're trying to piece together a set of tools into a solution. You're trying to automate and, where possible, simplify operation to minimize human error and improve data quality.
3G: You want to use your ALM tool as a communication center for all roles across the product team. You focus on ease of use, on a role-by-role basis. You're making the tool conform to your process rather than vice versa. You're looking to have information and actions front and center, with role-appropriate to-do lists, single-click reports, point-and-click rapid traceability navigation, and active workspace trees that compare your CM context view to your workspace and show you the details on the tree view without you having to ask.
4G: You focus on task-based and role-based dashboards that encompass areas of information and action specific to tasks and roles you need to support. You want to run all meetings from the tool with in-meeting capture of decisions and actions. You look to extend communication beyond your product team to customers, suppliers, and corporate executives. As such, you want to ensure that your tool requires no training—or perhaps just some process training and a 10,000-foot capability overview. You seek to replace all administration training with a few comprehensive admin dashboards. You want the tool to understand your process and to take advantage of this understanding.
-- Joe Farah
Joe thinks that most tools fall under the first and second generation category, while only a few are third generation. He believes that there is only one 4G solution out there, but he doesn't specify.
The question is whether 4G is only appropriate for large organizations. I think it could probably be useful for medium sized businesses as well because communication and collaboration issues between business, operations, and development are hard to stamp out, even in smaller organizations.
Where do disparate open source tools like Puppet, Jenkins, reporting, monitoring, and communication tools fit into this hierarchy? Do you think you could make a reliable 4G CM solution with all of the OSS that's out there? It would be cool to see if its possible, but it would be a time consuming task, no doubt.
WDYT about this analysis of CM? Check out Farah's post for a more in-depth look at what he means.
Opinions expressed by DZone contributors are their own.