Tech Insight: Good Ideas Whose Time Has Come

The midrange community has faced numerous challenges in its attempt to deliver on the concept of client/server computing over the last 10 years. These challenges, as well as with dissatisfaction with 5250 green screens, intensified with the blitz of flashy GUI front-end solutions just as the Internet was going public. Now the demand for delivering Web-based collaborative software has been thrown into the mix. With the relentless evolution of business information technology, there’s a compelling reason to take advantage of advanced Web technologies.

The midrange community, though, has been hesitant to move forward with incorporating new technologies. This hesitation can be attributed to the difficulties in upgrading or moving from heavily customized systems, an unwillingness to improve ancillary processes, and less than successful client/server implementations. Most OS/400 shops have a long history, and they have heard it all–sometimes more than once. They know that not every good idea pans out, and they tend to wait until the hype has died down to make their move. But sometimes that’s not the right strategy.

To some extent, not departing from existing systems can be rationalized, but those who lack a plan to keep systems updated risk falling behind. As for the failures in implementing client/server solutions, you may recall that when all of this began, there were conflicting opinions on what exactly the client/server model was. What did client/server mean to your business? How should it be implemented? Could existing technology support it? All of this uncertainty created more failures than successes. There was also the mindset that not knowing what client/server was did not matter, as long as you were doing something GUI. Consequently, solutions were developed that promised to deliver on the idea of client/server regardless of their viability.

Although, for example, GUI-enabling green-screen applications–whether using Windows or Web clients–may have seemed like a good idea, it only served to wallpaper existing solutions without adding functionality. The real question was, why hide the green screen? What value did masking the applications provide? If the point of going this route was just placing a mask on applications and placating users, this was the way to go. That is, of course, until real Windows or Web functionality was demanded.

Another example of a forward-looking idea that might be questionable was the outsourcing of e-commerce and e-business solutions under the application service provider model. Although outsourcing these solutions to hosting entities may have seemed cost-effective, it was not the best solution if your desired outcome was real-time information and scalability. These solutions often resulted in the creation of batch interfaces to extract/import information, maintenance of foreign databases, manual input of transactions, and limited flexibility. These constraints prevented adding functionality as a business grew and requirements became more demanding. Too often these solutions ended up being eliminated or reengineered by bringing the solution in-house, where access to enterprise information was readily available. Shifting the processes internally did not necessarily guarantee better results, though. Successfully reengineering these applications was dependant on using tools that could natively access your legacy applications and database.

Another example of something that sounded like a good idea for OS/400 shops but might not really be is using Windows solutions and development tools to create Windows applications. Although Windows solutions have been the standard choice for plenty of application software, just like RPG and COBOL programs, these also present considerable maintenance requirements. Depending on the software, support could vary between maintenance at the desktop level to multi-user servers. The scale of the software also determined whether implementing updates or upgrades produced scenarios where dedicated resources were required for that function alone. More important, most Windows-based solutions did not access enterprise data using native DB2 technologies, lending themselves to erratic failures in database integrity, increased demand for network infrastructure, and poor performance. As for choosing a development tool, it was not uncommon to begin developing applications only to find out long into the project that it would not work as desired, thus prompting the move to another tool, and so on.

Many so-called client/server endeavors involved spending millions of dollars and countless hours, with little but failed projects and shelved software to show for it. In the frenzied move to be part of something new, some overlooked whether a hardware or software technology could support a true client/server model–one in which a solution had a common user interface and a common methods interface, regardless of the access point.

Even now, with more capable technology available, the same problems occur. If an OS/400 server is as good a server as any other out there, why is it that venturing into client/server projects is still less than successful and has even prompted some companies to consider abandoning the platform altogether?

The green-screen interface, as well as the proliferation of PC-based technologies and the Internet boom, certainly contributed to the misperception that you had to go outside the OS/400 platform to have GUI applications. Another reason has been that the newest generations of developers are unfamiliar with the AS/400, and now the iSeries, and many RPG developers are unfamiliar with object-oriented technologies. But there’s been a push to position the OS/400 as a total-solution server and to convey that viable, evolving software tools can natively leverage the robust technologies built within it: tools that can be used to develop client/server and collaborative Web software solutions. OS/400 technology has certainly evolved substantially, creating an environment for solutions that use DB2 (not ODBC) and Web services to process business transactions.

For those who waited to see how things would play out, the move to Web-based, client/server solutions is much more than a compelling or novel concept. The opportunity to migrate to Web-based enterprise applications, or using Web-based solutions capable of complementing legacy software, is an exciting prospect for the midrange community. As with any move to use emerging technologies, performing due diligence is the key to understanding the design requirements of an environment in which the Web is used as a gateway for enterprise application software in order to transact and communicate in a collaborative arena. It’s an environment in which solutions can interact with one another through Web services, thus creating a way to access information from anywhere, at any time.

The challenge for the OS/400 community is to identify which solutions will best meet its needs. Are client/server or collaborative Web technologies for everyone? Maybe not, but the importance that the Internet will play in enterprise software in the years to come is becoming more clear, and using Web technologies to remain competitive looms as a necessity for the future.

Hector Martinez is president of SKM2 Technologies, which provides consulting services and software solutions for OS/400 systems. E-mail: hmartinez@skm2tech.com