Tracking is inferred more than observed
Status is frequently derived from the last event received rather than from current position, so confidence in the picture degrades with time and nobody can say by how much.
Technology consulting for logistics and transport
Logistics systems have a property most enterprise software does not: they describe things that are physically moving. Information that is thirty minutes old is not slightly less useful — for a routing or exception decision it is frequently useless.
Industry overview
A logistics estate has to reconcile a physical world that never stops with software that must occasionally be changed. Vehicles move, consignments transfer between parties, and exceptions occur continuously and at all hours, so there is no natural window in which the systems are idle.
The second characteristic is that most of the relevant information originates outside the organisation. Carriers, customs agents, warehouses, ports and customers each hold part of the picture, and each publishes it in a different form, at a different cadence, with different reliability.
Our work here is usually about establishing what the organisation actually knows versus what it infers, designing integration that tolerates partners of widely differing capability, and making the estate changeable without a maintenance window that operations cannot give.
Business challenges
What logistics operators bring to us most often.
Every partner integrates differently
Carriers, agents and customers each arrive with their own formats, cadence and reliability. Handled individually, onboarding a partner is a project rather than a configuration.
There is no maintenance window
Operations run continuously across time zones, so changes have to be made to a system that is in active use by drivers, warehouses and customers.
Exceptions consume the operation
The routine consignment is automated; the exception is handled by a person. As volume grows, exception handling rather than throughput becomes the binding constraint.
Connectivity cannot be assumed
Vehicles, remote depots and handheld devices lose connectivity routinely. Software that treats that as an error rather than a normal state fails constantly in the field.
Cost per shipment is hard to establish
Charges accumulate across carriers, surcharges, customs and handling, and are reconciled after the fact — so the margin on a movement is known long after the decision that set it.
Digital transformation challenges
Logistics transformation is constrained by the fact that the operation cannot pause to accommodate it. That rules out the cutover-style programme and favours running new capability alongside the existing one with traffic moved by lane, region or customer.
The second constraint is the field. Changes that affect drivers, warehouse staff and depot operations are adopted or rejected within hours, and rejection looks like people keeping paper or a private spreadsheet rather than raising a complaint.
- New capability run alongside the old, with traffic moved by lane or region
- Field-facing change piloted with the people who will use it, not announced to them
- Offline behaviour designed before rollout, because connectivity will be lost
- The old path retired deliberately, or the operation will run both indefinitely
Regulatory considerations
Cross-border logistics carries customs, documentation and dangerous-goods obligations that vary by lane and change without notice. Encoding those rules in application logic makes every regulatory change a software release, which is why they belong in configuration with an owner.
Data protection applies to consignee and driver data under the Digital Personal Data Protection Act, and driver data is worth particular care because location history is unusually sensitive. Where telematics data is retained, the purpose and retention period should be explicit rather than indefinite by default.
We advise on technical design. We do not provide legal or customs opinions, and we do not represent NG&NR as holding certifications it has not been awarded.
- Customs and documentation rules held in configuration, not in application logic
- Driver location data retained against a stated purpose and period, not by default
- Audit trail of documentation produced as the movement happens
- Jurisdiction rules externalised, because lanes change more often than software
Enterprise architecture approach
The defining architectural decision is how to represent a consignment whose truth is distributed across parties you do not control. The useful model separates what you have observed from what you have inferred, and attaches a confidence and an age to each.
The second is event handling. Logistics events arrive late, out of order and duplicated as a matter of routine, and a system that assumes otherwise produces a status history that contradicts itself.
The third is degraded operation. A depot must keep working when the central system is unreachable, which makes local autonomy and later reconciliation an architectural requirement rather than an enhancement.
- Observed and inferred state distinguished explicitly, with age attached
- Late, out-of-order and duplicate events handled by design rather than by assumption
- Local operation supported when the central estate is unreachable
- Reconciliation on reconnection designed, not left to manual correction
Cloud strategy
Logistics workloads suit cloud well: load varies by season and by trading day, geographic distribution matters because latency to a driver's device is real, and event volumes are high enough that elastic ingestion is worth having.
The qualification is that edge and offline capability remain necessary regardless of how good the cloud platform is. A vehicle in a tunnel and a depot with a failed link are normal conditions, and the architecture has to work through them rather than treat them as incidents.
- Regional presence where latency to field devices genuinely matters
- Elastic ingestion for event volumes that vary by season and trading day
- Offline-capable field applications, because connectivity loss is normal
- Cost modelled per shipment, so growth in volume has a predictable cost curve
Data strategy
The central data problem is provenance. A consignment's status is assembled from events published by several parties of differing reliability, and treating them as equally authoritative produces a picture that is confidently wrong.
Freshness is the second dimension. Most logistics data has a short useful life, and the pipeline investment should follow that: near-real-time for operational decisions, and a slower, governed path for the analysis and billing that follows.
Reference data is the quiet third problem. Locations, service levels, carriers and charge codes are maintained in several systems and drift apart steadily, so a movement can be valid in one system and rejected in the next. Mastering reference data is unglamorous and removes a surprising share of daily exceptions.
- Event provenance and reliability recorded, not flattened into a single status
- Freshness requirements stated per use case rather than applied uniformly
- Operational and analytical paths separated, with lineage between them
- Cost and charge data reconciled against a governed source, not per invoice
Security considerations
The distinctive exposure in logistics is the breadth of external parties with access. Carriers, agents, customers and contractors all integrate or log in, and access granted per relationship is rarely reviewed once the relationship becomes routine.
Field devices are the second concern. Handhelds and vehicle units are lost, shared and used outside any physical perimeter, so device identity and the ability to revoke a device quickly matter more than they do in an office estate.
- Partner and contractor access inventoried, scoped and time-bound
- Device identity established, with revocation that works within minutes
- Consignee and driver personal data minimised in operational interfaces
- Tracking interfaces protected against enumeration of other customers' consignments
Software engineering
Field software is the hardest engineering in this sector. It runs on constrained devices, in poor connectivity, in the hands of people who cannot stop to troubleshoot, and it has to be correct because a scan that does not register becomes a missing consignment.
That argues for local-first design: the device holds its own state, operates without a connection, and reconciles when one returns. It also argues for extremely conservative interface design, because retraining a distributed field workforce is expensive.
- Local-first field applications that hold state and reconcile on reconnection
- Idempotent event submission, because retries in poor connectivity are constant
- Interfaces designed for gloved hands, poor light and no time to read
- Backward compatibility maintained, because field devices update unevenly
Integration strategy
Partner integration is the dominant integration workload, and partners vary enormously in capability — from real-time interfaces to a file arriving by email. A design that assumes a uniform capability level excludes the partners who most need accommodating.
The workable pattern is one internal consignment and event model with per-partner adapters that translate into it, so partner variation is contained at the edge and the core stays comprehensible as partners are added and removed.
- One internal consignment and event model, with per-partner adapters at the edge
- Partner capability treated as a range to accommodate, not a standard to require
- Idempotent and order-tolerant processing on every inbound feed
- Onboarding reduced to configuration, so adding a partner is not a project
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
Separating observed from inferred state, and designing an estate that keeps operating when the centre is unreachable.
Software Development
Local-first field applications that work in poor connectivity and reconcile correctly when it returns.
AI & Data Engineering
Event provenance, freshness requirements per use case, and a governed source for cost and charge reconciliation.
Cloud Consulting
Regional presence where latency to field devices matters, and elastic ingestion for event volume.
Cybersecurity
Partner and contractor access, device identity and revocation, and protecting tracking interfaces from enumeration.
Managed IT Services
Operating an estate with no maintenance window, where recurring incidents are removed rather than absorbed.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Kubernetes
Elastic event ingestion and services that must be released without an operational pause.
Flutter
Field and driver applications from one codebase, where offline capability and device breadth both matter.
Python
Event pipelines, provenance handling and the reconciliation between operational and billing data.
Databases
Event history and consignment state, where late and out-of-order arrival is the normal case rather than the exception.
AWS
Regional footprint and managed event services, which suit high-volume, geographically distributed ingestion.
Java
Where transport management and warehouse platforms are typically built and extended.
Delivery approach
How an engagement runs where the operation never pauses.
Free first consultation
Your operation, your partner landscape, and whether the constraint is visibility, integration or exception handling.
Assessment against the running estate
What is observed versus inferred, how partner feeds actually behave, and where exception handling absorbs capacity.
Operational constraint mapping
Connectivity realities, field device estate, and the absence of a maintenance window, recorded as hard inputs.
Target architecture and sequencing
Event model, partner adapter pattern and increments deployable without an operational pause.
Delivery with your teams
Your engineers implement while we review design and validate offline and reconnection behaviour in the field rather than in a lab.
Handover
Runbooks, partner onboarding documentation and decision records, so adding a partner does not need us.
Frequently asked questions
Usually it is a modelling problem. Status assembled from events published by parties of differing reliability, then flattened into a single value, is confidently wrong by construction. Distinguishing what you observed from what you inferred, with an age attached, resolves most of it without new data.
With one internal consignment and event model and per-partner adapters at the edge. Where each integration is built individually, onboarding is a project by construction. The adapter pattern also means a partner's format change affects one component rather than the core.
Yes, and designing for it is usually necessary. Partner capability is a range to accommodate rather than a standard to require — a design that assumes real-time interfaces excludes the partners who most need accommodating, and they rarely leave.
By making deployment independent of availability: services that can be replaced instance by instance, backward-compatible interfaces so field devices on older versions keep working, and a verified rollback. The constraint is real, but it is an argument for better deployment engineering rather than for less frequent change.
By treating it as a normal state rather than an error. Local-first design has the device hold its own state, operate without a connection and reconcile on reconnection. Software that requires connectivity to function fails continuously in the field regardless of how well it is written.
Classifying exceptions before automating them. Most operations find a small number of exception types account for the majority of manual effort, and those are frequently caused upstream — by a partner feed, a data quality rule or a process assumption — rather than being genuinely exceptional.
Approximately, and approximately is usually enough for the decision it supports. Precise cost requires charges that arrive after the movement, so the workable design is an operational estimate against a governed source, reconciled later — rather than waiting for precision that arrives too late to act on.
More than most organisations treat it. Location history is unusually revealing, and retaining it indefinitely because the telematics platform does by default is a poor position. The purpose and retention period should be stated explicitly and implemented in the system.
For operational decisions, near-real-time genuinely earns its cost. For reporting and billing it does not, and building everything for real time is an expensive way to answer questions asked weekly. We state the freshness requirement per use case rather than applying one standard.
They can on more tracking interfaces than you would expect, usually through enumerable reference numbers. It is a common finding and a cheap fix, but only if someone looks — which is part of why we assess the running system rather than the design documents.
We do not name clients or publish case studies in any sector. The first consultation works through the reasoning on your own operation, which is a better test of judgement than a reference list.
More than it appears to. Reference data drifts steadily when it is maintained in several places, and the result is movements that are valid in one system and rejected by the next. Mastering it is unglamorous work that removes a surprising share of daily exceptions.
Next step
Discuss a logistics estate
A free first consultation covering your operation, your partner landscape, and whether the constraint you are experiencing is visibility, integration or the volume of exceptions absorbing your team.
No cost, no obligation. Pricing is transparent and includes GST.