Every organisation that has tried to become data-driven knows the scene. Business units raise tickets, a central data team works through them in order, and the backlog grows faster than anyone can clear it. Speaking at the Big Data and Business Analytics Conference 2026 in Sandton, Rofhiwa Tumelo Nengovhela, Group Head: Data Engineering, Architecture and Management at Netcare, argued that this is not a tooling failure. It is, in his words, an organisational problem wearing a technology costume.
His keynote, Data Mesh and Domain-Oriented Architectures, offered delegates a practical account of how large enterprises can move from a single queue to many accountable owners, and of where that journey tends to go wrong.
The central bottleneck
Nengovhela opened with a familiar picture. On one side sit the producers of data: in a healthcare setting, admissions, pharmacy, radiology, finance and human resources. On the other sit the consumers: dashboards, machine learning models, regulatory submissions and operational reports. In between sits a central data team, translating someone else’s business second-hand, through tickets, with a backlog measured in quarters.
The symptoms are predictable. Pipelines are built by engineers who have never met the source system’s owner. Data quality is patched in the warehouse, only to break again upstream with the next release. Most damaging of all, the business stops waiting and builds its own spreadsheets, creating competing versions of the truth. Drawing on Conway’s Law, Nengovhela observed that organisations inevitably ship their org chart, and that data mesh simply admits it.
Four principles, one system
The heart of the session examined the four principles of data mesh first set out by Zhamak Dehghani. The first is domain ownership: the team that creates the data serves the data. The second is treating data as a product, with real consumers, contracts and service level objectives rather than a collection of tables. The third is federated governance, in which global rules are defined centrally while local decisions remain with domains, and policies are expressed as code. The fourth is a self-serve platform of paved roads, so domains do not rebuild their own plumbing.
Nengovhela was emphatic that these principles only work as a set. Adopt ownership and product thinking without governance and a platform, and the result is ten domains running ten incompatible stacks. Adopt the platform and governance without genuine ownership, and the organisation has merely rebranded its warehouse.
He also gave the idea of a data product a hard edge. A product, he said, must be discoverable, addressable, trustworthy and self-describing, and each property must be measured: search-to-use time, breaking changes, SLO attainment and time to first query. If it cannot be measured, it is not a product.
Making it real
Using an illustrative healthcare example, Nengovhela showed how ownership follows the source. Admissions owns the patient episode. Pharmacy owns the dispensing event. Finance consumes both but owns neither; however, because Finance creates cost per episode, that becomes Finance’s own product. The platform team builds the shared roads of storage, cataloguing, lineage and access, while domains drive and are paged when something breaks.
You do not install a mesh, he told delegates; you grow one. Start with a single domain that has real pain, a willing owner and consumers who will complain loudly. Ship one product end to end, with a contract and an SLO, before any platform work begins. Then extract the platform, automating only what the second and third domains repeated by hand.
His indicative roadmap ran over eighteen months rather than six: a pilot at month zero, first products with contracts by month three, a first platform version by month six, policy as code by month twelve, and federation, where domains onboard themselves, from month eighteen onwards. Anyone promising a mesh in six months, he cautioned, is probably selling a rename.
Where it breaks
The most valuable part of the keynote may have been its honesty about failure. Nengovhela described four common failure modes on two sides of a spectrum. Programmes that decentralise too far end up with a mesh without a platform, or hand domains ownership of data without the engineers to run it. Programmes that do not decentralise enough simply rename the central team as the platform team, keeping the same backlog, or practise governance by committee, with policies written in PDFs, approved monthly and enforced never.
He was equally clear that data mesh is not for everyone. The approach pays off when five or more domains depend on each other’s data. Below that threshold, a strong central team still wins.
Three questions for Monday
Nengovhela closed by leaving delegates with three questions to take back to their organisations. Which domain would own its data tomorrow, if you let it? What would your central team stop building? Which policy could run as code this quarter?
It was a fitting close to a session that traded hype for hard-won practicality, and set a thoughtful tone for the conference.
