RTDP — Making a transport data pipeline operable

The Real-time Transport Data Portal sits between organisations that hold transport data and the systems that consume it. It brings datasets in, transforms them, checks their quality, and publishes them through consistent interfaces.

The frontend had two distinct jobs: Data Exchange, where external organisations configure data sources, source feeds, transformations and quality rules; and Control Centre, the internal portal for organisation administration and availability monitoring.

Transport standards are built for interoperability, not for pleasant editing. In one early design, the canonical model closely followed DATEX II, the European standard used to exchange road-traffic data. A relatively simple transformation expanded into more than a thousand lines of standards-shaped JSON. The platform could process it, but that did not make it a reasonable interface for a data owner.

The frontend question was simple: were people configuring their transport data, or were we asking them to learn the exchange standard underneath it?

My position was that standards-specific complexity belonged in backend adapters. The user-facing model needed to be smaller, neutral, and explained in the language of the task. Validation needed to say what was missing in the data, not recite a schema failure.

That discussion captures how I tend to work. I do not treat backend structures as inevitable UI. I look for the boundary where technical completeness stops helping the person at the screen.

The Source Feed Version page became the centre of the publishing workflow. A version was not just a database record. It gathered configuration assets, draft and published state, test activity, and the actions that could move the work forward.

I organised the page around three operator questions:

I separated metadata, the pipeline view, configuration assets, activity, quick actions, and test status into readable sections. Detail drawers let operators inspect a connected item without losing the version they were working on. Draft creation followed the real constraint of one active draft per source feed.

None of those choices was dramatic. Together, they changed the page from a collection of records into a place where an operator could understand the state of the work.

Testing a source-feed version was a long-running operation. A spinner could say that something was happening, but not what had run, what had passed, or where attention was needed.

I designed and implemented a step-based test runner that exposed the pipeline stage by stage. Running, passed, and failed states stayed visible as the test progressed, and the result sat beside the configuration being reviewed rather than in a separate technical tool.

Data Exchange and Control Centre had different users, permissions, and operational risks. I kept them independently deployable, but built them from one frontend workspace so the parts that should feel familiar did not drift.

By the end of the project, RTDP had a more structured operational experience for versioned configuration and pre-publication testing. Shared administration patterns, generated contracts, and documented conventions gave the two applications a common engineering language.

I cannot reduce that work to a neat performance percentage, and I would rather not manufacture one. The evidence is in the shape of the system: clearer workflow state, reusable foundations, broader test coverage, and documentation that another engineer could use without first loading the whole project into their head.