A company called Serena Software Inc. has been trying to sell me on the idea that software configuration management is an important security tool in these days of terrorist dread. The idea is that somebody inside or outside your organization could sabotage critical source code, and without a good configuration management system, you'd never know until it was too late.
Of course, Serena makes pricey, high-end configuration management tools, so it's not exactly an impartial observer. But security does matter, and so does good configuration management.
So, will fear of sabotage get corporate IT shops looking at their configuration management needs anytime soon? Probably not.
After all, how likely is that kind of source-code sabotage in most IT shops? Why would somebody go to the trouble of corrupting a Web store's source code, when a buffer overflow attack is so much easier? Why attack any custom application, when the real damage would be minuscule compared with a conventional terrorist attack? It's not a credible threat.
No, fear of sabotage probably won't put configuration management on your agenda. Neither will fear of a business catastrophe caused by a new application that doesn't work and can't be rolled back. And fear of confusion and chaos in your software development projects won't do it. Most of us have lived with that for years.
Right now, just one thing will make us look hard at beefing up our configuration management systems: the possibility that it will cut costs.
And that doesn't look likely, does it? These big-deal configuration management systems -- the kind sold by Serena and IBM and Computer Associates and Compuware and Rational Software -- cost a bundle. They're a lot of work to set up so that all of your mainframe and server and PC and Web code is tracked by the system. They require training and time and discipline.
All that translates into money spent, not money saved. And unless you need it to get ISO 9000 certification or to nail down a defense contract, why even think about configuration management now?
Why? Because you can't cut costs if you don't know what you've got.
You can't streamline software development if your Web developers and mainframe programmers are duplicating one another's work. You can't simplify transactions and shorten processes with a patchwork of ad hoc, outdated, single-project configuration management tools. You can't even see the opportunities to cut costs.
Until just recently, that didn't matter, because we weren't worrying much about costs. During the Internet boom, we had plenty of money and bodies to throw at every problem. We made things up as we went along, mixing and matching desktop software and back-end systems and Web sites, repurposing mainframes as servers and applications as Web pages, turning our customers into users.
OK, so we reinvented lots of wheels and ended up with lots of mystery code, but speed was more important than money or formal processes or knowing what we had. We were working in Internet time, all the rules were broken, and chaos was our friend.
Now the party's over. Money and bodies are in short supply, and to make the most of what we've got, we need to know what we've got. We can't afford the luxury of chaos now -- and we'll likely never be able to afford it again.
Maybe we won't implement state-of-the-art enterprise configuration management this year -- this is pricey stuff, after all, and it's the worst possible time to try to come up with the money.
But soon we will. If we really want to squeeze the most out of our software assets, we have no choice.
Because in the long run, if we manage our software development better at an enterprise level, we will cut costs -- and speed development, reduce risks and, yes, improve security, too.