In my book “Managing Software Debt: Building for Inevitable Change”, chapter 6 discusses Configuration Management Debt and approaches to help keep this type of debt to a minimum. Since I originally wrote this chapter a lot has gone on in the software development and operations communities. There has been a couple of huge uprisings: Continuous Delivery and DevOps. Of course, the ideas expressed as part of these movements are not necessarily new but rather standing on proverbial shoulders of giants.
Managing Configuration Management Debt
When I wrote in this chapter is only a small portion of ideas that are being feverishly adopted across our industry. It is exciting to see just how fast truly Lean approaches such as DevOps are motivating teams, enhancing customer experiences, and driving business results. Application of DevOps and Continuous Delivery are quickly maturing and seem to be a stronger force than even the Manifesto for Agile Software Development.
I would like to review the 3 areas that organizations can work on to improve their Configuration Management performance to put some perspective on how these hold up 5 or so years later:
- Transfer some Configuration Management responsibilities to the teams
- Increase automated feedback
- Track issues in a collaborative manner
Transfer Responsibilities to Teams
Release Engineering teams tend to get overburdened as time goes by. They tend to be centralized and support more teams than they have people. The DevOps movement has put a spotlight onto this problem and provided cultural, process, and technical approaches for reducing the risk of overburdening Release Engineering teams. Taking a DevOps approach implies moving some responsibilities for configuration management to the team.
Increase Automated Feedback
To reduce the impact of increasing the team’s platform complexity by adding these responsibilities, organizations must invest in increasing automation and developer user experience of automation tools. The other aspect of transferring responsibilities to teams from the book was automating Install and Rollback procedures. Going beyond Continuous Integration towards the fully automated build, test deployment and monitoring approaches contained in Continuous Delivery encompasses this idea. There has been a tremendous amount of innovation that makes Continuous Delivery more approachable including the growth of Cloud Computing adoption to Chef & Puppet to automate infrastructure to the promise of Platform as a Service (PaaS).
Track Issues Collaboratively
Automated build pipelines and teams that have more responsibility for software operations leads us to ask about who tracks issues. Again, the DevOps movement has pushed our organizations to think about the responsibility for production deployments. The more teams can take responsibility, given appropriate automation and developer user experience with the tools, the more responsive they will be to customer issues and operational changes needed around their software. It is my contention that the more responsibility teams have for production operations the better production will operate.
In review, I probably write enough on Configuration Management Debt. In my consulting and product development activities since the book I have realized that focusing on Configuration Management Debt first makes steps to address the other four types of software debt (technical, quality, design, and platform experience) easier to see. The build pipeline(s) and the spread of responsibilities can tell teams a lot about where they can find optimizations.