Happily Ever After: Reducing the Risk When Migrating IBM-Centric Businesses to the Web
"Something old, something new, something borrowed, something blue" is the traditional formula for a happy marriage.
The marriage of COBOL-based programming and the new wave of e-commerce, which we call e-COBOL, run along the same formula. e-COBOL allows a company to take its existing programs written in the COBOL language, tie them to the exploding world of e-business, borrow some handy technology to bridge the gap between the COBOL world and the Internet, and profit from the new opportunity.
e-COBOL extends the COBOL language so the ACCEPT/DISPLAY verbs (used to accept screen input and display text) can accept a Web form and display a Web page. This enables the programmer to use familiar syntax without being concerned with the details of CGI, SAPI or NSAPI. There is also an EXEC HTML statement, similar to EXEC SQL, that allows the acceptance of SQL data. EXEC HTML enables a programmer to embed HTML directly into a COBOL program, substituting dynamic data in the same way as the SQL data.
As we approach the Year 2000, e-business promises to be the major driving force in IT development through the early part of the next millennium. The challenge is making it happen fast enough to create a competitive advantage while leveraging existing skills and investment. The cost-effectiveness of NT and UNIX platforms is also making it increasingly attractive to migrate mainframe applications to these popular platforms.
Operations like the Army and Air Force Exchange Service (AAFES) know the value of e-COBOL. AAFES sells a wide range of products to active and retired armed services personnel through 10,878 facilities worldwide. With revenues of $5 billion, AAFES processed over 5 million invoices last year.
AAFES was aware of the success of online stockbrokers like e-schwab and e-trade. They knew that amazon.com was able to turn its electronic inventory 25 times a year and that organizations like autobytel.com have gotten 1.5 million purchase requests in the past three years. AAFES was quite unwilling to concede the potentially lucrative online market to any start-up firms. Yet many key processes, like their Visa statement system, were based on COBOL.
AAFES wanted to offer its customers the same kind of convenience in every area of its business, but was unwilling to throw out its old computer system and felt it imperative to use its existing staff to develop its e-business system. Today, they have fully automated their Visa statements so people can look at them online.
By now, most companies have dealt with the Y2K problem. The world of e-commerce is the next challenge IS/IT departments will face. According to International Data Corp., by 2001, the global Web economy will surpass $500 billion. Interestingly, while the consumer market is attractive, 80 percent of that growth will be in the business-to-business area and only 20 percent in the consumer market. That makes the case for e-business all the more compelling.
There are three levels of e-business development that any organization has to deal with:
• e-support – improving service or support
• e-commerce – trading on the Web
• e-business – the all-encompassing term which is the sum of e-support and e-commerce
The term e-business also is used to describe business-to-business systems (using the Web as the EDI transport layer). This is a rather narrow definition. Perhaps, better is IBM’s definition that says, "e-business is what happens when you combine the broad reach of the Internet with the vast resources of traditional information technology systems."
Changes in Structure
The GartnerGroup predicts (with an 80 percent probability) that the browser will displace Windows as the primary client platform for new application development. By the Year 2000, the browser will be as important as the Windows client. This does not mean that Windows is dead – the browser will run under Windows. But with this swing toward the browser as the main client, the browser will represent the biggest threat to Microsoft and the PC-oriented Web world.
The message is clear: No matter what is being used in today’s computing environment – whether Windows or COBOL – it must be browser-compatible.
Users are moving up a ladder from static applications to database-enabled applications. Next, they will go to transactional applications, and eventually (at the top level) to fully integrated processes that allow Web-enabled commerce between companies. At that point, buying and selling will be fully integrated in an EDI-like manner.
That last step is a tough one, especially for companies with a history of commerce. Most COBOL programmers would envy amazon.com’s "greenfield" approach to programming. They had a vision and wrote software to enable them to do commerce on the Web. Their programmers did a fine job of executing the company’s business plan.
The typical Fortune 1000 firm has a huge investment in COBOL. It is the heart of their business logic. They cannot afford to create an e-commerce system from scratch and then discover that it is not compatible with decades of corporate applications deployed on other systems. It is simply impractical to consider any alternative that does not allow the company to leverage its existing COBOL infrastructure.
Moving applications to the Web can involve screen scrapers. A screen scraper sits between the 3270 data stream and converts it to a graphical user interface format. A good example of the complexity required is the typical airline’s database. Every airline has a reservation system, with flight times, ticket costs, aircraft configurations and frequent flier information. That information is presented to ticket agents, travel agents and other industry insiders. The presentation is less than beautiful, but the information is available to anyone that has undergone two week’s training and studies the manual.
Unfortunately, typical travelers making airline reservations on the Web for a honeymoon trip to Cancun do not have the time to ramp up to the educational level required. They expect a pleasing, simple front-end interface that tells them which flights are available, at what times and for how much money.
The challenge for the MIS department is to change the plain, functional front-end visual format to something more graphically friendly, but to retain the information from the COBOL program and the transaction information that is running on the host. To do that, the front-end has to be changed while the back-end is retained. The key to success is to reuse as much of the COBOL as possible.
When connecting back to the mainframe, any key middleware should be usable, whether it is TX series, MQ series or Microsoft Transaction System. It also is imperative to gain access to the data whether SQL Data, Mainframe VSAM Data or some other data type is being used. That data must be available and usable by the computer in the format in which it currently exists.
Beyond the business tools, there is a sizable human investment in COBOL. The existing cadre of COBOL programmers are familiar with the company’s core business logic and its supporting data. They know which systems link to others. They know the people in the accounting and marketing departments. They have a deep loyalty to the organization. It would be senseless to waste valuable human resources with COBOL expertise which have built successful companies. In just about every case, the firm will have to keep some COBOL programmers on staff to guide the new, high-priced Web talent.
Most have no understanding at all of COBOL, which will be the key source of their information. It is fair to say that Java programmers typically a have much lower understanding of the business requirements of such projects, so there is a greater risk of failure.
Most of these Web programmers come from a Microsoft-centric world, one dealing with relatively small volume, small scale, departmental-based systems. At the higher end, typically the IBM/Cobol end, one finds large enterprises focused on transactional systems with CICS and IMS. The problem most programmers face is making the leap from the IBM mainframe world to the world of e-business.
After a one-week training program, typical COBOL programmers become familiar with Web-enablement technology and understand the issues involved in Web architectures (such as coping with the lack of states in HTTP).
Make vs. Buy
There is a watershed decision that needs to be made early in any e-business development process: Is the organization going to make its own solution or is it going to buy the expertise it needs? Starting from scratch obviously will take a long time. However, it may result in the most flexible and the most customizable solution.
Packages are quite fast to implement, but they do not allow the business to differentiate well. The real need is a process that takes a sizable core of existing COBOL programming – eliminating the need to develop from scratch – while permitting some customization to give the interface and graphical look needed for e-business.
To accomplish this, programmers need tools that have the staying power to support editing, compiling and debugging legacy mainframe COBOL applications. Gaining the competitive edge requires a product that provides all the programming tools in one easy-to-use, consistent interface.
Many firms have a deeply embedded COBOL base. Using e-COBOL simplifies the development of e-business applications and the extension of legacy applications to the Internet and eases legacy application migration.
e-COBOL is a powerful combination of COBOL syntax and highly productive tools that enable the programmer to develop Internet applications without needing to understand the detail of Web interfaces like CGI, ISAPI or NSAPI.
How It Works
The challenge, then, is to extend the existing databases and programming resources to the world of Web-based commerce. One of the fastest ways to bring an e-business project to market is to leverage the existing databases and existing human skill sets. This is what AAFES continues to do successfully.
A project which could have taken a year or more to complete, had management decided to re-invent the wheel by developing a complete Internet-based system, was executed using existing systems in three months and has been bringing in revenue ever since.
The secret is to find a way to make use of the existing business logic. (The fact remains, business logic is still developed in COBOL with an appropriate front-end). By using e-COBOL to extend its business applications to the Web, AAFES was able to re-host existing legacy applications and optimize the reuse of its existing business logic. e-COBOL makes it easy to create an HTML front-end around a COBOL business logic component and at the same time access transactions easily in that environment.
Taking COBOL to the Web
While nobody wants a shotgun wedding, time is of the essence. There is no question that the fastest way to get to e-commerce is to identify and reuse existing business logic. After that, other requirements would include support for CGI, ISAPI and NSAPI; ability to create CORBA/COM objects; a server-oriented Web design program, oriented to the typical COBOL programmer; and ability to execute remote transactions for IMS and CICS.
Forget about throwing a COBOL programmer some Front Page disks and expecting an e-business solution to appear a few months later. Any solution has to integrate COBOL and HTML. It has to provide transaction integrity. Parts of applications will have to be re-hosted on the server.
The programmer will want to select a tool that allows him or her to:
• Maintain existing applications
• Develop applications that require data and transaction access
• Identify and component-ize business logic (use COBOL to create CORBA objects from existing logic)
• Develop dynamic HTML and create Web pages
• Re-map from the Web page directly to a COBOL data item
• Generate applications from a Web page that automatically updates itself on the server
Typically, data in a Web page is ordinary string data. But a COBOL programmer wants COBOL numeric data items so they can be manipulated mathematically and converted from string to numeric data (or vice versa). Programmers must be certain to use an "open technology" approach, so as not to force dependence on a single middleware solution. Most successful IT organizations will elect a "best-of-breed," third-party approach.
In large corporations, it is the business systems that differentiate one from another. Service delivery, shipment tracking, customer access to databases, presentation of historic data – all are key components which provide the hallmarks of service used by different companies. Adopting a packaged application forces the company to become another face in the commercial crowd, and costs the company its service cachet. Once a company realizes the benefits of differentiation, any desire to dump the COBOL databases for a packaged plan simply disappears.
Make It Happen
With the proper tools, a COBOL-trained shop can get to e-business in a matter of months. AAFES completed four e-COBOL projects in one year using just two COBOL programmers. The key concept to keep in mind is that a COBOL/e-commerce marriage brings together two well-established families of technology. The mainframe component brings with it traditional values like scalability and reliability from the IBM world. The new technology comes from the Microsoft family with its heightened graphics and distributed background. The real challenge is to marry those two families of technology into a long, harmonious and productive relationship.
A reasonable business goal is to become fully e-business-compatible in 12 months or less. Key points to keep in mind are that the successful company must get to the Web – fast. It will leverage existing human skills and reuse existing applications and data. The payoff will be faster implementations, shorter payback time, flexibility to differentiate your company from all others and a scalable solution.
The next step is to move to the Unix world. The challenge of porting Unix to the Web world is similar, in broad terms, to COBOL’s. The payoff will be similar: scalability from the smallest PC-based system, through COBOL, up to the largest Unix-based system.
What about the "something blue" in our wedding success formula? In the case of e-COBOL, we can chase away the blues by planning the program properly and quickly moving forward to the world of e-commerce.
About the Author: Ian Archbell is the Vice President of Product Management at MERANT.