Understand the characteristics of a Level 1 architecture function

If your architecture function is at Level 1, it defines itself primarily through its governance outputs: standards documents, reference architectures, technology assessment reports, architecture review board decisions, and the documentation of enterprise-wide principles and patterns. The practitioners within it are typically knowledgeable, well-intentioned, and working hard. What they are not doing — and what the operating model does not allow them to do — is owning anything that your enterprise depends on or taking accountability for the outcomes of the delivery programs their governance covers.

The Governance Posture

Your architecture function at Level 1 stands outside the delivery process. It reviews artifacts that delivery teams produce and offers assessments those teams may or may not act on. Its governance authority is formal in the charter and limited in practice. It can flag standards violations and escalate to governance bodies, but those bodies respond in weeks or months — timescales that are incompatible with the delivery decisions they are supposed to govern. The practical result is that Level 1 governance is advisory regardless of how it is designated in the organizational chart.

The Documentation Reality

Architecture repositories at Level 1 organizations are typically incomplete, inconsistently maintained, and rarely published in a form that makes them discoverable and usable by the delivery teams they are intended to serve. This is not a reflection of the team’s intentions — it is a consequence of bandwidth. A small group of architects covering a large and complex technology landscape, conducting reviews, attending design sessions, and responding to escalations from delivery teams has limited time for the systematic curation of a comprehensive architectural knowledge base. The documentation that gets produced is a byproduct of advisory engagement rather than a systematically managed organizational asset. And the Architecture Modeling Tools procured to solve this problem create their own cost and complexity burden that is difficult to justify when the output they produce is not visibly connected to organizational outcomes.

What You See as the IT Leader

You know that your architecture function exists. You see its outputs periodically — in technology roadmap presentations, governance reports, and standards documentation. What you do not see is your architecture function’s specific contribution to any particular delivery outcome, any operational result, or any financial return. The function is visible as a category but invisible as a contributor to the things that matter most to your decisions as an IT leader.