While some people may wish otherwise, your enterprise resource planning (ERP) system can't do it all. For those tasks that are outside of the scope of your ERP package, you need a good means for interfacing and integrating those systems with your ERP. Integrating applications with your ERP can be one of the most challenging stumbling blocks to a successful ERP implementation. The task can be anything from needing to incorporate legacy home-grown applications when implementing a new ERP, to meeting the requirements of introducing new technologies like Web interfaces or RFID systems with your existing ERP, to supporting the latest supply-chain initiatives. And while the possibilities are endless, the concept in each of these cases is pretty much the same: There can be no compromises between sharing ERP information with other applications and ensuring the integrity of mission-critical data.

In this article, we'll examine ERP system integration concepts. The good news is that most ERP vendors have recognized the fact that their systems need to support interfacing with other applications at some level. In fact, many ERP vendors offer application program interfaces (APIs) to assist in the integration process. In most cases, however, some customization will be involved to supply the interface APIs with the data they need to do their job.

Application Integration Concepts

One of the most important things to determine when working on an enterprise application integration (EAI) initiative is exactly how tightly you want your applications integrated. Heavy integration can involve making major modifications to existing application flow and can ultimately impact the normal process flow. On the other hand, if your integration is too loose, you may end up with inconsistent data between applications. Fortunately, most modern ERP systems have some level of support for integration with other applications built in. I have always been a follower of the "don't reinvent the wheel" school of thinking, meaning that if your ERP already has some type of integration or interface technology built in, it's best to use that technology rather than use an external application or build a custom solution. Ideally, you want whatever integration solution you implement to make as much use of existing applications and services as possible while avoiding the risk of overloading your existing resources. Figure 1 below illustrates the type of interface that might exist in your current ERP.

Figure 1: This example illustrates an existing ERP process. (Click images to enlarge.)

This example illustrates a common process in any ERP system. Here, shop floor production data is entered into a data entry screen, which in turn creates a production transaction batch. This batch is then processed by a background job that handles adding the finished item into inventory and consuming the component items as well as updating production and status data for the work order. This is a perfect example of using an existing process to integrate your ERP to another system. Using this example, let's assume that you want to implement a third-party shop-floor data collection solution. Your interface would simply involve building the same batch data that would be built by the data entry screen using the information read from the data collection equipment on your production machines. This batch will then be processed using the same method that is used when transactions are entered through the data entry screen. Figure 2 helps illustrate this.

Figure 2: Utilize existing processes to integrate new applications.

As you can see, this example uses the existing processes already in place to process the data coming in from the data collection system. As a result, any necessary changes or corrections within the transaction processing job will automatically affect transactions entered via data entry as well as those coming in from the data collection system. This design concept can be extended when you don't have the existing background job in place and must develop a new interface application to handle integration. The most important thing to remember is flexibility. An integration process that you build today for one specific purpose may serve you down the road for some process that you can't even think of today.

XML/SOA-Based Integration

As XML and SOA technologies continue to make their way into the ERP world, new standards are developing for the processing of data between disparate systems. Because of the ever-growing use of Web services, it just makes sense to consider this technology when integrating applications with your ERP. Many examples of this technology are creeping into the business computing world.

One example is the UCCNet data synchronization initiative (recently renamed 1SYNC), which began several years ago and is supported by major retailers. The purpose of this initiative is to allow supply-chain partners to synchronize item-related data between their systems. At this level, we are talking about not only integration between systems and applications within a single company, but integration of systems and applications between multiple companies. In the case of the UCCNet initiative, this integration allows retailers and their suppliers to ensure that their systems are in sync from the standpoint of accurate item data.

The advantage to this type of standards-based approach is that many software vendors readily support these integration standards. As more standards continue to be developed, the demand to support these standards within your ERP will increase. In most cases, these standards are industry-specific and are defined by working groups made up of people with experience in that industry. The Planning and Scheduling Language on XML (PSLX) consortium, for example, has defined a set of standards for transmitting information related to planning and scheduling within the manufacturing industry. This is a means by which an organization can share information about the manufacturing process (items, processes, schedules, capacities, etc.) with other divisions, remote locations, or even external supply-chain partners. Similarly, standards have developed within the accounting field for transferring data related to financial transactions. Among these standards is eXtensible Business Reporting Language (XBRL). This standard defines messaging formats for sending data related to budgeting, financial reporting, procurement, and other accounting functions.

While these examples are all generally used to share data between partners, it's just as easy to design Web services to share data between applications within your organization for integration purposes. Possibly the greatest advantage to using Web services as the means to integrate your ERP with other applications is that Web services are platform-independent, meaning that Web services on different platforms can communicate without knowing (or caring) what platform the Web service on the other end is running on. Some of the major ERP players—SAP, Oracle, and PeopleSoft just to name a few—already support Web services as a means of application integration. This is great news from an application integration standpoint because, the same way that an existing process within the ERP can be utilized for integration purposes outside of the original design, so can XML Web services be utilized for purposes other than those for which they may have originally been intended. Leveraging that type of interface can greatly assist in application integration because of the standards-based approach used by Web services. Because more and more software vendors are including support for XML Web services, the integration task will become much easier to manage. Platform-independent Web services can communicate seamlessly without the headaches posed by platform-specific integration techniques. For example, a financial reporting application that supports XBRL standards can be easily integrated with an ERP also supporting those standards.

It's a Small (ERP) World After All

ERP application integration techniques continue to change. The introduction of XML/SOA into the mix will eventually mean that application integration will become more seamless; however, getting to that point may be a long and painful process. In the end, a great deal depends on what the ERP vendors themselves do to make this technology a core component of their software offerings.

Mike Faust is a Business Analyst for Invivo Corp. in Orlando, Florida. Mike is also the author of the books The iSeries and AS/400 Programmer's Guide to Cool Things and Active Server Pages Primer and SQL Built-in Functions and Stored Procedures. You can contact Mike at This email address is being protected from spambots. You need JavaScript enabled to view it..