This deep dive expands on the Loop Asia conversation with Erik Wilde, ambassador for the OpenAPI Initiative.

Erik Wilde didn't fully answer the customer-schema question when I pushed him in Paris. He called it "dear to his heart," said we'd need a longer conversation, and moved on. That non-answer points at the real failure mode: organizations treat "one canonical customer model" as a yes-or-no design question, when it's a governance question — who decides, domain by domain, whether shared or local wins.

Define a customer schema once, Erik said, and you get consistency across every API that touches it — reuse, one source of truth. Every architecture team has heard that pitch. I pushed back with a case that kills the clean version fast: a full-service bank with a retail division, a private bank, a wealth management arm, and a corporate and institutional division — each with a different idea of "customer." Erik didn't disagree. In most cases, he said, there isn't one true customer model for a whole organization.

The pyramid gives you the actual test

Erik had a tool for this already — Gregor Hohpe's double-sided pyramid: infrastructure at the bottom, platform in the middle, innovation widening above. Gregor's test: people build something on top of it that you didn't count on. If every use was anticipated, it's a product, not a platform.

Run the schema through that test, domain by domain. A shared identifier — confirming the retail customer and the wealth management customer are the same legal person — is platform-layer; nobody can innovate around broken identity resolution. But the retail division's profile, built for transaction volume and churn risk, and the private bank's, built around relationship depth and suitability obligations, aren't the same object wearing different labels.

What this means for the decision you're actually making

If you're the CTO or Head of Architecture when someone proposes a canonical customer object, the useful question isn't whether standardization is good — obviously it is. It's which layer this concept sits in, decided per-concept, not once for the whole data model. Three criteria worth borrowing: does a shared definition prevent real integration friction, or just look tidy on a diagram; would forcing one schema block a division from building something you didn't anticipate; and who owns the decision when a domain team diverges.