In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
setup, has a complete copy of all data. Any transaction sent to one site is also sent to all of the other sites, with a master site responsible for establishing the sequence number for every transaction. This has the effect that each site looks and feels as if it is the one and only site - just like a centralized system works. Each site contains a full copy of the repository. So there is no cross-site data access issue, there is no consistency issue, and users can freely roam from site to site.
This has two very large administrative side effects. The first is that you have a warm stand-by disaster recovery capability. If a site disappears, switch to another and keep working. The same information is at each site. The second is that you are less reliant on backups because each site is a backup of the others. So you can do the backup when you need it rather than in case you need it.
Ah, but what if the problem is a deep hidden issue within the ALM tool - then you still need backups to fall back on. In theory, yes. However, CM+ keeps an executable log of everything that happens to the repository, with time stamps. This is known as its transaction journal session. So you really only need to make backups when you start a new journal session (as the number of transaction files can easily grow quite large over time). To make even these backups easier, CM+ allows you to move the entire repository to a "read-only" location. You resume server operation, and as it needs to, it will migrate changed data files to the "read-write" location. Given the 80/20 rule, you end up with a one-time backup of the Read-only state (which can also be used to establish new sites if you need them), and then you only have to backup a fraction of the repository (the migrated read/write files) for "full" backups.
CM+ allows you to specify sites that cannot receive certain files in a number of different ways (e.g. large video files don't go to sites with slow links). This is often done for security reasons in a contractor/sub-contractor model. Of course, in this case, that site is no longer useful as a repository backup.
Next Generation ALM
Who would ever have thought of eliminating backups? Or of letting the customer add their own ALM function add-ons into the tool? Well, those companies which are truly working toward next generation ALM tools have. Although we used CM+ as a sample next generation tool, many tools have 4G features - some for many years. The "virtual file system" of ClearCase should be considered a 4G feature (or at least 3G). RTC has some nice 3G/4G user interfaces. MKS has a solid process engine that lets the customer have ALM add-ons. And CM+ has many nice 3G/4G features.
The goal is to get there. If we define where we're going it's easier to get there. Even a dashboard is much easier to implement in CM+ once we know what's desired on the dashboard.
Next Generation ALM is not an Agile support tool - it supports Agile, Traditional and other methodologies. It has to handle the full range because the needs are different in each organization and project. But the ALM tool itself can be Agile, letting the customer incrementally, through trial and feedback, move the solution ever closer to the ideal. That's why I gave a lot of focus to Customization in this article. Will it help you to stretch your ALM