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

the system will automatically replay transactions, preserving original timestamps.
If this level of data robustness is a requirement, it's important to look "under the hood" at the architecture of your prospecitve CM/ALM solution. With a reasonable bit of discussion/reading, you should be able to familiarize yourselves with both the capabilities and limitations, the latter often being carefully hidden within the marketing hype. A good solution will even provide you with an added layer of protection against software errors in the CM/ALM solution.

Hot/Warm-Standby Disaster Recovery

When a disaster arises, whether it's a disk crash or a natural or man-made disaster, ideally you'd like to continue operation with barely a glitch for your users. If you have a solution which can do this, you have hot-standby disaster recovery in place. If your users have to restart their application, but otherwise can continue from where they left off, you have a warm-standby capability. If your users are off-line for more than a few minutes, you will have some productivity loss. This may be more severe in mission-critical scenarios which cannot tollerate down-time.
One means of improving your recovery speed is replication. If your repository is replicated at another site, you can generally be up and running more quickly. Of course the tools must also be replicated. In the worst case, you may have some replication latency and lose a bit of data. If you have continuous replication/synchronization of your data between sites, you're in good position to establish a warm-standby, and possibly even a hot-standby capability.
Replication can work from a repository perspective - identifying data differences and synchronizing them - or from a transaction perspective - processing the same transactions in the same order using the same tools at multiple sites. The latter generally requires less bandwidth and provides more site autonomy, but this will vary with each solution. If your clients can be easily (or better yet, automatically) switched to work with any site, you have at least a warm-standby capability.
I remember the first time our main repository disk crashed and we were able to continue on without a hiccup using our multi-site as a warm standby recovery capability. Now a RAID (disk array) would have worked here too, but there are less neat "disasters" that may require a multi-site based solution.
As a buyer of CM/ALM tools, it's not sufficient that a vendor advertise such capabilities. If this capability is important, it must be easy and reliable. Your vendor should be able to readily demonstrate the capability, or better yet, have you demonstrate it yourself. A complex warm-standby capability may cause you to delay its implementation, or may defeat you when the need to use it arises.

Data Segregation

Of course, securing your data goes beyond maintaining data integrity. It also includes the ability to control data access. Beyond basic password control, your CM/ALM tool should provide a means of segregation data into (possibly overlapping) partitions that are appropriate for your level of access. Access control can get very complex very quickly. It's important to have a variety of means to control access so that complexity can be kept to a minimum.

Here are some examples:

• Segregation of data by keeping it in separate repositories, each guarded by user name/password/etc. controls.
• Segregation by role, so that certain roles are required to see and manipulate some of the data. For example, a customer role may have limited query capabiliites, while a developer role may have a much broader access.
• Data filters can be used to arbitrarily filter what gets through to an end user. This can be done on