In 2005, iSeries market surveys began to indicate a strengthening trend toward modernizing 5250 applications. For the first time, the applications being nominated as modernization candidates were large-scale, core business applications (e.g., ERP). Also, ISVs seemed to be realizing that true modernization of 5250 applications and multiplatform support was vital for them to grow, and even to maintain, their customer base.

Acting on this information, LANSA's CEO formed a team to examine our own in-house modernization experiences and perform further research. This revealed a polarization of iSeries modernization approaches:

The Makeover Pole

At this pole, a cluster of tools support ways to make over 5250 interfaces. Recurring issues include these:

• Providing value to users—Adding value to a demo is easy. Adding value to an application for users (by making their job better, faster, easier) is much harder. Our in-house experiences demonstrated a high level of "5250 recidivism" in users because the makeover hadn't added any real business value.
• Taking a step forward—Ultimately, a made-over application will always be 5250- and iSeries-constrained. Makeovers represent a step sideways, rather than a step toward the future. Unfortunately for the iSeries application portfolio, we noted a number of ISVs had sidelined their modernization efforts while trying to ascertain whether they had done enough to keep them in their respective games.
• Inhabiting the Planet of the Scrapes—Our review of some made-over 5250 solutions showed that though they weren't quite 5250 applications anymore, they fell short of being real Windows or browser applications. They inhabited a netherworld we called Planet of the Scrapes. Such applications may be fine for in-house use, but selling them to Windows users, who've grown up with expectations set by products such as Outlook and Word, seemed challenging.
• ROI and effort-risk-reward—ISVs spoke of the time it took to make over each 5250 screen. When they did the math and projected how long a complete makeover (with some added user value) would take on a 700-screen application, the ROI and effort-risk-reward equations often did not add up.

The Knock-Down-and-Rebuild (KDR) Pole

At the opposite pole, some tools support ways to redesign and rewrite existing 5250 applications. Customer experiences and the observation of iSeries sites undertaking modernization projects (particularly those we had lost to competitors) revealed areas of concern:

• Time to market—This was the "application killer" for small- to medium-sized sites. Almost nobody starting a large-scale application rewrite understood or had available the required skills, time, or money to successfully complete the project in a viable timeframe. By the time the KDR application reached the market, the market had already moved on to its own next big thing.
• Big bangs and black holes—Big-bang projects (running two or three years after the typical overruns) that deliver nothing useable or saleable until the end are notorious for becoming black holes. Having been involved in some black holes over the years, the prospect of being involved in more scared the research team. Many KDR approaches offer no alternative to this approach.
• The search for Superman or Wonder Woman—To be successful, KDR sites needed a leader/architect/designer who knew the existing application and the industry's trends and directions and was experienced in architecting and implementing the latest IT techniques, right down to the plumbing level. These people often did not exist.
• Too much complexity—Two application architects we spoke to indicated that the number of hardware/platform/server/database combinations that an application could be deployed to hugely impacted how the application was architected. In other words, you had to know how an application would be deployed before you could design it. One spoke of an XML-based interaction being transformed 11 times during a single user transaction because of how the customer had arranged its servers.

Developing the Process

Working with this research, we set about designing a modernization process to avoid these pitfalls and offer a gradual transition between the two poles. We distilled the process to three stages:

1. Create an executable prototype of the application to be modernized to let a subject matter expert set the project's direction before any programming begins. This stage is vitally important because you cannot modernize an application by asking a programmer to analyze existing source code.
2. Quickly create a functioning, modernized application by reusing 5250 application screens inside the prototyped framework, without making any changes to the application itself.
3. Give developers the option to enrich the application by gradually replacing the 5250 screens in the framework with platform-independent components, providing a staged path to strategic modernization.

Challenges Ahead for the iSeries Market

ISVs are challenged by the prospect of application modernization and the myriad of choices they need to make, just as most iSeries shops are.

One of the most significant areas of challenge is user interface choice. Most iSeries customers seem to want to use Web browser interfaces. The zero deployment aspect of the Web browser offers an extremely compelling argument; however, it is an argument about economics, not about application usability. Giving users a Web browser interface doesn't enrich their user interface experience or increase the application's functionality, usability, or speed. If you don't believe this, compare the best transactional Web page you've ever used with Microsoft Excel, Word, or Outlook and ask yourself which one you'd want to use all day, every day of your working life.

Additionally, Microsoft is set to use its Vista products and technology to try to retake ground it has lost to the Web browser user interface. This has the potential to completely repaint the user's expectation landscape all over again.

Matching a modernized application to a modernized user interface is a critical and complex decision, and clearly some people are not always making the best decisions in this area. Developers need to be able to deploy their modernized applications to the Windows-rich/smart client or the Web browser interface in their modernized applications —or, as we believe is the best option for large-scale commercial applications, both user interfaces.

Mark Duignan is currently the manager of the Application and Integration team at LANSA's product development center. He manages a dedicated team focused on helping customers to improve developer productivity and on investigating new ways that LANSA may be applied to solving business problems, especially by using frameworks. He has been with LANSA for almost 20 years and has a background in S/370, System/38, iSeries, and MS Windows commercial application development. You may reach Mark at This email address is being protected from spambots. You need JavaScript enabled to view it..

Mark Duignan has been in involved with IT for more than 25 years. His initial experiences were gained on IBM System/370 mainframes in the CICS era. He worked with the System/38 and then the AS/400 family for more than 20 years. He is passionately devoted to the AS/400 community because of their focus on producing business solutions rather than techno babble.

 

Mark is a senior architect at LANSA, specializing in commercial application design techniques and framework-based development approaches.

 

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails