In-Depth

Multi-enterprise e-business drives a new market.

• By Mike Gilpin
• May 31, 2001

The growth of e-business is transforming the relationship of software applications to the enterprise by electronically integrating customers and suppliers around the world. In this context, the Internet's impact on applications is no longer confined to the "edge" of the business process; it is now beginning to touch every part of the enterprise and its applications. As part of this changing role, individual applications often exist not only within an enterprise, but also as components within a multi-enterprise business pro-cess using the Internet as a communications backbone.

This change in perspective is important due to the way in which it drives requirements for application architectures and the infrastructure technologies needed to support these new or refined architectures.In working with our clients, Giga Information Group has seen a number of real-world examples of this e-business dynamic, including:

• Supply-chain logistics and fulfillment companies integrating with their customers' fulfillment and shipping systems.
• Manufacturers of consumer products integrating their sales and marketing promotion systems with the operational systems of their channel partners.
• Financial services firms integrating the underwriting of financial products with the retailers of those products.
• Continued growth of high-volume, business-critical, business-to-business and business-to-consumer commerce sites placing ever-increasing demands on Web application infrastructure and its integration with the back office.

At the same time, to be suitable for participation in business-critical, multi-enterprise processes, Internet applications must be transformed to mission-critical infrastructure. This demands not only high-volume, component-based applications with high performance, scalability and availability, but durable integration with legacy and packaged applications. This integration must now be achievable not only within an enterprise, but also across multiple enterprises. And to effect such integration in a reliable and secure way, the network and security infrastructure that supports these applications must also evolve to a level of layering and flexibility beyond anything that has come before.

A new market category is born

Many organizations are beginning to invest in Internet-application integration to improve customer satisfaction, reduce costs and improve profits. Yet the actual state of integration in many enterprises today falls short of what is needed to realize a highly efficient, integrated, multi-enterprise business pro- cess. Tales abound of front-office e-commerce applications that generate printouts of customer orders, which then have to be taken to call-center operators to be keyed in to the relevant back-office order-entry system. Huge volumes of business are handled by moving orders over the Internet via relatively unreliable FTP, requiring handcrafted error-handling programming to ensure a smooth flow of business. And to exacerbate the problem, many of the application-integration solutions available today are not well adapted for use in this e-business context because of their reliance upon proprietary technologies, rather than the open technologies that rule the Internet.

As the focus of application integration moves from inside the enterprise to multi-enterprise integration over the Internet, a different mix of requirements and priorities is beginning to take precedence over those associated with Enterprise Application Integration (EAI). Some requirements are refinements of approaches that have evolved for EAI, but there are also important differences. One difference is the need for integrated support for Internet application architectures, such as application servers that support Enterprise JavaBeans (EJBs), Microsoft COM/DNA or both. The distinction between EAI solutions and application servers becomes fuzzier in the context of multi-enterprise integration, to such an extent that Giga Information Group has recognized these new requirements as defining a distinct new market -- Internet Application Integration (IAI).

These distinct IAI requirements are beginning to drive actual buying behavior and the shape of solutions offered into the market. Giga has observed several leading-edge companies whose investments are being driven by e-business assembling solutions that address these requirements. In response, an increasing number of integration technology vendors see e-business as the main engine for growth in the future; they are now offering new products and services to this market, or evolving their current offerings to meet the needs of these customers more effectively.

It is important to recognize the existence of this emerging market and its underlying business need so that those integrating e-businesses can define more effective and durable interim strategies that address these requirements. Our understanding of this market also provides a context within which customers and vendors may hold a more productive dialog about customer requirements -- a dialog that can lead to more effective commercial solutions.

Requirements for an IAI solution

As enterprises form Internet-based trading groups, integrated supply chains or even virtual companies, application integration evolves to a multi-enterprise focus and is more connected with e-business applications. The impact of this change on requirements for IAI solutions is extensive. Giga has researched the integration requirements that are being encountered in e-business integration efforts such as the following:

• Integration of front-office, Web-based e-commerce and other self-service applications to legacy or packaged middle-office or back-office apps.
• Integration of call-center applications serving these customers to the same middle- or back-office applications, for handling complex interactions not amenable to self-service.
• Integration of data and events arising from customer interactions -- across both self-service and call-center applications --into a single resource in support of Customer Relationship Management (CRM) initiatives. These often extend to the population of data warehouses or data marts that are then mined for key information about individual customer's buying habits, as well as more general buying and other interaction trends. Completing the feedback loop, these customer profiles may be used to guide the interactions of customers who are actually online or with a call-center rep in such a way as to maximize revenue.
• Integration of middle- and back-office applications with each other -- both within and across multiple enterprises -- in support of the full life-cycle business process that supports the handling and fulfillment of customer orders and other interactions (such as customer-service requests, dispatching, delivery and completion).

In support of these efforts, we have observed the following integration solutions.

Component or object "wrappers" that act as a component-based way of invoking a legacy mainframe transaction or a remote function call interface provided by a packaged application. These are well adapted for use in interactive Web applications because they use the same component technology as the Web application, and enable the "wrapped" back-office application to become a synchronized part of the front-office business process. This strength is a weakness for IAI, however, because applications from different companies linked over the Internet cannot generally be relied upon to provide the same quality of service as applications that are directly under one's control. Inferior quality of service inevitably works against efforts to improve customer satisfaction.

Pre-built wrappers providing component-based interfaces to packaged applications, such as SAP. These are easy to use, but suffer from the same strengths and weaknesses as custom-built wrappers. Sun/NetDynamics Platform Adapter Components (PACs) are an example of such a pre-built wrapper.

Hand-coded invocation of messaging APIs for passing information between applications over messaging infrastructuressuch as IBM MQSeries or Tibco Rendezvous. Although this offers the ultimate in flexibility, these APIs are often complex and, in the past, have always been proprietary. Still, hand-coding does provide a solution for some business problems that cannot be easily solved when the problem is outside the "sweet spot" of the packaged solution.

Message brokers and their associated tools and pre-built application adapters, such as those from Neon, TSI, STC, Active Software and others. Primarily associated with the EAI market in the past, these solutions are now being positioned as IAI solutions. The primary issue with their being used for this purpose is the question of how well they fit alongside the other infrastructure being used. When little or no development work is done, as in a typical EAI scenario, then the choice of the language used to configure the message broker -- whether a rules-based declarative approach or a procedural language -- is isolated in the context of the EAI solution.

However, most IAI scenarios include some development, and the language chosen for that development work influences the same choice for integration configuration work. For example, when Java is used, Java support is often desired for the integration infrastructure. Most EAI vendors are working on adding support for Java and other Internet technologies in some form, but not all vendors are equally focused on this priority.

Who will offer IAI solutions?

It is hard to talk about winners and losers at such an early stage in the development of the IAI market, However, due to their support for at least some of the above requirements, it is possible to identify vendors that appear to be in the best position coming out of the starting gate:

• Application server vendors: IBM, BEA Systems, iPlanet(Sun/NetDynamics/Netscape)/Forté Software, IBI, Oracle, Bluestone, Microsoft, Iona, Inprise and Sybase
• EAI vendors with the best component technology support today: Active Software, Vitria, Candle, Oberon and SAGA
• EAI market leaders investing in XML and Java support: STC, Neon and perhaps others

Leaders in the EAI market are in a strong position to successfully transition to the IAI model. In the case of Neon and TSI, this is driven mainly by their partnerships with IBM, Forté and BEA Systems but also because of some existing support for component technologies, such as CORBA-based interface connectors. However, it will be tempting for existing leaders to see the market in the same EAI mold because that will be the easiest way to generate more revenue growth without increasing the cost of sales, marketing or development. Those leaders smart enough to make the right investments now can avoid this danger and continue their leadership.

In addition to solutions like IAI and application servers, which are used to create an integrated application scenario across multiple enterprises, packaged solutions are emerging at a higher level to support some of the same business drivers. For example, DSO has DBexplorer, a solution used to establish links between vendors and buyers in Internet-based trading groups typically enabled by a market-maker setting up the online market. Yet, just as application packages cannot meet all application requirements, these packaged solutions cannot meet all e-business requirements. Because DBexplorer is based on XML and written in Java, it (and other products like it) will be quite complementary to the other elements of a solution that would be assembled on top of an IAI infrastructure. This kind of dichotomy will persist as these new markets develop.

Another alternative business model for delivering IAI solutions is as a service provider. A typical example of this model is CommerceQuest, formerly MessageQuest, which offers an IAI solution as a service. CommerceQuest's enableNet is a managed business integration service that uses XML and a message-based infrastructure to provide an Internet-based alternative to traditional value-added networks and EDI solutions. Peel back the covers on enableNet and you will see all the elements of a real IAI solution, which CommerceQuest can also provide in a traditional software license-fee business model. But for those organizations that, for whatever reason, want to outsource the creation and management of this type of multi-enterprise integration infrastructure, this kind of solution is representative of an approach that is likely to gain popularity. This infrastructure service is also likely to emerge as one of the kinds of e-services offered by Hewlett-Packard and its business partners, using infrastructure technologies from BEA Systems and other HP partners.

How to proceed

Those using EAI and application server solutions today often have requirements springing from the business dynamic described above, but have to do the infrastructure integration themselves in order to create what is, in effect, an IAI solution. Therefore, companies that already have IAI requirements should proceed in the short term by doing this kind of best-of-breed integration -- ideally choosing from a set of vendors well-positioned for the IAI market and with a consistent set of infrastructure technologies that will be easier to integrate. Furthermore, the eight IAI requirements outlined should be observed as guidelines in the way these technologies are utilized. This will increase the chances that, as commercial comprehensive IAI solutions continue to emerge, they will interoperate effectively with the "roll-your-own" legacy. Fortunately, this is usually an innate property of these kinds of loosely coupled architectures.

Those that have only EAI requirements today need not necessarily change anything in the short term. However, be on the alert for signs that an IAI solution may be required as a result of changing business dynamics. If these signs appear, then immediately use the eight IAI requirements as a guideline so as to prepare for a transition to an IAI solution.

Companies preparing to participate in trading groups, integrated supply chains and virtual companies should use packaged e-business solutions or services for this purpose when possible. However, given the likelihood that significant parts of the solution will have to be integrated in a customized manner, these packaged solutions should adhere to as many of the eight principles as those to which IAI solutions should adhere. This will enable these packaged solutions to interoperate with these inevitable customized extensions, and to exhibit the kind of agility and resilience required to remain competitive as future e-business requirements evolve.

Mike Gilpin is vice president and senior analyst with Giga Information Group, Norwell, Mass. Prior to joining Giga, Gilpin was vice president of strategic technology at Intersolv.

Eight requirements of IAI

Giga has identified eight key requirements that Internet Application Integration (IAI) solutions should satisfy.

---

1

An IAI solution must support Internet technologies, including browser-based management and control, as well as the ability to deliver integration functions via standard Internet protocols and data formats such as XML. The end game is to enable standard XML-based business communications to flow over a secure, Internet-based, reliable messaging infrastructure in a way that enables the various components of a business process to be easily assembled across multiple enterprises. It is essential that this infrastructure be flexible and easy to reconfigure.

2

IAI solutions must integrate tightly with new application infrastructure technologies such as application servers that support EJBs, Microsoft COM/DNA or both. This is essential so that new Web-based applications (whether packaged or custom built) can leverage IAI solutions to assemble a collective multi-enterprise solution, and so that those Web-based applications can themselves be leveraged by IAI solutions as part of a business process.

3
An IAI solution cannot dictate a platform-specific infrastructure technology. For example, using Windows as an application platform in one enterprise should not preclude using Unix or a mainframe in another. Multi-enterprise integration is even more inherently heterogeneous in nature than EAI.

4

It is even more essential for IAI solutions to be loosely coupled than EAI solutions. While this may appear to fly in the face of Requirement 2, it is consistent if the correct architecture is used. A tightly coupled request/reply connection (such as that used by most component "wrappers"²) should therefore take place only within the confines of one enterprise business unit and be associated with an interface that will never be decoupled across enterprises or business units. If an internal interface may one day be decoupled to an extranet, then it should be based on loosely coupled brokered interchange of standard XML-based business communications.

5

IAI solutions must embody and embrace software component architectures. A best practice for enterprises that wish to participate in multi-enterprise integration will be the use of software component technology. Only the flexibility of a componentized internal architecture can be sufficiently responsive for the need to dramatically change and decouple various aspects of the business. More tightly bound pre-component architectures, like "fat client/server," are inherently ill-suited to respond to this kind of constant change and growth. Some legacy mainframe online transaction applications, if sufficiently modular, may actually be easier to change than client/server apps.

6

IAI solutions will themselves increasingly come to leverage runtime architectures like application servers, rather than build their own, as it becomes increasingly important to co-exist with distributed component Internet applications running on the same platform technologies. Integration with a consistent set of security and directory technologies will also drive this trend. Do not be surprised to see next-generation IAI solutions implemented using EJBs or COM components, and running on an application server, alongside the Internet apps with which they will integrate. Because it integrates messaging with EJBs, the Java Message Service will be part of app server-based IAI.

7

Just as Web-application workloads have huge unpredictable spikes in demand, so do the pipes making the connections between these applications. An IAI solution must therefore be easily scalable in order to handle these workload spikes and not become a bottleneck. One can embrace an application server infrastructure, as in Requirement 6.

8
Groups of enterprises that will trade together are currently engaged in establishing federated systems of directory and security infrastructures. IAI solutions must integrate with standard directory and security infrastructure, preferably the same infrastructure that is integrated with application servers. Clearly, integration solutions can no longer afford to have their own unique security and directory requirements in this new IAI space.