Our recent heads-up on Accurev prompted an email response from David Richards (CEO of WANdisco, Inc.), to the effect that we'd somewhat understated the level of adoption of Subversion. Well, perhaps we rather assumed that everyone knows that Subversion is almost everywhere, adopted bottom up because programmers like using it.
That said, success with software configuration management (SCM) is as much or more to do with people and process as it is to do with technology. We hear of Subversion shops where adoption has grown like a virus, perhaps subverting the good process associated with "Der Management's" choice of high-ceremony tools and others where Subversion has catalysed the hands-on adoption of an effective Agile process in places which previously only paid lip-service to process. And, how many people are aware of the difference between just downloading Subversion "for free" and buying a proper support contract from, say, Collabnet (see our article here)? Often it isn't the tools but the people using them (and their processes) that deliver success.
So, your evaluation of SCM tools needs to go a lot deeper than just the features list in the vendor brochure. Is a tool compatible with your established process? And, if you don't have a process (or don't like what you have), will your chosen tool help catalyse the adoption of a "good practice" process?
In the interests of helping you to answer these questions for yourselves, can we be permitted to place a small plug for an upcoming conference "The CMDB and CMS - the Powerhouse Of Service Management" being held at Olympia on 8 & 9 July 2008? As a matter of interest, David Richards will be speaking there, but two other things will also help to make this an essential outing for people contemplating an investment in Configuration Management.
Firstly, although vendors are involved, it is run by two independent bodies—the Configuration Management Specialist Group of the BCS (BCS CMSG) and the IT Service Management Form, itSMF International. This is the first time these bodies have presented a joint conference; although the itSMF is the "user group" for ITIL and Shirley Lacy (Vice Chair of the CMSG) is an ITIL author, so there has been a lot of past cross-fertilisation.
Secondly, the conference is presenting an innovative "Interactive Track", which will split up into interactive groups for hands-on investigation of practical configuration management issues such as, what is a configuration management database and/or configuration management system for; how do we judge its value; how can we improve the process behind it; what is the vision we're working towards and how can we bring it to fruition? And, last, but by no means least, how do we choose our tools and actually implement a real configuration management system (or, as Shirley Lacy puts it, "what works and what doesn't").
However, the real point we want to make here is that configuration management brings huge benefits—if you are prepared to put some effort into it. You need independent advice—not just from vendors—and you need to think about your requirements and the people/process implications of satisfying them. It isn't simply a question of buying a tool and telling people to get on with it. Some of Subversion's customers (and Perforce's too, for that matter) are developers adopting an SCM tool that they feel comfortable with, almost in defiance of the tools imposed on them by management. And perhaps management's choice isn't so bad in the greater scheme of things—but no-one wants tools imposed on them (and it is very hard to make a programmer use something he or she doesn't like, if it can be plausibly made to cause them to miss deadlines or become unproductive).
Nevertheless, if you do pay attention to people and process and pay attention to training the people that will use and interact with your configuration management system (so that you achieve grass-roots "buy in" to the process), good configuration governance enables business agility. We were talking with John Metcalfe of Mentor IT (also speaking at the conference, by the way) after a CMSG committee meeting recently, about some of the mashup governance issues we raised here. "Well, that one won't really be a problem in practice," Metcalfe said, "It's just a configuration management issue".
Absolutely right—but how many organisations (or, perhaps, agile departments within bigger organisations) are going to use the new mashup composer tools to jump into business mashups without benefit of a strong configuration management process underneath?
[David Norfolk is on the committee of the BCS CMSG]