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:
- 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.
- Quickly create a functioning, modernized application by reusing 5250 application screens inside the prototyped framework, without making any changes to the application itself.
- 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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online