Untitled Document
ebizQ research says there is no reason that OSS integration server software
cannot be as important to external EAI/BPM as OSS application/web server software
is to “internal” application integration. At least a dozen OSS projects
will try to make it happen over the 2008-2012 time period.
Starting in 1997-1998, the dot.com boom spawned a new type of mid-stack software
functionality that combined the features of the intracompany-centric freestanding
application server software of the 1990s with the intercompany-centric electronic
data interchange (EDI) software of the 1980s. Some of this new breed was called
portal engines, some of it enterprise application integration (EAI), and more
recently most of it is has been lumped together under the very wide and tall
umbrella of business process management (BPM). Some of this software is little
more than point-to-point gateway functionality, some of it borders on document
management, and some of it combines sophisticated straight-through processing
(STP) with event-handling automation.
However, all of it had one major goal in mind that was never fully achieved:
tie suppliers to producers to distributors to customers all along the services
and product supply chains. This is the case because although most name-brand
closed-source EAI/BPM/STP products are designed to integrate separate legal
entities, they are still being used more frequently inside a single legal entity
than outside. Often a merger or acquisition kicked off the user’s integration
software purchase. Quickly meeting an application integration need between the
different brands of applications software that the two companies had before
the merger or acquisition was the primary motivator for the closed-source EAI/BPM/integration-server
choice. Adding connections to clients and suppliers was a nice extra feature
but few users took advantage.
Before the advent of BPM/EAI/integration server software, such functionality
was either achieved one-off using an expensive custom project or built into
point products such as Red Pepper, i2, and Numetrix. Increasingly during the
late 1990s, via acquisitions and vendor development efforts, the functionality
became buried inside application suites like PeopleSoft running on fat Windows
clients (pre release 7), SAP R/3 on UNIX machines and J.D. Edwards “Everest”
software running on IBM AS/400s. Most users could not afford the former two
options and for the built-in-to-a-package solution to work best, all the suppliers/producers/etc.
in the chain had to use the same packaged application brand. A time and money
investment was an inhibitor in both cases.
1
Solution Center Resources
Print this article
Email this article
Talk Back!
Write to Editor
