Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist.
The other day I was reflecting back on what has been a long, and generally fun and interesting IT career. One thing I remember vividly was discovering the IBM System/38, the first incarnation of what would evolve into the AS/400 and the current IBM i. I was responsible at the time for a major planning process for a large university’s (hint: “Go Ducks!”) administrative computing strategy. The S/38 technology promised application flexibility and reliability unimaginable on the other platforms available at the time. The IBM i technology still does.
But, as in the early days of the S/38, this platform’s technology and benefits are a well-kept secret. There were more than a few nights I lay awake wondering whether I’d made the right decision to embark on a consulting career focused on the IBM S/38, AS/400, i world. Would the then “jazzy” Wang system, with its fairly slick, but also fairly shallow, interface capture the imagination of departmental organizations wanting to break free of the central IBM mainframe? Would the just introduced DEC-system 20 dominate, with its far greater horsepower than the S/38 and a more modern operating system than the IBM mainframe (but still years behind the S/38 architecture)? In the end only one of those competitors survived, and has in fact thrived.
So, I empathize with today’s System i IT managers who may share similar worries. But I also can offer encouragement. Before doing that, however, let me spin a story and see if it sounds familiar. I call this “The Secret Thoughts of an IBM i IT Manager.”
Once in a typical midsized company that was doing OK, but still facing pressure from the lagging economy and hard-scrambling competitors, there was a System i IT manager named Al who generally maintained his “game face” of calmness and optimism regardless of his anxieties. Al knew that top-level executives needed to have faith in his ability to safely navigate the vast and ever-changing landscape of modern computer technology, and that an IT manager who expressed his own doubts about the IBM i or seemed uncertain about how to deal with future application development wasn’t going to reassure executives that their faith in him was well-founded.
But in the late evening, after most employees had gone home, and Al was alone in his office, these are some of the thoughts that ran through his mind . . .
“How can I convince my managers the IBM i is still the right platform for us? I know the i can compete with Windows, but we can never seem to find time to ‘modernize’ our applications because of the time-consuming RPG maintenance effort. Our lack of innovation is painting the platform in a bad light. I need a way to produce applications on the i that showcase the platform.
Thinking about maintaining all this old code makes my head hurt. I can’t even determine how much of my code base is redundant or where the important business logic sits. I know we’ve ‘cloned’ a lot of the code, too; and I can’t tell which of the multiple variations are up-to-date.
We need to stop writing and ‘cloning’ more code until we can get a handle on what we have; and yet, tomorrow we’ll just pile on more of the same kind of code because that’s our only way to respond to demands from other departments. I know a day of reckoning is going to come when all this code will have to be rewritten. We need to find some way off this hamster wheel . . . or I better retire before that day of reckoning arrives.”
Al continued to muse . . .
“I remember how nice it was when all we had to think about was adding a new function to one of our big, all-purpose RPG programs, and I had a full complement of RPG programmers who could keep up with the workload. Now, I can’t even fill two of my programmer positions because good RPG programmers are so scarce. And Lord help me if I were to try to get one of my two .NET programmers to take on some RPG maintenance responsibilities. They don’t have a clue and aren’t interested in working with a language they consider ‘archaic.’
Then there’s the other side of the coin. Right now, our use of .NET is limited to a few web applications, and our main line of business apps still run on the i. But my boss keeps asking why our applications aren’t better integrated, and he clearly wonders if we wouldn’t be better off on a single platform, like Windows, which has a better user interface and seems to be widely used in our industry.
So far, I’ve been able to hold him off by arguing that our applications and data are more secure and operations are more reliable on the i, but just last week he said I better be looking for ways to deliver security and reliability on the Windows platform, as well as the i, because our company is in acquisition talks with another company that runs everything on .NET. Just what I need right now!”
The minutes ticked by; the cleaning staff came and went without Al even noticing. His mind was on the seemingly insurmountable problems he faced . . .
“What can I do? I hear all this talk in the IBM community about ‘modernization,’ but I don’t hear much that addresses my fundamental concerns. It’s really pretty simple – somehow, I need a practical way to move to a development strategy that will take advantage of the IBM i’s exceptional technology and reliability, but also let me easily deliver an equivalent application on .NET when that’s necessary.
Did I say ‘simple’? Ha! With the amount of old code I’ve got, trying to make such a transition would be a nightmare if I had to do it in one shot. That’s really the reason we’re still stuck. Why add some new approach to development – even if it is better than what we’re doing now – if we still have to maintain all our old code and can’t make use of any of the functionality we’ve already implemented in RPG?
Maybe I should follow in the footsteps of my two top programmers who left last year for jobs in a pure .NET shop? There’d be operational headaches with Windows, for sure, but at least I wouldn’t have other departments hammering me for the lack of integration between our IBM i and .NET applications. And, I could finally quit worrying about trying to manage multiple copies of data stored in DB2 and SQL Server.
Look for a .NET job in this job market and with my experience? Nah. Plus, I like the company and my current job, despite the stress. What I need to come up with is a plan for transitioning to a better development environment in a way that lets us continue to use our RPG implementations of business logic, while incrementally improving our user interfaces and increasing the integration among existing and new functions, so we get rid of our current application ‘silos.’ Eventually that could unify my IBM i and .NET application development. Then I could finally relax . . . at least a little.”
Finally, Al got up and reached for his jacket . . .
“Oh man! That’s enough worrying for today. I need to go home and get some rest so I’m ready for tomorrow’s round of questions about the IBM i’s viability.”
Do any of Al’s thoughts resonate with you?
What’s interesting is that Al’s concerns aren’t really about the IBM i, they’re about finding an application development strategy that will take advantage of the i, make use of his current application portfolio and support multiple platforms. Al realizes this isn’t going to be RPG, but his intuition correctly tells him it isn’t going to be just .NET, either.
So if I were Dr. Phil and Al came to me seeking advice, what would I suggest? Well, the details won’t fit in a single blog post, but I’ve written Transforming IBM i Applications – Your Journey Beyond Modernization – a series of three eBooks just for folks like Al. Take a look. The first book, “Prepare for Your Journey,” discusses the challenges faced by IBM organizations and their IT managers, including specific risks and opportunities. I also explain several “core” principles to guide your planning. In addition, you’ll discover how transforming your IBM i applications requires an enterprise application architecture that provides an over-arching description of the building blocks and practices your organization will ultimately use to design, implement and adapt applications that fulfill the enterprise’s business objectives. I complete the preparatory steps by describing eight pillars upon which any application architecture should rest.
In the second installment, “Be a Savvy Traveler,” I lay out seven steps to create an incremental transformation plan. Implementing a comprehensive enterprise application architecture that encompasses all your legacy and new applications can only be reached through a series of non-disruptive steps where each step produces immediate returns and minimizes risk. As we travel through this transformational journey, I explore ways your enterprise can reuse, recycle and reengineer legacy applications. I also explain how to put your current IBM i development staff in the right position to create success, without having to turn them into Java programmers.
“Embark with Confidence” completes the series by looking at specific technologies and “best practices” that support a non-disruptive, low-risk transition process from an organization’s current application portfolio and practices to a “new generation” of applications and an architecture-based approach to development. I provide a careful analysis of application generators as a potential tool and provide a set of specific scenarios and decision steps an IT organization can work through to assess the level of risk in using an application generator. This final book also describes a list of criteria to evaluate contemporary application generator products.
The journey through these three eBooks leads not only to an effective application strategy; it also leads to getting a good night’s sleep!
