Prediction: Multimodal transaction processing will emerge

Transcription

1 Strategic Planning, M. Pezzini Research Note 19 December 2003 Predicts 2004: Prepare for Multimodal Transaction Processing Online transaction processing will have to support Web services, mobile channels and events. Users must introduce unproven technologies, while maintaining the level of service offered by transaction processing monitors. Core Topics Application Integration and Middleware: Architectures and Patterns for Software Infrastructure Application Integration and Middleware: Enterprise Application Platforms and Platform Middleware Key Issues Which software infrastructure architectures and patterns will prevail, and which will fail to gain industry support? Which technologies will enterprises strategically adopt to implement their software infrastructure? What will be the prevailing benefits and best practices for the use of application platform technologies in the next five years? Strategic Planning Assumptions By 2006, at least 40 percent of new OLTP applications will be implemented as collections of transactional business components engaged by multiple deployment scenarios including multichannel, event-based architectures and multistep processes (0.7 probability). By 2007, more than 25 percent of new, multimodal transaction processing applications built in-house for 5,000 concurrent users or more will be deployed on a combination of mainframe TPMs and other platform middleware (0.7 probability). Through 2007, more than 50 percent of Global 2000 companies will adopt multiple, inconsistent mobile middleware architectures to support different mobile applications (0.8 probability). Online transaction processing (OLTP) is one of the most common computing styles. A typical OLTP application supports many online users. They manipulate in real time a large, shared database by triggering programs known as "transactions." Classic examples of OLTP applications include airline or hotel reservations, order entry and banking operations. Transaction processing monitors (TPMs) an early form of platform middleware emerged more than 30 years ago to support OLTP requirements for high scalability and performance, optimized resource allocation, fast recovery and transaction integrity. The basic application architecture for OLTP hasn't changed significantly for decades. But new business requirements, technologies and innovative computing architectures will change established practices and pose new challenges to IT organizations. Prediction: Multimodal transaction processing will emerge Traditional OLTP applications were stand-alone systems meant to support a well-defined set of users with homogeneous requirements. Best practices for developing these systems consolidated throughout the decades and the relevant technical and application know-how is well established across IT departments, system integrators and independent software vendors providing packaged applications or system software. This status quo has been disrupted by users' adoption of client/server, the Internet, service-oriented architecture, Web services, mobile and wireless devices, and event-driven architectures since the second half of the 1990s. The next generation of transaction processing applications will have to be Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 implemented in very different ways to respond to new business strategies, including multichannel, the real-time enterprise and business process fusion. These applications must be: Accessed by different classes of user, each needing a specialized view of the available business functions. Shared across different departments and business units by participating into multistep, cross-functional business processes. Modeled according to criteria of flexibility and reuse to enable greater business agility. Core business applications will have to be implemented as collections of transactional components that are accessible by a variety of modes through service-oriented interfaces or eventbased infrastructures. Requestors for the core transactional components will include multichannel front ends, other business applications, business process managers, process control systems, batch processing systems and other application contexts. We refer to this evolution of the classic OLTP application style as multimodal transaction processing. This indicates the different ways in which it will be possible to engage their core transactional logic terminals, browsers, mobile devices, Web services calls or event notifications. By 2006, at least 40 percent of new OLTP applications will be implemented as collections of transactional business components engaged by multiple deployment scenarios including multichannel, event-based architectures and multistep processes (0.7 probability). Action Recommendation for 2004 Multimodal transaction processing will pose new design challenges and unexplored technology and architecture options. Its impact will be long term and disruptive for enterprises' application and software platform architecture status quo. Users should begin to prepare for the next generation of core business applications based on multimodal architectures. This includes defining processes and plans to break the more strategic and viable set of transaction processing applications into reusable business components. The applications will then be able to support multichannel, composite applications integration, service-oriented and events-based architectures. To prepare for new business demands for more agile software systems, companies should begin to enable the multimodal approach by adopting proper best practices, software platforms and 19 December

3 integration technologies including Web services, if appropriate. Prediction: Multimodal transaction processing will renew interest in transaction processing monitors New multimodal transaction processing applications require a new software infrastructure able to support multichannel access, service orientation and event processing. But it will also have to provide the same enterprise-class quality of services (integrity, scalability, performance, availability, manageability and security) as traditional TPMs. Enterprise application servers (EASs) are incorporating increasingly sophisticated clustering and workload management technology to enhance quality of services for applications. Improvements in hardware and operating systems technology are further boosting scalability and performance. Powerful development and management frameworks are making largescale component-oriented software development increasingly simpler to implement and deploy. Many companies have used EASs based on Java 2 Enterprise Edition (J2EE) to deploy applications supporting thousands of concurrent users and hundreds of transactions per second. Microsoft has improved its software stack and.net has now been tested in several midsize, business-critical applications. Most EAS vendors consider improving quality of services further to be important, but not vital. Few applications need very high quality of service, compared with the many small-to-midsize deployments routinely carried out by large and midsize organizations. TPMs can support tens of thousands of users, thousands of transaction per second and very high availability. Improving EAS products to this level will take talented engineers, and lots of money. But vendors see little short-term business benefit in this investment. The main concern for J2EE vendors and Microsoft is to functionally enrich their products. Vendors want to differentiate them through features and functions and escape the price/performance war. This is why they have been working to turn their products into rich application platform suites since 2001, adding integration capabilities, portal features, integrated development frameworks and other facilities. Leading TPM products like BEA Systems' Tuxedo and IBM's CICS and IMS/TM are incorporating more and more interoperability and integration features, making it easier for users to adopt these products in complex, distributed 19 December

4 architectures. TPMs can now support modern technologies like Java, XML and Web services. But customers want better quality of service and lower total cost of ownership, rather than new, modern features. The technical effort needed to add extensive user-experience features or powerful integration capabilities to a TPM would be astronomical and would risk compromising product reliability. Return on investment for vendors would be questionable. Most TPM vendors already have an EAS or application platform suite (APS) that will support multimodal platforms, so adding these features to their TPM products is unnecessary. Companies should expect richer functionality from J2EE and.net-based platforms; for example, support for mobile devices, voice-based systems, business process management, and service-oriented and event-based architectures. But these products will not match the quality of service offered by TPMs until 2007 or TPMs will become even more dependable, scalable, manageable and available, and will further improve their performance, but will never incorporate all the sophisticated features required by modern computing architectures. Many TPM users developing demanding multimodal transaction processing applications will find it easier and safer to develop them on top of hybrid technical architectures combining an EAS or an APS and a TPM through some communication middleware. This approach will allow companies to combine the architectural flexibility and rich functionality of modern platform middleware as well as the reliability and scalability of traditional TPMs and the associated in-house skills. By 2007, more than 25 percent of new, multimodal transaction processing applications built in-house for 5,000 concurrent users or more will be deployed on a combination of mainframe TPMs and other platform middleware (0.7 probability). Action Recommendation for 2004 TPM users embarking on projects that use a multimodal approach should be confident in using modern platform middleware (EAS and APS) for applications with anticipated workloads up to 250 transactions per second or up to 5,000 concurrent users. But they shouldn't plan to stop using traditional TPMs, because their quality of service will remain unmatched until at least 2007 or They should consider adopting a hybrid technical architecture combining J2EE or.net with TPMs to support more demanding applications. Companies should invest in advanced application integration platforms like 19 December

5 integration suites and enterprise service buses to support these hybrid architectures. Prediction: Companies will have to support increasingly complex mobile middleware systems One of the crucial architectural components of multimodal transaction processing will be support for multichannel architectures, which includes the ability to integrate mobile and wireless device-based channels. Technology and standards are still volatile and customer interest is still sporadic, so vendors' attitudes vary greatly. Many specialized software vendors offer products capable of helping users add support to mobile channels in their applications. These vendors include Aether Systems, Air2Web, Aligo, Bradbeam, Cysive, EveryPath, Extended Systems, Mobileaware, Softwired and Xiam. Mobile and wireless support is not a top priority for traditional middleware vendors. Some of them BEA Systems, Cape Clear, webmethods, TIBCO and Vitria Technology have established loose relationships with specialized mobile-enabling providers. Others, like CommerceQuest, Iona and Software AG, have implemented some experimental products that support specific mobile scenarios. Sybase has a dedicated subsidiary (ianywhere) totally focused on mobile and wireless. The big software infrastructure giants IBM, Microsoft and Oracle have strategic mobile initiatives. Packaged application vendors like IFS, Intentia, PeopleSoft, SAP, SSA Global and Siebel have mobile-enabled some of their applications. SAP provides unbundled, mobile-enabling technology (SAP Mobile Infrastructure) within its NetWeaver APS initiative. Companies will find themselves struggling to understand which vendor's architecture is best for implementing their mobile and wireless channels and will risk unintentionally introducing multiple, incompatible, immature and volatile mobile-enabling products. Given the experimental, opportunity-driven nature of early mobile projects, users will concentrate on functional fit, not on architectural compliance. Different business units or subsidiaries within the same company will adopt whatever mobile-enabling technology their reference vendor or system integrator suggests. The many incompatible technologies will have to be reconciled and integrated sooner or later, and this effort will cost companies dearly. 19 December

6 Through 2007, more than 50 percent of Global 2000 companies will adopt multiple, inconsistent mobile middleware architectures to support different mobile applications (0.8 probability). Action Recommendation for 2004 Proliferation of inconsistent mobile middleware within most companies will be inevitable. Users will be forced to make their software infrastructures more complex to isolate, incorporate and interconnect incompatible mobile-enabling technology. To minimize the complexity and prepare for multimodal transaction processing, users should begin to build appropriate skills, experiment with mobile-enabling and integration software, and plan for its ultimate inclusion in the company's strategic software infrastructure. Acronym Key APS application platform suite EAS enterprise application server J2EE Java 2 Enterprise Edition OLTP online transaction processing TPM transaction processing monitor Bottom Line: Traditional online transaction processing will evolve into multimodal transaction processing to support new business requirements. The software infrastructure will need to provide rich features and quality of service similar to that offered by transaction processing monitors. Implementing this type of infrastructure will be painful for most companies because they will have to integrate established platforms like TPMs or enterprise application servers with immature or volatile technologies like mobile-enabling software and Web services. Users should begin to plan for multimodal transaction processing by understanding service-oriented, event-driven and multichannel architectures. Start implementing an appropriate infrastructure, combining TPMs, modern platform middleware, application integration technology and mobile-enabling software. 19 December