Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist.
“Give us the tools, and we will finish the job.” – Winston Churchill, February 9, 1941
While application modernization isn’t as daunting as the challenges Churchill faced during World War II, application developers and IT managers may feel his words perfectly express their sentiments as they face a mountain of “legacy” code that needs updating.
Some developers may wish for the kinds of bombs and artillery Churchill wanted, so they can blow the legacy code to smithereens and start fresh without all the headaches of gnarly old code. Dropping a bomb on an enterprise’s code portfolio might be gratifying to the IT team, but it would likely destroy the enterprise along with the code.
When more sensible views prevail, development teams often start looking for the right “modernization” tools to help them finish (and, in many cases, start) the job.
To help in that search, here’s my “top 10 checklist” for finding the right tool.
1. Get a good handle on what “modernization” means so you know what tool capabilities you need.
Here’s an example: You need the ability to create a variety of user interfaces – web, mobile, etc., but “refacing” isn’t where modernization ends.
Go deeper and look at the full range of modernization issues that need to be addressed. A good starting point is my Transforming IBM i Applications eBook Trilogy.
2. “Kick a few tires” to get a “real world” feel for the variety of tools that are available.
I’m not talking about lengthy “test drives” of modernization products. That comes later.
But settle in to watch some videos on vendor websites, visit trade show and conference “expo” booths and invite some vendors to present their demos on-site.
Keep written notes of what looks promising, as well as concerns over missing functionality or other deficiencies in the products you look at.
3. Get advice from your peers in the IBM i “social network.”
Hearing about other IBM i developers’ experiences with modernization tools is invaluable. You wouldn’t buy a car without plugging into the discussions on Edmunds.com, would you?
To use your time productively, I’d suggest getting customer references from product vendors and using that “legacy” device, the telephone, to call. For some reason, serious i application developers don’t seem to be hanging around a particular Facebook site to share their insights.
4. Sketch your “use scenario” and your “enterprise application architecture.”
I always think it’s better to get some initial exposure to what’s really out there in the product world before jumping right into writing specs for a “Request For Proposals.” But if you followed the first three tips, now is the time to shut your office door and draft a concise description of where you are and where you want to go.
A “use scenario” is a collection of “use cases” and other information that describes your situation and needs. So, for example, are you focused on having your applications able to run on platforms in addition to the IBM i? Is support for mobile devices or other UI technology a priority? And so on.
An “enterprise application architecture” describes how a set of building blocks and principles should be used to design, implement and adapt applications that fulfill the enterprise’s business objectives. A well-thought-out application architecture not only provides a conceptual structure to guide developers; the architecture lays the foundation for a corresponding framework and tool set that can automate much of the application development effort, an essential prerequisite for greater agility, productivity and reliability.
You can learn more about these two subjects in the Transforming IBM i Applications eBook Trilogy I mentioned earlier.
5. For most IT organizations: Go with an integrated product.
In theory, your organization can define an application architecture and assemble disparate tools to implement your architecture. In practice, this requires adequate staffing to support a home-grown infrastructure.
Modernization isn’t a one-time “face lift” or “code conversion” for your old RPG code. Modernization is a transformation of your application development strategies so you can efficiently deliver the right information and capabilities to the right people at the right time, as determined by changing business needs and initiatives.
For most IBM i organizations, purchasing an integrated “application generator” is the most practical way to deploy the tools necessary to fulfill this objective.
6. You’re going to need a tool that provides an “application repository.”
An application repository provides persistent and structured storage for all the information that defines applications. The repository may also contain information related to requirements, standards, environment and other aspects of application development and deployment.
The pivotal advantage of a repository is that shared application items can be stored, managed and reused effectively. Items like data element definitions, business calculations, user interface templates, code snippets and so forth can be defined once and used across many applications and developers in a consistent manner. Having one definition for a shared repository item yields application consistency, and having a “single point of truth” greatly simplifies modifications to applications.
7. Take any candidate product for a hard “test drive.”
One of the most common mistakes I’ve seen when an IT group evaluates a modernization tool is that their “test drives” usually are comparable to making sure the wheels roll and the brakes work during a new car test. Not very demanding, in other words.
What you need to do is what I did when I tested the “sport sedan” (an Infiniti) that I later bought. The salesman had been touting the superiority of the “I’s” anti-lock braking system. So I went to a large, vacant parking lot; accelerated to 40 mph; and then jammed down hard on the brakes while whipping the steering wheel sharply to the left. Impressively, the “I” rolled right through the sharp turn with no skid at all. That’s when I knew the car measured up to its promotional literature.
So, throw hard cases at any prospective tool to see how well it handles under pressure.
8. Spend a lot of evaluation effort and reference checking time on how well a tool enables you to exploit the functionality of your existing code.
For many i development teams, the biggest hurdle to comprehensive modernization is the insurmountable cost required, not to mention the risk, to “rip and replace” legacy RPG code. Consequently, the ability of a tool, such as an application generator, to incorporate existing application functionality is critical and varies widely among available products that support the IBM i.
9. Evaluate “risk” realistically.
Humans are notoriously bad at correctly assessing risk, and IT professionals aren’t immune to this limitation.
Your enterprise and IT management is likely to be uneasy about the risk of acquiring tools for application development that aren’t as widely used in the industry as Java or SQL.
The reality is that no comprehensive application modernization tools for the IBM i will ever reach the level of use enjoyed by these two languages or some of the popular code-centric Integrated Development Environments (IDEs), such as Visual Studio and Eclipse.
But here’s another reality: No version of RPG and its associated IDE will ever have much of a market presence either.
So an enterprise with a considerable investment in RPG code needs to compare the risk of a future development strategy based on writing more and more RPG code using an IDE or using a tool, such as an application generator, that frees developers from low-level coding complexities and allows them to focus on business functions, a wider range of user interfaces and better integration with internal and trading partner applications.
Although I don’t have concerns about the IBM i or RPG compiler “going away,” corporate mergers and acquisitions that force IT to support a different platform, as well as or instead of the IBM i, are just one of the “risks” that IT must also consider in choosing a development strategy. Application generators that target additional platforms, as well as the IBM i, are one tool that can mitigate this category of risk.
There aren’t any canned answers to balancing risks, so give this critical dimension of your modernization strategy very careful consideration.
10. Budget adequately for training and mentoring.
Beware of “shelfware”!
With any powerful tool or toolset, including an application generator, your organization will benefit tenfold by having adequate initial training and mentoring.
While good tools can automate and standardize much of the “glue and plumbing” code required in modern applications, the same tools provide such wide latitude to developers that you want to get off on the right foot using “best practices” learned from training and mentorship.
Training provides a foundation in the common ways a tool is used, mentoring provides invaluable advice on the best approach to unique enterprise requirements or cultural practices.
There’s another bit of wisdom that the “Great Old Man” passed along, which seems appropriate to IBM i developers and managers facing the challenges of application modernization: “A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty.”
I certainly think there’s lots of opportunity in a well-planned IBM i modernization strategy.
