TMS Migration and Middleware Implementation
A bi-directional integration solution for real-time driver updates
Industry
Freight transport and logistics
Company Size
Multinational
Services
LTL shipping
Key Factors of Success
- Infoview’s extensive experience connecting IBM i (AS400) based applications to middleware platforms
- A comprehensive mix of RPG, middleware, and integration professionals able to quickly scale up/down team size based on customer needs and project timelines
- A global team with around the clock ability to provide quick SLA support and issue resolution
- Infoview’s bi-directional DB2 replication and API based integration tools
Outcomes
- Numerous high complexity responsive bi-directional integrations between TMS, OMS, ELD devices and platforms, and IBM i (AS400) systems
- Customer team was able to re-use existing assets while “modernizing” their legacy applications
- A robust and scalable enterprise grade middleware platform was implemented, allowing the customer team to easily scale, govern, and monitor business wide APIs
- The customer team was trained with a leading middleware/API management solution
The Customer
A premier provider of trucking based logistic services for customers across the United States in divisions including standard flatbed, tankers, and refrigeration transport. For the customer team, their IBM i based TMS system was the source of truth, but posed challenges as the business pursued a new cloud based TMS system and needed to migrate data from the old TMS to the new cloud-based system.
The Challenge
Running key lines of business applications on a heavily customized IBM i (AS400) based TMS system, the customer was in process of transitioning some functionality of the existing IBM i based TMS to a new cloud-based solution. During the transitioning period, both the existing TMS and new cloud-based system needed to be bi directionally in sync in real time to eliminate or minimize the business process overhead and reduce the need for ops teams to work with both systems (avoid “swivel chair” approach).
The pre-existing integration design entailed a custom windows-based middleware that translated data flow between the IBM i and cloud TMS based applications. Limited re-use, inability to process real time transactions, custom development heavy, potential IBM i performance degradation as the number of interfaces grew, and security risks were all contributing factors to consider as the customer team sought third party assistance to confirm or adjust their integration design.
The Solution
Working with customer leadership, project, and business stakeholders, Infoview’s professional services team worked closely throughout the strategic advisory, POC, architecture roadmap, solution development, implementation, and interim support phases, including customer team training and knowledge transfer. As trust grew between the parties, Infoview’s project team slowly grew as more resources were allocated towards the project.
- The engagement started off with a series of discovery calls with customer stakeholders to understand key business processes, lines of business, challenges, and strategy for the next several years to come
- Through the sessions, we gained a deep understanding of source and target systems, timelines, and integration pain points. We conducted a proof of concept consisting of two possible IBM i based integration solutions and design patterns aimed to replace the existing ad-hoc middleware:
- One entailed a middleware neutral component that would expose IBM i business logic as a standards-based REST API
- The other entailed a leading middleware and AS400 based connector that enabled teams to exchange messages via data queues and call existing IBM i programs directly from said middleware platform
- Per the POC conclusions, the middleware route proved to be the best fit and the Infoview team began creation of the integration platform from hardware and software recommendations, infrastructure guidance, solution setup, and end to end integration architecture
- As the migration from the old TMS to new would take place in phases (each “phase” representing a particular business unit), the involve parties agreed to begin with the most minimally crucial unit and then scale up from there based on priority
The Design
The customer chose an on-prem based middleware for ease of flexibility and scaled their VM’s accordingly as the project expanded and more computing resources were required
- The engagement started inbound to the IBM i and the team leveraged Infoview’s infoConnect Connector
- To complement, the middleware platform was extended with additional monitoring, alerting, CI/CD, test automation, and quality of service tools
- As the team’s progressed, the end customer also adopted an outbound IBM i integration tool, infoCDC (change data capture) for outbound based integrations between the IBM i and cloud TMS system
Results
To address any unexpected support needs, Infoview also provided a 24/7 support contract with short SLA time making certain any high-level issues were addressed swiftly.
Comprehensive training was also provided to help the customers internal teams confidently learn operations of the newly implemented integration platform.