Past the Feature Checklist.

A two-person team had one week on-site and a specific goal: find out whether Looker could replace a cloud cost tool that had become too expensive to keep. Six months later, it had also replaced QlikView as the enterprise standard for all external-facing analytics.

That was not in scope. Here is how it happened.

THE PROBLEM

The head of enterprise architecture at a Fortune 15 healthcare company was managing two simultaneous mandates.

The first was BI consolidation. The company held an enterprise license agreement with Tableau and was in the process of consolidating several legacy tools onto it. MicroStrategy. QlikView. Business Objects. The question was whether Looker could fit into that architecture as a semantic layer, a BI layer, or both.

The second was cloud consolidation. The company had recently signed a major commitment with Google Cloud Platform and was migrating a multi-cloud environment across AWS, Azure, and GCP into one platform.

Running underneath both was a cost problem. When the company first moved to the cloud, they purchased Cloudability from Apptio, a cloud cost management tool that billed as a percentage of monitored spend. The model made sense early. Cloud spend was low, the tool was affordable, and it gave visibility across all three environments without significant lift. But spend had grown to roughly $6 million per month across all three clouds. A percentage-of-spend tool becomes a liability at that scale. Cloudability had been billing anywhere from $540K to over $2M per year.

WHAT WE FOUND

Most POCs are run on paper. A vendor submits to a requirements document. Someone builds a scoring matrix. The winning tool meets 80% of requirements. The runner-up meets 70%. A decision gets made. The real work is left for later.

The problem is that the requirements document is usually wrong. It captures what people think they need, not what is costing them.

We brought a different approach. Find a problem that is genuinely painful, cost-ineffective, and has clear gaps today. Evaluate tools against that problem hands-on. The feature comparison follows from the work, not the other way around.

Looker had recently published a reference architecture for cloud cost management on GCP. It gave us a natural POC target. Evaluate Looker as a semantic layer and BI tool through the Cloudability replacement. Not a demo. Not a sandbox. A real engagement with a real problem.

What made this possible was operating at two levels at the same time.

Both tracks ran in parallel. What we learned at each level shaped the other.

WHAT WE BUILT

We went on-site for one week. Two people: one strategic, one hands-on technical.

In that week, we reverse-engineered the specific reports Cloudability had built for AWS, GCP, and Azure and rebuilt them in Looker on Google BigQuery. That was the stated scope.

What came out of it went further.

We centralized AWS, Azure, and GCP billing logs into BigQuery. The team got ownership of their own data for the first time. We built a unified tagging model so machines and systems could be classified consistently across all three clouds.

Because everything now lived in one place, logic could cut across cloud boundaries. One example: identifying dev and staging machines running outside business hours or over weekends. Production systems run 24/7. Dev and staging systems should not. That gap had been invisible before. Now it was reportable.

We enforced aggregate and partition logic dynamically in the semantic layer, cutting total query cost for cloud cost operations by roughly 90%.

We tied cost centers directly to the VPs and directors who owned them. For the first time, executives could track spend against their own initiatives rather than reading reports built by someone else.

We also coached the executive team on how to package the engagement. The GCP migration commitment came with pre-negotiated spend numbers. By framing the Looker buildout and BigQuery centralization inside those committed dollars, the project bypassed discretionary budget conversations entirely. That kind of guidance only exists if you are in the room at the right level.

The cloud cost POC closed with a clear outcome. Cloudability was replaced with a Looker license scoped specifically to the cloud cost use case, priced at $180K annually. At $6 million per month across three clouds, Cloudability had been billing anywhere from $540K to over $2M per year. The savings compound in every subsequent year because a fixed license does not scale with cloud spend.

But the bigger outcome came next.

QlikView had been the company's external-facing analytics tool. A new initiative was on the table: building external analytics capabilities for a value-based care program in their oncology business. The question surfaced naturally. Could Looker serve this purpose too?

Value-based oncology care operates on episode logic. An episode has a target price set by the payer, and that target is based on a combination of factors: cancer type, stage, and comorbidities. A patient with lung cancer and diabetes is not the same episode as a patient with lung cancer alone. Each combination carries a different cost expectation, a different risk profile, and a different set of interventions that may or may not be authorized.

Cookie-cutter BI tools are not built for this kind of reporting. A standard dashboard can show you that episode costs are high. It cannot show you which patient profiles are driving that variance, why a specific comorbidity cluster is inflating 90-day costs, or how to adjust care protocols before the performance period closes. The oncology team had historically waited 12 to 18 months to see performance data from payers. By that point the episode is long closed.

We identified two technical champions who maintained the legacy QlikView infrastructure and ran working sessions with them using real data from their own environment. We focused on their actual pain points. Brittle embedded dashboards. A reporting layer that operated like a legacy system. No ability to express clinical and financial logic together in a way that was reusable or maintainable.

Looker's advantages here were specific.

Version control and GitHub integration meant the codebase could be maintained like software. A new comorbidity definition or revised episode cost formula could be tested, reviewed, and deployed without touching a fragile embedded report. API extensibility opened integration paths to EHR data, claims feeds, and third-party clinical sources that QlikView could not support. Custom visualizations could be built outside Looker and imported in, which meant a comorbidity risk profile could be displayed in a format that matched how a physician or care coordinator reads the information. HTML-based table customizations allowed bespoke clinical and financial outputs no standard dashboard could render. A custom front-end application could be prototyped quickly and composed into existing practice workflows rather than sitting as a separate reporting portal.

The semantic layer was the linchpin. Because Looker's logic layer sits between the data and the visualization, comorbidity groupings, episode cost calculations, and risk flags can be defined once and applied consistently across every report and every external-facing product built on top of them. That consistency is what makes value-based care reporting credible to payers. Cookie-cutter tools cannot provide it because they cannot separate logic from presentation.

For the technical champions, the story was about eliminating maintenance drag and building something that worked the way modern software teams work. For leadership, it was about team efficiency, long-term cost reduction, and the speed to publish externally.

OUTCOMES

The strategy, education, and reference architecture we produced became the foundation for a suite of analytics tools the company shipped publicly for community oncology practices. Physicians and administrators could see episode costs tracked in real time against target prices, patient risk profiles built from comorbidity and social determinants data, and clinical trial eligibility matched to their specific patient populations. Their internal teams built it. We produced the blueprint and proved the architecture would hold.

The company now holds two enterprise license agreements. Tableau for internal analytics. Looker as the enterprise standard for all external-facing use cases.

WHAT THIS MEANS FOR OTHERS

This engagement started as a vendor evaluation. It ended with an enterprise BI strategy, measurable cost savings, and the architecture behind a publicly shipped product.

None of it was in scope at the start.

The difference was not the technology. It was the approach. We find the problem that is costing someone, work on it hands-on, and operate at the strategic and operator level at the same time. Those two vantage points surface things that neither one can see alone.

The feature checklist tells you which tool wins on paper. It does not tell you what to build.