Sirius Software, Inc. 875 Mass. Ave. Cambridge, MA 02139 Tel: (617) 876-6677 The Case For Web Enablement By Mainframe Upgrade Preface: IS Beware IS should think carefully about the risks of migrating business-critical mainframe applications to the Internet. Today's enterprises typically consider three choices: (1) rewrite (write an application on the Web server performing the same functions as the mainframe one); (2) migrate and then upgrade (move the mainframe application somehow to the Web server and then Web-enable it), or (3) upgrade in place (Web-enable the mainframe application while keeping it on the mainframe). Superficially, choice 2 - and sometimes choice 1 - seems preferable to choice 3. In the three-tier architecture now popular in large-scale Internet implementations, putting an application on the second-tier Web server would seem logical. Aberdeen asserts that in most if not all cases, choice 3 - upgrade in place - is better. Moving mainframe applications to the Web server is far more risky and effortful than many users appreciate - and for performance-critical applications, it will often do harm rather than good. Moreover, there is no need to make the effort - mainframe-software suppliers can allow users to Web-enable mainframe applications without moving them. This Profile describes the troubles that moving mainframe applications to Web servers can cause, and ways to avoid them by upgrading in place, using mainframe Web-enablement technology. Executive Summary As Internet solutions pervade many enterprises, IS is revisiting the question of whether to move business-critical legacy applications away from the mainframe. Many of these applications are "performance-critical" - they must deliver high performance and scalability in a production environment, because the business depends on it. The argument for moving performance-critical applications onto Web servers has been that they can take advantage of the raw performance of Web-server hardware and integrate more effectively with the new Internet software and technologies. Moreover, Year-2000 concerns make some IS managers feel that some mainframe applications cannot be salvaged, and should be replaced with "newer" solutions that are Year-2000-safe from their inception. Aberdeen finds that, on the contrary, the technology balance is tilting towards Web-enabling performance-critical mainframe applications in place, and leaving them on the mainframe. Migrating or rewriting performance-critical applications is now far harder than upgrading them. The resulting Web-server application often delivers less performance, scalability, and robustness than the old mainframe one. Year-2000 tools used for mainframe-application upgrade and new Web-enablement software from suppliers such as Sirius Software are making mainframe-application upgrade more feasible. What is true for performance-critical applications is often also true for other types of mainframe applications, such as custom enterprise applications with complex code, applications that require frequent and rapid changes because of end-user and business needs, and customer-interface applications that Web-enable back-office systems - all systems where Web-enablement can yield major competitive-advantage benefits. These systems are typically critical to the enterprise's bottom line, and must continue to operate through the Web-enablement process. While scalability and robustness after conversion are of less concern for these types of applications, migration and rewrite are similarly risky and effortful, and the migration may create performance problems where none were before. Therefore, Aberdeen urges IS to reassess current efforts to rewrite or replace business-critical mainframe applications, and consider instead a "best of both worlds" upgrade - mainframe-application robustness plus rapid development and the ability to keep pace with the rapid changes in Internet technology. The Problems With Moving Mainframe Applications To Web-Enable Them Aberdeen finds that there are two added types of problem that enterprises encounter as they try to move key mainframe applications to Web servers, rather than upgrading in place: The usual risks and costs of moving a business-critical application from a mainframe to another platform; and For performance-critical applications, the problems of delivering performance, scalability, and robustness comparable to the mainframe on the new platform. Risks and costs of moving key mainframe applications to Web servers are massive. Mainframe applications - especially those highly tuned for performance - are so customized for the mainframe that they cannot simply be copied from one machine to another; instead, those migrating the application must have a deep understanding of the application's code and its purpose. Even then, migraters must rewrite much of the code in the application to run and deliver optimum performance on a very different type of computer - a matter of months or years. New errors may creep in during the process, making the resultant application unusable. Moreover, in many cases, the enterprise's knowledge of the application, or the documentation, has been lost or is inadequate. Today's reverse engineering or impact analysis tools cannot fully understand the performance-tuning code critical to the application's performance. Enterprises' Year-2000 efforts are a prime example of just how difficult it can be to adapt an application to a new platform. The Year 2000 conversion process requires much the same tasks as migration or rewriting, but on a much smaller scale. However, as noted in the Aberdeen Viewpoint "Aberdeen Picks The Right Tools For Year 2000", because the applications are business-critical, converters must go through an elaborate process of planning, impact analysis, conversion, testing, and reintegration into the enterprise's production environment. The testing phase alone can take over a year. IS should also note that maintaining the migrated application on a Web server can be a long-term problem. Web-server tools are better and more experienced at developing new applications than upgrading old ones. Moreover, typically, the application continues to access mainframe data. As new end-user needs drive further changes in the application, developers must upgrade the Web-server application and the mainframe data in sync - a complex process. Migrate/Rewrite Problems: Delivering Mainframe Power On Web Servers Aberdeen finds that the second set of problems - performance and robustness once the application is moved - is equally important and often more difficult to overcome. To put it bluntly, the Internet is not "ready for prime time". Developers must write Web applications using tools that have far too little experience in delivering performance in data-intensive situations or in adapting to the unique Internet architecture. Likewise, the middleware (such as TP monitors) that these developers must invoke is immature, not robust, or not scalable. In fact, it is not yet clear just what is the right way to scale a data-intensive application on the Internet: what is the right split between client applet and server, or between application servers. Aberdeen research shows that developers have two basic choices when creating or Web-enabling performance-critical, data-intensive Internet applications: Write on top of the CGI set of Web-server APIs; or Write on top of middleware that bypasses CGI, such as Oracle's Network Computing Architecture or Microsoft's Wolfpack. Each has major - but different - problems when the developer tries to create high-performance applications. Below, we show how, in both cases, the enterprise moving a performance-critical mainframe application to a Web server is very likely to run into scalability, robustness, and/or development-speed problems. The Problem With CGI For today's typical Web server software (usually Microsoft's or Netscape's Web servers) CGI serves a function similar to a TP monitor's: it allows client browsers to "pass through" the server to back-end applications, and it provides an API that back-end applications can invoke to receive input from the Web server and browser clients. Because CGI is the only such interface incorporated in most Web servers, and because most server-side Web development tools are still 3GLs with little knowledge of data access, the majority of enterprise developers still use CGI just as they would use CICS or other TP monitors: as the basis of Internet server-side development and the core of Web applications. As a "TP monitor substitute", CGI has major problems. As a first-generation Web TP monitor, CGI uses much more CPU time than necessary. Neither it nor the Web server was designed to handle transactions, so each transaction must be chopped up into request-reply interactions with no knowledge of the transaction's "state" between the interactions - a major source of unnecessary overhead and developer effort. CGI's interface is likewise very low-level and has no knowledge of data - placing the burden of creating not only a data access mechanism but also much of the database management system software on the developer. CGI does not offer the key TP-monitor scalability technologies proven in over 25 years of mainframe and Unix applications (communications multiplexing and load balancing). Thus, using CGI to build scalable, robust applications is a bad idea. The evidence for this in real-world application development is already clear: ISVs developing Web solutions testify that CGI-based applications act as a "scalability bottleneck" on the server, slowing communication through the Web server to the back end - and especially for data-access operations. As a result, CGI-based applications - the majority of today's Internet applications - are not scaling rapidly enough in many cases to match today's end users' exceptionally fast-growing Web-data-access demands. They are also more difficult to build and maintain. The Immaturity Of Today's Non-CGI Internet Scalability Technologies If CGI is not a good basis for performance-critical applications, is there an alternative? In fact, there are several other choices for the enterprise considering migrating/rewriting mainframe applications on Web servers. The main problem with all of these is that the software involved is immature - not robust and hard to scale. The Web middleware that enterprises can use as a basis for scaling Internet applications falls into one of two categories: Microsoft and third-party middleware aimed at allowing development for Microsoft Windows NT/Internet Explorer and similar Internet solutions; and Middleware most closely associated with Netscape and CORBA Object Request Brokers (ORBs). This middleware also often supports Microsoft environments. Microsoft-related Middleware Key technologies for scaling Microsoft Internet environments are Microsoft's IIS (a CGI equivalent that is more lightweight and includes communications multiplexing), Wolfpack (a TP monitor based on Tandem's technology), and Application Server (providing basic support for load balancing across applications on a single server). While IIS has demonstrated cost-effective scalability in some cases, it clearly does not provide the developer support and load balancing scalability of a TP monitor. Wolfpack is not yet widely available and is in any case aimed at less complex applications than the typical business-critical mainframe application. Application Server offers limited load balancing that must be programmed in by the developer and is not yet widely deployed. None of these technologies has been field-tested in scaling enterprise-scale data-intensive applications - and Microsoft is not focusing on delivering high-end scalability for Internet environments. Overall, Microsoft-related middleware products do not deliver robustness or scalability comparable with mainframe TP monitors, and because of the products' immaturity and Microsoft's focus elsewhere it is not likely that a fully integrated suite of mainframe-class products will be available in the next 1½-2 years. Non-Microsoft Middleware Non-Microsoft support for developing Internet applications on the Web server includes solutions focused on a particular supplier's software, such as Oracle's Network Computing Architecture (NCA) that provides the broadest support for the Oracle RDBMS, and proprietary middleware-supplier solutions such as TIBCO, Active Software, and BEA Systems. Supplier-specific middleware has difficulties handling non-supplier enterprise software, such as back-end access to mainframe applications - an important point when a migrated application must access other applications or data that remains on the mainframe. Proprietary middleware is typically from smaller suppliers, raising the risk that the user will bet on an approach obsoleted by a Microsoft, Sun, or IBM Web-middleware pronouncement. These solutions also have scalability or robustness problems: Their TP monitor functionality has not yet been fully tested in large-scale enterprise Intranets and Web sites; Some of the technology needed to support location-independent operation in the distributed Internet environment - e.g., ORBs, repositories, and partitioning tools - is not yet integrated together, much less field-tested as a whole; and It is not yet clear what is the best way of partitioning applications across servers - or of partitioning applications between client or applet and server - in the the new Internet architectures. The Migrate/Rewrite Bottom Line: Not What You Hope Aberdeen concludes that most if not all migrations or rewrites of mainframe performance-critical and similar applications will not deliver as hoped: Development will be harder and longer than expected. Initial success in small-scale Internet implementations can hide the difficulties of implementing complex and data-intensive performance-critical applications. Reproducing the application on a new platform - if it is possible - requires an extensive process. Because the basic tools to support scalable, robust applications are not yet there or not integrated, the developers must either add those tools by hand - a long and tricky process - or have the application fail to scale in the field. The application will be less robust than it was on the mainframe. Errors and problems may creep in during migration or rewrite, and the middleware on the Web server supporting the application is not yet as robust as on the mainframe. The application will often perform less well - to the point of unuseability - than on the mainframe. Certainly, Web-server hardware has impressive raw power and supports the latest software technologies. However, as we have seen, these Web technologies have not achieved the level of scalability that today's mainframe software delivers for performance-critical applications. Moreover, today's Web servers focus on servicing constantly-increasing end-user requests, and therefore "crowd out" applications seeking CPU time. The Alternative: Upgrading Mainframe Applications With Internet Technology Aberdeen finds that Web-enabling mainframe applications in place is more feasible than ever before, for three reasons: Upgrade tools are better. A side-effect of enterprises' Year-2000 efforts is a thriving market in field-proven tools to upgrade mainframe applications. While, as noted above, any change to a complex or performance-critical mainframe application is not easy, upgrading that application is less of a change than migrating/replacing it, and one that many enterprises will already have done in Year-2000 conversion. Moreover, Year-2000 efforts yield application information that can make upgrade easier. Mainframe software suppliers are doing better at staying abreast of Internet technology. Solutions such as IBM's Net.data provide connectivity from mainframes to Internets, ensuring that mainframe applications can connect to the Internet and Intranets effectively. Solutions are arriving to allow enterprises to Web-enable many performance-critical mainframe applications effectively. For example, Sirius Software's Janus Web Server will allow users to Web-enable performance-critical Model 204 applications rapidly, preserving their scalability and robustness. IBM's Net.data Net.data aims to allow businesses to deploy interactive Web-based applications that leverage existing application logic and data. Net.data DB2 WWW Connection enables developers to write HTML/SQL-based macros that handle Web-server data access. Thus, both Web pages and end users issuing queries can access or update information in backend databases "dynamically", i.e., immediately, without bringing down or bypassing the Web server. Developers can not only create macros from scratch, but also by cut-and-paste from Web authoring tools. Net.data delivers higher performance by allowing native access to DB2, Oracle, and Sybase databases, and native APIs rather than CGI. Net.data also includes ODBC-gateway and native flat-file support and supports DB2 Extenders for Internet-multimedia-data access. Net.data allows developers to place application logic on the client, Web server, or database server as appropriate. Net.data provides APIs and development tools for Java, C/C++, COBOL, and other server-side "backend" applications - thus, users can quickly redeploy existing logic into new Web-based applications. Net.data supports invocation of DB2 stored procedures, allowing higher performance for commonly-used data-management operations. Net.data allows Web-site developers to use "variable substitution": creation of variables that can be initialized by end users or backend programs (e.g., from a database) and changed by the administrator or backend programs while the Web server is running, allowing constant update of Web displays. Developers can also use these to keep track of an end user's Internet connections associated with accesses to a backend database - i.e., the "state" of a DB2 transaction between connections. Thus, a Web site can ensure that OLTP and decision-support transactions are carried out correctly. Sirius Software's Janus Web Server Computer Corporation of America's Model 204 has long been known as a "diamond in the rough" - an often-overlooked mainframe DBMS with innovative technologies that deliver exceptional scalability and rapid development of data-intensive applications. Thus, Model 204 User Language has been for the last 15 years a 4GL of choice among knowledgeable mainframe developers creating performance-critical applications. Janus Web Server extends Model 204 to allow Web-browser access to Model 204 databases. Moreover, Janus Web Server includes a Model 204 User Language API, allowing Model 204 User Language developers to extend their applications to support Internet access simply and rapidly. Janus Web Server includes support for Netscape's SSL security scheme (now widely supported by browser suppliers), ensuring vitally-important key-corporate-database security. An upcoming extension of Janus Web Server will support a CORBA Object Request Broker (ORB), allowing creation of Internet applications with location-independent access to persistent database objects in Model 204 databases. Upgrading a Model 204 application with Janus Web Server is clearly preferable to migrating it or rewriting it on a Web server using CGI or some other mechanism. Model 204 User Language is far higher-level than CGI and includes far more knowledge and experience of data-intensive applications - resulting in more rapid Internet-application development and greater programmer productivity - and has demonstrated scalability and robustness far beyond CGI. As a 4GL, Model 204 User Language is a match for any Web-server development tool; Model-204-based mainframe applications are typically more robust than non-CGI environments; and by placing the Web-enabled mainframe application on the mainframe, the user can take some of the load off the Web server and improve the mainframe application's performance. Aberdeen Conclusions Aberdeen finds that the advent of the Internet has had a mainframe effect directly opposite what one might expect. Instead of making it pay to deep-six performance-critical and similar mainframe applications by rewriting them on Web servers or migrating them, it makes it easier for enterprises to "have their cake and eat it too": to Web-enable in place, adding cost-effective Internet connectivity and application deployment with minimal impact on the enterprise's production environment.One key reason for this effect is that migrating or rewriting these mainframe applications is much more difficult than users might expect, and often results in applications that are less scalable and robust. A second key reason is that the tools for upgrading and Web-enabling mainframe applications, such as Sirius Software's Janus Web Server, are arriving and improving. Aberdeen recommends that senior IS managers thinking of rewriting or migrating mainframe applications for Internet purposes think again. Rather than having to continually question the need for mainframe applications, IS can use the new mainframe-software realities to upgrade much of its mainframe software to meet the new enterprise Internet needs, with minimal negative impact on the systems running the business. In these cases, IS managers can, indeed, "have their cake and eat it too". AberdeenGroup, Inc. One Boston Place Boston, Massachusetts 02108 USA Tel: 617.723.7890 Fax: 617.723.7897 Contact Information: For further information on AberdeenGroup's products and services please contact us at info@aberdeen.com This Document is for Electronic Distribution Only -- REPRODUCTION PROHIBITED -- Copyright 1997 Aberdeen Group, Inc., Boston, Massachusetts The trademarks and registered trademarks of the corporations mentioned in this publication are the property of their respective holders. Unless otherwise noted, the entire contents of this publication are copyrighted by Aberdeen Group, Inc. and may not be reproduced, stored in a retrieval system, or transmitted in any form or by any means without prior written consent of the publisher.