How to Choose the Right Enterprise Architect for Your

⏱ 19 min read

Most companies do not have an enterprise architecture problem. They have a wrong-enterprise-architect problem.

That sounds harsh, but it is true more often than people want to admit. ArchiMate in TOGAF ADM

A lot of organizations hire someone with a polished framework vocabulary, a few TOGAF diagrams, and a habit of saying “capability model” every seven minutes. Then six months later, nothing is clearer, delivery is slower, engineering is irritated, security is still fragmented, and the CIO is wondering why the architecture team produced 84 slides but still cannot answer a simple question like: _Should we standardize on Kafka globally or not?_

That is the real test.

The right enterprise architect is not the person who can create the most diagrams. It is the person who can help the organization make better technology decisions at enterprise scale, under political pressure, legacy constraints, budget limitations, and constant change.

If you are choosing an enterprise architect for your organization, here is the simple version early:

A good enterprise architect connects business strategy, operating model, technology reality, and delivery execution.

A bad one sits above the work and mistakes abstraction for value.

That is the short SEO-friendly answer. Now let’s get into the real one.

What an Enterprise Architect Actually Does

Let’s clear up the confusion first, because a lot of hiring mistakes start here.

An enterprise architect is not just:

• a senior solution architect
• an infrastructure strategist
• a cloud migration lead
• a governance reviewer
• a standards librarian
• a framework enthusiast

Those can all be part of the role. But the actual job is broader and harder.

A real enterprise architect helps the organization answer questions like:

• Which technology capabilities should be standardized enterprise-wide?
• Where do we allow variation and where do we force consistency?
• How do we reduce complexity without slowing the business down?
• What should be modernized now, later, or never?
• How do security, identity, data, integration, and cloud decisions fit together?
• Which architecture decisions are local, and which are enterprise-level?
• How do we move from current-state mess to a target state that delivery teams can actually reach?

That last part matters. A target state that nobody can reach is not architecture. It is decoration.

In real architecture work, the enterprise architect sits in the middle of competing forces:

• business wants speed
• security wants control
• engineering wants autonomy
• operations wants stability
• finance wants lower cost
• compliance wants traceability
• product teams want fewer approvals
• executives want one-page clarity on ten-year complexity

You need someone who can operate in all those conversations without becoming vague, political, or doctrinaire.

The Biggest Hiring Mistake: Confusing Seniority With Enterprise Thinking

I see this all the time. A company says, “We need an enterprise architect,” and then hires one of these profiles:

1. The senior solution architect who is excellent in one domain but has never really worked across the enterprise.
2. The ex-manager who knows governance but not technology deeply enough.
3. The framework-first architect who can classify everything and decide almost nothing.
4. The cloud architect who thinks every enterprise problem is a cloud platform problem.
5. The ivory-tower strategist who avoids delivery because delivery is messy.

None of those profiles are automatically wrong. But none are automatically right either.

Enterprise architecture is not “more senior architecture.” It is a different kind of work.

A strong enterprise architect must think in layers at once:

• business model
• operating model
• process and capability
• application landscape
• integration patterns
• data domains
• identity and access
• security controls
• platform strategy
• cloud and infrastructure
• governance and funding
• migration sequencing

And they need to switch between executive language and technical detail with almost no friction.

If your candidate cannot explain IAM federation to engineers and also explain identity operating model risk to a COO, they are probably not ready.

What to Look For First: Evidence of Judgment

If I had to reduce enterprise architect selection to one word, it would be this:

judgment

Not certifications. Not polished decks. Not architecture repository hygiene. Judgment.

Because enterprise architecture is mostly decision-making under ambiguity.

For example:

• Should a bank run one Kafka platform globally or multiple regional clusters?
• Should IAM remain centralized or move to domain-owned patterns with federated governance?
• Should cloud landing zones be standardized tightly or allow BU-specific variants?
• Should a legacy payments platform be wrapped, replaced, or left alone for five years?
• Should data ownership follow business domains or existing application boundaries?

There is no universal textbook answer. There are trade-offs.

A real enterprise architect can say:

> “Centralization gives us consistency and risk reduction, but if we over-centralize Kafka operations we will create a throughput bottleneck in delivery. We need a platform model with strong enterprise standards, shared controls, and delegated onboarding, not pure central command.”

That is judgment. It is practical. It is balanced. It understands both architecture and organizational behavior.

A weaker architect says:

> “Best practice is to create a centralized event backbone.”

That phrase — _best practice_ — has probably done more damage in enterprise architecture than almost anything else. Context matters. Always.

The Right Enterprise Architect Understands Real Work, Not Just Models

This is where many hiring decisions go sideways.

Organizations say they want strategic thinking, and yes, they do. But strategy without delivery understanding is dangerous.

The enterprise architect you want should understand how architecture shows up in real work:

• project intake
• portfolio planning
• platform engineering
• security review
• cloud adoption
• integration design
• IAM onboarding
• domain ownership disputes
• vendor selection
• modernization sequencing
• regulatory audits
• operational failure analysis

If they have never lived through a messy migration, a failed integration program, a cloud cost backlash, or an identity consolidation effort, be careful.

Because architecture is easy in PowerPoint. It gets real when:

• one business unit refuses your standard
• a regulator asks for traceability
• a merger doubles your IAM complexity
• Kafka topic ownership becomes political
• cloud networking constraints block your target design
• teams bypass architecture because governance takes too long

That is the job. Not drawing future-state boxes.

A Simple Test: Can They Make Complexity Simpler Without Lying?

This is one of the best signals.

A strong enterprise architect can simplify complexity without pretending it is simpler than it is.

For example, if you ask:

“How should we think about enterprise IAM?”

A weak answer sounds like this:

> “We need a unified identity strategy leveraging zero trust principles, centralized policy enforcement, and a modernized control plane.”

That sounds expensive and vague.

A stronger answer sounds like this:

> “We have three separate identity problems, not one: workforce identity, customer identity, and machine identity. We should not solve them with one product story. We need common governance and control objectives, but different operating models. Workforce identity should be centralized. Customer identity may need regional variation. Machine identity needs automation first, not committee governance.” ArchiMate for governance

That is the voice of someone who has done the work.

They decompose. They prioritize. They avoid fake simplicity.

The Contrarian View: Don’t Hire the Most “Enterprise” Person

Here’s a view some people won’t like: the best enterprise architect is often less ceremonial and more technical than organizations expect.

Many companies still imagine the role as a kind of architecture statesman. Someone who floats above engineering and translates strategy into governance. That can work in a very mature organization. In most places, it fails. EA governance checklist

Why? Because modern enterprise architecture sits directly on top of hard technical realities:

• cloud tenancy and landing zone patterns
• IAM federation and policy boundaries
• event streaming architecture with Kafka
• API lifecycle and integration sprawl
• data platform ownership
• resilience and observability
• regulatory controls in distributed systems

If your enterprise architect cannot reason credibly about these things, they will get ignored by the people who actually build the enterprise.

And frankly, they should.

I would take a technically credible architect with imperfect executive polish over a polished strategist with shallow technical depth almost every time.

Not because technology is everything. It isn’t. But because without technical credibility, enterprise architecture becomes advisory theater.

What Good Enterprise Architects Do in Practice

Let’s get concrete.

In real architecture work, a strong enterprise architect usually does five things well.

1. They identify which decisions are enterprise decisions

This is huge.

Not every architecture decision should be made centrally. In fact, one of the worst habits in enterprise architecture is overreaching.

Enterprise decisions usually involve one or more of these:

• shared risk
• shared cost
• shared platforms
• regulatory exposure
• interoperability requirements
• identity, data, or security consistency
• long-term lock-in consequences

Examples:

• IAM standards? Enterprise decision.
• Kafka platform operating model? Enterprise decision.
• Cloud account structure and network boundaries? Enterprise decision.
• UI framework for one internal app? Usually not.

The wrong architect pulls everything upward. The right one knows where to stop.

2. They create useful constraints

Architects love the word “standards,” but constraints are often the more useful concept.

A good enterprise architect says:

• “You may choose your service design approach, but all customer events must use the enterprise event taxonomy.”
• “You may deploy in AWS or Azure where approved, but IAM integration must use common federation patterns.”
• “You may use domain-specific databases, but regulated customer data must follow enterprise classification and retention controls.”

That gives teams room to move while preserving coherence.

3. They know migration matters more than target state

This is a big one. Maybe the biggest.

Anyone can draw a target state. The hard part is sequencing the move.

The right enterprise architect thinks in transition architectures:

• What can change first?
• What dependencies block movement?
• Which legacy systems must be isolated before replacement?
• How do we avoid a big-bang IAM consolidation disaster?
• What can be standardized through platform adoption instead of mandates?

The wrong architect designs the destination and leaves the journey to others. That is not leadership. That is outsourcing the difficult part.

4. They use governance selectively

Governance should reduce bad decisions, not create bureaucratic scar tissue.

Good enterprise architects build lightweight mechanisms:

• decision records
• architecture principles tied to actual trade-offs
• reference patterns
• exception processes with expiry dates
• review checkpoints aligned to funding and risk
• platform standards with self-service onboarding

Bad architects create architecture review boards that become a tax on delivery.

5. They know architecture is organizational design in disguise

This is one of the truths people avoid.

Many architecture failures are not technical failures. They are operating model failures.

You can design the perfect Kafka strategy, but if no team owns schema governance, topic lifecycle, and platform onboarding, you do not have a strategy. You have a slide. architecture decision record template

You can define an enterprise IAM model, but if HR, security, application owners, and infrastructure teams do not have aligned responsibilities, your access lifecycle will remain broken.

A good enterprise architect sees org design, funding model, ownership, and incentives as part of architecture. Because they are.

Common Mistakes Enterprise Architects Make

Let’s be honest about the profession for a minute.

Architects make some very predictable mistakes.

Here are the big ones.

Mistake 1: Confusing framework compliance with architecture quality

You can have excellent TOGAF artifacts and still make terrible decisions. TOGAF training

Frameworks can help with structure. They are not substitutes for thinking.

Mistake 2: Designing for purity instead of constraints

Architects often chase clean patterns and ignore existing reality:

• legacy contracts
• vendor dependencies
• regional regulations
• M&A baggage
• team capability gaps
• funding cycles

Real architecture is compromise with intent.

Mistake 3: Standardizing too much

This one is epidemic.

Not everything should be standardized. Over-standardization creates shadow IT, resentment, and slower delivery.

Standardize where the enterprise gains leverage. Leave room elsewhere.

Mistake 4: Ignoring identity until late

IAM is usually treated like a support function until it becomes the thing blocking cloud adoption, API exposure, zero trust ambitions, audit findings, and M&A integration.

Any enterprise architect who does not understand identity deeply enough is missing one of the central control planes of the modern enterprise.

Mistake 5: Treating integration as an application concern only

Integration is enterprise architecture territory.

If every team invents its own API style, event structure, Kafka topic naming, and ownership model, the enterprise becomes expensive to change.

Mistake 6: Producing target states with no funding path

If your roadmap depends on ten programs nobody has approved, it is not a roadmap. It is a wish list.

Mistake 7: Becoming an approval bottleneck

The fastest way to make architecture irrelevant is to make it slow.

Teams will route around you. And honestly, they should.

A Useful Hiring Table

Here is a practical way to evaluate candidates.

Use this table in interviews. Better yet, turn each row into a scenario question.

Real Enterprise Example: A Bank Trying to Modernize Integration, Identity, and Cloud

Let’s use a realistic banking example, because banking exposes architecture quality very quickly.

Imagine a regional bank with these characteristics:

• 20+ years of legacy systems
• multiple online channels
• separate business units for retail, commercial, and wealth
• fragmented IAM landscape
• on-prem core systems
• cloud adoption happening unevenly
• event streaming growing fast, mostly through local team decisions
• regulatory pressure increasing around access governance and resilience

The bank decides it needs stronger enterprise architecture.

What the wrong enterprise architect does

The wrong hire starts with a massive current-state assessment. Six months later there are capability maps, application heatmaps, and a target-state architecture showing:

• one enterprise IAM platform
• one enterprise Kafka backbone
• one hybrid cloud operating model
• one enterprise API standard
• one master data vision

It all looks coherent. It is also mostly unusable.

Why?

Because the architect did not answer the hard questions:

• Which business unit funds the Kafka platform team?
• Can wealth management data legally flow through the same event infrastructure in all jurisdictions?
• Which IAM use cases move first: workforce SSO, privileged access, customer identity, or service-to-service auth?
• Which legacy systems can publish events natively and which need CDC or adapters?
• How do cloud landing zones differ for regulated workloads?
• Who owns schema governance and API lifecycle?
• What exceptions are acceptable during transition?

So delivery teams keep doing what they were doing. Architecture becomes a parallel narrative.

What the right enterprise architect does

A stronger enterprise architect approaches the same bank differently.

First, they break the problem down into enterprise decision domains:

1. Identity and access
2. Integration and event streaming
3. Cloud control model
4. Data governance and regulated data handling

Then they define where enterprise consistency is required.

For IAM:

• centralize workforce identity
• define enterprise authentication and authorization patterns
• create a common control model for joiner/mover/leaver processes
• separate customer IAM strategy from workforce IAM
• automate machine identity lifecycle early

For Kafka:

• establish an enterprise event platform model
• define standards for topic ownership, schema management, retention, and resiliency
• allow domain-owned producers and consumers within enterprise guardrails
• avoid turning the central platform team into a ticket queue

For cloud:

• standardize landing zone controls, network patterns, logging, and identity integration
• allow application teams some service choice within approved boundaries
• tie cloud patterns directly to risk tiers and regulatory classes

Then — and this is the important part — they create a transition plan.

Transition plan example

Phase 1

• consolidate workforce SSO
• establish cloud landing zone baseline
• create Kafka platform team and schema standards
• onboard first two high-value event domains

Phase 2

• integrate privileged access controls
• migrate selected digital channels to common identity patterns
• move event-driven customer notification services to enterprise Kafka
• define regional controls for regulated data movement

Phase 3

• modernize machine identity and service auth across cloud-native workloads
• retire duplicate integration middleware for approved use cases
• implement enterprise-wide event catalog and lineage

Notice what is happening here.

This architect is not selling a fantasy end-state. They are creating architectural momentum.

That is what good enterprise architecture looks like in a bank, or really anywhere.

How to Interview for the Role

Please do not interview enterprise architects with only biography questions.

Questions like these are nearly useless:

• “Tell us about your architecture background.”
• “What frameworks do you use?”
• “How do you engage stakeholders?”

Fine as warm-up. Not enough.

Use scenario questions instead.

Examples:

Scenario 1: Kafka standardization

“You have five business units using Kafka differently. Some are on-prem, some in cloud, some use managed services. Leadership wants one enterprise strategy. What do you do in the first 90 days?”

Look for:

• segmentation of decision areas
• operating model thinking
• standards vs autonomy balance
• migration realism
• ownership model clarity

Scenario 2: IAM fragmentation

“We have separate IAM stacks for employees, partners, and customers. Audit findings are increasing. Product teams complain identity is slowing delivery. How would you approach this?”

Look for:

• distinction between identity domains
• control objectives
• lifecycle and automation thinking
• business risk framing
• realistic sequencing

Scenario 3: Cloud governance backlash

“Engineering says enterprise architecture is slowing cloud adoption with too many reviews. Security says controls are inconsistent. What would you change?”

Look for:

• platform and guardrail approach
• governance redesign
• self-service thinking
• risk-tiered controls
• empathy for both sides

A good architect will not answer in slogans. They will structure the problem and make choices.

Red Flags You Should Not Ignore

A few warning signs are worth calling out directly.

Do not ignore candidates who:

• speak fluently but avoid specifics
• cannot explain failures from their past
• treat all standardization as inherently good
• think governance is the main product of architecture
• have no serious view on IAM
• reduce cloud strategy to vendor selection
• see Kafka or APIs as purely technical tooling rather than enterprise coordination mechanisms
• cannot discuss funding, ownership, and operating model
• have never had to win over skeptical engineering teams
• seem proud of how many review boards they set up

Also, be careful with candidates who always describe themselves as “strategic.” Sometimes that means they have not been close to real delivery in years.

Strategy matters. But strategy detached from execution becomes self-flattering fiction very fast.

The Best Enterprise Architects Are Translators With Teeth

This is probably the phrase I would use if I had to summarize the role.

The best enterprise architects are translators with teeth.

They translate:

• business goals into architectural implications
• technical constraints into executive choices
• risk concerns into design controls
• platform patterns into team-level practices
• target states into funded transitions

But they also have teeth. Meaning: they can hold a line when it matters.

They know when to say:

• no, we cannot let every business unit invent its own customer identity model
• no, Kafka without schema governance is not an enterprise platform
• no, cloud freedom without IAM and network standards is just distributed risk
• no, this integration exception cannot be permanent

The role is not about being agreeable. It is about being useful.

And usefulness in enterprise architecture often requires saying uncomfortable things clearly.

Final Thought: Hire for Decision Quality, Not Architectural Theater

If you remember one thing from this article, make it this:

Choose the enterprise architect who improves enterprise decision quality.

Not the one with the best diagrams.

Not the one with the most frameworks.

Not the one who sounds the most “strategic.”

Not the one who promises harmony without trade-offs.

Choose the one who can walk into a messy organization and help it decide:

• what must be standardized
• what should remain flexible
• what gets funded first
• what risk is acceptable
• what target state is realistic
• how to move without creating architecture drag

Because that is the work.

In banking, in cloud programs, in IAM modernization, in Kafka platform strategy, in post-merger integration, in regulatory environments — that is what separates architecture that matters from architecture that decorates.

And honestly, the industry needs fewer decorators.

FAQ

1. What is the most important quality in an enterprise architect?

Judgment. Specifically, the ability to make and explain trade-offs across business, technology, risk, and delivery constraints.

2. Should an enterprise architect be hands-on technically?

Not necessarily coding every day, but yes, they need strong technical credibility. If they cannot reason about cloud, IAM, integration, data, and platform trade-offs, they will struggle to influence real decisions.

3. What is the difference between an enterprise architect and a solution architect?

A solution architect focuses on a specific initiative or system. An enterprise architect focuses on cross-cutting decisions, standards, target states, and transition planning across the organization.

4. How do you know if your enterprise architect is adding value?

Look for clearer decisions, better standardization where it matters, reduced technology sprawl, faster delivery through better guardrails, and roadmaps that teams can actually execute.

5. What is a common failure mode for enterprise architects?

Becoming too abstract and too governance-heavy. When architecture becomes a review function instead of a decision and enablement function, teams stop seeing it as valuable.

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.