System i and the Web: Where We’ve Been and Where We’re Going

Which server should have been first, and should continue to be, the predominant server for Web integration? The System i, of course. It is, after all, business applications that need to get to the Web so the functions they perform can be viewed, interacted with, and integrated with other business functions, customers, and suppliers. For a host of reasons, though, the applications that run on the Application System introduced by IBM in 1988, have, until now, had a tenuous relationship at best with the technology that brings business functionality to the Internet.

Where have we been? On an island. Where are we now? Moving slowly toward Web-facing those green screens. Where are we going if we want to leverage fully the investment in this platform and these applications? Web integration.

When IBM introduced the AS/400, the Application System name proclaimed the platform as IBM’s true business system, distinguishing it from its other hardware offerings. Thus it was, and thus it has remained. Even today, many of the platform’s original applications still run today. But the AS/400 significantly pre-dated the widespread acceptance of the Internet.

In the mid-1990s, IBM made its first significant introduction of Web facilities for its servers in the form of TCP/IP, and it soon became clear that moving AS/400 applications to the Web would cause problems. As Brian Kelly, a contributing author at IT Jungle and president of System i business partner Kelly Consulting, has pointed out in numerous articles, although IBM did provide a way for AS/400 programs to talk with Web browsers, through the Common Gateway Interface (which is used by other platforms as well), this required about 10 times more code than the standard RPG in the same program, making Web programs many times larger and many times more difficult to write than traditional AS/400 applications. As a result, “AS/400 shops responded to this complexity by leaving Web application development to their Windows and Unix counterparts,” according to Kelly.

This original positioning of the AS/400 set off a chain of events that hasn’t actually changed much across the span of nearly two full decades. The introduction of WebSphere was also shunned by those more comfortable with the simplicity, stability, and ease of development on what we today call the System i, as many organizations still avoid both WebSphere and Java.

For the most part, IBM has not budged in its position that WebSphere and Java are the tools that will bring System i applications to the Web. Equally persistently, the majority of System i shops have rejected this solution as being far too complex. Walk into any shop with a mixture of a System i boxes and a small farm of Windows servers and ask how much time is spent on maintenance of the two platforms. Ask to see uptime records for the two. There’s no doubt that the Webless System i justifies the loyalty of those who don’t want to brave the risks of other platforms.

But is leaving the Web component to the rest of the business a sound strategy? The answer would appear to be a clear “no.” The comfort of platform devotees has bred complacency. The lack of a need for attention to the platform and its applications has become inattention to the need to bring the System i into the world around it–a world buzzing with Web-enablement, with the transfer of data between departments and customers and suppliers, with moves toward service oriented architectures (SOA) that deliver business efficiency and agility, and with on-the-spot, real-time decision-making that business managers expect today. While the System i may be chugging along with some of the core business applications, the “face” of business is happening on the Web where the conversation between disparate environments shapes virtually all global commerce today.

In order to protect their allegiance to the platform and to ensure a continued return on their investment in those hardy business applications, System i users must come off that island of comfort and move into the mainstream of the Web-connected world. That wider world threatens the longevity of their System i platform only if the System i and its applications stay on that island, allowing other systems to come to it for core business data, but refusing to reach out and integrate with the other players.

Several weeks ago in this very newsletter, Timothy Prickett Morgan noted that ” . . . I know this might be hard to believe, [but] the Four Hundred Gurus at IT Jungle tell me that an awful lot of companies have not decided as yet how to Web-enable their applications…” They must be thinking: Who needs Java and PHP when RPG is the best darn business application programming language around? What operating system could be more stable than OS/400? Who needs Intel servers with high downtime and hoards of staff to support them when the System i just doesn’t break?

The numbers of those who have not started down the road of Web-enablement are somewhat startling. We know that:

• Many (if not most) of the applications that run on the System i are considered to be core business applications
• A lot of corporate data sits in those applications as well in DB2/400 databases
• A lot of other applications on other platforms–both internal to and external to the business–must somehow be using much of that data

The only conclusion we can reach, then, is that the transfer and presentation of that data to other departments, to suppliers, and to customers, must somehow be going through batch reporting processes, many of which involved printing, and some of which may take days to complete a business transaction.

It’s true that most companies have a working Web site. But as noted earlier, the operation of these sites has, for the most part, been delegated to the teams of Windows servers folks on the other side of the shop. Transitioning these sites from static to dynamic sites that more fully meet today’s on-demand business needs is a daunting task, especially since IBM has not delivered tools that meet the expectations and needs of System i developers. Alternatively, System i developers have not accepted the tools they have been offered to date. The reason, as Kelly correctly observed, is that IBM has been preaching WebSphere and Java as the tools that will bring OS/400 applications to the Web. But System i developers have been equally adamant in rejecting these tools and quite possibly because they now code in business language, not in a computer science language.

How do IT managers at System i shops solve this problem? One option may be the creation of an entirely new, updated application on another platform. A few companies go this route, but it’s not quick and easy, and it certainly doesn’t offer System i users two of the key ingredients they covet: the ability to stick with a platform and operating environment they trust, and a means to leverage the existing code.

A second alternative is “Webification,” by which is meant creating a new interface on top of the existing OS/400 application. This solution helps to spread out the time-to-implementation and allows you to phase into implementation. It still, however, locks you into the current functionality. More to the point, Webification or Web facing is only the beginning of the road to true Web functionality.

The third, and arguably the most important alternative, is integrating your existing back office, green-screen, productive System i applications to your Website. This integration can vary, from data-level integration (mostly to query and present data on the Website) to call programs, working via messaging queues, use screen records, and Web services. No matter which interface is chosen, you can obtain a very high productivity and enhance business agility by incorporating sets or business rules into the integration platform. This approach will give you a dynamic, up-to-date interface, with no need to implement complex Java and WebSphere infrastructures. Just as important, users don’t need to endure long and frustrating test cycles since they are using the same old trustworthy code, albeit with a new interface.

Those who have “Webified” their green-screen applications have taken an important first step by being able to present user-friendly data straight from the System i database to the Web user. This step, however, is not going to give a company the full benefits that will ultimately be achieved by integration of the applications across the supply chain. It’s one thing to have your System i application converse with a user looking at a non-green screen; it’s quite another to have that application converse in real time with myriad applications that touch the entire business process.

At this point in time, though, there may be some benefit for companies that have not yet set out on the Web-facing path. One of two scenarios is ultimately inevitable for that System i application. It will either be replaced by a newer, more agile application on a non-System i box, or it will be brought into the mainstream and integrated with the enterprise-wide, supply chain-wide applications that touch it. If the System i doesn’t move into the flow, it will stay on that island forever and ultimately be replaced.

Hence, as Wayne Kernochen, vice president for industry research firm Illuminata, points out, “Evolving the present System i application portfolio is inevitable. A strategy of ‘upgrading’ rather than migrating/rewriting is the least risky and the fastest alternative.” But simple Webification doesn’t meet all of the objectives of bringing the System i-resident applications into current technology in a way that can meet the objectives of today’s on-demand business environment. Instead, Kernochen suggests that companies should therefore “write not only browser interface, but Web-service provider (and consumer) code in a System i programming environment that combines the Web prowess of Java with the simplicity of RPG.”

Those who have not yet Webified their legacy applications can actually benefit now by moving straight to Web integration. This move, with the goal of maximizing business agility, should include a pragmatic approach to SOA on top of the existing environment. SOA, which allows you to describe your business processes as services delivered to any application, regardless of your hardware, software, or operating system, gives you the agility you need to add new functionality or change existing functionality in a real-time business environment.

SOA is a key concept here. Kernochen continues, “A key reason for SOA is that leveraging application-related information is now high on CEO’s lists as a key source of competitive advantage. SOA makes it much easier for applications, as well as users, to access this information flexibly as the needs of the organization change.”

System i users are slowly but surely recognizing the value that SOA will bring, but widespread acceptance from the System i community still lies in the future. Kernochen feels strongly, though, that “if System i users don’t participate in SOA, their run-the-business applications will eventually become irrelevant, as even those applications can be outsourced via software as a service (SaaS) for medium-sized businesses. The most cost-effective and least risky answer is to upgrade existing applications with Web interfaces and Web service provider/consumer interfaces, using a development environment that combines the simplicity and programmer productivity of RPG with full support for the Web and SOAs.”

The ability to develop and deploy programs in business terms will be crucial to bringing these System i business applications off the island, and those tools are here. To protect their investments in their stalwart server, robust operating system, and trusted applications, users of the System i will choose a pragmatic approach that will move them into the mainstream of today’s technology and business requirements–a true modernization that will not leave them wanting more as their platform of choice is being planned.

Amit Ben-Zvi is vice president of corporate marketing and products for Magic Software Enterprises, which markets the eDeveloper composite application development platform and the iBOLT business integration and business process management (BPM) environment. He can be reached be email at amit_ben-zvi@magicsoftware.com.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot