Tom De Wolf's Data Product Platform Navigator gives data-platform teams a way to examine why shared tooling can remain difficult to use even after provisioning is automated. Published on November 5, 2026, the framework applies CNCF's platform-engineering maturity model to data mesh, where domain teams take responsibility for reusable data products.
The original article on martinfowler.com is by De Wolf, rather than the site's host. Its new contribution is the data-product interpretation of an existing model: CNCF's version record dates the model's first version to October 2023.
The work left between automated components
De Wolf describes an operational platform in which repositories, pipelines, storage and processing can be provisioned separately, while developers still have to connect them. His scalable level shifts the interface toward declaring a data product and having the platform integrate the underlying resources. He argues that this level is the minimum needed for a successful data mesh.
That is a practitioner argument, not a measured adoption result. Its useful implication is to examine the whole developer task. Consider a hypothetical team that can create storage automatically but still needs help connecting permissions and a pipeline. Counting the completed provisioning action would miss the remaining integration work.
Assess each capability before choosing the next investment
The CNCF model considers investment, adoption, interfaces, operations and measurement separately. It explicitly warns against giving an entire organisation one maturity level, and says the highest level should not be an objective in itself because it requires more funding and time.
That qualification matters when using the Navigator. A polished portal does not establish that its users can complete their work, while a modest interface may address an immediate need. The assessment should identify a concrete obstacle rather than become a reason to rebuild every component.
TechKili's suggested starting exercise is to follow one data product from request to usable output and record where its owner needs another team. Choose one repeated handoff to improve, then check whether the owner can complete the same task with less assistance. This is an evaluation proposal, not an outcome demonstrated by the essay.
The framework is most useful as a shared way to decide what to improve and why. The evidence for an organisation's next step still has to come from its own users and workflow.
Sources
Related Articles
White House proxy report identifies network exits, with device and impact unresolved
Layer3 reports 236 proxy exits through six public addresses. The observations warrant investigation but do not identify an endpoint or demonstrate internal access.
French blood-storage cyberattack puts monitoring and continuity in focus
EFS protected blood products after refrigeration settings were altered. A new US fact sheet gives operators a concrete basis for reviewing access and continuity.
Teams helpdesk impersonation led to AD CS abuse in two Microsoft cases
Microsoft's October case study follows fake support contacts into privileged certificate access. Recovery has to consider issued certificates and sessions alongside the first device.
Discord plans to replace Electron with a Rust client
A November 4 statement confirms a client rewrite. The useful test will be Discord's behaviour during calls, screen sharing and long sessions, rather than the programming language alone.