Large companies today are filled with disparate systems containing overlapping functionality. Companies frequently support separate systems to handle manufacturing, financials, human resources (HR), and customers. Those companies that are disciplined enough to run on a single vendor’s line of business (LOB) applications are not necessarily better off than those running on applications from multiple vendors. It is likely that the vendor gained the application suite through acquisitions, and supports only custom integration between the individual applications.
Even companies that run on a single Enterprise Resource Planning (ERP) system that also handles HR and Customer Relationship Management (CRM) data are rarely able to handle the custom requirements of each organization. The result is that millions of dollars are spent on customizing the LOB application or developing an entirely separate application (a satellite system) to handle the custom functionality. (The advantage of creating a satellite system is that it is significantly easier than dealing with the LOB version upgrade problems that accompany the modification of source code in an LOB application.) Regardless—whether a company has multiple LOB applications, a plethora of satellite systems, or both—the data between systems needs to be sourced from a single master and synchronized across each application. Otherwise, the data becomes stale and worthless. Data synchronization is one of the problems that Microsoft® BizTalk® Server is designed to address, and with the addition of the LOB adapters in BizTalk Server 2006, applications such as PeopleSoft, JD Edwards, and Siebel can be smoothly integrated.
ERP Systems
ERP systems are a type of LOB system. In their early form, they were sold as a “magic bullet” solution to integrating an enterprise’s business, people, and processes. ERP systems were popularized in the 1980s and 1990s with the intention of integrating multiple business functions into a single application platform. Built by the likes of Oracle, PeopleSoft, JD Edwards, Siebel, SAP, and Baan, these ERP systems created application silos bounded by each vendor’s proprietary application technology. Inevitably there was a need to integrate ERP systems with each other or with other systems that provided additional functionality.
Figure 1: Typical LOB system integration scenario (partial integration).gif)
Figure 1 depicts typical scenarios in which LOB system integration occurs with seemingly ad-hoc integration links needed to keep data synchronized. These include mergers and acquisitions that result in two companies, running two different ERP systems, that must share data through synchronization or real-time exchange. Another scenario where such integration occurs is when new systems are introduced with functionality not available within the ERP systems. For example, the implementation of a custom e-commerce system introduces the need for the customer to enter a sales order into the corporate Order Management System (OMS) in near-real time. Still another example is when there is no centralized organizational application strategy (due perhaps to “political boundaries” or to improper management), resulting in departments within the same company using different systems.
Integration and Interoperability
The need for integration prompted the need for external, or integration-based, APIs from ERP vendors. However, the APIs produced were clunky, proprietary, and required very specialized skill sets. The need for standards-based adapters based on a common pattern was apparent, and several vendors went to work to create adapter frameworks that would allow a developer to learn a single API for creating software to integrate with multiple ERP platforms. Some adapter vendors took this a step further to create adapters that were ready to use with integration platforms such as BizTalk Server 2006.
Figure 2: Typical integration scenario designed by using BizTalk Server and LOB adapters.gif)
This allows BizTalk Server to be used as a centralized integration broker, as shown in Figure 2, reducing the need for point-to-point or custom integrations between two systems. BizTalk Server 2006 provides a diverse set of LOB adapters to facilitate the exchange of information between a variety of ERP systems, and other external data repositories, through the use of a common technology. We will summarize important high-level technical points about the LOB adapters throughout this white paper.
The purpose of the LOB adapters is to enable companies to leverage their existing investments in their enterprise application infrastructure while mitigating risks inherent to integrating business systems. The following paragraphs discuss some advantages of using the adapters.
Reuse of Existing Business Logic
A common integration challenge faced by companies today is that much of their investment in the design and development of business logic cannot be leveraged when interfacing directly with the underlying databases. Use of a data transformation utility such as Data Transformation Services (DTS) or SQL Server™ Integration Services (SSIS) can often lead to data exchanges that violate critical business rules because these rules are implemented in application logic, and not in the databases. This also undermines the investment made in the LOB system’s business logic. By communicating directly with the LOB system at the database level, it is possible to introduce data that will be misinterpreted by the LOB system.
“Application adapters” allow integration platforms to interface with the “business logic layer” of the LOB system using each system’s proprietary interface mechanisms. By using application adapters, IT departments can create integrations that will exchange data while still adhering to the critical business rules that have been programmed into the business logic layer.
Specifically with BizTalk Server 2006, the Adapters for Enterprise Applications (the “LOB adapters”) enable run-time application integration while also providing key design-time functionality. BizTalk Server ports are configurable for connections to multiple instances of the LOB systems. “Wizards” are used in the Microsoft Visual Studio® .NET development environment to browse business object metadata and generate XSD schemas and orchestrations that can be consumed as part of the BizTalk Server development cycle.
Reduced Development Cost
Because the BizTalk Server LOB adapters communicate directly with the existing business logic layer on the LOB system, additional components that would otherwise be duplicated as part of an integration effort are not needed. Companies can avoid having to develop components for their integration projects that mimic the logic that already exists on the LOB systems.
Lower Change Management Risk
Eliminating the need for duplicated business logic greatly reduces the risks associated with managing changes to the LOB systems and any dependent systems. For example, if you have seven different processes all using distinct versions of the same business logic, a change in one could necessitate a change in all. However, it is possible that not all seven processes would be modified correctly or at all. Even if the changes were properly completed, imagine the resources expended in making the same change repeatedly or inaccurately.