Deepak Kumar Jha
DT Access 4.0 — Interface engineering inside a 300-person carrier-grade programme
Radisys Technology · Oct 2021 – Apr 2024 · Full role details →
The Problem
DT Access 4.0 is Deutsche Telekom’s carrier-grade network operations platform — the tooling network engineers use to manage and monitor telecom infrastructure. A defect in an operations interface for a carrier isn’t a UX inconvenience; it is a path to a technician making the wrong call against live network equipment, so the interface layer had to be built to a different reliability bar than a typical enterprise front end.
Constraints
- Part of a 300-person global programme — decisions at the interface layer had to interoperate with teams and services this role did not directly control.
- Carrier-grade reliability expectations: network operations tooling cannot silently show stale or wrong state to the engineer using it.
- An 8–10 engineer team scoped specifically to interface engineering within the larger programme, not the full platform.
Architecture
Interface engineering here meant owning the layer between the operator and the underlying orchestration platform — the surface where correctness and clarity mattered most:
React front end
The operator-facing console for network engineers — status views, controls and alerts.
Node.js services
The interface layer’s own backend, brokering between the front end and the platform’s orchestration and data services.
Kubernetes
Deployment and scaling for the interface services, consistent with how the larger 300-person programme ran its own components.
PostgreSQL
Durable state for the interface layer where the orchestration platform itself was not the source of truth.
Key Decisions & Trade-offs
Treat interface state as something that can lie, and design against that
A console for live network infrastructure is more dangerous when it looks correct and isn’t than when it visibly fails. I prioritised making stale or uncertain state visible in the UI over always showing the most optimistic value — a design choice that costs some perceived polish in exchange for engineers never acting on data the system itself wasn’t confident in.
Scope the team to interface engineering deliberately, and hold that boundary
Inside a 300-person program it is easy for an 8–10 person team to drift into owning adjacent platform concerns because nobody else has picked them up yet. Holding the interface-engineering boundary kept the team’s surface area matched to its size, at the cost of more explicit coordination with the teams on either side of that boundary.
Extend the IoT data-pipeline work into the same reliability discipline
The Smart Home IoT pipelines processing concurrent event streams from cameras, gateways and geofencing devices sat alongside the interface work and were held to the same standard: an event pipeline that silently drops or reorders events under load is a worse failure than one that visibly backs up.
Outcome
- Led interface engineering for DT Access 4.0 within Radisys’s Deutsche Telekom partnership, managing 8–10 engineers inside a 300-person global programme.
- Engineered high-throughput IoT data pipelines for Smart Home applications handling concurrent event streams from security cameras, gateways and geofencing devices.
- Established engineering standards and mentored the team on best practices, code quality and architecture patterns.
What I'd Do Differently At Greater Scale
At greater scale, the coordination cost of holding a strict interface-engineering boundary inside a 300-person programme grows faster than the team does; I’d push earlier for a formal contract (schema and SLA) between the interface layer and the platform teams on either side, rather than relying on the standards this team set informally holding up as more teams touch the same surface.