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
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
- 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
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
- 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
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
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
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
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
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.
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
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.
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.
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"2
) 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
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.
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.
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.
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.