PROSTO24: Analyzing Transport Management System Architecture and the Rationale for In-House Development
PROSTO24 presents an in-depth analysis of a real-world Transport Management System (TMS) architecture and the motivations behind a company’s decision to move away from external providers towards in-house development. The system, operational for just over a year, has already established a complex infrastructure and demonstrates significant control over key business processes.
Architecture of a Modern TMS System
The TMS system under review is a comprehensive solution comprising fifteen modules deployed across three nodes behind a load balancer. It processes orders originating from SAP, facilitating the selection of drivers and vehicles based on specific requirements for transport and specific points. Routes are planned with timed windows for each stop, where checklists are utilized. Vehicle dispatch and return processes involve creating damage assessment reports.
- Data Flow: The system handles a continuous stream of GPS coordinates, stored in partitioned tables for tracking routes, locations, and counterparties.
- Infrastructure: The underlying infrastructure includes RabbitMQ and Kafka (each with three nodes), Redis, PostgreSQL, and a dedicated identity server.
- Functionality: Beyond core management, the system features a mobile application for drivers and a public client portal, allowing customers to track delivery status.
The Business Case for In-House TMS Development
The shift to in-house TMS development was driven not by cost savings, but by the critical need to regain control over essential business operations. Initially, the company utilized TMS as a service from external providers. However, over time, the associated risks escalated significantly. These risks were quantified financially and encompassed:
- Downtime: Inability to influence system downtime.
- Fix Timelines: Dependence on external provider priorities for issue resolution.
- Vendor Lock-in: High reliance on a single vendor when contract terms or service quality changed.
When these risks reached a critical threshold, in-house development became a strategic imperative, enabling the company to reclaim full control over its core operations, despite the initial investment. This highlights a corporate strategy shift from outsourcing to internal development to ensure business stability and security.
This article really resonates with my experience. We also made the shift to in-house TMS development after facing similar vendor lock-in and slow response times from an external provider. The control over our specific routing logic and real-time adjustments has been a game-changer, especially for our last-mile deliveries. The biggest challenge has been maintaining the infrastructure, particularly keeping Kafka and RabbitMQ humming, but the ability to push updates instantly far outweighs that. My tip: invest heavily in robust monitoring from day one, it pays off when you’re managing complex distributed systems.