The Existing Assets Pattern

The most expensive sentence in enterprise data is "we need a new platform."

It sounds reasonable every time someone says it. The current systems are slow. The data is siloed. The business can't get answers. A new platform will fix everything — modern architecture, faster queries, better integration, happier users.

I've sat in dozens of these meetings. The diagnosis is usually correct. The prescription is almost always wrong. Not because the new platform is bad technology. But because the problem was never the platform.

Here's how it typically unfolds. A commercial leader complains they can't get data they need. IT investigates and identifies limitations in the current environment. A vendor appears with a compelling demo. The business case gets written around the new platform — migration timeline, licensing costs, implementation resources. Eighteen months and several million dollars later, the organization has a new platform running the same disconnected data with the same undefined business rules and the same frustrated users.

The platform changed. Nothing else did.

I've watched this cycle repeat for twenty years. The organizations that break out of it do something counterintuitive. They stop buying and start connecting.

A Pacific-focused carrier brought us in because three SVPs — marketing, sales and commercial — were each using a different source for revenue. And not just three versions — three different databases. Same airline. Three answers to the same question. Sound familiar? That was yesterday's pattern — the shared definitions problem.

But here's where this story diverges. The conventional response would have been a new enterprise data platform. A twelve-to-eighteen month selection and implementation cycle. Instead, we built a unified commercial data layer on their existing, outdated SQL Server 2012 infrastructure.

In just 90 days, we had booking and ticketing data in a unified model — granular, joinable and historicized. Not because we liked SQL Server. Because it was what they had.

Then the world shut down. Planes grounded. Capital budgets slashed to near zero. The original business case went right out the window.

But that 90-day old unified view was one of only five capital projects approved to continue while the airline's fleet sat idle. Not because the ROI still penciled out. Because all three SVPs could see they couldn't do their jobs in the new world without it. Schedule change analysis. Outstanding liabilities. The questions that mattered during a crisis all ran through the data layer we'd built in three months on infrastructure nobody in IT considered usable.

18 months later, they eventually migrated to the columnar DBMS of the day. IT rewrote the ingestion, rebuilt the ETL. But the data model — the one built that first year on a SQL Server that was supposed to be temporary — the business wouldn't let them change it. That model, built quickly on existing infrastructure — not the platform — became the foundation.

Another carrier had a different version of the same instinct. Operations leadership needed better fuel efficiency data. The conventional path: buy a fuel optimization product. A vendor with a dashboard and a subscription.

Instead, we connected what they already had. ACARS data from the aircraft. Flight planning data from dispatch. Their operations system of record — where delay definitions, manual corrections and other business rules lived. Three existing systems that had never been joined together.

No new platform. No new vendor. Just connections and a data layer that made the information usable.

The integrated operations data layer went into production and the fuel efficiency team built their first analytics initiative on top of it. The first initiative alone generated over $10M in annual fuel savings. Project payback: six days.

Not six months. Six days. The transformation became a rocket ship after that.

Same carrier, different problem. Their enterprise data warehouse was running slow and running out of space. The technology team's recommendation: bigger hardware. More capacity. New enterprise ETL tool in the cloud. Instead, we optimized what was there — recovered 25% of their data warehouse space that was full of data but idle to the business. We reduced query times by 79%. No new hardware required. The freed capacity enabled new commercial data capabilities that the business had been waiting years for.

These aren't lucky outcomes. They follow a methodology.

Crawl: deliver something useful with the systems and tools you have today. Don't wait for the ideal architecture. Build a working version that proves the concept and generates immediate business value. This is not a proof of concept that sits in a sandbox. This is a production deliverable that people use.

Walk: use what you learned to improve it. The first version will have rough edges. Some of it will be held together with duct tape. That's fine — it's strategic duct tape. The business value it generates funds the improvements. And the working prototype becomes the best requirements document your technology team has ever received, because it's not a slide deck describing what the business wants. It's a functioning system demonstrating it.

Run: build the permanent solution informed by everything you learned in the first two phases. By now you've validated the data model, the business rules, the user workflows and the ROI. You're not guessing about requirements. You're codifying what's already working. And if scaling that requires new tech, you have a CFO-ready case with real results, not a projection.

The critical insight: the crawl phase isn't a compromise. It's a strategy. A working prototype built on existing systems in six weeks teaches you more about what the business actually needs than six months of requirements gathering ever will. And it generates revenue — or saves costs — from day one.

Most organizations try to skip to run. They want the permanent, scalable, enterprise-grade solution from the start. That instinct adds months to the timeline, millions to the budget and risk to the outcome. And it means the business waits the entire time without any value.

That one carrier's SQL Server environment wasn't anyone's idea of a strategic asset. It was aging infrastructure on the replacement list. But the data model built on top of it — the one that proved its value in three months, didn't just survive a pandemic, it went on to survive a PSS migration and a merger. More than survive, it underpinned every major commercial decision the carrier made from first delivery forward. Different platforms. Different PSSes. Same logic. Same definitions. Same trusted answers.

The platform is a commodity. The understanding of how your business works is not.

The kitchen is in maintenance mode. School year coming to an end means concerts, field trips, teacher gifts and a calendar that looks like a Tetris game. Creative cooking is on hold. We're just trying to finish the race.

—

Kicked off a new engagement this week. Always humbling. Always exciting. You arrive with frameworks and methodology, twenty years of pattern recognition, a working hypothesis about where the value is. By the end of the week, all of that is provisional and you’re ready to pivot. The trick is this: take your own advice, stay focused on the business, not the tech. The organization knows what needs to happen. Help them ask the questions they’ve stopped asking themselves.

Finishing the race in the kitchen. Staying focused on outcomes with what's already there. Most weeks, that's the whole job.

Next week: The Business Ownership Pattern—why the teams closest to the commercial question should own the data that answers it.

—Ben