Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist
Are we done yet? With “modernizing” our applications, that is?
It seems so long ago that someone came up with the clever concept of application “modernization” as a response to how outdated AS/400 applications looked by comparison with graphical Windows applications.
But now, even after years of screen-scraping, “refacing” and crash courses in Java, there still exists an unfathomable mountain of monolithic RPG applications that – dolled up or not – simply don’t serve modern business needs.
Why have so many attempts at “modernization” failed to deliver? Herewith are my own “top ten” reasons, listed somewhat in the order I’ve seen them occur in many IBM i organizations:
1. Focusing just on the user interface
Of course the 5250 interface was the most visible evidence that AS/400 applications were dated, but even the best efforts at “refacing” can’t deliver the application integration, “anywhere/anytime” access and the multitude of other capabilities a truly modern application needs to deliver.
2. Trying to solve the problem with “better RPG”
So let’s fix the code then: Switch from RPG III to ILE RPG, start using SQL for database I/O, use procedures to increase modularity, even code routines for a web server to provide a browser interface.
Efforts of this sort can seem promising at first, especially to top-flight programmers whose work environment lets them get enough time away from critical maintenance tasks to learn and apply new skills. But this approach soon falls behind the demands for supporting new business needs, including expanded functionality and support for new technologies.
The problem is that ILE RPG serves such a small community the language hasn’t kept pace with more, yes, “modern” languages in terms of capabilities, procedure libraries, code frameworks, training and the peer support provided by a large, talented community of developers.
3. Trying to solve the problem by switching from RPG to Java (or C# or PHP or …)
Some IBM i organizations saw Java as the answer, and who can blame them given the sweeping promise of this new language and the supporting infrastructure? But early adopters were burned by the steep learning curve, gaps in critical capabilities necessary for business applications or performance problems.
Java and associated technologies are now mature enough to run serious business applications, but two problems remain. First, for IBM i shops, maintaining both ILE RPG and Java skill sets is difficult and the two languages don’t interoperate in a natural way.
The other problem is that Java remains a complex language and environment to use for business applications. Despite being a genuinely more modern language than ILE RPG, Java applications still require developers to be responsible for a lot of “plumbing” code. Similar considerations apply to C#, PHP or the other popular language choices.
4. Not capitalizing on the value of current application assets
Despite the obstacles that coding in ILE RPG and/or Java present, some organizations have hired the necessary staff and consultants to grind out the code for a new application or a relatively independent addition to an existing application. There are many success stories of this sort, especially when you consider the many applications that have been written in “plain old Java” for platforms other than the IBM i.
Yet, when you examine the results within IBM i shops, this approach doesn’t generally produce integration among the old and new applications and is often practical only for a fairly limited set of applications because it’s too expensive and risky to “rip-and-replace” the entire “legacy” application set.
5. Developing without an application architecture in place
Many of those IBM i organizations that evolve this far seem to then hit a wall at which point efforts to deliver truly modern, well-integrated applications stall for lack of a practical strategy for agile, productive and reliable application development.
My view is that organizations who get stuck at this point have failed to lay out a suitable enterprise application architecture.
An 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.
A sound enterprise application architecture can take many specific forms, but there are eight “pillars” I believe should always be in place. The architecture should:
Pillar #1 – Be based on a framework
Pillar #2 – Provide an application repository
Pillar #3 – Provide automation and developer guidance
Pillar #4 – Be based on a service-oriented architecture
Pillar #5 – Support multiple platforms
Pillar #6 – Support multiple application interfaces
Pillar #7 – Integrate legacy applications
Pillar #8 – Manage application evolution
My white paper “The Eight Pillars of Enterprise Application Architecture” contains more information on the application architecture topic.
6. Not following a business-driven approach to goals and priorities
I’ve seen numerous successes when an organization puts in place a sound application architecture along with supporting tools and training. But some modernization projects still fail due to reasons that apply to almost all business application development.
The first of these is that the IT group sets its goals and priorities based on technical, rather than business, drivers. Every significant development undertaking, whether it’s maintenance, “modernization” or brand-new development, should have a sound business justification and a business sponsor.
Otherwise, you build the wrong thing; or you build the right thing, but no one cares.
7. Not delivering real value early and often
Other than Warren Buffet perhaps, everyone these days seems focused on short-term risks and returns. If you want to keep the support of your business sponsors, don’t plan to deliver them twenty-five “units” of value in a year – deliver then five “units” every quarter. They get less by the end of the year, but I guarantee you they’ll be much more content as they see your organization delivering real value continually and consistently. And, in just one more quarter, your “customer” will get the other five units anyway.
8. Not using an iterative and incremental project structure
There’s only one real “silver bullet” for managing risk in application development projects, and that’s to use an iterative and incremental approach. Basically you repeat a “plan, deliver, feedback” cycle to deliver working versions of applications that add functionality in smaller increments, rather than as a one “big bang” near the end of the project.
This approach lets you deliver value early and often. It also reveals “what you don’t know you don’t know” as early as possible so you can adjust your targets and/or methods, thereby greatly reducing risk of failure.
9. Ignoring interoperability
Interoperability is one of the hardest problems to deal with in application development because which other applications your applications must interoperate with, and how applications interoperate, changes constantly. Thirty years ago “interoperability” meant procedure calls in the same language on the same system, today “interoperability” requires communication across languages, platforms and disparate devices using evolving protocols.
A sound application architecture must provide the ability for data and service exchanges up and down the software stack from simple method calls to long-duration transactions. Building on this foundation, enterprises can realize significant benefits through faster, more effective interactions with trading partners, as well as through the efficiencies and service improvements that can be gained from enterprise workflow automation.
Failure to plan ahead for pervasive interoperability will severely limit the ultimate success of any modernization effort.
10. Not getting the right people on the bus and in their right seats
And finally, it all comes down to the people. As Jim Collins’ advises: Get the right people on the bus, the wrong people off the bus and everyone in their right seats.
For many IBM i shops, the key is to make sure the “right seat” is available for your most productive and reliable developers. That means putting in place a solid strategy, beginning with an enterprise application architecture and providing the tools and training to enable your staff to maximize what they produce.
As to getting the wrong people off the bus, don’t feel too bad. There’s always another IBM i shop down the road that still thinks “application modernization” means screen-scraping and who’ll be looking for programmers who’ll be satisfied with that approach.
