⏱ 19 min read
Most companies hire enterprise architects for the wrong reason.
They hire one because the board wants “transformation.” Because a cloud program is drifting. Because there are too many systems and no one can explain how they fit together. Or because an auditor used the phrase technology risk concentration and suddenly everyone got serious.
That’s understandable. But it’s also the first mistake.
If you’re trying to choose the right enterprise architect, don’t start by looking for someone who can draw perfect diagrams, recite TOGAF terms, or run a governance meeting with a polished deck. That’s not the job. The real job is harder and much less neat: reduce complexity, make better trade-offs, and help the business move without blowing up risk, cost, or control. TOGAF training
A good enterprise architect is not the person who knows the most frameworks. It’s the person who can walk into a messy bank, an overgrown cloud estate, a Kafka platform nobody fully owns, or an IAM landscape held together by custom scripts and fear—and make it governable.
That is what you’re hiring for.
The simple version: what an enterprise architect actually does
Let’s get the SEO-friendly explanation out of the way early.
An enterprise architect aligns business strategy, applications, data, technology, security, and operating models so the company can change safely and efficiently.
That’s the clean definition.
In real life, the enterprise architect is the person who answers questions like these:
- Why do we have five customer masters?
- Should this platform be on AWS, Azure, on-prem, or split?
- Can Kafka be our integration backbone, or are we just creating a new dependency mess?
- Why does IAM take nine months to onboard one application?
- Which systems are strategic, which are tactical, and which should be retired?
- What standards are actually worth enforcing?
- Where do we accept complexity, and where do we kill it?
If the person you hire cannot answer those kinds of questions in plain English, they’re not ready.
And if they only answer with architecture theory, they’re definitely not ready.
The biggest misconception: enterprise architects are not senior solution architects with nicer slides
This is where many hiring decisions go wrong.
A strong solution architect can design a great platform. A strong domain architect can clean up a business area. A strong security architect can tighten controls. Those are valuable roles.
But enterprise architecture sits above and across all of that. It’s not “bigger solution architecture.” It’s a different discipline.
The right enterprise architect has to think in systems of systems. Not just technology systems. Organizational systems too. Funding models. Governance. Regulatory expectations. Delivery constraints. Vendor lock-in. Political gravity. Legacy inertia. All the ugly things that determine whether architecture survives contact with reality. ArchiMate for governance
That’s why some brilliant technologists fail in the role. They stay too low in the stack. Or they become architecture philosophers and float too high above reality. Both are dangerous.
The right enterprise architect has range.
They can discuss identity federation patterns with security teams, event backbone design with platform engineers, cloud landing zones with infrastructure leaders, and business capability maps with executives—without sounding fake in any of those rooms.
That is rare. Which is why hiring this role casually is expensive.
What to look for first: judgment, not certifications
I’ll say this plainly: certifications are weak signals for enterprise architecture.
Useful? Sometimes. Decisive? No.
I’ve met architects with every badge available who could not make a practical decision under pressure. I’ve also met excellent enterprise architects who were a bit rough around the edges, didn’t speak in framework language, and were ten times more effective because they had judgment.
Judgment is the core trait.
When choosing the right enterprise architect, ask:
- Can they simplify a complex problem without oversimplifying it?
- Can they make trade-offs visible?
- Do they know when standardization creates value and when it creates bureaucracy?
- Can they say “no” without becoming a blocker?
- Can they say “yes, but not like that” and offer a better path?
- Do they understand that architecture is partly technical, partly economic, and partly political?
That last one matters more than people admit. TOGAF roadmap template
An enterprise architect who ignores politics is not principled. They’re naive.
The real test: can they connect strategy to execution?
Every architecture leader says they want “strategic thinking.” Fine. But strategy without execution is decorative.
The right enterprise architect can connect:
- business goals
- capability changes
- application and data impacts
- security and control requirements
- platform implications
- delivery sequencing
- operating model changes
That chain matters.
For example, if a bank wants to improve digital onboarding for SME customers, the architect should not jump straight to “let’s modernize the customer platform.” That might be part of it, but it’s not the first thought.
The first thought should be something like this:
- What business capability is actually weak? Onboarding, KYC orchestration, customer identity proofing, document handling, decisioning?
- Which systems own customer identity today?
- How fragmented is IAM between workforce, customer, and partner access?
- Where are the handoffs?
- Are we blocked by legacy core banking integration, or by bad process design?
- Would event-driven integration via Kafka reduce coupling, or just hide poor ownership behind more topics?
- What controls must remain explicit because of regulatory expectations?
That is enterprise architecture work. Not just target-state pictures. Not just standards documents. Sequencing and consequence.
A useful hiring lens
Here’s a practical way to assess candidates.
If you use only one table from this article, use that one.
The contrarian view: don’t hire the “future-state” architect if you need a fixer
Some organizations need a visionary architect. Most think they do. Fewer actually do.
If your estate is fragmented, your cloud spend is rising without control, your IAM model is inconsistent, and your Kafka platform has become an unofficial dumping ground for integration, you do not need a pure visionary. You need an architect who can clean up a live environment while delivery continues.
That’s a different profile.
There’s a type of enterprise architect who is excellent at target-state design, reference architecture, and strategic narrative. Useful in the right context. But if your reality is operational chaos, these people can become accidental tourists. They describe the destination beautifully while the engine room is on fire.
In messy enterprises, especially banks and insurers, the best enterprise architects are often a little battle-scarred. They understand debt. They understand coexistence. They know architecture is often a game of containment before it becomes a game of redesign.
That may sound less glamorous. It’s also more useful.
How this applies in real architecture work
Let’s bring this down from theory.
In real enterprise architecture work, choosing the right architect changes how decisions get made week to week.
A good enterprise architect will:
- stop platform sprawl before it becomes permanent
- force ownership clarity for data, services, and events
- prevent “temporary” exceptions from becoming strategy
- challenge duplicate investments across domains
- identify where standardization helps and where autonomy should remain
- connect security controls to delivery patterns instead of bolting them on later
- make migration sequencing realistic
That sounds obvious. It isn’t.
Take cloud, for example. A weak architect often treats cloud as a destination. A strong architect treats cloud as a set of operating choices. They ask:
- What workloads benefit from elasticity?
- What services increase lock-in beyond our tolerance?
- How do we structure landing zones so teams can move fast without inventing their own security model?
- Which controls should be centralized and which federated?
- What does resilience mean in practice: multi-AZ, multi-region, multi-cloud, or just better recovery discipline?
Those are not implementation details. Those are enterprise decisions with cost and risk attached.
Same with Kafka. Weak architects often like Kafka because it feels modern and scalable. Strong architects know Kafka is not a universal integration cure. It is very good at some things and a bad fit for others.
In real work, the enterprise architect must decide:
- What events are true business events versus technical noise?
- Who owns topic schemas?
- How do we manage backward compatibility?
- Where do we need exactly-once semantics, and where are we pretending to need them?
- Are we building event-driven architecture, or are we just moving point-to-point spaghetti into a broker?
That distinction matters. A lot.
And in IAM, the gap between theory and reality gets even wider. Everyone says identity is foundational. Almost nobody funds it like it is. So the right enterprise architect has to bridge business urgency and security discipline.
That means understanding:
- workforce IAM versus customer IAM versus privileged access
- federation patterns across SaaS and internal apps
- role design and entitlement models
- lifecycle automation
- access review realities
- how identity decisions affect cloud adoption, zero trust, and audit readiness
An architect who cannot work in that level of practical detail will produce elegant irrelevance.
Common mistakes enterprise architects make
Let’s be honest about the profession for a minute.
Enterprise architects make some very predictable mistakes. If you’re hiring, you should screen for these hard.
1. They confuse standards with architecture
Standards matter. But architecture is not a giant list of approved technologies.
I’ve seen architecture teams produce beautiful standards catalogs while the enterprise remains deeply incoherent. Why? Because standards without ownership, transition paths, and consequence are just polite suggestions.
A real architect knows that standardization only works when it is tied to funding, platforms, delivery patterns, and governance. EA governance checklist
2. They ignore the operating model
This is one of the worst mistakes.
You can define a perfect target architecture and still fail if the operating model can’t support it. If product teams are autonomous but data governance is centralized and slow, your architecture has friction built in. If cloud controls are too manual, teams route around them. If IAM onboarding is painful, business units buy shadow SaaS. architecture decision record template
Architecture that ignores how work gets done is fantasy.
3. They over-index on technology novelty
Kafka, service mesh, zero trust, platform engineering, AI governance, multi-cloud. All useful in the right place. All overused in the wrong hands.
A mature enterprise architect is not impressed by modern words. They ask whether a thing solves a real problem better than the alternatives, in this enterprise, with these people, under these constraints.
That’s a much tougher standard.
4. They avoid hard trade-offs
Some architects try to stay popular. So they leave options open too long. They word everything carefully. They create “principles” that offend nobody and guide nothing.
That’s not architecture. That’s choreography.
At some point, someone has to say:
- we will consolidate here
- we will tolerate diversity there
- this platform is strategic
- this one is sunset
- this pattern is banned
- this exception expires in six months
A good enterprise architect is not reckless. But they are decisive.
5. They treat governance as a gate
Architecture governance should improve decision quality and delivery speed. Not just add approval steps.
If every project review feels like a design tribunal, teams stop engaging honestly. They present polished fiction. Risks get hidden. Architecture becomes theater.
The right architect builds governance that catches meaningful issues early, not governance that rewards deck-writing.
A real enterprise example: mid-sized bank modernization
Let’s use a realistic banking example.
A regional bank had grown through acquisition. It had:
- three customer onboarding journeys
- multiple IAM stacks across workforce and customer channels
- overlapping integration patterns: batch, APIs, ESB, Kafka
- two cloud providers in use, neither with consistent landing zone controls
- duplicated customer and party data
- rising audit findings around access control and traceability
Leadership thought they needed a new enterprise architecture function to “define the target state.”
That was partly true. But the real need was more specific: they needed an enterprise architect who could reduce architectural drift while preserving delivery momentum in regulated domains.
A weak hire would have spent six months producing capability maps, target-state diagrams, and principle catalogs. Some of that would be useful. Most of it would arrive too late.
The architect they actually needed—and eventually hired—did something different.
Step 1: framed the problem economically, not just technically
Instead of saying “the architecture is fragmented,” they said:
- onboarding costs are inflated because identity proofing, KYC, and account setup are duplicated
- audit exposure is increased because entitlement models differ across channels
- cloud cost is rising because platform controls are inconsistent
- Kafka is being used without clear event ownership, increasing operational risk
That got executive attention fast.
Step 2: separated strategic platforms from tolerated legacy
This was critical.
They identified:
- one strategic customer IAM platform for retail and SME channels
- one workforce identity authority with stronger joiner-mover-leaver automation
- Kafka as the strategic event backbone for domain events, not generic integration
- APIs as the default for synchronous cross-domain interactions
- the ESB as tolerated legacy with a retirement path
- one primary cloud control model, even though some workloads remained split across providers
Notice what they did there. Not “modernize everything.” Not “replace all legacy.” They created decision boundaries.
That is enterprise architecture at its best.
Step 3: fixed ownership before fixing technology
This is where many programs fail.
The architect forced explicit ownership for:
- customer identity
- party master data
- event schemas
- IAM role models
- cloud guardrails
- exception approvals
Without ownership, modernization turns into distributed ambiguity.
Step 4: used architecture to sequence change
They did not start with core replacement. They started with the highest-friction, highest-risk seams:
- customer onboarding orchestration
- identity federation for digital channels
- privileged access cleanup in cloud administration
- event model discipline in Kafka
- API and event standards tied to actual platform governance
This produced visible wins in under a year:
- faster onboarding changes
- reduced duplicate integrations
- better access audit outcomes
- lower architectural conflict between programs
That’s what a good enterprise architect delivers. Not just a future picture. A path.
What experience matters most?
People often ask whether they should hire from consulting, from internal architecture, from engineering leadership, or from a regulated industry.
My view: domain context matters more than many people admit, especially in complex enterprises like banks.
You do not always need someone from your exact industry. But if you operate in a highly regulated, control-heavy environment, don’t underestimate the value of someone who understands how architecture decisions show up in audits, incidents, and control failures.
For example, in banking:
- IAM is not just user convenience; it is access risk, segregation of duties, traceability
- Kafka is not just throughput; it is resilience, event lineage, replay discipline, ownership
- cloud is not just speed; it is control evidence, resilience, exit strategy, data handling
A candidate who has only worked in lightweight digital-native environments may struggle with this. Not because they’re weak, but because enterprise constraints are different. The architecture game is different when regulators, legacy estates, third-party dependencies, and control testing all matter.
That said, don’t over-correct and hire someone who only knows governance and legacy. You still need enough modern technical instinct to avoid preserving old mistakes in new formats.
The interview questions I would actually ask
If I were hiring an enterprise architect tomorrow, I would spend less time on methodology and more time on scenarios.
Here are the kinds of questions that reveal the truth.
Scenario 1: Kafka sprawl
“We have a growing Kafka platform. Teams like it. But topic ownership is unclear, schemas drift, and some teams are using it for near-real-time request-response patterns. What do you do?”
Good answer:
- establish event classification and ownership
- define when Kafka is appropriate versus APIs
- implement schema governance with domain accountability
- align operational support and replay expectations
- stop misuse without blocking legitimate event-driven design
Bad answer:
- “Create a center of excellence”
- “Define standards”
- “Use best practices”
Too vague. Not enough.
Scenario 2: IAM modernization in a bank
“We have separate IAM tools for workforce and customer channels, manual provisioning for many internal systems, and audit findings around privileged access. Where do you start?”
Good answer:
- separate customer IAM, workforce IAM, and PAM concerns
- prioritize privileged access and lifecycle automation
- align target role models with actual business processes
- integrate with cloud admin controls and critical apps first
- avoid trying to redesign every role in phase one
Bad answer:
- “Implement zero trust”
- “Move to one identity platform”
Sounds nice. Usually nonsense in phase one.
Scenario 3: cloud platform inconsistency
“Different business units have built different cloud landing zones. Security is worried. Delivery teams are tired of rework. How do you approach standardization?”
Good answer:
- identify mandatory controls versus optional patterns
- define a common platform baseline and guardrails
- preserve some domain autonomy above the baseline
- migrate through incentives and policy, not just mandates
- tie architecture standards to deployment pipelines and runtime controls
Bad answer:
- “Centralize everything”
- “Let each team choose”
Both are lazy extremes.
Red flags when choosing an enterprise architect
A few warning signs are worth taking seriously.
They talk only in framework language
If every answer sounds like a certification exam, be careful. Real architects speak in consequences, trade-offs, and delivery reality.
They cannot explain failure
Ask what architecture decision they got wrong. If they have no real answer, they either lack experience or lack self-awareness.
They are too abstract about legacy
If they talk as though legacy can simply be replaced once the target is defined, they have not lived through real enterprise change.
They have no opinion on governance
An enterprise architect without a strong view on governance is incomplete. The role exists partly to shape decision mechanisms.
They have no scars from organizational resistance
If they’ve never had standards ignored, domain leaders push back, or delivery teams reject architecture constraints, then they probably haven’t operated at scale.
What the right enterprise architect feels like in practice
This is a bit subjective, but experienced leaders will recognize it.
The right enterprise architect usually creates a few effects pretty quickly:
- meetings become clearer because trade-offs are named
- technology debates become less ideological
- standards become more enforceable because they are tied to platforms and delivery
- business stakeholders hear fewer vague promises and more structured options
- engineering leaders feel challenged but not patronized
- risk and security teams get brought in earlier, not later
- legacy is discussed honestly, not apologetically
In other words, the role creates coherence.
Not perfection. Coherence.
That’s enough to move an enterprise a long way.
Final advice: hire for courage, range, and restraint
If I had to reduce this whole article to one hiring principle, it would be this:
Choose the enterprise architect who can make your organization simpler without pretending it is simple.
That requires courage, because they will have to make hard calls.
It requires range, because they must work from boardroom intent down to platform consequences.
And it requires restraint, because the wrong architect over-designs, over-governs, and over-promises.
The best enterprise architects are opinionated, but not theatrical. Technical, but not trapped in technology. Strategic, but not detached from delivery. They know when Kafka is the right backbone and when it’s just fashionable plumbing. They know IAM is never just an identity problem. They know cloud is not transformation by default. They know banking architecture is full of compromise—and that good compromise is still architecture.
So when you choose the right enterprise architect, don’t ask who sounds the smartest.
Ask who will help you make fewer bad decisions, faster.
That’s the real job.
FAQ
1. What qualifications should a good enterprise architect have?
Strong experience matters more than formal qualifications. Certifications can help, but the essentials are judgment, business understanding, technical breadth, governance experience, and the ability to make practical trade-offs in real environments.
2. Should an enterprise architect be highly technical?
Yes, but not narrowly technical. They need enough depth to challenge engineers, security teams, and platform leaders credibly. But they also need business and operating model awareness. Pure technologists often struggle in the role.
3. What is the difference between an enterprise architect and a solution architect?
A solution architect focuses on designing a specific solution or program. An enterprise architect looks across the whole estate—business capabilities, data, platforms, security, governance, cost, and sequencing—to ensure decisions work together over time.
4. How do you know if your company needs an enterprise architect?
Usually when complexity starts hurting delivery, risk, cost, or control. Common signs include duplicate platforms, inconsistent cloud patterns, unclear system ownership, IAM fragmentation, integration sprawl, and repeated architecture debates with no lasting resolution.
5. What industries benefit most from strong enterprise architects?
Any large or complex enterprise can benefit, but the role is especially valuable in banking, insurance, healthcare, government, telecom, and other heavily regulated environments where architecture decisions directly affect risk, compliance, resilience, and change speed.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture is a discipline that aligns an organisation's strategy, business processes, information systems, and technology. Using frameworks like TOGAF and modeling languages like ArchiMate, it provides a structured view of how the enterprise operates and how it needs to change.
How does ArchiMate support enterprise architecture practice?
ArchiMate provides a standard modeling language that connects strategy, business operations, applications, data, and technology in one coherent model. It enables traceability from strategic goals through business capabilities and application services to the technology platforms that support them.
What tools are used for enterprise architecture modeling?
The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign Enterprise Studio. Sparx EA is the most feature-rich option, supporting concurrent repositories, automation, scripting, and integration with delivery tools like Jira and Azure DevOps.