Not Just for the C-Suite: Building the Missing Career Path for Enterprise Architects
Enterprise architecture isn’t only for the most senior experts—it needs real roles, progression, and learning paths
When I wrote earlier about how to become an enterprise architect, it sparked more discussion than I expected.
Many people shared the same belief: that enterprise architecture (EA) is something you can only do after a long career—after you’ve led projects, managed portfolios, or sat in strategy meetings.
In other words, EA was seen as a destination, not a journey. A role reserved for those who already “speak C-suite.”
But I do not think it has to be that way.
Problem with the “Only for Seniors” Mindset
Of course, experience matters. Enterprise architects deal with complex systems, dependencies, and trade-offs that often reach across the whole organization. That requires maturity and credibility.
But the idea that only seasoned professionals can do EA creates its own set of problems:
It makes EA elitist and inaccessible—something people can only “graduate into,” not learn gradually.
It narrows the talent pipeline, keeping new perspectives and skills at arm’s length.
It disconnects EA from real development work, since junior and mid-level experts rarely get to participate or contribute.
If we want EA to be sustainable, it cannot be a room reserved for experts. It must be a discipline people can grow into.
Focus on Enterprise Architect Roles
Before we go further, a quick clarification: this article is not about other architect roles such as solution architects, technical architects, or process modelers.
Those roles are vital in their own right. But here, the focus is specifically on EA roles—the people who work at a higher level, at the intersection of business, data, and technology, keeping the architectural perspective that connects them.
For thoughts on how deep enterprise architects should go, see my earlier article on that topic.
Lightweight Career Framework for Enterprise Architects
If we treat EA as a real profession, it needs a visible structure: a way to develop, learn, and take on more complex responsibilities over time.
In practice, three dimensions define progression in EA:
Independence: how autonomously one can work, advise, and represent the architectural perspective.
Scope and complexity: how wide, complex, and strategically critical the domain of responsibility is.
Credibility and seniority: the trust and authority earned through experience, which allows an architect to engage with senior leadership and influence major decisions.
These dimensions grow together: independence requires trust, and trust comes from both skill and experience. A balanced EA practice needs all of them—not only senior experts who advise executives, but also developing architects who build the foundation and keep architecture alive in everyday work.
I would like to propose a simple model that reflects this balance and that I have seen work in practice.
1. EA Analyst / Junior Enterprise Architect
The starting point. Often someone with a background in analysis, data, or solution design who wants to learn the bigger picture.
Key contributions:
Builds and maintains EA models such as capability maps, process overviews, and application inventories.
Keeps architecture content structured, consistent, and accessible for decision-making.
Contributes to various EA support activities, such as maintaining repositories, collecting and analyzing data, preparing materials, and documenting findings.
How they work:
Work closely with senior architects as part of a team. Learn by doing: assisting in tasks, shadowing experienced colleagues, and receiving regular feedback. Over time, begin to take responsibility for specific modeling or analysis tasks.
Why it matters:
This is where future enterprise architects build their foundation. Junior architects keep EA visible and organized in daily work, while learning the languages, methods, tools, and ways of thinking that make architecture practical.
2. Viewpoint, Domain or Area Architect
A bridge role, connecting enterprise-level principles with concrete domains, solutions, or organizational areas.
Key contributions:
Owns the architecture of a specific business area, architectural viewpoint, application landscape, technology domain, or solution—ensuring it aligns with enterprise-level goals and standards.
Builds and maintains domain-specific models using shared EA methods and tools.
Identifies dependencies across projects, applications, and processes, and ensures they fit into the overall EA.
Translates EA principles into actionable guidance for delivery teams and stakeholders within their area.
Provides feedback from the field, helping refine enterprise-level practices and models.
How they work:
Operate semi-independently within their scope, applying EA practices to ongoing initiatives and ensuring local designs connect to the enterprise view. Collaborate closely with both enterprise architects, domain experts, and delivery teams to balance practicality and alignment.
Why it matters:
This is where EA influence becomes tangible. Domain and area architects make sure that architectural thinking reaches real initiatives—keeping solutions consistent, connected, and valuable across the organization.
3. Enterprise Architect / Senior EA
This is the level most people imagine when they hear the title enterprise architect—strategic, cross-domain, and collaborative.
Key contributions:
Develops and maintains enterprise-level models, ensuring their quality, consistency, and usability across domains.
Contributes to the development of the EA practice itself—improving methods, standards, and shared ways of working.
Guides and supports other architects in applying those practices to real initiatives.
Facilitates alignment between business strategy, investments, and technology direction.
Leads discussions between business, data, and IT leaders, ensuring that architectural consequences are visible and considered in key decisions.
How they work:
Operate independently, managing relationships with senior stakeholders while mentoring and coordinating other architects. Their role bridges strategic planning and operational delivery, ensuring that architecture remains both coherent and continuously evolving.
Why it matters:
This level is where architectural leadership truly takes shape. Senior enterprise architects not only enable better, faster decisions—they also develop the discipline itself, passing on the methods, judgment, and mindset that keep EA relevant and alive.
4. Chief or Lead Enterprise Architect
At this level, the architect’s focus expands from architecture content and its use to leading the entire EA function and ensuring its impact across the organization.
Key contributions:
Defines and continuously improves the EA operating model, governance, and toolset.
Leads and manages the architecture team—setting direction, priorities, and standards for the whole practice.
Develops organizational EA capability, ensuring consistent ways of working and measurable value.
Represents architecture in executive, strategy, and transformation leadership forums.
Builds trust and alignment with senior management, ensuring architecture remains an integral part of planning and change.
How they work:
Operate at the highest level of independence, scope, and accountability—responsible not only for architectural coherence but also for the performance and visibility of the entire EA function.
Why it matters:
Sustaining an EA practice requires persistence, systems thinking, and leadership. The chief architect ensures that architecture is not a side activity but a living part of how the organization plans, prioritizes, and transforms—connecting strategy to execution through people, processes, and structure.
What This Means for Organizations
If EA is to thrive, organizations need to treat it as a profession with progression, not a title people inherit after 20 years of leading IT or business.
That means:
Opening entry-level opportunities where junior architects can learn by doing.
Defining clear expectations and growth paths within the EA team.
Creating mentorship and rotation models so people can move between domains and levels.
Without this, EA risks becoming an isolated function—maybe respected, but stagnant.
A healthy EA practice needs both experienced voices who can steer strategy and emerging talent who can connect details to the big picture.
Final Thoughts
EA is one of the few disciplines where you can truly work at the intersection of strategy, design, and delivery—and see the organization as a living, evolving system.
But the field will only grow if people can enter it before they reach the very top of their careers. Experience matters, of course. Yet the qualities that define great enterprise architects are curiosity, structure, and persistence—not just seniority.
Progression in EA is not about titles or tenure. It is about developing the ability to see more, connect more, and guide more, while staying grounded in collaboration rather than authority.
So perhaps the real question is not “How senior should an enterprise architect be?” but “How do we build a path that allows more people to become one?”
🔗 You May Also Like
Looking to dive deeper? Here are more enterprise architecture insights you might find useful:
📬 Want More Practical Enterprise Architecture Content?
Subscribe to Enterprise Architecture Transformation for real-world advice on architecture that supports change, strategy, and delivery.
First of all, thanks for your articles. Enterprise architecture is an interesting topic and there isn't much written about it!
I'm a bit skeptical about the role of 'junior Enterprise Architect'. First of all, I think the best way to avoid the gap between enterprise architecture and lower levels is common understanding.
I have asked many lower-level architects the following question: 'I know you help enterprise architecture with your domain knowledge and diagrams, but what do YOU get from enterprise architecture? Does it help YOUR work?'
Many times the answer is not clear.
In general, I think the better way would be to include lower-level architects to make enterprise architecture together, not to bring new juniors in.