You are currently viewing Case Study: Middleware and Integration

Case Study: Middleware and Integration

Burger Consulting Group is currently finishing up work with one of the largest specialty contractors in the nation. The scope of this engagement included management of the integration work between four different software solutions along with an additional Middleware solution that would act as the go-between for the four solutions as part of a larger ERP implementation.

An integration project can be a complex and very technical undertaking. However once complete, an integration can be a very streamlined and efficient process, eliminating double and sometimes triple entry in multiple solutions. Although possible to build an integration without using a Middleware solution, there are some clear benefits:

  • Flexibility – middleware can receive data from a source solution and then translate or alter the format of the data before then inserting or updating it into a destination solution.
  • Ease of updating – once the integration is built the process of updating it in a middleware solution is easier than working with multiple vendor technical resources.
  • Maintaining into the future – similar to the item above, maintenance of the integration is easier to do in a middleware solution.
  • Scheduling the timing of integrations – a middleware solution allows you to define your own integration schedule versus potentially having only the option of using a vendor-defined integration schedule.
  • Visibility – a middleware solution provides a level of visibility into the integration by using an administration console.

Preparing for success

Before starting any level of integration work you have to define how both internal and external resources will collaborate. For example, in this recent engagement, we leveraged Microsoft TEAMS to both communicate (using Chat and Posting) and collaborate on all integration documentation.

We also had to fully understand the vendor-provided web service API’s and how robust they are. Some vendors have a philosophy of supplying fully open APIs and some vendors do not.

Field mapping and process documentation

The first step in the process is understanding what the business requirements are from a process standpoint and identifying what required fields are needed to pass from solution to solution. For example, one of the integration points we worked on was between a Human Resources solution and an ERP solution.  Each software solution had its own required fields, and we were able to leverage the middleware solution to identify data types, translate, and update the data required for each destination solution.

Middleware was also leveraged to identify exceptions based upon specific criteria – for example, employees in a specific location may require specific accrual plans and middleware was able to identify these exceptions and apply to appropriate accrual plans.

Testing

Testing is another area where good collaboration is needed between team members. In these times of virtual meetings, we were able to again leverage the functionality within Microsoft TEAMS.

two types of testing should be anticipated:

  • Back-end IT testing – before rolling out to end-users, internal IT resources should perform basic testing activities to ensure end-users can test sufficiently. Not all test activities will be performed at this stage but high-level functionality should be vetted.
  • Front-end testing with end-users – Once the basic integration functionality is confirmed, a team of end-user testers should be formed to perform detailed test activities for the integration. This is the point where we try to “break” the integration to identify issues to fix.

Updates to the process documentation and identification of new required fields or logic typically are discovered during the testing phase and should be incorporated into the field mapping and process documentation.

Documentation

Throughout the process, back-end IT documentation including the integration logic, field mappings, data types, translation tables, etc. Should be maintained.

Another item that should be documented is the integration schedule.  Typically, each integration point schedule is different and can be set up initially to gather statistics.  Throughout the process, this schedule can be updated as needed with the final schedule published out to the organization so end-users understand the timing of when to expect data to move from one solution to another.

As the integration project comes to a close the activity of ‘knowledge transfer’ should occur from the middleware vendor resource to internal IT resources so they can maintain the integration moving forward.

Go-live

There will always be a need for error trapping and monitoring of the integration after go-live and a middleware solution can provide this functionality.

Additional activities that occur after go-live are continuing to update integration documentation as changes occur as well as implementing additional ‘Phase 2’ items.

Interested in working with Burger Consulting Group? Contact us and tell us about your project.