Welcome Guest. | Log In| Register | Membership Benefits

News In Review

March 8, 1999

Print this story
Print this story
ERP Integration

Vendors race to meet IT's growing need for integral links to enterprise apps

By Dan Kara

Related links:
  • Please download the accompanying tables and charts as a PDF file.
    Acrobat
    To view a PDF file, download the Adobe Acrobat Reader
  • E nterprise resource planning software has become a strategic platform for carrying out common business functions, from human resources to financial management. The importance of these packaged application suites often requires corporate IT departments to integrate their ERP systems with other strategic computing resources such as client-server, Web, and legacy applications.

    ERP systems are the primary means companies use to automate business processes. But these business processes often transcend departmental and even company boundaries. Enterprise application integration is a complex process that can have a profound effect on the IT architecture.

    The major ERP vendors--Baan, J.D. Edwards, PeopleSoft, SAP, and others--all publish APIs that let external applications communicate with the ERP system. While APIs are a good way to provide information access, they're often not sufficient for distributed processing across different applications.

    That's why a number of development tool vendors are broadening the scope of their programming environments to address the needs of enterprise application integration.

    Integration Approaches
    It would appear at first glance that the publication of APIs that can be used to access ERP data and metadata provides a solution for ERP integration. The reality, however, is quite different. To illustrate one problem, consider what's required to integrate two ERP applications at the data level. Developers write a low-level API to read data from the first ERP system. They then write more code to transform the data, and finally write the data out to a file in the second vendor's format.

    Writing multiple low-level APIs is difficult, time-consuming, and costly. Keeping the interfaces current as the packaged software changes is also a challenge. The manual maintenance of such programs is nearly impossible, especially for smaller organizations.

    Now consider what happens if the number of ERP implementations is increased. Two partnering systems require one interface, three systems require three, but as the number of partnering systems is increased past three, the number of interfaces increases dramatically.

    This only points out the theoretical problems when integrating disparate software systems. There are also the issues of dealing with multiple operating systems, communication protocols, and data types.

    Recently, a new class of middleware has appeared on the market that opens application packages to the enterprise without the need to write low-level APIs. The amount of industry attention paid to this new class of integration software speaks volumes about the need to extend the reach of ERP systems.

    At the most basic level, ERP integration middleware vendors can be broken down into two groups. The first make data-oriented products that support ERP integration primarily by sharing data sources. The data-oriented segment are represented by vendors such as Argent, Carlton Software, and SmartDB. These vendors' products extract and transform data, and subsequently exchange data files between ERP packages and other applications.

    The second group, the messaging-oriented vendors, support direct data-sharing between programs without the need to use a data file or database as an intermediary. Active Software Frontec, New Era of Networks, and Vitria are representative of vendors whose products support inter-application passing of data using a messaging approach. This method of inter-application passing of data supports dynamic registration and message-brokering services for distributed applications across a network.

    Some vendors of ERP integration software have tackled the problem of the multiplying number of interfaces by employing a single, central integration engine in a hub. While this approach limits the number of required interfaces to one for each partnering system, it introduces a single point of failure. If the broker and integration engine go down, all application components that rely on it are locked up.

    IDEs And ERP
    The need to integrate ERP applications into the enterprise architecture is so fundamental that many vendors of software development and deployment environments have added ERP connectors or adapters to their products. But more important, these vendors realize that ERP packages have become de facto industry standards for back-end application services. Simply put, integration support for ERP packages has joined the long list of middleware, object model, database, and platform standards that application development vendors must support in order to meet customer demands.

    It's likely that many other application development vendors will add support for enterprise application integration. The current players in the market are also expected to continue to enhance the scope of their integration capabilities with support for an increasing number of ERP systems.

    continued...page 2


    Back to This Week's Issue

    Send Us Your Feedback

    Top of the Page