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
App A
Partners
Suppliers
App B
Enterprise
Enterprise Integration:
1. Legacy Data-centric 2. Message-centric 3. Application Server-centric 4. Process-centricCurrent Enterprise Integration Approaches
BPM Applications
or Processing Engines
New
Enterprise
Applications
Legacy
Adapters
Components Application Server Components Components Open Development EnvironmentMessaging
Security
Database
CORBA
Typical Services Business Process Management: Deploy Monitor Update Optimize JMS JNDI JDBC RMI-IIOP
Executive Overview
The Enterprise Integration (EI) market has been growing very rapidly in re-cent 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 integra-tion.
Global enterprises, wanting to improve partner and sup-plier relations, are looking to collaborative models to improve interactions and looking to integration methods to automate associated business processes. The business cli-mate 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.
Where before integration software suppliers struggled with portability, the Sun J2EE platform now is being widely adopted as an alternative to main-taining a code base for each operating system. J2EE has spawned a standards based application server market that has delivered on the promise of compo-nent technologies. J2EE is bringing the popular integration approaches together into a unified architecture that gives enterprises a common infra-structure for developing, deploying, and managing integration applications. Consequently, this architecture is also being adopted by major enterprise ap-plication 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 develop-ments 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-to-program interface, provides a standards-based method for them to interact.
“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.
Integration Today
Global manufacturing enterprises are now implementing business models that require application integration beyond that provided by enterprise ap-plications (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 pro-vided by enterprise applications today. This is leading some applications suppliers to adopt EI technologies or partner with EI suppliers for more ro-bust solutions.
New Manufacturing Business Models
With only a few exceptions, integration projects targeted internal applica-tions because the cost of external communicaapplica-tions was prohibitive. The Internet changed all that with low cost, readily available global communica-tions that even the smallest businesses could afford. This stimulated a broad
range of opportunities, technologies, prod-ucts, and standards specifically designed to accommodate new business models. The ARC Collaborative Manufacturing Man-agement (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, sup-ply, 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 with-out 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.
Suppliers Desi gn Supp ort Business Customers Production CAS PLM/D CRM SCM BPM PLM/S ERP Product Lifecycle Product Lifecycle Product Lifecycle Product Lifecycle Axis AxisAxis Axis Value Chain Value Chain Value Chain Value Chain
Axis AxisAxis Axis Enterprise Axis Enterprise AxisEnterprise Axis Enterprise Axis Desi gn Supp ort Business Customers Production CAS PLM/D CRM SCM BPM PLM/S ERP Product Lifecycle Product Lifecycle Product Lifecycle Product Lifecycle Axis AxisAxis Axis Value Chain Value Chain Value Chain Value Chain
Axis AxisAxis Axis Enterprise Axis Enterprise AxisEnterprise Axis Enterprise Axis
Several ERP, SCM, and other software suppliers have offered their own inte-gration platforms, but these typically have not been as robust as those from the Enterprise Integration suppliers. Over time, as requirements become lar-ger 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, ena-bling them to leverage J2EE compatible products.
“Open” Now Includes “Integrate”
Integration has become an important considera-tion for all applicaconsidera-tions. In some situaconsidera-tions, the term “open” has been used to define a user re-quirement for applications from different suppliers to interact. Now almost all applica-tions must operate in the context of the Web, and simply being “open” is not enough. Appli-cations now have a new requirement – to “integrate” using standard, cross-platform methods.
The Convergence of Integration Products
Integration is not a single problem, but is a broad range of changing prob-lems. 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 re-quirements became clearer and new technologies developed, suppliers positioned products for basic messaging solutions, application server solu-tions, and business process solutions. Of course, data integration and legacy system integration are still required. As features required for each approach
Desi gn Supp ort Business Customers Production Enterprise Enterprise Enterprise Enterprise Information InformationInformation Information Applications Applications Applications Applications BPM Equipment Strategic Enterprise Management Visibility Equipment Connectivity Desi gn Supp ort Business Customers Production Enterprise Enterprise Enterprise Enterprise Information InformationInformation Information Applications Applications Applications Applications BPM Equipment Strategic Enterprise Management Visibility Equipment Connectivity
were added, product lines segmented into general message-centric, applica-tion 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 sepa-rate integration stsepa-rategy 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 mainte-nance.
Defining a strategy can be very complex with a large number of consid-erations. The table below and subsequent sections provide some of the common strategic considerations including requirements, architecture, and integration approach.
Enterprise Integration Software Attributes
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 pe-riodically 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.
Attribute RequirementRequirement RequirementRequirement PriorityPriorityPriorityPriority
Hardware Platform Enterprises are heterogeneous ;portability is critical for the long term.
High Scalability and Reliability Ultimate load is often unknown. Clustering, mid-range, and
mainframe class systems, load balancing. 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 Global, multi-national organizations require local language
support. Automatic translation is helpful.
High Business Processes and Rules Some situations require graphical modeling and application
tools for business analysts. High Adapters For legacy information, and protocols. High Components and Frameworks Components increases re-use and cuts development time. Medium Messaging The message layer provides secure, reliable delivery of
mes-sages and can include mapping, transformation, brokering, logging, and other functions.
Medium
Monitoring Systems should provide tools for monitoring application
exe-cution, identifying problems and resolving them. Medium Trace Application messages, transactions and other operations
should be logged for verification, and problem solving. Medium Dynamic Changes Application parts should be updatable without shutting down
the entire application.
Medium Remote Deployment Integration applications are distributed across multiple
serv-ers and should be manageable from a central system. Medium Solution Templates Most enterprises have repeatable patterns that can be built
into templates for re-use and maintenance.
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:
• The location of enterprise applications, stores of information and tools (ERP, SCM, portal, exchange, RDB, etc.). Some applications are distributed, and some information is replicated.
• Connections for information and event flow between sites.
• Location of integration software with application access points and meth-ods. Accesses can be local or remote. This will change as integration
prod-ucts are selected and replaced.
• General security strategy. This is de-tailed at lower levels.
• Relationship between integration software and other parts (applications, information, portals, exchanges, etc.). This may consider whether infor-mation is accessed in place or replicated.
Multiple views may be used to map out site, integration, user access, organ-izational 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. Ex-cept 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.
Integrated Enterprise Suppliers Partners Customers Service Providers
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 applica-tions 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 inte-gration platform as their application platform.
Point-to-Point
Point-to-point integrations are attractive as fast solutions to a specific prob-lem. 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 inte-gration software is designed specifically for it. Messages, events, and information always go to a central system for processing, logging, and distri-bution 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, simpli-fying 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-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 neces-sary 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, process-ing, information access, security, monitorprocess-ing, 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-to-peer 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 architec-ture, 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. Inte-gration 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, technolo-gies, and architectures to handle today’s general integration needs. There are, of course, special purpose products that are very effective for more lim-ited needs.
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 suffi-cient 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 pro-prietary. This means that each supplier must develop adapters to the same products (ERP for example). New technologies, such as Java Connection Ar-chitecture (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 imple-mented, 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 mid-range systems, requiring suppliers to specialize in legacy integration. Mes-saging, 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 in-formation existed in two or more applications (or databases), there was a
need to keep them synchronized. The second requirement was to make ap-plication 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 re-quirements where integration processes are not needed. Their effectiveness
depends on the complex-ity of applications, breadth of adapter interfaces, ease-of-use, and robustness. Some products provide very sophisticated parsing and packaging methods and are configured with 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 syn-chronized 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 data-centric integration aggregate information into a common data store or pro-vide 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 up-dated 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-Integration Approach Recent Application TCO Adoption Maturity
Legacy Integration Visibility $$ **** **** Data-Centric Synchronization $ ** **** Message-centric Reliable Transactions $$$ *** **** Application Server Component Platform $$$ *** **
ized the interface with the Java Messaging Service (JMS). This has spawned a new generation of Java-implemented messaging products and has encour-aged suppliers to add the JMS interface to existing messaging products. The most fundamental
messag-ing function is to make disparate networks look the same to appli-cations, with message queues to avoid loosing messages when applications are not available. Secure, reliable, once-only deliv-ery is critical, as is multi-platform support.
Messaging product lines are suitable for central architectures where the cen-tral 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 heteroge-neous network, as well as delivering all messages securely and reliably. Various types of connection management are required, including point-to-point and publish-subscribe connections. Most suppliers add various types of brokering, transformations, and transaction processing. Transaction fea-tures 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 develop-ers, 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 envi-ronment for loading and running multiple integration applications, which have been developed as components. Application servers “contain” compo-nents and provide common services needed by the compocompo-nents such as messaging, connection management, security, persistence, and other func-tions. Thus the selection of an application server supplier is important because it defines many important attributes of the integration application.
App A Partners Suppliers App B Enterprise 1. Message-centric Adapters Adapters
• Multi-platform Network API • Queues – always there • Broker
• Transform
• Content based routing
• Combine and partition documents
In addition to those mentioned above, application servers also provide ser-vices 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 het-erogeneous platforms. This is critical for increasing code re-use and minimizing integration development and maintenance efforts. Recently, ap-plication servers have been enhanced to easily expose component functions as Web services, making it easy for existing applications to create Web ser-vices.
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 appli-cation servers. Alternatively, tools can generate configuration data to be
processed by an engine deployed as a component. This strategy is being used by some BPM tools suppliers, to leverage standard application server environments.
Application servers are not new, but recently, J2EE- (Sun Java 2 Enter-prise Edition) compliant application servers have become the clear win-ner 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, sys-tems 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, provid-ing 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, con-nections, etc.). By defining just the interface, J2EE encourages competition between service providers, giving end users multiple sources. J2EE applica-tions typically leverage Web servers that support Java Server Pages (JSP) and servlets to implement the presentation requirements.
App A Partners Suppliers App B Enterprise 2. Application Server-centric • Standard Interfaces • Deployment • Monitoring • Failure management • Scaling, distribution • As components – EJB • Using Standard Interfaces
Supplier J2EE Application Server: Integration Applications:
Applications developed for J2EE should run on any standard server, on any operating system, and this has made J2EE a target for many integration soft-ware 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 enter-prise packaged application software suppliers, also laboring with the same issues. The recent SAP adoption of the J2EE platform is one of the most visi-ble examples.
Process-Centric Approach
The dynamic nature of current business environments has changed the re-quirements for integration software in two major ways, and process-centric integration is the result. First, process-centric integration
recognizes that the integration programs are applications themselves. Integration applications actually implement business logic, in addition to moving data and brokering messages. Second, business logic is dynamic and is de-fined by business analysts. This shift is leading to a flood of Business Process Management (BPM) products with graphical programming tools that target analysts.
Several software types, including packaged applications, have a business process focus. By comparison, the BPM 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 software to build industry-specific parts or to get an in-dustry-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 proc-esses are essential to keep other procproc-esses running when deploying changes.
Key BPM
Features Function
Modeling Use graphical tools and ob-jects to describe and analyze business processes.
Automation Execute business models to link applications for rapid consistent response. Workflow Execute business models to
integrate human decisions and operations in processes Monitoring Tools for analysts to monitor executing processes, resolve exceptions and optimize Management Deploy and update models
and processes in real time, tune load balancing, man-age profiles, security and other configurations.
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 envi-ronment for BPM packages includes adapters for access to legacy systems,
packaged applications and data-bases, and various other integration technologies such as messaging and transaction sup-port. Runtime architectures used by suppliers range from a complete integration server that does everything, to code genera-tors that build application parts (e.g. EJB) and run them on more traditional integration software. Two classes of products are common. One uses an integrated run-time en-gine that executes (interprets) processes directly. The integrated enen-gine 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 exist-ing 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 enter-prises. The integration requirements for software that supports successful models are becoming better known, and the integration product winners are
App A Partners Suppliers App B Enterprise 3. Process-centric
• Graphical (draw it)
• Becomes part of the Enterprise App • Build vertical Apps
• Complete integration environment • Several implementation strategies
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 specifi-cally 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 in-ternal and exin-ternal 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 applica-tion 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 com-plete the infrastructure, end users must select an application server, an appro-priate 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 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
BPM Applications or Processing Engines New Enterprise Applications Legacy Adapters Components Application Server Components Components Open Development Environment
Messaging Security Database CORBA
Typical Services Business Process Management: Deploy Monitor Update Optimize JMS JNDI JDBC RMI-IIOP
(EJB) that are loaded in an application server (container) or generate configu-rations 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 run-time engines to EJB components so that they will run in a J2EE environment. Others generate EJB, JSP, Servlets and other components that are automati-cally built into deployable modules.
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 applica-tion development tools are implemented in Java, demonstrating its feasibility (performance was a con-cern) and giving suppliers a broader market and the security of portability.
Considerable time and effort has been expended on inte-gration 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 De-velopment Environments (IDE). With deDe-velopment 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” de-velopment and deployment environments similar to the standard J2EE runtime environment. This will not only be good for large Sun and IBM us-ers, but also will be very good for smaller suppliers and their customus-ers, thus
NetBeans (Sun) Eclipse (IBM)
Sun (iPlanet) IBM
BEA CommerQuest COMPAQ Computer Associates Compuware i2
DataMirror Peregrine Information Architects Skyva IONA Versada
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 main-tenance 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 aban-doned abruptly, and a gradual evolution to J2EE is necessary. Because J2EE is largely interfaces, this is feasible.
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 cre-ates 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 enter-prise platform of choice, but Microsoft is working hard to establish a presence with the .NET platform. Most manufacturing plant
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 re-use, and extreme scalability are requirements, and they will continue on a J2EE path for Web services, even for Windows platforms.
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 .NET Platform J2EE Platform Bus ine ss Portability Scalability Common Low Cost Platform Pr od uct io n
.NET
The .NET platform consists of a Web services strategy with several Microsoft servers. .NET servers, anchored by the popular SQL Server and Internet In-formation Server (IIS), have been developed and released in sequence, but without native Web service support. Visual Studio.NET, the enabling Micro-soft 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 develop-ment 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 di-rectly with other BPM integration servers from enterprise integration software suppliers. EI software suppliers are not adopting .NET as a plat-form 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 Internet-driven 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 in-tegrating 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 de-velopment of tools, technologies, and standards for the creating of Web service platforms. The technologies are largely known, and software suppli-ers are enhancing tools to support the creation of Web services. The J2EE and .NET platforms are central, and related work will be sufficiently com-plete 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.
User products are needed to consume Web services in a flexible, ad hoc way. Currently, portal software is adopting Web services rapidly, and other simi-lar areas will quickly follow suit; this is a good place for early adopters to start. The integrated value chain will be managed around business proc-esses, 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 ser-vice maintenance issues are sorted out. The use of Web serser-vices 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 enhanc-ing 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 en-hanced 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 neces-sary 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 irre-sistible:
• Manufacturing process management – procedures, plans, orders, reports, recipes, records – requires the same technology for enterprise and pro-duction 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 in-formation.
• 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 manu-facturing 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 inte-gration platform will be a combination of these and existing inteinte-gration 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.
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 plan-ning and technology assessment services to leading manufacturing companies, utilities, and global logistics providers, as well as to software and solution suppli-ers 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 pro-prietary 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 di-rections 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: [email protected]
Three Allied Drive • Dedham, MA 02026 USA • 781-471-1000 • Fax 781-471-1100 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
