Role, responsibilities & career path

A typical job description

This composite reflects what enterprise architect roles at mid-size and scaling organizations usually ask for. Real postings vary a lot, so read them for the balance between strategy, governance, and hands-on work.

Purpose of the role

Shape the organization’s business and technology landscape so that it supports the strategy: connecting business goals to architectural direction, guiding investment, and helping teams make coherent decisions.

Key responsibilities

• Translate business strategy into target architectures and capability-based roadmaps
• Develop and maintain the business capability map and application portfolio
• Define architecture principles, standards, and reference architectures
• Lead architecture decision-making for cross-cutting and enterprise-level concerns; maintain the decision log
• Advise on build/buy/SaaS decisions, vendor selection, and business cases
• Run or contribute to architecture governance forums
• Build and lead a community of practice across engineering
• Identify and manage architecture risk, including security, compliance, resilience, and technical debt
• Communicate architecture direction to executives, product, and engineering

Typically required

• Significant experience in software engineering, with time in technical leadership, engineering management, or solution architecture
• Breadth across application, data, integration, cloud, and security architecture
• Experience influencing senior stakeholders and leading change across teams
• Strong written and visual communication

Often desirable

• TOGAF certification, or familiarity with an EA framework
• Business architecture experience (capability mapping, value streams)
• Experience in the organization’s industry or regulatory environment
• Modeling notations (ArchiMate, C4) and EA tooling

Responsibilities by level

	Solution architect	Enterprise architect	Lead / principal EA	Chief architect
Scope	One program or solution	Enterprise, often one or two focus areas	Enterprise-wide, across domains	The architecture function and enterprise direction
Horizon	Months to a year	1–3 years	2–3+ years	3–5 years
Main outputs	Solution designs, ADRs	Target states, roadmaps, principles	Enterprise strategy, practice standards	Architecture strategy, operating model
Influence	Delivery team and program	Directors and engineering leadership	Executive team	CEO / board, executive peers
People	May mentor engineers	Leads a community of practice	May manage architects	Leads the architecture function

Engineering managers often move into enterprise architect directly, especially at scaling companies, skipping solution architect. That works best when you have strong technical breadth. If you don’t, a stint in solution architecture, or deliberately pairing with strong solution architects, closes the gap.

Interview preparation

EA interviews usually test four things. Typical questions and what they’re probing:

Strategic thinking

• “Tell me about a time you connected a business strategy to technology decisions.” Can you work at enterprise altitude, or only in technical terms?
• “Our strategy is X. What would you want to know before proposing an architecture?” Do you start with questions about the business, or jump to solutions?

Architecture judgment

• “Walk me through a significant architecture decision you made. What were the options and trade-offs?” Do you think in trade-offs? Can you explain them clearly?
• “How would you approach rationalizing our application portfolio?” Do you know the methods (inventory, TIME), and are you pragmatic about them?

Influence

• “Tell me about a time you changed a senior stakeholder’s mind.” Have you influenced without authority?
• “How do you handle a team that ignores architecture guidance?” Do you reach for gates or guardrails? Do you seek to understand first?

Practice building

• “What would you do in your first 90 days?” Do you listen first? Do you understand that value has to come before process?
• “How would you measure EA’s value?” Outcome metrics, not activity metrics.

Build a portfolio of evidence

Collect concrete examples before you start applying:

• Two or three decisions you shaped, with options, trade-offs, and outcomes (ADRs are ideal)
• A roadmap or target state you produced, even an informal one
• A story of influence: someone whose mind you changed, and how
• Outcomes with numbers: cost saved, risk reduced, time to market improved

As an engineering manager you probably have more of these than you think. They’re just framed as delivery stories. Reframe them around the decisions and trade-offs.