System iNetwork

September 25, 2007

Building Apps: Change Management or Chaos Management?

One of the major issues in software development is keeping track of what changes have been made to applications under construction or maintenance. Especially when more than one developer is working on a particular piece of software, it becomes far too easy for programmers to duplicate each other's work unproductively. One developer may inadvertently overwrite the work of another, a team may build incompatibilities or errors into code, and blocks of code may be rendered useless when conditional statements that would cause them to run are deleted. Plenty of unintentional problems can crop up, and these examples are just about coding steps.

The solution to these problems is to use software that provides some automation for software version control, compiling new builds and distributing them, organizing workflow and other processes, tracking change requests and incident reports, and auditing and reporting to management on these activities. Most people seem to agree that software of this kind is necessary and can pay for itself over time, even though the managers of many companies are reluctant to spend the money for it initially. The most common name for this product type is software configuration management (SCM).

System iNEWS covered the major issues surrounding SCM and highlighted the major SCM solutions for the System i market in its Software Configuration Management i5 Route Finder included with the March 2007 issue. The software requirements and players for System i have been the same since then.

One thing that remains confusing is how to refer to products of this type. There's really no general agreement. Not so long ago, they were called change management (CM) solutions. Then they were redubbed SCM. Lately, the IT industry has been moving towards a new name, application lifecycle management (ALM). And IBM, which certainly carries some weight, additionally refers to such solutions on its Rational website as "change and release management" and "build and release" management. But that's not the only problem.

Outside the System i market, there are some signs of disarray in this product area. Late last month, Borland Software Corporation released a survey about ALM use at 300 of its customer sites that shows 90 percent of those customers using "multiple ALM tools from several different vendors." Fifty percent are using four different tools, and 33 percent use three tools. What's more, 69 percent are supporting two or more development platforms (42 percent deploying to both Java and .NET environments), and 44 percent are using at least two separate development processes. That doesn't seem very orderly.

To put this in perspective, Borland's tools don't run natively under i5/OS, and its ALM suite consists of more than 10 products that, while integrated, individually focus on different aspects of planning and designing apps, defining their requirements, developing and managing processes, and serving apps to users. Borland also plays in the multiplatform space on purpose, so its customers are naturally going to favor those environments. But this isn't irrelevant to System i because many System i sites are multiplatform as well, and trends in the greater IT market have a way of catching up with System i sooner or later.

Borland's revelation struck close enough to home that MKS CEO Phillip C. Deck (whose company does produce three System i ALM tools) issued a same-day statement dismissing the survey results. "Borland's marketing machine may be working overtime on their ALM spin, but they aren't creating order among the chaos of heterogenous products with their totally different interfaces, data models, and workflow mechanisms," his statement said in part. Deck's recommendation is that customers need to look for "a unified solution for end-to-end ALM."

So it would seem that, far from being as simple and straightforward a product area as the term CM might imply, we have at least some disagreement about the best means to achieve it as well as difficulty nailing down what to call it.

Shakespeare's Romeo famously expounded on the meaning of names. In the centuries since his musings were put to paper, people have tended to quote him as much to show the lack of importance of names of things as to show the importance of agreement on nomenclatures. What we call products and concepts in the IT world in general, and therefore by extension the System i market, can be more crucial than we think because it's all too easy to overlook critical shadings of meaning. These can get lost in our rush to jargonize concepts and reduce them to shorthand references in conversation, as we all tend to do, and that can lead to discussions in which two people use the same words but are actually referring to different concepts. Tracking application development activity is turning into a technical area that holds that danger because CM, SCM, and ALM aren't necessarily different names for the same idea. They're each developing their own flavors.

CM's cachet is old hat. It has become too general because it started out meaning simpler processes, as an acronym it's too easily confused with configuration management, and at least for me, it's too tempting to think of it as chaos management, an oxymoron. SCM comes from an early software engineering book and focuses on the management methodology of individual software development projects. ALM, in contrast, views software development not as a project with a beginning and end but rather as a process that repeats more or less infinitely but follows the same basic steps. IBM's Rational site postulates a three-tiered definition. SCM is for "version control and parallel development support to manage and control software assets." "Software change management" products are for "defect tracking and automation of software processes." "Build and release management" products are for "accelerating, standardizing, and automating build and release cycles." To me, this sounds like a methodology that would apply best to a company that primarily produces software, proposed, strangely enough, by a company that produces software.

How can we simplify this? SCM works as a model for building or revamping a single application or application system. ALM presumes that application development is never done, that as soon as you finish revising anything, it's on to V3 tomorrow with no letup. So SCM still seems appropriate for SMBs who want a new app, or to update an app, but then plan to run with that for a while. That's a common System i shop scenario. ALM-type development, though, is becoming the defacto situation in any enterprise that can't keep up with user and business demands for software changes. By the time IT delivers the goods, the next wish list is already on the white board. I think the worst of all worlds would be to have an SCM mindset in an ALM reality. Know anyone in that pickle?

What's the answer? I think Deck is right about this product area being chaotic, but I also think the chaos doesn't come just from the proliferation of ALM product approaches. It comes from the inherent chaos of application development having been an art rather than a science for decades now. Herding a catlike team of programmers or organizing a couple of handfuls of legacy apps into producing a unified outcome is similarly going to resist any one-size-fits-all approach. The bottom line is that when thinking of adopting any SCM or ALM product, your enterprise needs to do a lot of self-analysis first to figure out where your demand is on the SCM/ALM spectrum and what approach might work best. Starting a Google search for products should be anything but your first step.

Posted by at September 25, 2007 10:26 AM