La mort du CM (and Other Predictions)

It's the start of a new year, and that means predictions for the future. Not content with a twelve-month window, I'll go out on a limb with some longer-term prognostication. Also, of course, some suggestions on what to do when I'm right. Because everyone else is making predictions, too, I'll try to keep this light and fast. Here we go:

1. Microsoft TeamSystem will kill CM.This isn't as bad as it seems. In the short term, of course, TeamSystem will flop—all new technologies suffer a pregnant silence in the year after they come out. This is when various large corporations pay to beta test the product and work the bugs out. Afterwards, the next version is a killer app.

In this case, TeamSystem will provide a platform for understanding what SCM can do. Automated processes, Build automation, Change control, Defect tracking, Earned value, all the way up to whatever starts with 'Z', TeamSystem shows enormous promise.

Other developers have provided  implementations of task-based development, builds integrated with checkins, etc. Now Microsoft is bringing their enormous market share to the table with a “real” CM tool. This will set the bar not just for vendors, most of whom already offer some or all these features, but for development shops, too. Because of TeamSystem, every still-employed software manager is going to know about the stuff that CMers have been discussing for years.

2. SCM will be a commodity function.

One of the effects of TeamSystem will be that build systems become  commodity products. Existing systems that rely on hand-crafted scripts that understand the environment and the system being built will be trashed, replaced by inefficient, unoptimized systems that are less capable, less costly, and able to do far more because they will be standards. At the very least, you need to look at Apache Ant or Nant plus something like CruiseControl. Realistically, though, you should be looking at Maven.

3. CM folks will climb the value chain.

Because so many CM functions—like integration builds, workflow reporting, and impact analysis—are going to become commodity data, CM analysts will advance to a higher productivity level. Time that was spent collecting or refining data will be freed up for other purposes. This is a productivity increase, and like every other increase in productivity it will cost some people their jobs. Others will find themselves doing things that weren't a part of the CM job description in 2005. Taking advantage of the automated data collection will let more teams achieve more sophisticated development than was possible in the past.

The “active” CM folks—those who participate in the development process—will probably receive these changes as positive steps. Their reporting will be more automated, their scripts will have a better abstraction layer upon which to build, and so the more sophisticated tools will turn them into more advanced, more sophisticated participants in their development organization.

On the other hand the “passive” CMers—who have allowed development to bypass them, substituting simple “release forms” and reports for involvement in the development cycle—are going to get nothing but stress from these changes. The pressure to produce more for less money and the increasing productivity from advanced tools will produce engineering groups that do more CM functions internally. There will be more of these groups feeding the same one or two “CM gurus” reports generated by the new generation of tools. Sorry, folks, but you're going to be spread thinner and thinner.

4. Traditional CM vendors will attempt ITIL integration.

CMers haven't done the best job integrating the ITIL folks into our community, probably because so many shops fall short when it comes to tracking the kind of data ITIL needs. The next year or eighteen months will show the beginnings of convergence as CM vendors (not Microsoft—they've made their big effort for the decade) begin to try to position their extant change and defect tracking products into the ITIL space.

Microsoft is probably the best of all the OS vendors when it comes to automating the OS patch/upgrade process. Sadly, however, there isn't yet a standard mechanism for reporting this kind of information. SMS can, with help from the administrators, install most OS and key software patches, but reporting and interdependency data is not there yet. Look for the various *nix vendors to begin providing a similar patch installation mechanism, and to go one step beyond Microsoft to provide complete patch reporting as well.

From a CM perspective, whether it's an ITIL CDB[1] or traditional CM SDE/TOE[2] monitoring, being able to automatically obtain a precise description of the state of a platform is crucial. So far this has required different mechanisms for different operating systems. Look for OS vendors to incorporate the best ideas from ITIL product vendors in the next year. The new Microsoft Longhorn release will almost certainly provide such an interface. Assuming that Microsoft provides a standards-compliant API, other OS vendors will likely simply copy the Longhorn interface. (This is a questionable assumption: Microsoft is famous for being stupidly non-accessible for little or no good reason.)

5. Sarbanes-Oxley will spread to other countries.

Sarbanes-Oxley is the name of a U.S. law that requires change tracking for all significant financial elements in public corporations. The public grace period is basically over, and most accounting/financial organizations have staked out their positions on what the law actually means. To date there hasn't been much legal action to provide judicial interpretation. (This is a good thing: “not much legal action” means “no large corporation has imploded.”)

For non-U.S. readers in Europe and Canada, a prediction: You'll have your own version of SarbOx within three years. It will be sooner, of course, if one of your large corporations self-destructs. But three years even if not.

6. Sarbanes-Oxley will be tested in the United States.

SarbOx has been one of the driving forces behind the widespread adoption of the ITIL. More and more IT managers are coming to understand that their sophisticated MRP, ERP, and/or CRM systems are not black boxes—that they've got a staff of coders frantically trying to squeeze more profit from the business using software. And that, of course, means that the CM Office can offer value to IT as well as R&D. If you aren't already doing so, I predict you'll have some pretty surprising meetings with your IT department this year.

The important CM aspect to SarbOx is that it requires change controls on systems that have a significant impact on the financial statements made by a company. The act provides some guidance on this, but only this year is progress being made towards consensus on what is and is not required.

As a case in point, the PCAOB[3] recently instructed auditors to begin telling their clients which controls were not, in fact, necessary for compliance. However, the difference between “we feel this is not necessary” and “this is definitely not necessary” comes from judges, not accountants. Until case law exists, no auditor will feel truly comfortable with ignoring controls.

And case law comes from court cases, which can only take place when someone goes to court. While there is always a certain amount of legal harassment from the shareholders, I predict this year companies will allow some SarbOx-related lawsuits to proceed to trial in order to get basic case law established without the anti-corporate hostility and angst that surround the massive disasters that make for definitive case law but tend to require thousands or millions to be injured.

Consider two examples, one real, the other hypothetical:

Example A: A corporation outsources financial reporting to the Phillipines. An accounting center is established, WAN connectivity is purchased, and 300 jobs are eliminated in the U.S. while 700 happy Phillipinos gain jobs in a new, 24-hour operation.

Due to other U.S. regulations, the corporation purchases most of the equipment on the local market. This includes localized versions of Microsoft Windows and Microsoft Excel.

The auditor argues that because the center produces reports that contribute to financial statements, SarbOx controls are required. And because both the software systems and the personnel changed, the company should run the two offices in parallel for at least a year to establish that consistent answers are being provided.

Example B: A company has set up a backup data center in a separate complex. The auditor argues that because the backup data center could be used to produce financial reports, SarbOx controls are required. Because fire safety is a significant issue in the tight backup center, photos of the smoke detectors in place with the equipment are required, as are receipts establishing the scheduled purchase and replacement of batteries.

It's probably obvious to you which of these is the real example and which is contrived.[4] Of course, as a CM professional instead of a financial auditor, you may have a different sense of what controls are for and who needs to be controlled.

7. No Oscars for 'Brokeback Mountain.'

Despite all the press, and the Golden Globes, and serving as joke fodder for every comedian and talk-show host in the United States, 'Brokeback Mountain' won't win any Oscars that anyone cares about. (It might win one of those “Best technical lighting of live animals against a CGI background in a major motion picture” awards that none of us understand or care about. But that's it.)

What does that have to do with CM? Nothing. I'm out of CM predictions. But what better way to wrap up something none of us will care about in a few weeks?8. Super Bowl XL: Pittsburgh 24, Seattle 10.

Okay, now I'm really out of predictions.