“The tech is ready for decentralization. The governance is not.“
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!
This is the final post in a four-part series exploring decentralization not as a buzzword, but as a series of hard tradeoffs that digital infrastructure teams, architects, and strategy leads must navigate.
- In Engineering Meets Economics, we explored why resilience depends on the ability to shift between centralized and decentralized systems, not cling to one model.
- In How Decentralized Are You Willing to Pay For?, we talked about the very real costs of optionality: complexity, coordination, and duplicated capabilities.
- And in Redefining Success, we looked at why our success metrics often reinforce centralization—even when it’s no longer serving us.
So if we know decentralization has value, and we know it’s technically feasible… why does it still fail in practice?
Because the tech might be ready, but governance is lagging behind. This makes sense because governance means politics, and politics are hard.
Decentralization Doesn’t Mean Disorder
Most enterprise folks hear “decentralization” and think:
- Increased risk
- Lack of visibility
- Slower coordination
- No one in charge when something breaks
But that’s not a property of decentralization; it’s a symptom of missing or immature governance.
We see this all the time in digital identity:
- A federation that works technically, but has no process for resolving disputes
- A wallet ecosystem that’s privacy-preserving, but can’t agree on what metadata is mandatory
- An access system that’s delegated, but lacks revocation mechanisms that everyone honors
If you’re a technologist, this probably sounds familiar. Governance gaps show up as operational issues: broken policy syncs, inconsistent audit trails, revocation flows that only work in theory. If your service mesh or access broker assumes everyone interprets “suspend access” the same way—but no one agreed on what that means—you’ve built an elegant mess.
When decentralization fails, it’s often not because the protocols were bad. It’s because we didn’t define who gets to decide, update, delegate, or enforce—and under what terms.
Governance Is Infrastructure
If decentralization is the design pattern, governance is the scaffolding.
And here’s the important part: we already know how to build decentralized tech. The internet itself is built on decentralized protocols: DNS, BGP, email, and even identity federations. We have working models. We know how to distribute trust and authority technically.
What’s missing isn’t architecture, it’s agreement.
We can make it happen at scale. But without governance, decentralization becomes friction, not flexibility.
Governance defines:
- Who holds authority
- How power shifts over time
- What happens when participants disagree
- How trust is established and withdrawn
For CIOs and digital strategy leaders, it’s a core risk management issue. Weak governance delays implementation. It also increases legal exposure, regulatory risk, and recovery costs when things go wrong. It makes vendor transitions expensive. And it turns architecture decisions into lock-in faster than most teams realize.
In enterprise environments, we already know how to manage distributed control.
- We decentralize org charts … with reporting lines, SLAs, and escalation paths
- We allow teams to own systems … within shared standards and budgets
- We outsource critical functions … with contracts and enforcement mechanisms
We don’t expect everyone to act independently. We expect them to act accountably within a structure.
I think we should treat digital infrastructure the same way.
Examples Worth Learning From
Across the identity and trust space, we’re starting to see governance taken seriously as more than a compliance exercise. It’s a strategic enabler for an organization.
- The Trust Over IP Foundation’s Governance Stack Working Group is actively developing models and interoperability standards for governance frameworks that support legal, business, and social trust. Their work includes templates and specifications for governance architecture, trust assurance, and certification—tools that make decentralized systems both usable and accountable.
- Projects like SCITT at the IETF are tackling supply chain integrity by designing trust architectures that include not just technical assertions, but clear governance of who can issue, verify, and rely on those assertions.
- Wallet ecosystems are (slowly) recognizing that success will depend not just on cryptography, but on common rules for inclusion, suspension, and dispute resolution.
If you work in identity, you’ve probably seen this up close: great protocols with no shared process for trust anchors, no agreement on metadata, no real mechanism for shared accountability. We don’t need another working group (says someone who loves to manage working groups). We need rules for when and how trust changes.
Identity professionals often sit closest to the tension and are best positioned to help shape how governance gets built. If you’re part of IAM, you’re part of the governance problem and the solution. Don’t wait for someone else to define the structure you’ll be bound by later.
What Governance in Decentralization Means for Your Team
If you’re building toward decentralization, whether in authentication, cloud strategy, data sharing, or infrastructure, ask yourself:
- Who gets to define the rules of engagement?
- What happens when two participants disagree?
- How does a new participant join—and how can they be removed?
- Are you solving the governance questions before the technical ones lock you in?
The hard part isn’t building the system—again, we kind of know how to do that—but deciding who can change it later.
Final Thought: Governance Is Not Overhead, It’s Capability
If you take only one thing from this series, let it be this: Resilience isn’t just a technical attribute. It’s a governance capability.
I’ve spent this series talking about how to shift, how much flexibility costs, and what we’re incentivized to build. But none of that matters if no one agrees on how to share control when it counts.
The good news? Governance is designable. It doesn’t need to be perfect. It needs to be intentional, so decentralization becomes a strength, not a source of uncertainty.
Because when the tech is ready but the governance isn’t, you don’t have a distributed system. You have a political standoff, and nothing gets done.
📩 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.
[00:00:26]
Let’s get into it.
[00:00:29]
Hey everybody. Welcome back. This is the third episode in our series on centralization and decentralization and the balance between the two.
If you’re just tuning in now, here’s what you’ve missed:
- In episode one, we explored why resilience isn’t about being centralized or decentralized. It’s about being able to move between the two models when circumstances change.
- In episode two, we looked at the real cost of building that kind of flexibility. Because optionality isn’t free. It takes planning, coordination, and a willingness to invest before you need it.
Why Is Decentralization Often a Hard Sell?
[00:01:01]
And that brings us to today’s topic. Why is decentralization often still such a hard sell, especially inside enterprises?
[00:01:09]
One answer is that most of our success metrics reward centralization.
[00:01:15]
If we don’t challenge how we’re defining success, we’re going to keep optimizing for systems that look great—right up until the point that they don’t.
Centralization and Scale
[00:01:22]
Let’s talk about that in tech. We don’t just love things at scale; we know how to do things at scale fairly well.
[00:01:31]
When we’re working with centralized systems, we know the playbook:
- Throw more hardware at it
- Replicate the databases
- Spin things up in other regions
- Set up failovers, caching, and routing magic to absorb traffic
And that totally works—up to a point. Even when control is centralized, we’re very good at scaling the infrastructure around it.
[00:01:50]
When it comes to decentralized models, we know how to do that too. We just don’t plan that way as often.
[00:01:56]
At least not anymore. Think about the protocols from the early days of the Internet: DNS, BGP, SMTP. They’re not flawless or simple, but they work at global scale because they were built to distribute control and survive failure.
[00:02:14]
Everyone gets a piece of the responsibilities in those protocols. Everyone can operate within a shared structure. That’s decentralized centralization, and we did it really well.
The Problem with Success Metrics
[00:02:25]
But now, today’s challenge: most of the success metrics we use today, especially in enterprise systems, still push us towards centralization.
[00:02:33]
Why? Because it looks faster, is easier to explain, and is a lot easier to report on.
[00:02:40]
But when success is only measured by how tightly we can control the system, we end up building architectures that aren’t particularly flexible. And that’s a problem.
Centralization Helped Us Grow—But Does It Still?
[00:02:49]
Now let’s step back for a moment. You might be thinking, “Well, yes, but centralization is what helped us grow as a company, helped us grow at speed.” And yes, you are absolutely right. Centralization often is what helps organizations move fast, simplify complexity, and work at scale. It gives you:
- Clean handoffs
- Predictable systems
- Fewer moving parts
- Optimized performance without needing to get everyone to agree on everything
And when you’re trying to move quickly, those things are real advantages.
[00:03:19]
But the thing is, those advantages—whether from your infrastructure perspective or your market perspective—don’t last forever.
[00:03:30]
Markets might shift, regulations might change, vendor lock-in might become a liability, and the systems that helped you grow start to hold you back.
[00:03:40]
There’s a great idea from supply chain strategy that applies here: the faster your environment moves, the more important it becomes to reconfigure quickly.
[00:03:48]
And that’s where centralized success starts to crack—not because it failed technically, but because it couldn’t adapt fast enough.
[00:03:56]
So the question isn’t, “Didn’t centralization help us grow?” It’s, “Can we keep growing without the ability to be a little bit more flexible?”
Decentralization in Organizations
[00:04:07]
It’s kind of funny—we decentralize all the time, but just not when it comes to our infrastructure and definitely not our identity infrastructures.
Inside organizations, we break up control and distribute responsibility on purpose:
- Teams have their own budgets
- Product groups make roadmap decisions
- Key performance indicators are set at the department level, not just at the company level
[00:04:31]
Why? Because trying to control everything from the top down slows you down. It’s more sustainable to align goals than to micromanage every function.
Take a typical enterprise product org as an example. One team focuses on mobile, another on partner integrations, a third on internal tooling. Each team moves independently within shared priorities. They don’t all escalate to the CIO to push code; they’re trusted to make decisions locally based on their goals and context. We don’t call that chaos—we call that autonomy and maturity.
[00:05:05]
Think of it like a city: every neighborhood has its own character, maybe its own rules, but they follow the same traffic lights, zoning laws, public services. That’s decentralization with coordination.
[00:05:17]
The control, to an extent, is distributed. If we can do this with people and even in governments—if we can handle distributed authority in complex orgs—why does decentralizing infrastructure sometimes feel so risky? It’s not because we can’t do it. It’s because we haven’t applied the same thinking to systems that we apply to teams of people.
Building Flexibility into Identity
[00:05:42]
If centralization has been our default version of success, what does success look like when you build in the flexibility to decentralize?
[00:05:50]
It doesn’t mean blowing up your current architecture, because that would probably be bad and you wouldn’t get very far.
[00:05:56]
It doesn’t mean ditching your identity provider or rebuilding everything from scratch, because that also wouldn’t make you very popular and probably wouldn’t get you very far. But it does mean designing for modularity and movement.
[00:06:07]
A successful, flexible identity system might include:
- Federated logins that work across partners but don’t collapse if one party changes their trust model
- Credential issuance that’s anchored to your core directory but usable outside your domain
- Policy enforcement that supports delegation, so different teams or regions can adapt without rewriting global configurations
- Flexible authentication layers that can shift to support new protocols without breaking legacy systems
[00:06:42]
Another good example of flexible identity systems that don’t require a centralized focus.
[00:06:49]
Ask yourself in your organization:
- Can you change identity providers without breaking logins for 50,000 users?
- Can you delegate trust without rerouting everything through one central system?
[00:07:03]
Are you prepared to adapt when legal or business requirements shift, or will you end up frozen and need to make a plan on the fly?
[00:07:14]
Being able to say “yes” to those things—that’s what success with flexibility looks like.
Key Takeaways
[00:07:25]
You don’t have to decentralize everything—and probably shouldn’t. But if your architecture can accommodate controlled divergence and flexibility, you’re set up for long-term success.
[00:07:43]
That’s what matters. That’s what’s really cool.
[00:07:46]
Here’s the takeaway from today.
[00:07:50]
Centralization isn’t the enemy. But if success only counts as scale, simplicity, or speed, that story can get brittle quickly.
[00:08:03]
We already know how to decentralize in our org charts and delegate decisions without chaos. We just haven’t always brought that thinking into our infrastructure and identity systems—but we could.
[00:08:15]
Success doesn’t have to mean one system to rule them all. It can mean systems that adapt without starting over. That adaptability only works when you’ve got governance built in to support it.
[00:08:30]
Our technology is almost good enough—sometimes more than good enough. But shared control takes more than configuration files. It takes structure, accountability, and intention.
Closing Thoughts
[00:08:53]
And remember, resilient systems don’t just run well—they recover well and grow on purpose.
[00:09:04]
That’s it for this week’s episode of the Digital Identity Digest. If this helped make things clearer or more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan. If you enjoyed the show, subscribe and leave a rating or review on Apple Podcasts or wherever you listen. You can also find the full post at sphericalcowconsulting.com.
Stay curious, stay engaged, and let’s keep these conversations going.