Enterprise Architect interview questions, with worked answers
Fifteen questions that enterprise architect interviews come back to, for a domain architect moving up, an enterprise architect and a senior enterprise architect on the way to lead enterprise architect. Each has what the interviewer is checking, a short answer, the full answer in plain words, a weak answer to avoid and a likely follow-up.
Contents
How to use these questions
Interviewers for this role often play the sceptical executive. Answer in the language of the business first, money, risk and time, and bring in the frameworks only where they help. Give a real landscape you worked on, what you recommended and what the business decided.
What an enterprise architect is expected to know
- The practice: enterprise architecturePlan the whole landscape of systems, data and processes against the strategy of the business., from capability maps to roadmaps and reviews.
- The language: TOGAFUse TOGAF's method and vocabulary where they help, and leave out what the company does not need. and ArchiMateModel capabilities, applications and technology in ArchiMate so that others can read and reuse it., or another framework, as tools not as goals.
- The layers: solution designRead and challenge solution designs so that each project fits the target landscape., cloudSet the company's cloud direction: what moves, to which platforms, under which rules., the ERP and the data, well enough to judge projects.
- The people: executives and business ownersWin executives, business owners and IT leads for one roadmap that they fund and follow., and the changePlan the change for people and processes that every new landscape brings. each roadmap brings.
The repository tools are named in ads side by side and none is a must: LeanIX, Ardoq, Bizzdesign and MEGA HOPEX hold the landscape, Archi edits ArchiMate models for free. Interviewers care more about whether people trust and use the repository than about the tool.
Capabilities, target and portfolio
What is a business capability, and how do you build a capability map with the business?
What they check: the backbone of most enterprise architecture work.
Short answer: "A business capability is something the business must be able to do, such as pricing or onboarding customers, independent of who does it or which system supports it. A capability map lists them on one page in two or three levels. I build it in workshops with the business, not in IT, and then hang the applications and their problems on it."
The full answer: Capabilities change slowly while organisations change often; that is why the map stays useful after a reorganisation.
A weak answer: "It is a list of our departments." Follow-up: "Two units claim the same capability." Say how you settle it.
How do you describe a target architecture and the roadmap to reach it?
What they check: turning a strategy into steps.
Short answer: "The target architecture is the landscape we want in three to five years, described by capability: which platforms, which data, which integration, and what disappears. The roadmap is the order of changes to get there, each with its business case, its dependencies and an owner, with the first year in detail and the rest in outline."
The full answer: A target nobody funds is a drawing; tie each step to a budget decision.
A weak answer: "We describe the ideal state." Follow-up: "The strategy changed after six months." Say what you change.
How do you assess the application portfolio and decide what to retire?
What they check: rationalisation that saves real money.
Short answer: "The application portfolio is every application the company runs, with its owner, users, cost, technical health and the capabilities it supports. I score each on business value and technical fit; low on both is a candidate to retire, high value but poor fit a candidate to renew. Rationalisation means acting on that list, one decision at a time."
The full answer: Retiring an application needs its data and its last users moved; plan that, or the system lives on in a corner.
A weak answer: "We list all applications in a spreadsheet." Follow-up: "Every owner says their application is critical." Say how you decide.
How do you make technical debt visible to people who fund the work?
What they check: speaking about technology in business terms.
Short answer: "Technical debt is the extra cost and risk a company carries because of shortcuts and ageing technology. I show it by capability: which capabilities rest on unsupported systems, what it costs to keep them, and which incidents or delays they caused. Then I propose what to fix first and what it frees."
The full answer: Executives decide on risk and money; a list of old version numbers decides nothing.
A weak answer: "Everything old should be replaced." Follow-up: "There is budget for one fix this year." Say which and why.
Principles, standards and the board
How do you set up an architecture board that helps rather than blocks?
What they check: governance that teams accept.
Short answer: "An architecture board is a regular meeting where projects bring decisions that affect the landscape. I keep it small, publish what it reviews and why, answer within days, and let teams decide everything that stays inside their own solution. Most of its work is advice early, not approval late."
The full answer: Measure the board by how fast it answers and how often projects come early on their own.
A weak answer: "Every project needs our approval." Follow-up: "A project went live without asking." Say what you do.
Which architecture principles would you write first, and how do you make them stick?
What they check: guidance that decides real cases.
Short answer: "Few principles, each with what it means and what it costs: reuse before buy before build, data has one owner, cloud services before own data centres where the rules allow. I write them with the business and IT leads, and point to them in every board decision, so people see them used."
The full answer: A principle nobody can break is too vague; a good one sometimes says no.
A weak answer: "We follow the usual practices." Follow-up: "Two principles conflict on a project." Say how you decide.
How do you set technology standards, and how do you retire them?
What they check: keeping the landscape simple without freezing it.
Short answer: "I keep a short list of standard technologies by area, each marked as preferred for new work, allowed, or on the way out, with the date it will be retired. Teams can ask to try something new; a successful trial can become a standard."
The full answer: A standard without an end date stays forever; the list of what is leaving matters as much as the list of what is in.
A weak answer: "We allow everything." Follow-up: "A team wants a tool that is not on the list." Say what you ask.
How do you build the business case for a platform change?
What they check: value in numbers the business recognises.
Short answer: "I compare doing nothing with two options over five years: costs to change and to run, savings from retired systems, risks removed, and what the business can do that it cannot today. I state the assumptions, show the cost of delay, and let finance check the figures."
The full answer: Name who gains the value and who carries the cost; when they are different units, the case needs both.
A weak answer: "The new platform is modern." Follow-up: "Finance halves your savings figure." Say whether the case still holds.
How do you use TOGAF and ArchiMate in practice?
What they check: frameworks as tools, not rituals.
Short answer: "I use parts of TOGAF's method, such as the steps from a vision to a roadmap and the idea of an architecture repository, and leave out what the company does not need. ArchiMate is a modelling language for business, application and technology views; I use a small part of it so that business readers can follow. Zachman is another way to classify what is described."
The full answer: The repository, kept current in a tool such as LeanIX, Ardoq, Bizzdesign, MEGA HOPEX or Archi, is worth more than any one diagram.
A weak answer: "We follow TOGAF fully." Follow-up: "Executives find the diagrams too complex." Say what you change.
Mergers, cloud, regulation and data
After a merger, how do you bring the two IT landscapes together?
What they check: a classic, high-stakes case.
Short answer: "First the business decisions: which processes, products and brands go on. Then both landscapes on one capability map, a choice per capability, keep one, keep the other or replace both, and an order that protects revenue, usually finance and customer-facing systems with care. Day-one needs, such as email and reporting, come first."
The full answer: Choose by capability and data, not by which company bought which; people accept that better.
A weak answer: "The buyer's systems win." Follow-up: "The smaller company's CRM is clearly stronger." Say what you recommend.
How does enterprise architecture shape a move to the cloud?
What they check: strategy rather than single migrations.
Short answer: "I set what moves, in which order and to which platforms, from the application portfolio: retire, replace with a cloud service, move, or keep. I agree the rules for data, security and cost with the teams that run them, and make sure each migration follows them, so the company does not end up with a new landscape as tangled as the old one."
The full answer: A cloud strategy is mostly a portfolio decision; the technology choices follow.
A weak answer: "Everything goes to the cloud." Follow-up: "A supervisor asks how you would leave the cloud provider." Say what you show.
How do regulation and the supervisors' rules change your architecture work?
What they check: awareness that the landscape is read from outside.
Short answer: "In regulated firms, supervisors want to see that critical functions and the systems and suppliers behind them are known, tested and can recover. Regulation such as the EU's DORA for financial firms turns the architecture map into evidence. I keep that map current and work with risk and compliance on what each rule asks."
The full answer: Each country has its own supervisor and rules; the company's legal and compliance teams interpret them, the architect makes them visible in the landscape.
A weak answer: "Compliance handles regulation." Follow-up: "The supervisor asks which systems support payments." Say how fast you answer.
How would you guide the company's use of AI and data across the landscape?
What they check: today's strategic questions.
Short answer: "I map where AI could serve a capability and what data it would need, check that the data has owners and is reliable, and set a few platform choices so that each team does not buy its own. I add AI use to the risk view, with rules for what may be automated and what needs a person."
The full answer: AI projects fail on data more than on models; data governanceKnow how data is owned and governed, so the landscape keeps data reliable across systems. is part of the answer.
A weak answer: "Every unit tries its own AI tools." Follow-up: "Five units bought five AI products." Say what you do.
How do you show the value of enterprise architecture to stakeholders who doubt it?
What they check: a practice that earns its place.
Short answer: "With results they recognise: systems retired and their cost, a merger finished faster, a supervisor's question answered in a day. I report a few such figures each year and make the architects useful to projects early, so the value is felt before it is reported."
The full answer: A practice that only produces documents will be cut in the next budget round; one that saves money will not.
A weak answer: "Architecture is important for the long term." Follow-up: "The CFO wants to cut the team in half." Say what you show.
Senior rounds
As a senior enterprise architect, how would you grow a domain architect into an enterprise architect?
What they check: building the practice through people.
Short answer: "I give a domain architect a cross-domain question, such as the customer data used by three units, with my review, then a seat on the architecture board and a roadmap of their own. I coach the conversations with executives, which are usually the new part."
The full answer: A senior or lead enterprise architect is judged by the practice around them: its trust, its speed and the people it develops.
A weak answer: "They learn by watching." Follow-up: "Your best domain architect wants to stay a specialist." Say how you keep them.
Your CV for these questions
Each job on your CV invites the questions above: which landscape, which roadmap, which board and what it changed. Give those stories a line each, written so a chief architect wants to hear more:
| Skill | Weak line | Strong line, with proof |
|---|---|---|
| Target architecturePlan the whole landscape of systems, data and processes against the strategy of the business. | Wrote target architectures. | Set the target architecture for customer service across three countries; the first two roadmap steps were funded. |
| RepositoryKeep an architecture repository current enough that people trust what it shows. | Maintained the EA tool. | Rebuilt the architecture repository with the owners; it now answers supervisors' questions the same day. |
| MergerPlan the change for people and processes that every new landscape brings. | Supported a merger. | Led the landscape decisions after a merger; two ERPs became one within eighteen months. |
| Cloud strategySet the company's cloud direction: what moves, to which platforms, under which rules. | Defined a cloud strategy. | Wrote the cloud strategy from the application portfolio; a third of the applications were retired, not moved. |
| Business caseWin executives, business owners and IT leads for one roadmap that they fund and follow. | Prepared business cases. | Built the business case for a new integration platform with finance; the board approved it in one meeting. |
Put your CV beside an enterprise architect job you want with the free score; the area it finds thin is the one to rehearse first, with a landscape you can draw from memory.
Key takeaways
- Speak about money, risk and time first; bring in frameworks only where they help.
- Capabilities make a landscape readable for the business.
- A target architecture matters only with a funded roadmap.
- Governance should answer fast and advise early.
- Senior roles add the practice itself and the people in it.
Frequently asked questions
- What do enterprise architect interviews ask most?
- Capabilities, the target architecture, the roadmap, the application portfolio, the board and the business case.
- Is there a case study?
- Often: a company with too many systems, a merger or a cloud move, and a plan to present.
- Do I have to know TOGAF in detail?
- No. Know its main ideas and say how you used parts of it, or of another framework, in practice.
- Can I move into the role from solution architecture?
- Many do; show work across several solutions and business units, not only inside one project.
- How should I prepare in a week?
- Draw a capability map of a company you know, prepare one roadmap story and one merger or cloud story, and practise saying each in business terms.