Great People With Good Tools

Revised: October 3, 2011

by Martin Fincham

I don't think I'm the only one who tires of the constant drumming that comes from so-called mainstream IT media articles and Internet discussion threads that couch the future of RPG developers and the IBM i platform in simplistic black or white terms that belie the real issues and options.

In the black hat camp, we have the doomsayers who advocate "get the hell off the platform right now and get your hands dirty with something that has a future." On the other side, the Big Blue proponents are tarred with being the "make do and mend" brigade, with a reputation for alleged unwillingness to learn anything new and who are secretly saving their energy and creativity for retirement.

In the same way that bad news garners more coverage than good news, I often find more proponents for the next big thing than I do for make do and mend prudence. One finds that the vendors, journalists, analysts, bloggers and the proverbial one man and his dog all have a vested interested in pumping the next big thing. But surely, after going through all of the effort, pain, and cost of getting a core system installed and stable, we just want to keep that system running for as long as is prudent and sensible for the organization.

So before relegating all AS/400-derived systems (iSeries, System i, and IBM i) to the legacy scrapheap, how about we toy with some analogies: Is Blackberry considered legacy in the shadow of the Apple iPhone? Are all those legacy ERP apps from Oracle and SAP about to be usurped by NetSuite? Is Zuckerberg snacking on the lunches of Page and Brin? Is the word legacy in this context just a synonym for that which you already have that works in much the same way as a new car becomes a used car as soon as the rubber hits the road? Surely the only important distinction is between a good system (current, reliable, cost effective) and a bad system (not meeting business needs, flaky, increasingly expensive to maintain).

There's a big difference in IBM i shops today compared to 25 years ago. Today, very few shops have only an AS/400 system. They have embraced other server platforms like Microsoft Windows and deployed new applications and technologies like business intelligence, Web-based and mobile applications, workflow and business process management in concert with their IBM i environments. Each of these additions has added value to the underlying core system and prolonged both the life and the usefulness of the original system. The choice between old and new is not black or white (or distinguished by black or blue hats), but rather a colorful vignette of choices and combinations. And, just for the record, there is less than a 5 percent attrition rate from the IBM i system so please don't let the doomsayer with his "the end is nigh" clapboard scare you into irrational decisions.

There was a story published in Four Hundred Stuff earlier this year of a long-time IBM AS/400 shop, where a couple of IT managers decided their RPG resources were far too great to squander. (See RPG Skills, LANSA Tools, Plays Well for Music Industry Licensing Company from the May 3, 2011 issue.) The story dumps on the idiotic stereotypes associated with the IBM i platform and RPG and demonstrates a common sense approach that other RPG shops could easily emulate.

The first mistake the black hats make is to regard a legacy system as a single entity to be discarded rather than an asset to be managed. Even the blackest of hats would struggle to argue that an IBM Power7 system is not state-of-the-art hardware. In most cases, the RPG applications are not broken and collectively they represent great business value. So, where are the problems with being an RPG shop and what is the risk of just staying put?

The RPG programming language has two limitations that cannot be ignored when assessing business risk: It is an IBM platform-specific language and the talent pool is diminishing with fewer new developers entering the community. These limitations combine to fuel spiraling costs for maintaining RPG applications.

So a good first step is to draw a line under those RPG apps by assigning them to be modernized rather than actively developed. This designation is seen by some people as a pejorative term, but it shouldn't be. Modernization is merely shorthand for that series of tasks that keeps applications in tune with the needs of the business and its users. But to spend more than the minimum is irresponsible when you consider that for every dollar spent maintaining an old system you are building a three-dollar debt for when you eventually rewrite or migrate the legacy code. But the other extreme, starting over in a new language--like Java, for instance--is even more fraught with risk and is unjustified in many cases.

It is a fallacy to assume that "newer is always better" because there is genuine commercial value in stuff that already works and good software developers know the business as well as the technology. In my experience, it is the business knowledge that is hardest won and therefore vital to persist as corporate memory, whereas skills with a particular programming language, database, or operating system can diminish in value as technology evolves.

This point is underlined by a quote from the Harry Fox story: "I wasn't sure of the direction I needed to take the RPG team. The CIO explained how valuable the team was. So I started to understand what they were doing. I realized that these guys are the ones that know everything and have the deepest history of our data and solutions. They handle the guts of our processing here. On top of that they are extremely sophisticated in the whole process of setting up the data structure, writing good code, and testing it; they know everything from the requirements stage through the deployment of the product. To me, that is more than 50 percent of being a good coder. And they know the music business. When you bring a new developer in off the street you don't get this."

In the western world, we are living through an era of increasingly fewer computer graduates entering the work place and we are operating in a global market place where technical competency (like writing code in a particular programming language) is being seen as a commodity skill that can be outsourced to cheaper locations. If you are an RPG shop then please, before you embark on your next major application development, modernization or integration project, ask yourself how can this company best use its existing software developers rather than how cheap and easy will it be to find new Java, C#, PHP, HTML, (fill in the blank) software developers and then integrate them into our team?

Never underestimate what great people can achieve with good tools.

Martin Fincham is LANSA's chief operating officer and a well-known blogger in the IBM i community. This commentary was adapted from his blog on the LANSA iOpener blog site.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot