Software configuration management is a set of business problems to be solved, and the set of programs and processes used to create a solution is very much like a software application project.  We can use the same processes we use for software development to make our SCM system decisions – by treating them just like we treat any other software project – by using a Software Development Life Cycle.

There are many types of software; many categories of software. There is systems software, applications software, network software, and web-ware. The list goes on, including some not so good types of software like malware, adware, and spyware.  Applications software is a set of programs that do the work for users. Users that solve business problems benefit from applications software.

If it’s as easy as following an SDLC, why do we struggle so hard to accept good software design principles as the best way to identify and design our software configuration management problems? Why do we have stubborn, entrenched software engineers squaring off against one another to defend their favorite continuous integration servers, scripting languages, and version control systems?

We know software. We know software best practices. Why then, do we sometimes throw this all to the wind and fight like grade school bullies? Sorry it this offends some of my colleagues; I have unwavering respect for your abilities as software professions and it’s not my intent to insult you. It is my intent to get your attention. If I just sparked a fire in your belly, you know exactly what I’m talking about. Why do we spend so much time convincing other team members to accept the software systems we like – convincing them to accept our way of doing things – yet staunchly refusing to be flexible and learn other ways of working.

When we design a software configuration management system, we need to think like a software engineer developing an application for a complex business problem. That means we start with identifying the stakeholders. All of the stakeholders; including the managers, testers, maintainers, and of course, the developers. Who carries the most weight? Should it be the developers? Should it be the testers? How about the configuration management team?

As with any problem, it’s important for us to see the big picture. What are the requirements? We find these out from the stakeholders for applications development.   We spend time analyzing these requirements. They are best if written down, complete, and prioritized, but that’s not the most important aspect.   Thinking about the problem correctly is the most important thing.  We need to think about the software properties our stakeholders would like to see in the solutions. And we need to know they will evolve over time.

Change management must be taken into account. We need to know what is likely to change and plan for it. We need to lock down the most solid requirements first – just as we do with applications design. What are the relationships between the selected software in the system? What are the major components of the configuration management system?  How tightly coupled are they? What kind of customization has been done?   Do we need any custom plugins? Will they need to be updated as the other major parts of the system evolve?

But let’s back up for a moment. Since we need to plan for changing requirements, we need to start by recognizing that change actually begins with the stakeholders. Designing for change means we’ll be expecting the group of stakeholders to change over time. Who are the stakeholders today, and who will they be next year? Who will they be five years from now?

Without an SDLC, SCM is just another software project doomed to failure.

SCM is Software.