Engineering Meets Economics: Shifting, Not Choosing, Between Centralized and Decentralized
“What if the real innovation is not centralization vs decentralization, but the ability to shift between them?”
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
That question has been rattling around in my brain lately, and I keep coming back to it. Not because I have a clever answer—goodness knows I’m not an identity architect, nor can I play one on TV—but because it changes the shape of the conversation I’m used to hearing. It stops being about camps or philosophies—centralized vs decentralized—and starts being about resilience. Adaptability. Survivability. Malleability. The real stuff that makes or breaks systems under pressure.
Whether you realize it or not, most of us are already living in the murky middle. Even the most rigorously centralized enterprise setup has had to grapple with siloed systems from acquisitions, third-party integrations that can’t be wrangled into compliance, or regional requirements that throw a wrench into the “single source of truth” fantasy.
On the consumer side, it’s no simpler. Many apps build their entire onboarding flow around third-party login, such as Sign in with Google, Facebook, Apple, only to realize later they can’t get out. Apple tweaks its policies, Google changes branding or scopes, and suddenly your user flow is broken. Or worse, your legal team is panicking about data access that was never fully under your control.
So maybe the goal shouldn’t be to “pick a side.” Maybe the goal is to build something that can move.
We’ve Been Here Before
I remember when the phrase “if you’re not paying for the product, you are the product” first started making the rounds. It was a wake-up call for how data was being monetized, especially in consumer tech. But in enterprise settings, it’s always been more complicated. Control over employee and operational data is often treated as sacred… until an M&A event hits, or an offboarding workflow depends on access to a different tenant’s system, or someone discovers the only copy of a critical record lives on a spreadsheet maintained by a single team in Ukraine.
Even the executives who believe they have centralized control are often just looking at a well-behaved abstraction. Under the surface, the architecture is often more federated (or fragmented) than anyone wants to admit.
So: centralized in theory, decentralized in reality. And that’s (probably) fine, if you plan for it.
Centralized vs Decentralized is the Wrong Question
The wrong question is, “Should we centralize everything or decentralize everything?” Because you’re never going to have a clean answer to that. Business needs shift. Systems fail. Teams grow faster than governance can keep up. Which means sometimes, decentralization isn’t just a compromise, it’s a strategic advantage.
Take employee authentication. It’s easy to default to a centralized IdP for control and visibility. But control doesn’t always mean centralization. In some cases, like high-assurance access to sensitive systems, decentralized approaches like verifiable digital credentials might offer more resilient and efficient ways to meet your risk and compliance goals. (I’ve written about this in more detail over here.)
So instead of asking “which architecture is best?” the real question is:
How do we build for mobility between them?
Shift Zones: A Mental Model
Here’s how I think about it. Your architecture probably has at least three layers:
- Core systems that demand high assurance, strong governance, and low tolerance for error. These might initially seem like candidates for centralization, but in practice, decentralized approaches (like verifiable credentials) can reduce exposure, improve auditability, and allow more precise access controls. Think about systems managing employee benefits, third-party entitlements, or financial approvals that span org boundaries.
- Edge systems where decentralization improves speed, autonomy, or user experience. Think mobile app login, partner ecosystems, or field service platforms.
- Bridge systems that help you manage both ends: identity brokers, API gateways, credential verifiers. These are your control points. They don’t need to be perfect, but they do need to be swappable.
This Isn’t About Complexity. It’s About Control.
There’s a reflexive fear that anything outside your central architecture introduces risk. But lock-in is its own kind of risk. What happens when:
- The cloud provider you bet everything on has a region-wide outage?
- Your go-to identity vendor starts charging for what used to be free?
- A new privacy law forces you to isolate user records by country?
If your systems can’t move, your strategy can’t either.
Which brings us to an uncomfortable truth: flexibility isn’t a feature you tack on later. It’s an investment in survivability. And yes, that includes your DR/BC planning. If your recovery plan assumes the architecture will look the same when you need to recover—same vendors, same identity flows, same regional rules—you’re about to have a Really Bad Day.
Systems don’t fail in isolation. They fail in ways that expose your hidden dependencies. The real risk is that the thing you need next won’t work the way it used to or, more to the point, the way you’ve planned for come recovery time. If your plan can’t flex, it can’t recover. To put it another way: rigid design is brittle, so avoid it if you can.
Trends That Make This Urgent (Not Just Interesting)
Still on the fence about needing this kind of mobility? Here’s what’s already pushing organizations in that direction:
- Regulations that require data residency or mandate new consent flows
- Cloud concentration risk, made worse by geopolitical volatility
- AI deployment that needs decentralized access to proprietary or regional datasets
- Identity policy changes (looking at you, browsers) that upend previously stable auth flows
None of these trends are waiting for you to clean up your architecture.
Pop Quiz!
If you’re a CIO, architect, or planner, ask yourself:
Can your systems…
- …switch to a new identity provider or trust a new authority within 48 hours if they have to
- …segment authorization policy by region or user group without rewriting everything?
- …keep functioning when a key vendor changes terms or disappears?
- …pivot to a new compliance boundary without a year of re-architecture?
If not, it might be time to rethink what “flexibility” really means in your environment.
Final Thought: Don’t Confuse Control with Stability
Centralization often feels like control. Decentralization often feels like chaos. But both are illusions if you haven’t built for change. The real strength comes not from sticking to one approach, but from designing your systems to flex across time zones, use cases, org charts, and crises.
So next time someone in the boardroom or the architecture review committee asks, “Should we [de-]centralize this?” maybe try responding with:
“There are pros and cons, but first, let’s make sure we build in an ability to change our minds later.”
📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
[00:00:00] Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists. If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place. Let’s get into it welcome to Episode one of the Audio Blog. This is engineering meets economics, and today we’re going to talk about something that gets framed as kind of a binary option a little too often, and that’s centralization versus decentralization.
[00:00:42] Now this episode isn’t about picking a side and arguing for an either or. It’s about recognizing that the best systems, especially identity systems, don’t live at either extreme. They move around.
[00:00:55] So this episode is based on the blog post Engineering Meets Shifting, Not Choosing between Centralized and Decentralized, which you can find on sphericalcowconsulting.com now we’re going to be focusing on digital identity, but the ideas here apply to infrastructure more broadly because whether you’re designing a login flow, a wallet ecosystem, a cloud strategy kind of doesn’t matter. The resilience comes in from the ability to shift around and not just scale and get bigger. So let’s dive in. First, let’s start with a bit of a clarification, because centralized and decentralized can mean so many different things depending on what layer you’re talking about.
[00:01:33] In an identity system, centralization usually refers to who controls the source of truth and the rules of engagement.
[00:01:41] A centralized identity system might use a single corporate directory as the source of truth, where identities are managed, access policies are enforced, and decisions flow from one authority. Even if you’re using a third party provider like Okta or Microsoft Entra, the control is still centralized if it all stems from that single directory and policy framework. Now that’s different from decentralized identity systems, where the control is distributed, the user or device might hold their own credentials, and verification happens independently of any single governing authority. Trust is negotiated. It’s not inherited from a single source.
[00:02:20] Now to be clear, decentralized doesn’t mean there’s no structure. It just means that the structure allows multiple parties to operate with some level of autonomy. Now, in practice, most organizations sit somewhere in between. You might authenticate users through a central identity provider or idp, while also issuing credentials that work across external partners, vendors, or federations. And that hybrid space is where things get interesting and where smart architecture can give you room to maneuver as your environment changes. Okay, did that make sense? No. Let me try an analogy. When I was a kid, my father decided it would be hilarious to toss me a stack of plates. These were those old Corningware white and blue plates. And if you’re of a certain age and in the US I know you probably remember these. Now, me being me, I’m not about a to attempt to catch a pile of plates. And so I jumped back and the plates crashed to the ground. And I promise this is going somewhere relevant.
[00:03:16] Those plates didn’t just break. They shattered and continued to shatter for a good five minutes. You could hear the little crackles as things turned into small slivers of Corningware. A purely centralized technology is like a whole plate. A purely decentralized technology is a lot like slivers of plate. The best model is to have a plate that can survive being broken and yet still remain useful in one configuration, and that it won’t become an unmanageable pile of slivers so can be broken. Those broken pieces are still useful, but it doesn’t break down into just unrecognizable shattered bits. Okay, I digress. I suppose. So why does this matter? Because in an enterprise system, especially Identity, you’re always making decisions about control, or whether you call it that or not.
[00:04:04] Now, let’s say your organization uses a central IDP like Okta or Entra. You manage the directory or directory like object. You define the policies. But now you want to federate across to a partner organization or issue credentials that could be verified independently or meet new data residency rules in different jurisdictions. You’re not decentralizing for the fun of it. You’re decentralizing because your environment changed.
[00:04:29] And that’s where the friction begins. If your architecture assumes that everything will always route through one system, one policy engine, one source of truth, you’re going to have a problem.
[00:04:40] Now you might be thinking, why do I need to build systems that can shift between models? Isn’t that just overengineering for edge cases? You know, it’s a fair question. But here’s the thing. No one ever thinks they need that optionality until their primary model fails. The thing is, they don’t have to be fast. You know, the shift doesn’t have to be complete, but it does have to be possible. Because if the only direction your system can actually move is like in this one, one pattern, it’s not resilient, it’s actually brittle. Which gets me to that heart of the problem. You’re not choosing decentralization or centralization for its own sake. You’re design, you know, what you need to be doing is designing for the ability to shift control when the situation demands it, whether that’s technical, legal or organizational. Now, I’m not trying to tell a fear story here. I’m giving you a design challenge. Fear, uncertainty and doubt may, you know, maybe what you’re hearing, but for me it’s this challenging moment that’s a new take on the reality that I think we can do better with.
[00:05:39] So let’s talk about why most systems don’t feel flexible and why decentralization may sound good in theory but so often gets pushed aside in practice, especially in the enterprise. Well, I think the short answer is because centralization is easier to explain. It’s easier to build and it’s easier to control, at least at first. When you’re under pressure to ship a service, secure a system, or meet compliance requirements, centralization feels like such an obvious choice because it’s simplifying your procurement, it’s probably shortening your decision making and it’s giving you that one throat to choke when something goes wrong. And it’s not a failure, it’s just what happens when you don’t have time to design for flexibility.
[00:06:21] Now it’s kind of funny that you know when you’re thinking about it that way because most organizations already decentralized, at least to some some extent, they just don’t necessarily call it that.
[00:06:31] So if you’re, you know, in a big company, you might let different business units manage their own IAM policies.
[00:06:40] You might federate identity across subsidiaries or required companies.
[00:06:44] You might let contractors use their own credentials, tying them into your systems through some kind of federation like SAML or OpenID Connect. And that’s decentralization usually works reasonably well, though if it’s not done mindfully, it can be a little bit fragile, a little bit informal. And when that informal stuff breaks, then you’re kind of scrambling and you want to rebuild that central source of control because control feels good. Or, or worse, you might start doubling down on centralization in ways that creates serious lock in.
[00:07:17] Because once you’ve optimized for a single identity provider or a single trust model, or a single cloud region, you’ve made a bet as to what’s going to persevere in the long term. If your business changes or the legal environment shifts or the vendor gets acquired, you’re kind of stuck. And that’s not a failure of centralization, it’s a failure of being flexible.
[00:07:39] So what I want to talk about isn’t abandoning control. It’s designing a system that can be reconfigured without having to start all over again. And I don’t think that’s a fantasy. I think it’s a different set of design goals.
[00:07:51] So what does flexibility actually look like in real world identity systems? Okay, it’s not about throwing out everything centralized, and it’s definitely not about decentralizing just for the sake of doing it. It’s about designing with options. Right? You want to build a system that supports more than one model of control, more than one model of trust, and more than one path forward. For example, your internal directory can still be the system of record, but you can design APIs or token flows that let external verifiers validate credentials independently.
[00:08:26] You can use federated logins across business partners, but layer on policy controls that live with the relying party, not the issuer.
[00:08:34] You can store data in the cloud, but architect for multi region failover or multi cloud redundancy. So your compliance strategy isn’t tied to one jurisdiction.
[00:08:44] Again, the goal isn’t to decentralize everything. It’s to avoid systems where the only way to function is through one tightly coupled dependency.
[00:08:52] That kind of flexibility isn’t free. It does cost more to architect, and it takes more time for teams to align. And you’ll probably have to explain it repeatedly to leadership who wants to know why you’re not using the default centralized option?
[00:09:08] What you’re building in and the argument you can make is that you’re building room to maneuver. So when things shift, like when a vendor changes their roadmap or regulation forces your hand, you’re not stuck rewriting your entire stack. You’re shifting your control intentionally.
[00:09:23] So here’s the takeaway from all of this. Decentralization isn’t inherently better. Centralization isn’t inherently bad. What matters is whether your system is designed to adapt not just to today’s need, but to tomorrow’s constraints.
[00:09:37] Now, that might mean building systems that can federate when needed but still operate independently. Could mean designing identity flows that let you change providers without rewriting your policy framework.
[00:09:48] It could mean making architecture decisions that give you breathing room, not just efficiency, because you know your real resilience isn’t going to be about eliminating all risk. You can’t. But it is about having the room to shift across vendors, across trust models, across jurisdictions, without throwing everything out.
[00:10:05] Think of optionality as a feature, and flexibility is what is keeping your designs relevant when the world changes around it.
[00:10:14] So what now? The written post Engineering Meets Economics does dive a bit deeper into all of this if you want an idea of more about what I’m talking about. And also, since this is the first of a series of four posts where the series is heading, if you’re building identity systems, managing user access, or just trying to future proof your architecture, remember this isn’t about choosing a side. You know, for the people who are passionate about decentralization or centralization. It’s about building the flexibility to respond to change.
[00:10:45] So thank you for listening. You can find the written post in the rest of the series as
Spherical Cow Consulting over the next few weeks, and I’d love to hear what you think.
[00:10:57] And that’s it for this week’s episode of the Digital Identity Digest. If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan. And if you enjoy the show, do be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts. You can also find the written full post@sphericalcowconsulting.com now stay curious, stay engaged, and let’s get these conversations going.
