When getting started with enterprise architecture, it’s tempting to begin by focusing on architecture itself. But that’s likely not the best place to start.
While enterprise architecture has its own lane, it extends into many others, so is inherently cross-functional. Not everyone will welcome that, especially in large organizations with senior leadership challenges.
I learned this the hard way.
Establishing Structural Authority for Enterprise Architecture
How an enterprise architecture program is structured will determine whether it is merely informative or genuinely implemented. This is typically more about reporting relationships, decision rights, funding dependencies, and the formal understanding of authority than about any system design.
Without this structural foundation, enterprise architecture teams often produce artifacts that look authoritative, but the gravitational pull of delivery will likely overwhelm architectural intent.
From Influence to Instrumentality
Authority emerges when enterprise architecture is operationally connected to the mechanisms of organizational instrumentality through which work gets done.
Those moments often include funding approvals, technology selection, production readiness, vendor onboarding, security reviews, and lifecycle management.
When those links are missing, fragmentation becomes inevitable.
Creating the Operational Substrate for Enterprise Architecture
Consider finance as an analogy. It has a clearly defined domain, yet its reach spans all others, typically with authority.
That authority is defined by structural elements like cost centers, P&Ls, and procurement controls. It is further enabled by processes like budgeting and forecasting. This is the substrate on which the discipline of finance operates.
Organizational leaders pay close attention to budgeting and forecasting processes because their budget is a primary determinant of their operational effectiveness. Finance works, in this way, as a forcing function. It has power.
Enterprise Architecture as a Forcing Function
For enterprise architecture to operate in this manner, it needs equivalent mechanisms that integrate into the technology lifecycle. This substrate includes asset cataloging, lifecycle classifications, review workflows, exception processes, reporting, and traceability between investments and strategic intent.
When this structure and substrate exist, leaders will engage with enterprise architecture for the same reason they engage with finance: their ability to deliver depends on it.
Without it, enterprise architecture serves in an advisory role. With just part of it, enterprise architecture must negotiate from a structurally weaker position with organizational functions that typically have outsized momentum. But with it, enterprise architecture can direct outcomes.
We’ll take up how to begin building those mechanisms in the next article, Enterprise Architecture, ITIL, and the Architectural Role of Asset Management.
The Computer Is Going to Do Something
Join me in an ongoing, practical examination of enterprise architecture, systems engineering, and technology operations.
Notes:
1. Headline image generated by Gemini and ChatGPT.

Leave a Reply