Enterprise Integration Converges

BY ARC ADVISORY GROUP NOVEMBER 2001 Enterprise Integration Converges Executive Overview...3 Integration Today...4 Global Information Architectures...7 Enterprise Integration Approaches...10 The Emerging Enterprise Application Architecture...16 Disruptions Looking Forward...19 Conclusions...22 Enterprise & Automation Strategies for Industry Executives

App A Partners Suppliers Enterprise Integration: 1. Legacy Data-centric 2. Message-centric 3. Application Server-centric 4. Process-centric App B Enterprise Current Enterprise Integration Approaches Open Development Environment Application Server Components Legacy Adapters Components BPM Applications or Processing Engines Business Process Management: Deploy Monitor Update Optimize Components New Enterprise Applications JMS JNDI JDBC RMI-IIOP Typical Services Messaging Security Database CORBA Emerging Enterprise Application Architecture 2 ARCweb.com Copyright ARC Advisory Group

Executive Overview The Enterprise Integration (EI) market has been growing very rapidly in recent years but has slowed to a Cumulative Annual Growth Rate (CAGR) of 20 percent through 2006. It is crowded with suppliers and products and is changing through the usual acquisitions, partnerships, alliances and other arrangements. EI today has evolved from a basket of middleware tools to a few dominant product types and approaches. These are message-centric, data-centric, application server-centric, and business process-centric integration. Global enterprises, wanting to improve partner and supplier relations, are looking to collaborative models to improve interactions and looking to integration methods to automate associated business processes. The business climate is very dynamic, placing requirements on systems to be flexible. In response, Business Process Management software has raised the level of application development thinking, leading to intense interest in high-level tools used by analysts to model and streamline the business. Open now includes integrate. Applications must play in a larger, global context where multiple platforms, multiple sites, and multiple applications routinely exchange information and participate in global business processes. Where before integration software suppliers struggled with portability, the Sun J2EE platform now is being widely adopted as an alternative to maintaining a code base for each operating system. J2EE has spawned a standards based application server market that has delivered on the promise of component technologies. J2EE is bringing the popular integration approaches together into a unified architecture that gives enterprises a common infrastructure for developing, deploying, and managing integration applications. Consequently, this architecture is also being adopted by major enterprise application suppliers (e.g. ERP) in response to the requirement to make their product global. Just as some technical aspects of integration are settling in, new developments are on the horizon. The Microsoft Windows operating system dominates the plant floor applications, lower tier end user organizations, and the desktop. This installed base offers a receptive market for the evolving Microsoft.NET platform. Accordingly, both J2EE and.net will have wide scale deployment. Fortunately, Web services, an Internet based program-toprogram interface, provides a standards-based method for them to interact. Copyright ARC Advisory Group ARCweb.com 3

Integration Today Global manufacturing enterprises are now implementing business models that require application integration beyond that provided by enterprise applications (ERP, SCM, CRM, etc.). Accordingly, more and more enterprises are looking to EI architectures, technologies, tools, and methods to provide a distributed e-business infrastructure separate from the limited solutions provided by enterprise applications today. This is leading some applications suppliers to adopt EI technologies or partner with EI suppliers for more robust solutions. New Manufacturing Business Models With only a few exceptions, integration projects targeted internal applications because the cost of external communications was prohibitive. The Internet changed all that with low cost, readily available global communications that even the smallest businesses could afford. This stimulated a broad range of opportunities, technologies, prod- Business Enterprise Axis ucts, and standards specifically designed to Suppliers SCM Design PLM/D ERP PLM/S BPM CAS Production Support Product Lifecycle Axis CRM Customers Value Chain Axis accommodate new business models. The ARC Collaborative Manufacturing Management (CMM) strategy proposes a new way for enterprises to organize and manage, with a focus on leveraging partnerships and other external relations. CMM focuses on managing key business and manufacturing processes in response to a shift in the overall value proposition. Business processes are automated and optimized globally to build an integrated value chain. CMM and the new models encompass collaborative selling, procuring, supply, product design, customer service, and others. Furthermore, enhanced collaborative processes changed the way enterprises operate, allowing them to leverage resources at any location, in any organization, rapidly, and without travel. But collaborative activities require the integration of several different applications in different locations. To provide global visibility and the exchange of documents, CMM and the integrated value chain require an integration infrastructure that supports the automation and management of business processes (BPM) across a broad range of applications. 4 ARCweb.com Copyright ARC Advisory Group

Several ERP, SCM, and other software suppliers have offered their own integration platforms, but these typically have not been as robust as those from the Enterprise Integration suppliers. Over time, as requirements become larger in scope, these special purpose platforms will be abandoned in lieu of successful platforms from integration suppliers (such as BEA, IBM, Oracle, SeeBeyond, WebMethods, and others). Some large packaged application suppliers, such as SAP, are adding J2EE capability to existing products, enabling them to leverage J2EE compatible products. Open Now Includes Integrate Integration has become an important consideration for all applications. In some situations, the term open has been used to define a user requirement for applications from different suppliers to interact. Now almost all applications must operate in the context of the Web, and simply being open is not enough. Applications now have a new requirement to integrate using standard, cross-platform methods. Applications Design Business Strategic Enterprise Management Visibility BPM Equipment Connectivity Equipment Production Support Customers Enterprise Information The Convergence of Integration Products Integration is not a single problem, but is a broad range of changing problems. Various technologies, including data movement, messaging, and transaction management were developed early on, leading to an extremely diverse set of EI products, commonly referred to as middleware, with most products aimed at internal integration. The Internet provided low cost communication media that spawned a flurry of new businesses, which required increased external integration over public media. This introduced new security risks and concerns, as well as adding new functionality. The effect was that both B2B and EAI suppliers extended their product lines to move into this exploding market, causing the internal and external integration markets to converge. During product evolution, they have converged in another way. As the requirements became clearer and new technologies developed, suppliers positioned products for basic messaging solutions, application server solutions, and business process solutions. Of course, data integration and legacy system integration are still required. As features required for each approach Copyright ARC Advisory Group ARCweb.com 5

were added, product lines segmented into general message-centric, application server-centric,and process-centric categories. These categories are very useful to understanding the differences in product feature sets. User Integration Practices Where integration might have previously been an after-thought, it is now important to think about an integration strategy separate from applications and projects. Such an approach will build a foundation that cuts the time and cost of each project, thereby reducing the overall enterprise cost. A separate integration strategy allows IT organizations to build a core competency and consistent approach around an appropriate architecture. Defining a strategy can, of course, be a large task and even then is only a guideline. A few critical tasks that must be defined within the context of an integration architecture are: Consider general integration needs and tune them for the current and anticipated requirements. Several integration features and their function are listed in the table on the next page for prioritization. Use multiple views to define high-level information architecture for the enterprise. Select an integration approach based on requirements, architecture, available products, and capabilities of the organization. Select a primary integration software supplier based on the above and other business requirements such as service, support, training, location, etc. Manage exceptions well, paying close attention to the effect on maintenance. Defining a strategy can be very complex with a large number of considerations. The table below and subsequent sections provide some of the common strategic considerations including requirements, architecture, and integration approach. 6 ARCweb.com Copyright ARC Advisory Group

Attribute Requirement Priority Hardware Platform Scalability and Reliability Enterprises are heterogeneous ;portability is critical for the long term. Ultimate load is often unknown. Clustering, mid-range, and mainframe class systems, load balancing. High High Extensibility Coding is typically required. Medium Security Critical for B2B integration, less so for internal projects. High Standards Provides open, multiple suppliers, and connections. High National Language Support Business Processes and Rules Global, multi-national organizations require local language support. Automatic translation is helpful. Some situations require graphical modeling and application tools for business analysts. High High Adapters For legacy information, and protocols. High Components and Frameworks Components increases re-use and cuts development time. Medium Messaging Monitoring Trace Dynamic Changes Remote Deployment The message layer provides secure, reliable delivery of messages and can include mapping, transformation, brokering, logging, and other functions. Systems should provide tools for monitoring application execution, identifying problems and resolving them. Application messages, transactions and other operations should be logged for verification, and problem solving. Application parts should be updatable without shutting down the entire application. Integration applications are distributed across multiple servers and should be manageable from a central system. Medium Medium Medium Medium Medium Solution Templates Most enterprises have repeatable patterns that can be built into templates for re-use and maintenance. Enterprise Integration Software Attributes Low Global Information Architectures A global information architecture should be an abstract re-useable model that is supplier and system independent. It provides a framework for decisions about best practices, organization, technologies, platforms, and software suppliers. In most situations, these decisions are made over time and are periodically revisited. The architecture must provide basic consistency in direction and a framework for impact analysis. Architecture definition does not have to be rigorous, but it must be accurate and kept up to date. Copyright ARC Advisory Group ARCweb.com 7

A global information architecture provides a picture of how information and applications will be distributed over multiple sites or multiple facilities at one site. At the highest level the architecture must show: Suppliers The location of enterprise applications, Partners stores of information and tools (ERP, SCM, portal, exchange, RDB, etc.). Some applications are distributed, and some information is replicated. Integrated Enterprise Connections for information and event flow between sites. Customers Service Providers Location of integration software with application access points and methods. Accesses can be local or remote. This will change as integration products are selected and replaced. Integrated Value Chain General security strategy. This is detailed at lower levels. Relationship between integration software and other parts (applications, information, portals, exchanges, etc.). This may consider whether information is accessed in place or replicated. Multiple views may be used to map out site, integration, user access, organizational and other plans. Information architecture is a complex topic, but a few basic patterns are worth discussing. Integrating Around a Central Application When one application, such as ERP, dominates business activity, enterprises naturally focus integration on that application. This is especially attractive when the application creates all the integration needs and the application supplier offers appropriate integration. The solution works best for simpler, central systems, but becomes unwieldy and restrictive for large, multi-site enterprises, and virtually unusable for integrating with partners. The central application architecture is ineffective when integration involves two other applications and not the central application. It is also limited in capability compared to offerings from an integration software supplier. Except for the largest application suppliers, most enterprise application suppliers will partner with integration software suppliers, displacing their own integration software, to offer their customers more complete solutions. 8 ARCweb.com Copyright ARC Advisory Group

SAP, being one of the largest enterprise application suppliers, has previously included some integration technology with its products. SAP has recently revised its strategy to add J2EE support to its servers, allowing J2EE applications to run in their environment with or without close coupling to their application modules. This also paves the way for SAP to use the J2EE integration platform as their application platform. Point-to-Point Point-to-point integrations are attractive as fast solutions to a specific problem. The return may be good in the short term, but scalability, flexibility, and maintenance are problematic. The basic failure stems from the limited scope at the start of the project and the poor scalability of custom code. Point solutions are not always bad, such as when the scope is known to be limited, or when the system is to be replaced anyway. Some middleware may be used in the solution to easily enhance the scalability. Hub and Spoke A hub-and-spoke architecture has considerable acceptance, and some integration software is designed specifically for it. Messages, events, and information always go to a central system for processing, logging, and distribution to other sites (spokes). The remote systems have minimal integration software and do not interact directly with each other. A hub architecture is especially attractive when the spoke organizations have a large variety of protocols and each spoke needs to communicate with several other spokes. Each spoke has one interface to the hub instead of one to each spoke, simplifying the protocol, connection, and security management at each spoke. Centralizing everything simplifies design, implementation of applications, and management for medium to small enterprises. But it does not scale well as the enterprise grows, and creates concerns for reliability and security. Not all exchanges between distributed enterprises need to go through a central system, and some suppliers of hub designed systems mitigate the scaling problem to some extent by supporting spoke to spoke connections. Basic messaging systems start as hubs for collection and processing of all messages, but can be expanded to multiple message servers to implement other architectures. Most hub designs need to transform messages into a common format for transformation and other processing before being routed to destination sites. Messaging systems provide these functions but process- Copyright ARC Advisory Group ARCweb.com 9

centric BPM integration tools may be necessary for complex processing. BPM applications are most easily understood from a hub and spoke view. Processes are designed and deployed in one place, orchestrating exchanges between spokes, the central facility, and other spokes. Distributed A distributed architecture (peer-to-peer) is flexible, scales well, and can map more closely to the needs of each enterprise. Distributed concepts are necessary for any approach involving global enterprises with multiple information hubs, as would result from the merger of two enterprises, resulting in several autonomous divisions. This architecture is necessary when centralization is undesirable and several large applications are spread over several locations. Integration software is located in multiple sites for local flexibility, processing, information access, security, monitoring, and problem resolution. Local integration of an application does not require interaction with a central site. Of course, a distributed system can be implemented in a single site, and this is a good way to start implementation. One of the disadvantages of peer-topeer communications is the necessity for each location to manage security, protocol, and profile information for all necessary peer connections. Much of the Enterprise integration software supports a distributed architecture, but differentiation lies in deployment, monitoring, and management functionality, which is different for a distributed system. It is interesting to note that the Web service technology encourages a distributed architecture. Enterprise Integration Approaches It is important to remember that not all integration needs are the same. Integration priorities differ relative to size, distribution, information type business model, skills available, frequency of change anticipated, security required, and many other issues as shown in the table presented earlier. However, the most common priorities have shaped a few basic approaches. Most EI products have been positioned and have evolved to focus on one of these approaches, leading to a convergence of products, features, technologies, and architectures to handle today s general integration needs. There are, of course, special purpose products that are very effective for more limited needs. 10 ARCweb.com Copyright ARC Advisory Group

It is always tempting to compare technologies (messaging, J2EE, BMP, etc.), but some technologies are used in two or more approaches. For example, message queues and transformation engines are used in several categories. Adapters Adapter modules implement the critical function of connecting integration software with a large variety of enterprise applications and protocols. They are important for all types of integration. Their function is to understand an external interface and transform content into a format understandable by the integration software. The reverse process is also required. Adapters range in functionality from very simple to very intelligent parts that contain significant application logic. Simple ones may not provide sufficient data, state, or process information, but placing too much logic in the adapter may yield an inflexible, difficult to maintain application. Integration products need many adapters, and adapter architectures are proprietary. This means that each supplier must develop adapters to the same products (ERP for example). New technologies, such as Java Connection Architecture (JCA), and Java Messaging Service (JMS) are intended to reduce the need for repeated adapter development by all suppliers. XML interfaces and Web services tend to eliminate the need for adapters completely. Legacy Systems Over the years a large number of back-end applications have been implemented, and now these must be integrated with new applications. A segment of EI software was designed specifically for this requirement with most of the larger suppliers offering host integration servers or some method that does not require modification to the legacy application. Many of these applications are on mainframe (OS/390 for example) and midrange systems, requiring suppliers to specialize in legacy integration. Messaging, CORBA, and Web technologies have been used in addition to native host integration software. Data-Centric Approach Two basic requirements drove data-centric integration. When the same information existed in two or more applications (or databases), there was a Copyright ARC Advisory Group ARCweb.com 11

need to keep them synchronized. The second requirement was to make application information visible, such as in a Web portal. Data-centric integration products were among the first integration products (before they were called EAI), and are still effective solutions for many requirements where integration processes are not needed. Their effectiveness depends on the complexity of applications, breadth Integration Approach Recent Application TCO Adoption Maturity of adapter interfaces, easeof-use, and robustness. Legacy Integration Visibility $$ **** **** Data-Centric Synchronization $ ** **** Some products provide Message-centric Reliable Transactions $$$ *** **** very sophisticated parsing Application Server Component Platform $$$ *** ** and packaging methods and are configured with Process-centric Dynamic Business $$ ** ** mapping tools requiring no custom coding. Data-centric products are commonly used with mainframe applications and databases where the priority is fast deployment and minimizing the effect on existing applications. This software typically moved, transformed, and synchronized data from one place to another, usually without an intermediate store and without adding new processes; logic is attached to events and processes within the existing applications (or database manager) to trigger the data movement. To make information more accessible or visible, some methods of datacentric integration aggregate information into a common data store or provide a federated view of data stored in a variety of systems. Data aggregation pulls information of interest from a variety of sources into a common data store that is accessed by all applications. Information is updated periodically or on some event. Some integration software provides access to information in various applications and systems through a single interface as with data aggregation. But the information is accessed by the integration software when needed and not stored. Message-Centric Approach Messaging software and transaction engines have been the foundation for enterprise integration for some time, and are still an essential function of most EI supplier offerings, in some form or another. Their functions are well known for connecting applications, and recently the J2EE platform standard- 12 ARCweb.com Copyright ARC Advisory Group

ized the interface with the Java Messaging Service (JMS). This has spawned a new generation of Java-implemented messaging products and has encouraged suppliers to add the JMS interface to existing messaging products. The most fundamental messaging function is to make disparate networks look the same to applications, with message queues to avoid loosing messages when applications are not available. Secure, reliable, once-only deliv- App A Partners Suppliers Capabilities Evolved: Multi-platform Network API Queues always there Broker Transform Content based routing Combine and partition documents App B Enterprise ery is critical, as is multi-platform support. Adapters 1. Message-centric Adapters Messaging product lines are suitable for central architectures where the central facility transforms and brokers messages for several customers or suppliers. Messaging products can also be used to implement a distributed bus architecture with the bus providing a consistent interface in a heterogeneous network, as well as delivering all messages securely and reliably. Various types of connection management are required, including point-topoint and publish-subscribe connections. Most suppliers add various types of brokering, transformations, and transaction processing. Transaction features are included to guarantee that transactions are executed safely including proper updates of multiple databases. Most messaging suppliers started with solutions for integration inside the enterprise. In response to rising demands for B2B connectivity, these suppliers are adding capabilities, such as increased security and EDI support, which are necessary for external integration. Early messaging products were intended for software developers, but higher-level tools were added to increase productivity and enable non-developers to help build and maintain the messaging applications. Application Server Approach An application server is a run-time program that provides a standard environment for loading and running multiple integration applications, which have been developed as components. Application servers contain components and provide common services needed by the components such as messaging, connection management, security, persistence, and other functions. Thus the selection of an application server supplier is important because it defines many important attributes of the integration application. Copyright ARC Advisory Group ARCweb.com 13

In addition to those mentioned above, application servers also provide services such as failure detection and recovery, load balancing, caching, mobile device support, and distribution - transparent to the components. Because application servers contain the component applications, they can provide portability through a common, consistent environment across heterogeneous platforms. This is critical for increasing code re-use and minimizing integration development and maintenance efforts. Recently, application servers have been enhanced to easily expose component functions as Web services, making it easy for existing applications to create Web services. App A Partners Suppliers Application servers do not always require users to write code. Graphical and mapping tools can generate Java code that can be compiled and run on application servers. Alternatively, tools can generate configuration data to be Integration Applications: As components EJB Using Standard Interfaces processed by an engine deployed as a component. This strategy is being used by some BPM tools suppliers, 2. Application Server-centric App B to leverage standard application server environments. Supplier J2EE Application Server: Standard Interfaces Deployment Monitoring Failure management Scaling, distribution Enterprise Application servers are not new, but recently, J2EE- (Sun Java 2 Enterprise Edition) compliant application servers have become the clear winner with integration software suppliers. Companies such as BEA (WebLogic), IBM (WebSphere), Oracle (9iAS) and Sun (iplanet) compete heavily and are most visible, but there are many other suppliers of standard servers. Servers differ in robustness, systems management features, failure management, performance, and other features, and careful evaluation is necessary when selecting products. From a limited viewpoint, J2EE abstracts operating system interfaces, providing portability from PC to mainframe, but J2EE goes far beyond that by defining an enterprise component framework (Enterprise JavaBeans, EJB) and interfaces for many common application level services (messaging, connections, etc.). By defining just the interface, J2EE encourages competition between service providers, giving end users multiple sources. J2EE applications typically leverage Web servers that support Java Server Pages (JSP) and servlets to implement the presentation requirements. 14 ARCweb.com Copyright ARC Advisory Group

Applications developed for J2EE should run on any standard server, on any operating system, and this has made J2EE a target for many integration software suppliers that have been laboring to support different implementations on multiple platforms. They have clearly demonstrated the benefits of J2EE component-based development, and this has attracted the attention of enterprise packaged application software suppliers, also laboring with the same issues. The recent SAP adoption of the J2EE platform is one of the most visible examples. Process-Centric Approach The dynamic nature of current business environments has changed the requirements for integration software in two major ways, and process-centric integration is the result. First, process-centric integration Key BPM Function recognizes that the integration programs are applications Features themselves. Integration applications actually implement Modeling business logic, in addition to moving data and brokering messages. Second, business logic is dynamic and is defined by business analysts. This shift is leading to a flood Automation of Business Process Management (BPM) products with graphical programming tools that target analysts. Workflow Several software types, including packaged applications, have a business process focus. By comparison, the BPM Monitoring tools from the integration software suppliers tend to be more general, with less industry-specific content. This leaves end users with an option to use their integration Management software to build industry-specific parts or to get an industry-specific package from a supplier with considerable industry domain knowledge. Using integration software allows a consistent tool set to be used across a broad range of applications, while using a vertical solution may result in a better solution in less time, providing no customization is required. The best situation is achieved when the supplier with domain knowledge implements with the same tools as the integration supplier. Dynamic business environments mean that BPM products must have tools for monitoring processes that are running and quickly detecting when things go wrong. This, of course, is valuable for validating implementations, changes, and optimizing processes as they operate. On-line changes to processes are essential to keep other processes running when deploying changes. Use graphical tools and objects to describe and analyze business processes. Execute business models to link applications for rapid consistent response. Execute business models to integrate human decisions and operations in processes Tools for analysts to monitor executing processes, resolve exceptions and optimize Deploy and update models and processes in real time, tune load balancing, manage profiles, security and other configurations. Copyright ARC Advisory Group ARCweb.com 15

App A Partners Suppliers During process modeling and development, a standard graphical modeling scheme such as UML (Unified Modeling Language) is provided by many suppliers. Others use more application specific tools. The execution environment for BPM packages includes adapters for access to legacy systems, packaged applications and databases, and various other Business Processes: Graphical (draw it) Becomes part of the Enterprise App integration technologies such as Build vertical Apps messaging and transaction support. Runtime architectures Complete integration environment Several implementation strategies App B used by suppliers range from a Enterprise complete integration server that does everything, to code generators that build application parts 3. Process-centric (e.g. EJB) and run them on more traditional integration software. Two classes of products are common. One uses an integrated run-time engine that executes (interprets) processes directly. The integrated engine typically provides all messaging, queuing, transformation, internal storage, tracing, and on-line operation functions. It also must have some sort of adapter architecture in addition to XML exchange support to interact with other applications. The second class of products leverages existing integration technologies and products (messaging, application servers, etc.). They may have an execution engine or may be code generators, automatically creating Java components that run on existing engines. These products, which may be added to existing applications, build on the confidence that has developed through experience in difficult applications. Emerging Enterprise Application Architecture There has been considerable experimentation with business models since the Internet became pervasive. While several models have collapsed, some have proven effective and are being adopted by an increasing number of enterprises. The integration requirements for software that supports successful models are becoming better known, and the integration product winners are 16 ARCweb.com Copyright ARC Advisory Group

starting to take shape. Perhaps more importantly, product architectures seem to be converging on a few types with normal variations. For the short term, the emerging product structure is based on BPM as the primary user view of the integration applications built upon a J2EE infrastructure. Many enterprise integration suppliers are moving in this direction. Beyond the integration suppliers, packaged enterprise software suppliers are also committing to a J2EE platform or are giving it serious consideration for new products. In some situations, partnerships between integration suppliers and packaged application suppliers will lead to vertical applications built specifically for the development and runtime of the infrastructure. This will have far reaching benefits. Infrastructure The role of software infrastructure is to provide a consistent environment across platforms for building and deploying all enterprise applications. It must provide enterprise wide services with standard interfaces for both internal and external integration. The infrastructure provides distribution, scaling, load balancing, and general application management capabilities, such as loading, starting, stopping, as well as monitoring all aspects of the environment and applications. Monitoring tools are generic and not application specific. For a J2EE infrastructure, a Java Virtual Machine and Developer Kit (JDK) are required, and these are available for almost all operating systems. To complete the infrastructure, end users must select an application server, an appropriate Web server and other parts, such as messaging software, and adapters, depending on the application. These are available from multiple suppliers and can be selected to suit the nature of the enterprise. Application Server Typical Services Open Development Environment Components Legacy Adapters Components BPM Applications or Processing Engines Business Process Management: Deploy Monitor Update Optimize Components New Enterprise Applications JMS JNDI JDBC RMI-IIOP Messaging Security Database CORBA Application Deployment and Management Runtime integration applications are deployed as EJB components (entity beans, session beans, and message beans). When graphical BPM or mapping tools are used, there are two possible designs: generate Java components Copyright ARC Advisory Group ARCweb.com 17

(EJB) that are loaded in an application server (container) or generate configurations that are run by an engine developed as a component. The application may provide monitoring, validation, and problem resolution tools beyond that provided with the infrastructure. Some enterprise applications (ERP, SCM) are currently converting their runtime engines to EJB components so that they will run in a J2EE environment. Others generate EJB, JSP, Servlets and other components that are automatically built into deployable modules. NetBeans (Sun) Sun (iplanet) BEA COMPAQ Application Development Environments There is now a large Java developer community and several modern Java integrated development environments, supported on multiple platforms (primarily Windows, UNIX, and Linux). Many application development tools are implemented in Java, Eclipse (IBM) IBM demonstrating its feasibility (performance was a concern) and giving suppliers a broader market and the CommerQuest Computer Associates security of portability. Compuware i2 DataMirror Peregrine Information Architects Skyva IONA Versada A Sampling of Supporting Suppliers Considerable time and effort has been expended on integration platforms, technologies, and architectures, but as J2EE standards are adopted, we can see the benefits of standardization. Supplier competition is moving on to other issues important to users, and one of those is ease (and cost) of development, validation, and maintenance. Traditionally, J2EE applications have been developed in Java Integrated Development Environments (IDE). With development moving to graphical BPM tools, most suppliers offer an environment to house tools to build, test, and deploy applications. But when product lines are extended, especially through acquisition or partnership, users can end up with multiple dissimilar environments, making development difficult. Both IBM and Sun (iplanet) offer end-to-end integration and heavy partnership strategies, which has led them to offer competing, open Java-based environments, Eclipse and NetBeans, respectively. The unique aspect of their approaches is that they offer the environment under an Open Source license agreement, making it available to all suppliers at no cost. In essence this is creating standard development and deployment environments similar to the standard J2EE runtime environment. This will not only be good for large Sun and IBM users, but also will be very good for smaller suppliers and their customers, thus 18 ARCweb.com Copyright ARC Advisory Group

it has considerable promise. However there are two camps with different followers as shown in the table above. Moving to J2EE Over the last decade, a lot of integration products that have been written to operating system native interfaces, creating high maintenance costs with versions on several platforms. Some suppliers supported as many as 30 different configurations. It should come as no surprise that the portability offered by Java is very attractive, resulting in most integration software suppliers adopting J2EE as their strategic platform. However, native code cannot be abandoned abruptly, and a gradual evolution to J2EE is necessary. Because J2EE is largely interfaces, this is feasible. How do Suppliers move native code to J2EE? Add Java interfaces to existing native code Replace native parts over time, eventually resulting in pure J2EE products Develop new product in Java for J2EE Disruptions Looking Forward Within the Enterprise Integration market, technologies are changing rapidly on several fronts. Often it is not clear which technologies will be broadly adopted and subsequently receive the greatest long-term support. This creates high risk for users with many taking a wait-and-see attitude. Two areas that are in this state now are Microsoft.NET and Web services. Both are still evolving and their effectiveness for enterprise applications is uncertain. Most Web services development work has been at the supplier level, and end users are just starting to both experiment and define strategies that include Web services. In the short term, J2EE will provide the enterprise platform of choice, but Microsoft is working hard to establish a presence with the.net platform. Most manufacturing plant J2EE Platform.NET Platform floor operations are Windows- based, and this will be a strong pull for.net adoption. Enterprise software suppliers (above the manufacturing execution level) are deeply entrenched in J2EE strategies, where portability, high reuse, and extreme scalability are requirements, and they will continue on a J2EE path for Web services, even for Windows platforms. Production Business Portability Scalability Common Low Cost Platform Copyright ARC Advisory Group ARCweb.com 19

.NET The.NET platform consists of a Web services strategy with several Microsoft servers..net servers, anchored by the popular SQL Server and Internet Information Server (IIS), have been developed and released in sequence, but without native Web service support. Visual Studio.NET, the enabling Microsoft tool for developing Web services has been under beta testing for over a year, and will not be released in 2001. None of this precludes the development of Windows native Web services, but Visual Studio is a gating item for the general adoption of Web services. Significantly, Microsoft BizTalk, a BPM product, was released in early 2001 as one of the.net servers. Biztalk runs only on Windows and competes directly with other BPM integration servers from enterprise integration software suppliers. EI software suppliers are not adopting.net as a platform for developing integration products, except for adapters. Web Services and Enterprise Integration In a sense, Web services are solutions looking for problems in an unknown future business environment. The term Web services was created to refer to specific technologies and methods for sharing a generally available interface between two programs over the Web. But projections about future Internetdriven businesses lead to a generalized use of the term to mean the services offered to business and people. This is appropriate because it appears that the evolution of Web services and the formation of new fully integrated value chains are tightly coupled. Integrated value chains are composed of multiple businesses depending heavily on each other to serve customers. Integrated value chains are created for business reasons and are built by integrating partner business processes using EI technologies with a collaborative service model. Accordingly, the evolution of Web services may be a yardstick for mapping the evolution of new business models. Web services will develop through several overlapping phases that may help users decide when and how to participate. The first phase involves the development of tools, technologies, and standards for the creating of Web service platforms. The technologies are largely known, and software suppliers are enhancing tools to support the creation of Web services. The J2EE and.net platforms are central, and related work will be sufficiently complete after mid 2002. Technology standards are in good shape, but the establishment of vertical industry standards will continue for some time, and is a gating item. 20 ARCweb.com Copyright ARC Advisory Group

User products are needed to consume Web services in a flexible, ad hoc way. Currently, portal software is adopting Web services rapidly, and other similar areas will quickly follow suit; this is a good place for early adopters to start. The integrated value chain will be managed around business processes, and analyst-oriented BPM tools will leverage Web services heavily. Public Web service registries are essential for flexibility, but private registries will be deployed through most of 2002 as the performance, security, and service maintenance issues are sorted out. The use of Web services by portal and BPM tools will accelerate in early 2002 and will be commonly available by end of year. Many Web services will leverage existing applications and information stores. Some packaged enterprise application suppliers are already enhancing their products to support the creation of Web services within the application, sometimes relying on EI technologies and products. The EI technologies and products are available to begin this now, including enhanced J2EE application servers and BMP integration engines. EI technologies and products are central to realizing an integrated value chain, and these are progressing. But achieving an integrated value chain will take considerable time because some general experimentation is necessary for developing workable Internet-based business relationships and the inevitable time to achieve cultural changes. Integration Infrastructure on the Plant Floor? While we have traditionally viewed manufacturing enterprises as stacked operations, and debated integration of business and plant floor functions, the integrated value chain makes this model inadequate. Vertical integration still makes sense when all the manufacturing functions are in one location, but value chain integration at any level also makes sense. A few areas are irresistible: Manufacturing process management procedures, plans, orders, reports, recipes, records requires the same technology for enterprise and production and often involves a broad range of organizations. Visibility for supply chain management requires information from all levels of an operation to be assembled into one view and kept current. This means enterprise portals must reach down into a SCADA, HMI, LIMS, or other software to get an inventory level, quality data or other information. Copyright ARC Advisory Group ARCweb.com 21

Remote access, troubleshooting, alarm and alert response, schedule changes using portal technology. Using EI technologies and products to leverage the accumulated large stores of underutilized information in plant wide databases. Web services and XML technology in general are the common technologies that will draw enterprise and production applications together, even though the adoption of platforms may diverge. Conclusions Enterprise integration has become a critical consideration in almost all manufacturing enterprise applications. This is forcing end user organizations to think about a general integration strategy, including architecture, methods, tools, and technologies. Many aspects of these are changing and evolving rapidly. Integration software suppliers are reacting to market trends in the direction of J2EE, Business Process Management, and Web services. The popular integration platform will be a combination of these and existing integration technologies. Packaged enterprise software suppliers recognize that integration beyond a published API is a requirement for application software and are reacting by either partnering, targeting standard integration platforms, or developing their own robust integration platforms. Future enterprise applications will be developed as components and delivered in standards-based environments supporting portability and scalability. 22 ARCweb.com Copyright ARC Advisory Group

Analyst: Robert Mick Editors: John Moore, Ed Bassett Distribution: All EAS and MAS Clients Acronym Reference: For a complete list of industry acronyms, refer to our web page at www.arcweb.com/arcweb/community/terms/indterms.htm AI Artificial Intelligence ANSI American National Standards Institute API Application Program Interface APS Advanced Planning & Scheduling B2B Business-to-Business B2C Business-to-Consumer BPM Business Process Management BPR Business Process Reengineering CAGR Cumulative Annual Growth Rate CAS Collaborative Automation System CMM Collaborative Manufacturing Management CNC Computer Numeric Control CORBA Common Object Request Broker Architecture CPG Consumer Packaged Goods CRM Customer Relationship Management EAI Enterprise Application Integration EAM Enterprise Asset Management EDI Electronic Data Interchange EI Enterprise Integration EPM Enterprise Production Management ERP Enterprise Resource Planning HMI Human Machine Interface IIS Internet Information Server JMS Java Messaging Service LAN Local Area Network MRP Materials Resource Planning OLE Object Linking & Embedding OPC OLE for Process Control PAS Process Automation System PLM/D Product Lifecycle Management/ Design PLM/S Product Lifecycle Management/ Support ROI Return on Investment SCM Supply Chain Management SPC Statistical Process Control TMS Transportation Management System UML Unified Modeling Language WMS Warehouse Management System XML extensible Markup Language Founded in 1986, ARC Advisory Group is the leader in providing strategic planning and technology assessment services to leading manufacturing companies, utilities, and global logistics providers, as well as to software and solution suppliers worldwide. From Global 1000 companies to small start-up firms, ARC provides the strategic knowledge needed to succeed in today s technology driven economy. ARC Strategies is published monthly by ARC. All information in this report is proprietary to and copyrighted by ARC. No part of it may be reproduced without prior permission from ARC. You can take advantage of ARC's extensive ongoing research plus experience of our staff members through our Advisory Services. ARC s Advisory Services are specifically designed for executives responsible for developing strategies and directions for their organizations. For subscription information, please call, fax, or write to: ARC Advisory Group, Three Allied Drive, Dedham, MA 02026 USA Tel: 781-471-1000, Fax: 781-471-1100, Email: info@arcweb.com Visit our web page at ARCweb.com Copyright ARC Advisory Group ARCweb.com 23

Cambridge, U.K. Düsseldorf, Germany Munich, Germany Hamburg, Germany Tokyo, Japan Bangalore, India Boston, MA Pittsburgh, PA San Francisco, CA Visit ARCweb.com for complete contact information Three Allied Drive Dedham, MA 02026 USA 781-471-1000 Fax 781-471-1100