Avoid homegrown Web-to-mainframe solutions - Industry Trend or Event

A recipe for success uses preservation of mainframe data and applications right where they are.

More than 70% of the world's critical business data is stored in mainframe computer systems. In the front office, almost all business data is accessed by computers, usually relying on a Windows operating system. In between the back and front offices is an extensive layer of transaction servers running Unix, Linux and Windows NT, or now, Windows 2000.

A big help in enabling the back-and-forth movement of data has been the Internet. Companies are rushing, not just to "be on the Web," but also to build strong business-to-business, business-to-employee and business-to-consumer functionality into their Internet channels.

While this is a great idea, and a great use for the Internet, it involves more change and more complexity.

Since the majority of Internet transactions take place via a Web server, the ideal solution would be to bypass the mainframe and do everything at the server level. Right? Wrong! Reinventing the wheel is costly, and the idea of moving legacy data and business logic out so that it can be served up through a distributed computing architecture is an idea that has "titanic" written all over it. It is far from unsinkable.

The ideal solution is to preserve mainframe data and applications right where they are. This serves multiple purposes by leveraging the power and inherent safety of the mainframe environment, helping realize additional value from legacy resources, and saving a ton of money. A successful Web-to-host relationship brings direct, transparent access to legacy applications, preserves data consistency and availability, and ensures reliability across the Internet.

GO OUT-OF-THE-BOX

The real solution for Web-to-mainframe access then is to plan your architecture around out-of-the-box applications created specifically to address and reduce the complexities of putting an "Open for Business" sign on your mainframe. This will save you lots of time in development, implementation and support costs. It also mitigates many of the issues found in homegrown solutions:

* Poor performance. This leads to high frustration for your business, employee and consumer users.

* Integration roadblocks. Many companies have three or more mainframe data sources (e.g., DB2 for OS/390, IMS/TM, CICS/TS, ADABAS). Integrating these disparate systems with either home-brewed or point-product solutions that increase the integration complexity gives rise to additional islands of computing as disaffected groups go off on their own and develop a "better" solution.

* Lack of expertise. There are many ways to get a mainframe application to the Web. The architecture that works best for one organization may not be best for another. Do not be afraid to make a different architectural choice than the ones you read about in the trade journals. It will be more risky to follow the crowd and ignore your own organizational skills and strengths. Having to completely retrain a group of developers and support personnel adds more risk to the project. While highly skilled, your in-house professionals do not do enterprise integration development on a day-in/day-out basis, so the Web interface packages they deliver usually include numerous points of failure. This translates into additional frustration and expanding development time and cost.

* Production support. When the solution is finally delivered, will you have the continuous manpower reserves to support this system in production?

* Bridging the gap. Out-of-the-box solutions help you focus on business instead of technological philosophy by bridging the communication and generation gaps that often exist between mainframe and Web developers. Do-it-yourself applications tend to widen the gap because one group will seldom be happy with the solution the other brings to the table.

There is quite a bit to think about in opening up your mainframe applications and data to the Internet--simple architecture, scalability, support and future flexibility, to name a few. The good news is, it is not as complicated as it sounds because there are already proven, highly cost-effective solutions that can be up and running in just a few days.

Bennett, an IT professional, works for NEON Systems in Sugar Land, TX.

www.neonsys.com

Circle 255 for more information from NEON Systems

RELATED ARTICLE: Eight Steps for Success

1 Play to your strengths. There are many ways to get a mainframe application to the Web. The architecture that works best for one organization, however, may not be best for another. Think tactically, stick with your strengths, and you will be less likely to encounter unwelcome surprises.

2 Keep it simple, Designing a complex application with many moving parts is easy, but developing one that works well is much more difficult. Overly complex solutions will take longer to implement, adding to the cost of the project. One architectural decision that will increase simplicity would be to standardize on a single type of connector from the server to the legacy application. Otherwise, using a different connector to each type of legacy application will increase complexity and put an additional drain on your IT personnel.

3 Plan for the future. Be sure your architectural solution leaves room for growth. Make sure your Web-to-host application will be able to scale and handle more volume as it grows.

4 Less is more. Some architectural constructs that can limit scalability are too many network hops or too many components in the process. Each handoff between components saps performance and reduces throughput.

5 Consultant-free implementation. If a solution is so complex that it cannot be implemented without a team of highly skilled consultants from outside your organization, good luck. The only ingredient that will help you win the game at this point is luck--and lots of money, too.

6 Brush-up on your crystal ball skills. Consider the flexibility, or lack of it, in your architecture. There are tradeoffs in every architecture, and your choice will have far-reaching consequences, for the better or worse, as time goes on. For instance, a terminal emulation or screen-scraping solution may get your legacy application on the Web in a short time frame. This architecture may not support you later, however. Try to anticipate future business requirements and determine if your architecture will be able to support them.

7 Did someone say "support?" Distributed Web applications are notoriously difficult to debug and troubleshoot. Some architectural solutions will provide you with useful tools to monitor request/answer transaction times and system components. Without this, your support team will need to know ahead of time of all the places to gather this kind of information. Since this is constantly changing, you will need a comprehensive plan to help your support staff identify all the pinch points.

8 Get references. Make sure the solution you choose has been used successfully by other enterprises. Talk to the people who have "been there, done that." In addition, evaluate whether the solution you choose will be able to:

* identify and stop runaway queries against your legacy databases before they impact user response time;

* identify and audit the actions of users accessing your legacy applications; and

* bill certain users for Web activity against your legacy applications.

COPYRIGHT 2000 Nelson Publishing
COPYRIGHT 2000 Gale Group