Objective
We have a long-term client who has been undergoing a time of significant change. This change was bringing in new software systems, as well as modified business processes. As part of the implementation of the new software, Senior Management wanted to avoid manual integration. They also wanted to allow for software systems to easily talk to each other, where it made sense.
We had previously built an inexpensive middleware API-Integrator for them. It handled traffic and packets between two software packages who only wanted to receive data and not push it. Senior Management asked us to expand on this API Integrator and allow for their new integration needs
Solution Delivery
- The initial middleware functionality was built allowing for future growth. It lived on a segregated SQL server within the client’s network. This segregation allowed them to manage their internal security effectively – external traffic was limited to this point of contact.
- The middleware was already configured to authenticate data to/from the business ERP software. The pre-existing integration was used to listen for webhooks fired from Service software. It retrieved required changes, then sent those changes back to the ERP.
- The first new integration required was between new Payroll software and the existing ERP. Project data was sent from the ERP to the Payroll software. Timesheets and Payroll financial postings were sent back to the ERP. This was a simple addition to work within the existing middleware structure.
- Service Management realised that they could use the existing Middleware to directly communicate between their Service software and Payroll. They wanted to send leave requests from the Payroll software to update the Service Schedule. They also requested the ability to send their time recording from Service to the Payroll software. Unfortunately, this could not occur due to limitations with the Payroll software integration options.
- As part of the Service/Payroll solution, we realised that it made sense to implement/develop a common employee table in the middleware database. It meant that we could easily verify and match the right data across all the linked packages.
- Almost simultaneously, a requirement arose to integrate the new Health and Safety software to the Payroll software. This new need would send users and their home departments to the Health and Safety software. It would avoid users needing to rekey data. An expansion of the existing common employee middleware table allowed this to happen relatively easily.
Achievements
- One of the key benefits of the use of this bespoke middleware piece is that it can translate and map data as needed. Tables can be built and adjusted as requirements change, but a common repository across all the packages is always present.
- The middleware and all the integration development and tables are wholly owned by the business. If, in the future, they decide that it is cost-effective to have a permanent, on-staff, developer, they can manage all changes themselves.
- While there have been up-front costs for setup of the middleware for each integration, as well as the actual integration development, these costs would exist regardless. Our client, however, is able to avoid paying any ongoing costs to a pricey third party in order to have the middleware translation and integrations in place. They only pay for initial development/deployment, then ad hoc assistance as needed.
If you’d like to learn more about this project or talk to us, click here for our contact details.