MENTARA
Book a call
Software Services

The platform was never the problem.

Most data programmes deliver a working platform and an unchanged decision process. MENTARA works backwards from the decisions the data should improve.

Discuss a data priority Read the detail

More in Software Services

The decision in front of you

A striking number of data programmes complete successfully and change nothing. The warehouse is built, the pipelines run, the dashboards exist — and the decisions the investment was justified by are still made the same way, from the same spreadsheets, by people who do not trust the new numbers.

This is not a technology failure. Modern data platforms work. It is that the programme was scoped as a platform build rather than as a change to how specific decisions get made, and those are different pieces of work with different success conditions.

The failure mode

Nobody distrusts a dashboard for technical reasons.

When a business team keeps using their own spreadsheet after a reporting platform ships, the stated reason is usually that the numbers are wrong. Investigated, the numbers are typically not wrong — they are defined differently. Somebody chose a definition of active customer or recognised revenue or open incident that is defensible and is not the one the business team has used for years, and nobody reconciled the two or told anyone it had changed.

That is a governance and ownership problem wearing a technical costume, and it is fatal, because trust in a data product is lost quickly and regained slowly. Once a team has found one number they believe is wrong, they revert to their own source and the platform becomes an expensive parallel system.

The second failure is ownership. Data products get built by a central team and handed to nobody. When source systems change — and they change constantly — the pipeline breaks or, worse, silently degrades, and the first person to notice is a business user who now trusts the platform less. Data quality is not a one-off remediation project; it is an ownership model, and if no name is attached to a dataset it will decay regardless of the tooling around it.

Capability

What MENTARA does.

01Data strategy and architectureTarget architecture driven by the decisions and workloads it has to serve, with an explicit position on what is centralised, what is federated and who owns each.
02Data engineeringPipelines built to be operated — tested, monitored, documented, with lineage and defined behaviour on upstream change rather than silent failure.
03Cloud data platformsWarehouse and lakehouse implementation sized to the actual workload. We will recommend the simpler architecture where it is sufficient, which it often is.
04Governance, definitions and qualityMetric definitions agreed and owned, quality expectations expressed as tests that run, and stewardship attached to named people rather than to a committee.
05Business intelligenceReporting designed around specific decisions and their cadence, with far fewer dashboards than most organisations have and much clearer ownership of each.
06Advanced analyticsForecasting, segmentation and optimisation work where the decision it feeds is identified in advance and someone has committed to act on the output.
Approach

How the work runs.

  1. 01 Start from the decision

    Which decisions should change, who makes them, on what cadence, and what evidence would change them. Everything downstream is scoped by this, and some proposed work does not survive it.

  2. 02 Agree definitions before pipelines

    Reconcile competing definitions of the handful of metrics that matter, with a named owner for each. Doing this after the build is what causes the trust failure.

  3. 03 Build thin and vertical

    One decision, end to end — source to consumption — in production and in use, before widening. A complete narrow slice surfaces integration and quality problems that a broad foundation layer hides.

  4. 04 Transfer ownership deliberately

    Every dataset and product has a named owner, a quality expectation and a runbook before we leave. Unowned data assets decay, and the decay is invisible until trust is already gone.

Starting points

Where engagements usually begin.

01Data platform assessmentWhy an existing platform is not being used, and what would concretely change that — usually definitions, ownership and trust rather than architecture.
02Metric definition reconciliationThe competing definitions of your core measures, reconciled and owned. Unglamorous, fast, and frequently the highest-value work available.
03One decision, end to endA single vertical slice from source to decision, in production, as proof the pattern works before committing to the wider build.
04Pipeline reliability reviewWhy data arrives late, incomplete or silently wrong, and the monitoring and ownership model that stops it.
Questions

What buyers ask.

Which platform do you recommend?

It depends on workload, existing estate, team capability and data residency — and for a large share of organisations the honest answer is that the platform choice matters far less than the definition and ownership work, which is where the programme will actually succeed or fail.

We hold no reseller or partner arrangement with any data platform vendor, so the recommendation carries no commission.

Do we need a lakehouse?

Frequently not. A substantial proportion of organisations describing a lakehouse requirement have a reporting problem, a definitions problem and a modest data volume, and would be better served by a well-modelled warehouse they can actually operate.

We would rather tell you that than build the more expensive thing.

Can you work with our existing platform?

Yes, and that is the more common engagement. Most of our data work is on estates that already exist and are underperforming, not greenfield builds.

How do you handle data protection across regions?

Residency, transfer basis, retention and access are established in scoping before any access is granted — including which jurisdictions the data subjects sit in and who is controller versus processor for each dataset. Our full position is on the trust and security page.

07

Where MENTARA fits best.

Scope

We fit where the constraint is judgement — deciding what to build, what to stop, how definitions get agreed and who owns what afterwards — rather than the volume of hands required to build it.

If you need a very large multi-year platform migration executed at scale across dozens of source systems simultaneously, that is a headcount problem and a large integrator will serve it better.

Where this connects

Bring the decision your data is supposed to improve.

Share the business context, constraints and expected outcome. MENTARA will identify the relevant accountable route.

Submit your requirement

One partner. One plan. Measurable outcomes.