What Senior EA Teams Look for When Hiring in 2026

Senior enterprise architecture teams hire architects who can contribute to a governed practice without close supervision. In 2026 that practice increasingly works AI-augmented: the architect decides what should be done and AI does the mechanics in the tool and the model. AI is only as good as the person prompting it, so the skills a panel tests have shifted toward the ones AI depends on. Can the candidate state clearly what the model should contain? Can they review what AI built against the notation and the organization’s rules? Can they design what a stakeholder sees? Can they keep a shared repository governed?

Certification is a baseline. This piece sets out what hiring managers assess, where strong candidates separate themselves, and the gap that most often catches well-credentialed applicants.

What senior EA teams need

Start with the job. A senior team needs someone who can work in a governed practice at a level above a junior. In concrete terms, that means a person who can:

• Take a domain brief from a stakeholder and turn it into architecture content that is correct, typed and governed, whether they build it by hand or state it clearly enough for AI to build it.
• Work in the shared repository without introducing structural problems: using profile elements, holding to naming conventions, keeping package discipline, and checking that AI-built content does the same.
• Present architecture to a mixed technical and non-technical audience and field questions without deferring everything to the lead architect.
• Say what the architecture is for. A weak answer is “I was asked to document the application layer.” A strong one is “the business needs to understand its application redundancy before the consolidation program, and this view answers that.”

The hiring scorecard at a glance

Across the dimensions a senior panel evaluates, the line between a strong and a weak candidate is rarely whether they know the vocabulary. It is whether they can apply it under questioning.

The hiring scorecard at a glance

What's assessed	Strong signal	Weak signal
Notation knowledge	Places elements in the correct layer without hesitation and explains why a relationship was chosen	Knows the element names but uses Association for anything uncertain
Stating intent	Describes a view by its purpose, audience, scope and rules before anything is drawn	Starts drawing, or prompting, and works out the purpose later
Reviewing output	Finds the wrong layer, the misleading relationship and the missing element in content someone else built	Accepts content because it looks finished
Governance understanding	Describes MDG as a metamodel governance mechanism and discusses configuration trade-offs	Calls MDG “the settings menu” or “the profile thing”
Stakeholder experience	Designs what each audience should see and adjusts technical depth to the room	Has only ever presented to other architects; becomes defensive under challenge
Mindset	Leads with the problem the architecture solved	Leads with the modeling choices that were made

Technical skills: what is assessed

Knowing the notation well enough to review

For most enterprise EA roles, ArchiMate fluency is the baseline. Today a panel tests it by asking the candidate to model something. When AI builds much of the model, the same knowledge is what lets an architect review it. In assessment it shows up as:

• Correct layer placement. An Application Component sits in the Application Layer, a Node in the Technology Layer, a Business Service in the Business Layer. Confident placement signals real understanding.
• Relationship selection. “I used Realization here because the Application Service realizes the Business Service. They are different abstractions of the same function.” That answer separates a candidate from one who reaches for Association whenever they are unsure.
• View construction. Taking a business scenario and specifying a view that answers a specific question, with the right elements, relationships and level of abstraction for the intended audience.

Some panels now hand the candidate a view that contains deliberate errors and ask them to find them. That is the review skill tested directly. For roles with a systems-engineering component, such as defense, aerospace and complex infrastructure, SysML replaces or supplements ArchiMate as the core notation.

Sparx EA proficiency

In Sparx EA environments, proficiency is assessed functionally. Can the candidate find content across packages in a structured repository? Create elements through the MDG profile instead of inventing custom types? Build a multi-layer ArchiMate diagram with typed relationships? Describe the role of Pro Cloud Server in a multi-user setup? Architects who have used Sparx EA on real projects answer these immediately. Those who have only studied it tend to stall on the specifics.

MDG governance understanding

Repository governance is the clearest differentiator at mid-to-senior level. Hiring managers look for candidates who can explain what MDG Technology does with an example: “MDG restricts element creation to defined types, so when someone drops a Node into the Business Layer, the tool flags it. That is what keeps the repository consistent enough to query.” Strong candidates can describe how to spot governance drift, what a poorly governed repository looks like, and how to hold discipline alongside less experienced colleagues. A candidate who frames MDG as a metamodel governance mechanism, and argues specific configuration choices, is showing depth.

Stating intent clearly

Senior roles used to reward scripting: JScript, VBScript and the Automation Interface for bulk changes. AI now does most of those mechanics when an architect describes the change. The hiring signal has moved to whether the candidate can say precisely what should change, in which part of the model, under which rules, and how they would confirm it worked. Ask a candidate how they would add a new tagged value to every application in a domain and set it from a spreadsheet. A strong answer covers scope, the rule for each case, what to do with exceptions and how to check the result. Knowing the automation surface still helps, because it tells the architect what is possible.

Practice skills: what is evaluated

Repository governance behavior

Senior interviews often include a repository walk-through, either the candidate’s own work or a deliberately flawed repository they are asked to assess. What is the package structure? How are elements named? Are MDG element types used consistently? Are there informal elements that should be typed? Are cross-layer relationships correct? Candidates who run this assessment fluently, and have a clear view of what good looks like, are showing practice maturity.

Designing the stakeholder experience

Most senior processes include a communication exercise: present a view to a panel that includes non-technical assessors, and handle challenge. The panel is checking whether the candidate can explain choices in business terms, take questions calmly and pitch the detail to the room. With AI able to build views and navigation diagrams on request, the stronger candidates also talk about design: who opens the model, what question they arrive with, where they should land and how they drill down. That is the part of stakeholder work the architect still owns.

Architecture governance participation

Evidence of real governance work counts. Have you contributed to an architecture review board? Written architecture decision records? Managed an architecture contract on a program? These show that a candidate has worked inside a serious architecture governance practice.

Decision documentation

The ability to document a decision cleanly is assessed at senior level, often through a short written exercise: what was decided, which alternatives were weighed, the rationale, and the constraints that apply. Strong candidates produce concise, reasoned documents. Weaker ones produce long descriptions that avoid taking a position. AI can draft the record. The position in it has to be the architect’s.

Judging AI output

A line that has started appearing on senior scorecards is how the candidate works with AI in the model. Panels are not looking for a list of product names. They want to see that the candidate understands two things. First, AI reads the repository through element types and relationships, so an ungoverned repository yields poor answers. Second, AI output looks finished whether it is right or not, so someone has to check it.

A useful question is: what would have to be true about a repository for AI to answer “which applications support capability X?” reliably, and how would you check its answer? A candidate who talks about typing, relationship completeness and a spot check against what they know of the estate understands where the work is heading. A plain account of what they have and have not used counts for more than claimed expertise. For the reason governance quality drives AI quality, see why your EA repository quality determines your AI output quality.

Mindset: the hardest thing to teach

The distinction that most reliably separates strong candidates from merely credentialed ones is a consulting orientation. Strong architects ask what problem the architecture solves before they ask what it looks like. In an interview they describe the outcome their work enabled as well as the modeling choices behind it.

Compare two answers. “We built this application portfolio map because the consolidation program had no agreed list of applications to rationalize, and the map gave them a decision baseline they used at the first phase gate” is a consulting answer. “We built an application portfolio map using ArchiMate Application Components with tagged values” is a documentation answer. The first shows the candidate understands what architecture is for. Teams building a practice that delivers value select for it.

What strong candidates do differently

• They bring a portfolio. A working repository or screenshots of real governance work: a capability map, the package structure it lives in, the MDG profile that governs it, and the stakeholder feedback it generated.
• They talk in outcomes. “This view answered which applications were candidates for decommissioning” tells the panel more than “this is an ArchiMate Application Layer view.”
• They say how they checked AI-built work. If AI produced part of their portfolio, they explain what they asked for and what they corrected.
• They ask about the practice. The repository governance, the MDG profiles in use, how the team works with stakeholders and with AI. Those questions signal maturity and interest in doing the work well.

FAQ