Gitting along with Configuration Management and Perforce Helix. - Configuration Management is fundamental to good governance, but it is a journey not a destination.

I met someone who teaches Configuration Management in Sweden, on the Perforce On Tour shindig in London a week or so ago. Configuration Management (more properly, Service Asset and Configuration Management) is a good career, with excellent prospects, and his students apparently find his course both challenging and rewarding (he runs anonymised surveys in order to find out). He tells them (and I’d agree) that Configuration Management is fundamental to good governance in an automated software-controlled business. If you don’t know what you have, where it is, who’s responsible for it, and how it interrelates, and so on, you can kiss goodbye to security, business continuity, and all those good things – but he also tells his students that Configuration Management isn’t an end in itself, it’s a means to an end (it is important that your investments in Configuration management tools and databases are actually used by people).

So, what’s the problem? Well, it’s just that graduates from his course are numbered in tens rather than thousands, and there aren’t many other specialist configuration management courses in the world. Unfortunately, there are millions of organisations that need configuration management (which is partly why configuration management is a good career, of course, as you can find out at BCS CMSG meetings). But automated businesses, running on software, are everywhere; so what is happening?

Well, everyone is actually doing configuration management (defined as something like this), to a greater or lesser – SCM (Software Configuration Management) – extent, but they are doing it in their heads, or in disconnected spreadsheets etc. If the right person, with a brain the size of a planet, is in the right place to manage everything needed for a business outcome beyond merely a successful software build, this works well enough – until it doesn’t. It’s a high risk approach, but as long as none of your competitors are doing it better, you’ll probably get away with it and as long as the general maturity of IT remains low, everybody will accept IT failures (which are often failures of configuration management) as a fact of life and not hold anyone in particular responsible, when things do go wrong.

This is the context to talking about some Perforce issues. Perforce is a good tool, capable of a lot more than mere SCM, but it needs to be deployed in the context of a bigger process, to deliver all that configuration management makes possible. That said, although enterprise-wide configuration management (dealing with all assets and their relationships, not just code assets) is a good thing, it’s not all-or-nothing. It’s a vision, a journey, and implementing just source code configuration management is a good start. It’s just that one should never see it as the journey’s end.

One competitive issue that Perforce is facing is Git SCM, it appears. Git is exceedingly popular with developers but it is really just software configuration management and it does have issues with scalability and large binary assets; and is not always quite so popular with managers. Simple distributed Version Control Systems (which is what Git is) are good and Agile – but at the large enterprise scale, if not before, some measure of central (architectural) control is needed. It is worth noting that Git was built for managing changes to the Linux kernel over 10 years ago – but even there, according to Mark Warren of Perforce, there is central control (by Linus Torvalds) of a “blessed repository” before distributed changes make it to the Linux kernel distribution.

There is absolutely nothing wrong with Git, in the context for which it was designed. Open Source is just fine (I’m sure you can find commercial support for Git if you need it) and distributed development is productive and speedy. But using Helix (the current branding of Perforce versioning) to manage the Git repositories also makes a lot of sense, I think. If it is successful, most Git enthusiasts will be mostly unaware that they’re using Perforce at all!

Nevertheless, there are value-adds from Helix that may be far from invisible, to the right people. Perhaps chief amongst these is its new security analytics capability. When IP leaks can be blamed for major company failures, the ability to discover dysfunctional or malicious usage patterns in access to IP assets in Helix repositories might sometimes save the life of a business. And Helix can manage far richer assets than just source code (which is, basically, just highly-structured text) – reusable graphics components, documents and so on. 

Another Perforce capability that I thought could further help to expand its context beyond source code asset management (which is mostly what Git does) is Commons – see my comments here. This has been very successful for Perforce internally, but hasn’t attracted the outside interest amongst its customers that was hoped for. So, and there were no roadmaps announced on the tour, Perforce is revisiting the Commons user experience to suit non-IT customers, who just work in directory structures these days, so it should end up with a user experience something like Dropbox at some point. I’m looking forward to following this development.

So, where do I think Perforce is at now, overall? Well, I think its future looks good. I particularly like its idea of working with Git, in such a way that Git users can be almost unaware that their Git repositories are being managed by Perforce – and that they’re not experiencing some of the scalability and repository-proliferation issues some Git users experience. But I also like the fact that Perforce looks beyond mere SAM – Software Asset Management. Nevertheless, Perforce must continue to focus on what its existing customers need as well as what could excite potentially new customers, and maintain empathy with user experience outside of the company itself. I see no reason why this should be a problem.