Do Your CM/ALM Tools Help Secure Your Development Assets?

Pick-up-And-Drop Technology Transfer

The first question I might ask is do you have Pick-up-and-drop technology transfer. Can you take your product and drop it into a new site? Whether it's disaster recovery or a company merger, you should have this capability. Where are your development assets? Scattered across developer desktops? Scattered across servers? Scattered across multiple sites?
Your development assets include everything from product inception to customer tracking. These are all critical to development. They do not start at the software design group and end in the verification group. They also include the tools and platforms required end-to-end - including your customizations. If you can easily pick-up-and-drop your product into a new project setting, you're sitting in pretty good shape.

Backup Basics

Another measure of your situation is your backups. How complex is your backup process? Does it include information that rests on a developer's desktop (or notebook), and if not, what is your exposure here? Does design documentation sit on a developer's disk? What about work in progress - how easy is it to "shelf" it. Does your CM/ALM tool allow you to do consistent backups, or do you need a lot of post-recovery maintenance to get things back on track? Is your ALM suite spread across multiple servers? Where does the glue reside between components?
If you run a multiple site development shop, does consistency extend across multiple sites? Can you easily relocate one site, or perform data recovery at one site, without disrupting the others?

Beyond Backups

 Backups generally provide a way forward, a means of recovery. But still, precious time is lost in the recovery process. There are hardware solutions, such as RAID (disk arrays), and hybrid solutions such as disk mirroring. Some CM/ALM tools allow specific mirroring, of both source files and meta-data files. The advantage here is that a smaller portion of the disk (typically specific directories) requires mirroring, improving bandwidth and reducing disk space requirements. Another advantage is that the tools will typically allow you to recover quickly or even automatically from a disk outage.
Another means of recovery supported by some transaction-based tools is to replay the transactions processed since the last checkpoint/backup. If transactions are located on a different disk from the rest of the repository, this can add some redundancy to your backup strategy.
CM/ALM tools should not hiccup if there was a power outage in the middle of a critical operation. They should always recover gracefully. Any manual intervention required to recover will lead to productivity loss.

Data Sabotage - Checkpointing and Roll Forward

For any number of reasons, you may have someone manipulating your data illegally. Maybe they delete a pile of data. Or maybe they more subtly morph the data so that the problems are not noticed for weeks or even months. To deal with this, your CM/ALM tools need to be able to perform 3 basic tasks: checkpoint your repository (or in the worst case full backups); locate potential areas of data sabotage (or for that matter, a typo/inadvertent action that went unnoticed) and repair the errant transactions; roll the repaired transactions forward from the checkpoint.
Although it may seem that such a capability requires a heavyweight solution, these capabilities are not that difficult for CM/ALM to design into their tools from the start. CM+, for example, allows very lightweight checkpointing (a few seconds) and even automates this. Given a checkpoint, you can actually view the repository as it was at the time of the checkpoint, in parallel with your running system. After editing transactions and placing the checkpoint in place as the "current" checkpoint file,