The Operating Model
Doesn't Determine
the Data Model

Three executives.
One architecture.

That was Ian Di Tullio, chief commercial officer of Minor Hotels, quoted by Morgan Hines in PhocusWire in June. He was part of a substantive tech-stack conversation involving Choice, Minor, and Ascott - three enterprise chains articulating remarkably similar architectural commitments. Fragmentation is the constraint. Adding another layer is not the fix. The answer is a unified data layer that everything else connects to.

If you've been reading anything I've written about hospitality data infrastructure, you'll recognise the vocabulary. Substrate rather than application. Canonical model. Single source of truth. Integration and orchestration layer beneath the AI interface. What Di Tullio, Doug Lange at Choice, and Tan Bee Leng at Ascott were describing is, structurally, the same architecture I've been arguing hotel groups at the ten-to-a-hundred property scale need too. Enterprise chains are building it. The article was, for anyone building in this category, an unusually clean piece of public validation.

Di Tullio's remark about the operating model, though, is the specific thing worth engaging with. It's an argument that if left unanswered would exclude most of the market I write for from the category of groups that can plausibly build canonical hospitality data. And the argument is wrong - not in a small technical way, but in a fundamental one about what enforcement actually is.

Two mechanisms
of enforcement

The core of Di Tullio's claim is that data unification requires enforcement, and enforcement requires operational control. In the Minor context, this makes sense. Minor owns or leases the majority of its properties. When Minor's chief commercial officer decides that a guest profile will have a specific canonical shape, the operating environment can be told to comply, and it will comply, because the reporting lines run through Minor's own management. The organisational hierarchy is the enforcement mechanism. The memo works because the operating company can back it up with an operating decision.

For a group whose portfolio includes independent operators, franchise partners, managed properties under third-party contracts, and joint ventures with regional partners, the memo does not work the same way. The reporting lines don't converge. The operational levers aren't uniform. A group HQ can request a canonical guest profile from a franchisee; it cannot mandate it in the same architectural sense.

Di Tullio is right that this is a real problem. He's wrong that operational control is the only mechanism that solves it.

Enforcement of a canonical data model has two possible mechanisms. One is organisational - the operating structure requires compliance, and the org chart is the fabric through which that requirement propagates. The other is architectural - the platform itself refuses to allow non-canonical data, because the software that everyone reads from and writes to only understands the canonical shape. Minor's approach is the first. What I've been arguing hotel groups at the ten-to-a-hundred property scale need is the second. Both are legitimate mechanisms. They produce the same outcome - a group where every consumer reads the same answer to the same question - through structurally different paths.

The interesting empirical point is that architectural enforcement is not merely a substitute for the organisational kind. In some ways it's stronger.

Why organisational
enforcement decays

Consider what happens to organisational enforcement over time.

Ownership models change. A group acquires a competitor whose properties operate under a different management structure. A group sells off a regional portfolio and takes back the brand rights under a franchise arrangement. A joint venture with a local partner ends and the properties transition to managed contracts. Each transition breaks a piece of the enforcement fabric. The canonical model that was mandated across the owned portfolio suddenly has to be re-mandated across a portfolio that no longer looks like the one the mandate was designed for.

Management changes. The CIO who defined the canonical guest profile leaves. The regional VP who understood why a specific segment definition was chosen retires. The general manager who trained her team on the group's ADR methodology is replaced by someone brought in from a competitor. The organisational memory that made the enforcement mechanism work erodes.

Standards revisions happen. The definition of net ADR after distribution has to change because the group's contract with an OTA shifts from commissionable to merchant model. The commercial team argues for including a new distribution channel in the calculation. The revenue management vendor deploys a new algorithm that requires a different segmentation. Each of these decisions has to propagate through the organisational hierarchy, and each propagation is another opportunity for the enforcement to decay or the transition to be handled inconsistently.

I've written about a specific version of this in a previous piece. Marriott - which by any reasonable measure is the most standardised, most integrated, most operationally-controlled hotel company in the world - changed its rebate accounting methodology one year. The change was clean going forward and silently incoherent looking backward. Historical numbers were computed under the old methodology; new numbers under the new. My regional VP at the time asked for a percentage increase in segment ADRs the following year, not knowing that the ADRs she was looking at had been computed under a different definition than the historical comparison she was anchoring on. She was not being unreasonable. She was using the discipline she had used for years. The organisational enforcement mechanism - global standards, internal audit, operations manuals - had failed to surface a change that materially affected her decision.

If this happens at Marriott, it happens at Minor. It happens at Choice. It happens at Ascott. It happens at every operationally-controlled hotel company that relies on the organisation to be the enforcement fabric, because organisations are made of people and people are made of turnover, incomplete knowledge transfer, and reasonable assumptions that are silently invalidated.

Architectural enforcement doesn't have this problem in the same way. The platform holds the canonical definition as a versioned object. When the definition changes, the change is recorded. Year-over-year comparisons across the change either refuse to run or return with the change flagged. The regional VP asking for a percentage increase would have been told, by the platform, that the metric she was anchoring on had shifted methodology in the intervening period. The platform doesn't need to remember; it's the memory.

What architectural enforcement
looks like

The concrete shape of architectural enforcement is what makes the argument for it. It's not an abstract commitment; it's a specific set of engineering moves that collectively produce a canonical data layer any hotel group can operate, regardless of ownership model.

The canonical model is opinionated. It defines what a stay is, what a folio is, what a channel is, what a guest is, in the terms every hotel group needs. It does not adapt to each group's idiosyncrasies. It provides the shape that idiosyncrasies map into. This is opinionated substrate work; it is done once, by the platform provider, and reused across every group that runs the platform.

The adapters translate. Every source system that the group runs - Cloudbeds, Mews, Opera, SiteMinder, D-EDGE, whatever the actual stack looks like - has a dedicated adapter that maps its native data structures to the canonical model. When a franchise partner uses one PMS and a managed property uses another, both write to the canonical model through their respective adapters. The group HQ doesn't have to mandate that the two properties use the same system; it has to run a platform whose adapters normalise both into the same canonical representation.

The semantic layer is the enforcer. Every metric - RevPAR, ADR, net ADR after distribution, occupancy, channel contribution - is computed by the platform, not by each consumer. The dashboard doesn't implement RevPAR; it asks the platform for RevPAR. The revenue management vendor's report reconciles against the canonical value; it doesn't compete with it. The BI tool visualises the canonical answer; it doesn't compute its own. When any consumer needs a number, the number comes from one place, and that one place is code, not memo.

The consumer contract is thin. Applications sit above the canonical layer and read from it through a stable interface. When a new application arrives - a new revenue management vendor, a new marketing automation tool, a new AI-powered guest experience layer - it plugs into the canonical layer through the same interface. It doesn't build its own version of the group's data. It uses the version the platform holds.

This is what makes architectural enforcement work across ownership models. The franchise partner doesn't have to accept a mandate from group HQ about data structure. The franchise partner runs its own PMS in its own way. The platform's adapter for that PMS translates its data into the canonical model. Group HQ reads the canonical model. The enforcement lives in the platform, not in the reporting line.

Who this argument
is actually for

Enterprise chains have a legitimate path to canonical data through organisational control. Minor is one. Choice is another. Ascott is a third. These groups have the balance sheets to run data engineering teams of dozens, the operational control to enforce standards across their portfolios, and the scale to amortise the internal build over enough properties to make the economics work.

Below that scale - and this is a big region of the industry - the story is different. Independent and regional groups typically operate mixed portfolios: some owned, some leased, some managed under contract, some franchised. Ownership diversity is not a bug in these groups; it's how they grew, how they entered markets, how they partnered with local operators, how they moved risk off the balance sheet during downturns. Requiring operational control as the precondition for canonical data effectively excludes them from the category.

For these groups, architectural enforcement is not a compromise. It's the only mechanism that scales. The platform holds the canonical model. The adapters normalise every source system, regardless of who owns the property that runs it. The semantic layer produces the canonical metric every consumer reads from. The independent group achieves the same outcome as Minor achieves through operational control, through a completely different structural path.

This matters commercially, not just architecturally. If you run technology at a regional hotel group with a mixed portfolio, the message you've been receiving from the enterprise chain conversation is that canonical data is coming, that it's transformational, and that it's only accessible to organisations that look like Marriott. That message is wrong on the last point, and getting it right is the difference between believing the future belongs to someone else and understanding that a different path exists.

This is what we are building
at Studio Oriente

Meridian is hospitality data infrastructure for exactly this audience: independent and regional hotel groups at the 10-100 property scale, with mixed portfolios where owned, leased, managed, and franchised properties coexist. The canonical model is hospitality-shaped and opinionated. The semantic layer is encoded once and enforced by the platform. The adapters normalise every source system, regardless of which property runs which PMS. The whole architecture is designed around the assumption that the group does not have operational control over every property in its portfolio and does not need to acquire it.

We're building Meridian because the group at this scale has been left with two bad options: build the analytical substrate internally and watch it fail in the ways I've written about, or wait for the enterprise-chain vendors to come down-market and discover that their economics don't work for independent groups. Neither option is what this segment of the industry deserves. The category of vertical hospitality data infrastructure - hospitality-shaped, delivered as a finished product, priced for the 10-100 property scale - is what needs to exist. Meridian is our attempt to build it.

Where the paths
converge

Both mechanisms produce the same outcome: a group where "what's our RevPAR" has one answer. Where the reservation Sales sees is the same reservation Operations sees is the same reservation Marketing sees. Where a methodology change is visible, dated, and traceable. Where the analytical substrate that AI applications need to consume is coherent, consistent, and machine-readable.

Enterprise chains got there by making the organisation the enforcement fabric. Independent and regional groups get there by making the platform the enforcement fabric. The difference is the mechanism. The endpoint is the same.

Di Tullio's argument is a good faith articulation of how Minor got where it is. It's not a good general theory of how hotel groups get to canonical data. It's Minor's theory of how Minor got to canonical data, generalised implicitly to an industry with a much more diverse ownership structure than Minor's.

The operating model is one thing that can make the data model possible. The data platform is another.

For most of the market, the second is the one that has to do the work.