The Independence Pattern

Over the last four weeks we've covered four patterns. System design. Shared definitions. Existing assets. Business ownership.

Each one matters on its own. But the fifth is what makes the other four more than the sum of their parts—and what separates organizations that improve from organizations that become genuinely hard to disrupt.

The Independence Pattern is about who owns the logic, the definitions, the rules and the services that connect your data to every decision, every channel and every system in your commercial operation. Not the platform it runs on. Not the vendor that hosts it. The data.

Nobody sets out to become dependent on a vendor. It happens gradually.

A PSS vendor offers an analytics add-on. Bundled into the contract, maybe it's even "free." It connects to their system natively, so it's fast. Maybe they call it a "Hub"—who doesn't love a hub? They call it "event-based," so we know it's modern. The business is going to get answers and IT doesn't have to build anything. Everyone wins.

Then a merchandising system arrives from a different vendor. It doesn't connect to the "Hub." Another integration, point-to-point, tightly coupled to both systems—it works, but only in this exact configuration. Then the marketing platform. Another connection, another set of rules, another place data gets lost.

Five years later you have eight systems and dozens of integrations. Every vendor touchpoint has its own version of who the customer is, what an "order" is and how revenue gets counted. You know you need to combine and realign. But changing any one system means renegotiating every connection that touches it.

Here's the part that's easy to miss: those point-to-point connections don't just create complexity. They create control. Your data flows through vendor infrastructure. Your commercial intelligence lives inside their platform. The "insights" they sell you exist because you can't get to your own data without them.

That's not a technology problem. It's an architecture that let vendors—not your organization—define how your data flows, where it lives and who uses it.

Everything in this series so far has pointed at data at rest—the analytical layer. Trusted definitions. Versioned history. Fit-for-purpose views. A layer where the business rules—what constitutes an OD, how revenue is recognized, what a customer segment means—are codified once, governed by your team and served everywhere they're needed.

But independence requires a second layer: data in motion.

Get availability. Commit booking. Authorize payment. Get seat map. Assign seat. Price first bag. These are common services. They work the same whether they're called by your website, your mobile app, an agent desktop, an NDC distributor or an AI assistant. The system underneath might be Sabre or Amadeus or something built in-house—the services layer doesn't care. It translates between what the business needs and what the systems provide.

Just like your data model is a common unified view of what your business looks like, the services layer is a common unified view of how your business runs.

Own both and the analytical layer gives you the understanding while the services layer gives you the agility. Together they give you independence—because if your commercial data already flows through a services layer you own, you can capture and serve all of it, where you want and to whom you want. The analytics, the optimization, the AI become capabilities you choose and plug in, not tolls you pay to reach your own information.

A few years ago we built a common services layer for a startup carrier—not a data warehouse, the services architecture itself. The carrier needed to get off the internet booking engine they were running because it was limiting ancillary and bundling capabilities and blocking international expansion due to long lead times to add payment gateways. The IBE was wired to its PSS, and the carrier wanted to get off the IBE but not the PSS.

Rather than plug in another IBE, they chose to own their services layer and build their own digital experiences on top of it. We licensed that turnkey layer—libraries of operational data models and APIs. This wasn't a consulting engagement. This was a product. Portable across platforms, usable in any ecosystem, valuable because it didn't just deliver integration, it delivered independence.

It became the start of a completely composable commercial stack—DCS next, then a new payment gateway, then an IRROPs platform—each one easier than the last to deploy, because none of them had to be integrated with the others. Snap in and snap out. No 18-month integration project, no expensive SI to run it.

When AI agents are the interface—shopping, booking, servicing—they need pricing, availability, customer and order state to get the right answer. And the same services your app calls today are the APIs a partner's AI agent calls tomorrow and a consumer's AI chat calls next year. If your data is unified and flows through a services layer you own, you're ready. If it's locked inside vendor platforms behind point-to-point integrations, you're not just behind on AI—you're behind on the architecture of how commerce will work.

Content used to be king in this business. Today it only gets you to the table. Context is the data + services that put you in control. The carrier that serves its own context—state, status, entitlements, history—through its own services keeps control and grows in value. The one that outsourced all of it shrinks to simple fulfillment.

We've been here before. Airlines ceded shopping relevance to OTAs—not because the content wasn't theirs, but because they couldn't orchestrate shopping on their own data as well as an OTA could using a GDS. NDC was supposed to fix that. Instead most carriers shifted from one landlord to another, outsourcing NDC to platforms that now control the connection. The vocabulary changed. The dependency didn't.

For the mid-size challengers squeezed between the majors and well-funded new entrants, this isn't aspiration—it's survival: every migration should leave you more portable than the last. The organizations that don't own their data and services get defined by someone who does.

I'm headed to the west coast. Which means gourmet coffee, fresh sushi and red eyes. The red eye is underrated—cabin dark, nobody texting over the satellite wifi, nothing in the queue. A fair amount of this series got written at 38,000 feet.

Platforms change. Vendors change. What you own is what's left when they do.

Thanks for reading—see you next week for more patterns from inside the rooms where we make data work for people.

—Ben