Software compliance & the marathon runner’s ‘wall’

I’m currently looking at working with a web-based start up that is in its embryonic stage helping to put a little gloss on its positioning and technology proposition. For myself, hitting the brick walls that rise up in the shape of privacy, security and compliance felt a little like the marathon runners “wall”; it just slams the breaks on after most of the race has been run, but you’re not quite there.

I’ve always stayed somewhat blissfully clear of compliance. I spend most of my time trying to provide lucid (I hope) comment on systems development, architecture and the like. I faced a rude awaking and had to learn fast.

Needing to connect software application development with compliance issues I started looking at software change and configuration management (SCCM) tools that might guide project development appropriately. While I might have thought of any product from Subversion, CVS, Perforce or Microsoft Visual SourceSafe (or Team Foundation for that matter) I ended up looking at a tool that is perhaps one stage further back.

My question to you is: before SCCM for compliance, do we need BRM for compliance?

BRM being Build Release Management, Gartner’s March 2009 Magic Quadrant for SCCM mentions a company called Aldon who I profiled about four years ago when I worked on a dev magazine. Plugging into all of the aforementioned SCCM vendor’s products and providing “automation and compliance support” for the application lifecycle, I thought I might be on the right track.

Knowing that I needed to propose a management-friendly product that guided developers but still allowed them to use their tools of choice, I could feel myself being sucked in by the marketing-speak and suddenly phrases like “self-documenting automated compliance processes” actually started to sound good!

I have not recommended a product either way, but I was interested to read that Aldon says many IT shops have resisted adopting compliance-savvy solutions because it would mean developers would have to stop working in their chosen version control solution.

Only a week or so ago an SCCM company that I have known for years (the previously mentioned Perforce) releases another ‘enhanced’ version of its plug-in for Eclipse, which they hope will see release managers creating and maintaining multiple lines of code.

Great stuff, but will it result it compliant code? Perforce says it provides new preview features and a new integrate dialog to view the consequences of an integration prior to check-in. But should the development team also be using BRM end-to-end process automation and enforced approval management functions to achieve compliance at the same time?

I’m really only touching on the subject. But if I’ve discovered anything, I think if you look at top level compliance issues and then scratch the surface for software tools to help with this process; then it’s more than likely that there will be another set of ‘tools that support tools’ sitting right alongside them. But heck, maybe that’s what keeps the software industry going after all?