This is a compelling vision and the direction of travel feels right. A couple of questions that I keep returning to when I read pieces like this.
On authority: the recommendation to give EA teams greater visibility and decision rights is the right instinct, but I think it matters enormously which decisions we're talking about. EA needs real authority over design principles, capability boundaries, and guardrails. That's where structural thinking creates lasting value. But implementation decisions are a different story. When EA becomes the approval gate for those, it tends to create exactly the bottleneck reputation that makes executives reluctant to invest in the function in the first place. Most organisations that have tried to elevate EA have done it by giving them more of the wrong kind of authority. What's your view on where that boundary should sit?
On governance and value creation: the piece moves between them as if they're naturally aligned activities. Sometimes they are. But governance that protects flow and architecture that generates new value operate on different cadences and with different failure modes. Conflating them can produce structures that are good at neither. I'd be interested in how you think about separating those two roles in practice, especially in organisations where governance has historically been the primary EA identity.
Underneath both questions sits a harder one: most EA teams were built around technical depth, not strategic translation. How do you see that identity shift being cultivated, rather than just mandated?
Excellent feedback. Let me attempt to address your comments:
1. Authority: Setting the “Rules of the Road,” Not Driving the Car
This is a critical distinction–Enterprise Architecture (EA) thrives when it focuses on strategic structural authority rather than tactical implementation. EA’s role is to define the “What” (capability boundaries) and the “How” (guardrails and standards), but it must stay out of the “When” and “Who.”
- The Approach: EA owns the System of Record for Decisions. Think of it as paving the road with pre-approved patterns and guardrails. Teams can move freely as long as they stay on the paved road. EA only steps in when a team needs to go off-road, ensuring agility without sacrificing structural integrity.
- The Outcome: This model removes bottlenecks while maintaining architectural consistency. Teams move faster, and EA shifts from being a gatekeeper to an enabler.
2. Governance vs. Value Creation: Decoupling the Cadence
Governance and value creation operate on different cadences, and conflating the two is where many EA programs falter. To fix this, we need to treat them as distinct outputs of the EA function:
- Governance as “Flow Protection”: This is about risk mitigation and standards. It should be automated and embedded into the CI/CD pipeline, ensuring it’s seamless and continuous rather than a separate activity.
- Architecture as “Value Generation”: This is a consultative, high-touch activity focused on strategic outcomes. It’s where EA creates real business value.
- The Shift: Move away from a centralized “Architecture Review Board” and toward Architecture Guilds or Product-aligned Architects embedded within value streams. A small core team can manage the automated governance platform, ensuring efficiency without slowing teams down.
3. Identity Shift: From Technologist to Translator
This is the hardest but most important transformation for EA. It’s not about issuing memos or enforcing compliance–it’s about redefining the EA Value Proposition and aligning incentives.
- Incentive Alignment: Shift EA metrics from “Compliance %” to outcomes like Time-to-Market or Reduction in Technical Debt. When architects are measured on how fast teams ship or how much complexity they remove, their role naturally evolves from “policing” to “problem-solving.”
- Architecture-as-a-Service Mindset: Developers and product owners should be seen as EA’s customers. The goal is to make it easier for them to deliver value, not harder.
- Skill Bridging: Hire and promote for systems thinking and negotiation skills. It’s easier to teach a business-minded person the basics of technology than to teach a deeply technical person how to think strategically and empathize with business needs.
EA’s future lies in becoming an accelerator, not a gatekeeper. By focusing on enabling flow, aligning incentives, and embedding within value streams, EA can transform from a compliance function into a strategic partner that drives velocity and value.
Great point! And you’re absolutely right: measuring EA maturity is where many organizations struggle. The ones who do it well usually keep it simple and focus on how EA connects to business outcomes, not just on how many diagrams are produced. A few things I’ve seen work:
- Is EA influencing strategic decisions? If leadership uses EA insights to guide investments, that’s a big maturity signal.
- Are business teams actually engaged? When EA moves from “ivory tower” to planning conversations, you know you’re making progress.
- Can EA show real impact? Things like cost optimization, risk reduction, and innovation enablement are tangible proof points.
The most mature organizations directly tie EA metrics to business KPIs. That’s what shifts the perception from “overhead” to “value creator.”
This is a compelling vision and the direction of travel feels right. A couple of questions that I keep returning to when I read pieces like this.
On authority: the recommendation to give EA teams greater visibility and decision rights is the right instinct, but I think it matters enormously which decisions we're talking about. EA needs real authority over design principles, capability boundaries, and guardrails. That's where structural thinking creates lasting value. But implementation decisions are a different story. When EA becomes the approval gate for those, it tends to create exactly the bottleneck reputation that makes executives reluctant to invest in the function in the first place. Most organisations that have tried to elevate EA have done it by giving them more of the wrong kind of authority. What's your view on where that boundary should sit?
On governance and value creation: the piece moves between them as if they're naturally aligned activities. Sometimes they are. But governance that protects flow and architecture that generates new value operate on different cadences and with different failure modes. Conflating them can produce structures that are good at neither. I'd be interested in how you think about separating those two roles in practice, especially in organisations where governance has historically been the primary EA identity.
Underneath both questions sits a harder one: most EA teams were built around technical depth, not strategic translation. How do you see that identity shift being cultivated, rather than just mandated?
Excellent feedback. Let me attempt to address your comments:
1. Authority: Setting the “Rules of the Road,” Not Driving the Car
This is a critical distinction–Enterprise Architecture (EA) thrives when it focuses on strategic structural authority rather than tactical implementation. EA’s role is to define the “What” (capability boundaries) and the “How” (guardrails and standards), but it must stay out of the “When” and “Who.”
- The Approach: EA owns the System of Record for Decisions. Think of it as paving the road with pre-approved patterns and guardrails. Teams can move freely as long as they stay on the paved road. EA only steps in when a team needs to go off-road, ensuring agility without sacrificing structural integrity.
- The Outcome: This model removes bottlenecks while maintaining architectural consistency. Teams move faster, and EA shifts from being a gatekeeper to an enabler.
2. Governance vs. Value Creation: Decoupling the Cadence
Governance and value creation operate on different cadences, and conflating the two is where many EA programs falter. To fix this, we need to treat them as distinct outputs of the EA function:
- Governance as “Flow Protection”: This is about risk mitigation and standards. It should be automated and embedded into the CI/CD pipeline, ensuring it’s seamless and continuous rather than a separate activity.
- Architecture as “Value Generation”: This is a consultative, high-touch activity focused on strategic outcomes. It’s where EA creates real business value.
- The Shift: Move away from a centralized “Architecture Review Board” and toward Architecture Guilds or Product-aligned Architects embedded within value streams. A small core team can manage the automated governance platform, ensuring efficiency without slowing teams down.
3. Identity Shift: From Technologist to Translator
This is the hardest but most important transformation for EA. It’s not about issuing memos or enforcing compliance–it’s about redefining the EA Value Proposition and aligning incentives.
- Incentive Alignment: Shift EA metrics from “Compliance %” to outcomes like Time-to-Market or Reduction in Technical Debt. When architects are measured on how fast teams ship or how much complexity they remove, their role naturally evolves from “policing” to “problem-solving.”
- Architecture-as-a-Service Mindset: Developers and product owners should be seen as EA’s customers. The goal is to make it easier for them to deliver value, not harder.
- Skill Bridging: Hire and promote for systems thinking and negotiation skills. It’s easier to teach a business-minded person the basics of technology than to teach a deeply technical person how to think strategically and empathize with business needs.
EA’s future lies in becoming an accelerator, not a gatekeeper. By focusing on enabling flow, aligning incentives, and embedding within value streams, EA can transform from a compliance function into a strategic partner that drives velocity and value.
Great point! And you’re absolutely right: measuring EA maturity is where many organizations struggle. The ones who do it well usually keep it simple and focus on how EA connects to business outcomes, not just on how many diagrams are produced. A few things I’ve seen work:
- Is EA influencing strategic decisions? If leadership uses EA insights to guide investments, that’s a big maturity signal.
- Are business teams actually engaged? When EA moves from “ivory tower” to planning conversations, you know you’re making progress.
- Can EA show real impact? Things like cost optimization, risk reduction, and innovation enablement are tangible proof points.
The most mature organizations directly tie EA metrics to business KPIs. That’s what shifts the perception from “overhead” to “value creator.”