Looker.

Where Looker fits on a long engagement.

The modelling layer is the whole point. In most BI tools every dashboard carries its own logic, so two reports disagree and nobody can say which is right. In Looker the definition lives in one reviewed place, and a change propagates rather than fragments.

That discipline is also the cost. LookML has to be maintained by someone comfortable with code review, and an organisation that wants analysts dragging fields around without governance will find it heavier than the alternatives. It suits organisations that have already been burned by conflicting numbers.

What an assigned team does with Looker.

A modelling layer is only worth its overhead if it is maintained with review discipline. LookML edited by whoever is nearest, without review, becomes the same sprawl it was adopted to prevent — just in a more expensive tool.

The model and the warehouse beneath it are one problem, so they are normally one assignment, scoped under data engineering outsourcing rather than split between a BI contractor and a data team.

What we use Looker for.

• Ending the metric argument One reviewed definition of each measure, so meetings stop being about whose number is correct.
• Self-service with guardrails Business users exploring within a model that prevents nonsensical joins.
• Maintaining an inherited LookML project A model that has grown unowned brought back to a state someone can safely change.

How Looker capacity is assigned.

Analytics engineering is assigned under managed data services, since the model and the warehouse beneath it are one problem. Every assigned specialist comes through the Talent Success and Academy programme first.