Change management. The big CM. Back in the old days, change management could be as easy as backing up the source library. However, as applications become more sophisticated and require more-complex architectures, the change management picture becomes more complicated as well.

A Couple of Terms

Of course, I couldn't really write an article without a little introduction, could I? Whether it's a brief history lesson or a bit of terminology, I like to make sure we're all on the same page to start with, and vocabulary is definitely the focus for this article. There is an important difference between change management and source control, and it's crucial to understand the difference.

Basic source control involves simply keeping versions of the source around. Other terms include "version control" or "source code management." At the other end of the spectrum are "change management" or "configuration management" systems, which actually build software and deploy it. These terms often overlap, and I will try to avoid centering on the various acronyms, since the industry changes them at the drop of a hat. For example, one of the current hot acronyms is ALM, or application lifecycle management. The plethora of acronyms is nothing new; in the '80s, we had good old PDLC, or product development life cycle.

If you really want to dig into the topic, a good place to start would be the Configuration Management Wiki-Web, perhaps the most comprehensive compendium of all things related to change management.

However, I want to get moving forward here, and all I really wanted to do in this opening section is to differentiate between source management, which is primarily focused on the source code, and change management, which is more about software building and deployment. I would like to point out one specific issue: concurrency. One of the biggest differentiators is the concurrency model; some tools are designed for tightly integrated teams of developers with strict check-in and check-out procedures (this is the "lock" model), while others are designed for distributed development (more along the lines of open-source projects) in which individual developers or teams may have their own separate project track, and then multiple tracks are merged at some point to create deliverable builds (known as the "merge" model).

The System i Players

One reason I wanted to talk about concurrency is because the native System i vendors primarily supply tools for complete change management—not only tracking the source code for a piece of software, but also building it, testing it, promoting it, and deploying it. Because of this focus, most System i vendors revolve around the lock concurrency model rather than the merge model. I'm not going to get into an analysis of the commercial products; that's a different sort of article. But if a change management decision is in your future, you should do your due diligence on the System i players, since they know the platform better than those who supply primarily UNIX or Windows products. The System i-centric vendors include these:

• Aldon—Lifecycle Manager
• ARCAD—Skipper
• Industrial Strength Software—ChangeMaster
• MKS—Implementer
• SoftLanding—TurnOver

This isn't to say that each of these vendors supplies only System i tools or that their products occupy the same niche; each vendor has different product suites and different approaches to the change management game. For example, SoftLanding (recently acquired by Unicom) was one of the early adopters of Eclipse technology, and its product is pretty tightly integrated into WDSC. SoftLanding even provides a free suite of extensions for the Remote Systems Explorer component of WDSC. These extensions provide access to spooled files and messages. Meanwhile, Industrial Strength Software puts more of an emphasis on command-line integration with the System i operating system (OS/400 or i5/OS); for example, a single green-screen command can provide an impact analysis.

In general, though, I think it's safe to say that most of the System i-centric vendors have until now primarily focused on the QSYS world of development, and they all fared pretty well in that environment. But even in that environment, System i developers need features that are beyond those of simple source control. For example, I might want to be able to associate an RPG program with its display file so that when I promote one to QA, both objects get transferred. This situation gets even more complex when you start dealing with ancillary objects, such as screen definitions for thick clients and screen scrapers. I don't know of any package today that allows me to define a "distribution object" that consists of a Web service written in Java and the RPG program it calls for business logic in such a way that I can either promote it from test to production atomically or package it for distribution to another machine.

Note that I am not an expert on these products by any means. I do know that many of these products either already have or are considering tight integration into WDSC, as well as support for non-traditional System i programming objects, such as Java. But the state of those features is product-dependent, which is why you should contact the individual vendors.

The Non-System i World

Then there is the vast world of non-System i development. In that world, a wide variety of source code and change management systems vie for the hearts and minds of developers. Both commercial and free solutions exist, with a wide range of capabilities. Interestingly enough, the default in the non-System i world is the merge model. A few vendors support both models; none are purely lock-based. Even more importantly, nearly as many of these products use a distributed repository model, in which there is no central host repository, but instead every developer has a complete copy of the software local on the workstation, something that just isn't feasible in many environments.

While literally dozens of these packages exist, there are three that are probably most relevant to the System i development world, mostly because of their integration into Eclipse framework and thus their natural affinity for the WDSC tool suite.

The first is the de facto standard in the open-source world. Concurrent Versions System (CVS) is a little long in the tooth and no longer actively developed, but it serves as the baseline for version control systems, and of course the price is right. Perhaps the first system to bridge the UNIX and Windows worlds, CVS has been around so long that its Windows component is known as CVSNT (does anybody remember Windows NT?). In any event, Eclipse ships with support for CVS, and thus every product built on Eclipse (including WDSC) has at least some degree of integration with the package. However, CVS is lacking in a number of major features and, despite its worldwide use, is generally considered outdated.

Subversion (SVN) can perhaps be thought of as the next generation of CVS. Just as JavaServer Faces is the replacement to Struts, SVN is the next step after CVS. In fact, the parallels between the two open-source projects are interesting: In both cases, the developers of the original package decided to create a completely new project rather than attempt to extend the original. And while there is a considerable current population of users for the older tool, SVN is probably the tool gaining more new adherents, while CVS is primarily being used by companies that already use it. I could be wrong on that; it's not clear to me what the non-System i world is focusing on these days, but I do know that SourceForge, the world's largest open-source project repository, supports both CVS and SVN, and that's about it. And in any case, there is strong community support for Subversion and Eclipse via the Subclipse project.

The third product that should be mentioned in this space is IBM's own Rational ClearCase product. As far as I know, ClearCase is available only in the Advanced Edition of WDSC, but since there is still no clear direction as to the eventual packaging of WDSC, I can't tell you what the real cost of this tool will be. We have heard consistent rumors that only one edition of WDSC will be available but with additional optional components available for a price, and I think it's quite likely that any ClearCase functionality will cost System i developers extra money; at least, that has been the modus operandi of the Rational product management team up to this point. In any case, the iSeries project view of WDSC (a subject I'll touch on again momentarily) has some built-in support for ClearCase, which gives it a leg up on the competition.

The Larger Universe

And even beyond the scope of change management itself lies the larger spectrum of ancillary tools ranging from bug tracking to install managers. And it may well be those ancillary tools that help you decide which change management tools best suits your business.

What's important to your business may not even be an issue for another company. A home-grown green-screen solution maintained by a couple of employees has a completely different set of requirements than a thick-client application built using a code generator, which in turn is entirely different from a custom multi-tier application deployed by an application service provider (ASP). In fact, about the only thing common these days is that things are more complex than they used to be. Even the home-grown green-screen solution may have a requirement to do something non-System I, such as generate PDF reports; these typically require some external applications that aren't covered by the standard SAVLIB/RSTLIB techniques.

The Two Directions

To that end, the two worlds are coming at things from different directions. The System i vendors are adding capabilities onto their products, such as the ability to handle source code on the IFS (both traditional System i source such as RPG and more recent additions to the development lexicon like Java) and tight integration with Eclipse and/or WDSC. Meanwhile, almost all the UNIX/Windows products are coming into this with basic hierarchical support but without a lot of attention paid to the build capabilities, especially regarding different environments, like integration testing and quality assurance. The lack of standard capabilities to move an object through those phases is a weakness that most non-System i products have in common.

That's not to say that the two worlds aren't getting closer. For example, some of the System i-centric vendors are providing additional capabilities for IFS objects. This includes IFS-stored source both for standard System i languages (yes, you can store RPG code in the IFS!) as well as for completely non-QSYS items such as JAR files and Java source code, or even images and HTML. While as recently as a year or so ago I would have told you that most System i tools couldn't really handle a Web application project, that is no longer true. But be forewarned: If you plan to do any sort of non-traditional development, you had best check carefully with any potential change management supplier as to its support for non-QSYS objects.

And you're still not done. Other external components come into play, such as bug tracking and package distribution. For example, one of the better bug-tracking packages I've seen is CodeBeamer. It is a commercial product, but the vendor supplies a free edition that supports 15 users and two projects, which is probably enough for an initial installation. CodeBeamer has tight integration with both Eclipse (thus WDSC) and Subversion, making it a good fit for the non-System i centric development environment. And as you continue down that path, you find even more integration with other external products such as SugarCRM, one of the more popular customer relations management products.

I'm not sure what the bug-tracking capabilities are for the System i tools. You would have to check with the individual vendors to find out how they handle issue reporting and tracking. In my experience, we always had home-grown solutions for all of that. My old employer, System Software Associates, had a completely custom application written specifically for issue tracking; of course, we had an entire department devoted to the help desk, and error reporting and maintenance was a large component of that department.

The Dark Horse Option

An interesting alternate option exists for those interested in using a non-System i change management tool. One of the fundamental components of Eclipse is the concept of a project. Different types of projects exist, such as Java projects or Web application projects. WDSC introduced a new concept called an iSeries project, which I alluded to a little bit earlier. Interestingly, the iSeries project has not yet been renamed to System i project, although that ought to be coming soon. Name aside, with an iSeries project, the developer is able to "check out" code from the host onto his or her local workstation or laptop and then do disconnected development. This is limited to source entry and verification (such as syntax checking), but it's a nice feature for people who can do long periods of source code entry without testing, for example on long plane flights.

However, it leads to an interesting side effect: You can keep all of your code in just about any source control system. iSeries projects can be pointed to nearly any folder on your machine, so they can be targeted to use a folder that is versioned by any of the UNIX or Windows tools (UNIX tools need an additional drive mapping step, but that's beside the point). The iSeries project will automatically convert between Windows text-based source and System i source files when the developer actually wants to compile. The System i becomes just a temporary source container used for compiles only, with the actual repository being down on the PC (and conceivably on a network drive somewhere).

At that point, you simply need to figure out how to push your IFS changes (such as those for non-System i source code) and of course how to handle the external components, such as issue tracking.

As you can see, there is no universal answer to change management; as with most system development aids, a lot depends on your requirements. And I barely even touched on the issues that come up when you deal with multiple platforms. As more companies come to rely on packages and products running on other machines in their network, the concept of multiple-platform versioning will become more important. For example, how will you keep your PHP scripts in sync with your RPG programs? Or measure the impact of a database change on your Excel spreadsheet formulas? In my estimation, the important component of any change management solution in the next decade will be its versatility and its ability to support multiple environments with a single standard interface, and to date I haven't seen a package that works seamlessly across both System i and non-System i platforms.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..