Module 2 · Foundations
The enterprise architect role
What enterprise architects actually do day to day, how the role differs from other architects, and where it sits in the organization.
By the end of this module you should be able to
- Describe the core job functions of an enterprise architect
- Distinguish enterprise, domain, and solution architects and how they work together
- Explain common reporting lines and engagement models for EA
- Sketch what a typical week looks like for an EA in a scaling organization
The job in one paragraph
An enterprise architect helps the organization make good, coherent change decisions. In practice that means understanding the business strategy well enough to work out what it implies for capabilities, information, applications, and technology. The EA then writes that down as target states, roadmaps, and principles, and spends most of their time bringing people along: executives, product leaders, engineering managers, and teams. The role is roughly one-third analysis and design, two-thirds communication and influence.
Core job functions
Most EA job descriptions are some mix of the following. Weightings vary a lot by organization.
| Function | What it involves | Typical outputs |
|---|---|---|
| Strategy alignment | Translate business goals into architectural implications; advise leadership on technology-enabled options | Architecture vision, strategy briefs |
| Current-state understanding | Know what exists: capabilities, applications, data, integrations, costs, risks | Capability map, application inventory, landscape views |
| Target state & roadmaps | Define where the organization needs to get to and sequence the path | Target architectures, transition states, roadmaps |
| Portfolio guidance | Advise on what to invest in, consolidate, or retire; assess build/buy/SaaS | Rationalization recommendations, business case input |
| Principles & standards | Set the rules of the road so teams can decide independently and consistently | Principles, standards, reference architectures, tech radar |
| Governance & decisions | Make sure significant decisions get made well and are written down | ADRs, review forums, exception/dispensation records |
| Advisory & consulting | Help programs and teams with their hardest cross-cutting design problems | Options papers, design reviews, spikes |
| Practice building | Grow architecture capability across the organization | Architect community, templates, onboarding, metrics |
Types of architect
Titles vary widely, but most organizations use something like this structure:
| Role | Scope | Time horizon | Primary question |
|---|---|---|---|
| Chief / Head of Architecture | Whole enterprise; leads the function | 2–5 years | Is our architecture capability enabling the strategy? |
| Enterprise architect | Enterprise-wide, across domains | 1–3 years | Are our change decisions coherent and aligned to strategy? |
| Business architect | Capabilities, value streams, organization | 1–3 years | What does the business need to be able to do? |
| Domain architect (data, security, integration, cloud) | One domain, enterprise-wide | 1–3 years | Is this domain fit for purpose across the enterprise? |
| Solution architect | One program or solution | Months to a year | How should this solution be designed to meet its needs and fit the enterprise? |
| Software / technical architect | One system or product | Weeks to months | How should this system be structured and built? |
In a scaling organization, one person often covers EA, business architecture, and some domain architecture, and solution architecture is done by senior engineers and tech leads. That’s normal. Know which hat you’re wearing at any moment.
Where EA sits in the organization
Common reporting lines:
- CIO or CTO: the most common arrangement. Close to technology decisions, but there’s a risk of being seen as “just IT.”
- Strategy / transformation office: closer to business strategy. There’s a risk of being disconnected from delivery.
- Within an engineering or platform org: the most delivery-connected option. There’s a risk of being seen as serving that group’s interests.
Whatever the reporting line, the role needs perceived neutrality. It has to be trusted to weigh enterprise-wide trade-offs, including ones that are inconvenient for the leader it reports to.
Engagement models
| Model | How it works | Fits when |
|---|---|---|
| Centralized | An EA team owns architecture and reviews significant designs | Large, regulated organizations with a mature EA function |
| Federated | A small EA core sets direction; architects or tech leads embedded in teams apply it | Most scaling organizations |
| Decentralized | Teams decide; EA is purely advisory | Very small or highly autonomous organizations |
For a mid-size or scaling organization, federated is almost always the right starting point. You can’t review everything, and you shouldn’t try. Your leverage comes from principles, shared context, and the community of people who make architecture decisions in teams.
A typical week
There’s no standard week, but in a scaling organization a realistic mix looks like this:
- Monday: Leadership or portfolio meeting. A new initiative is proposed and you flag that it overlaps with an existing platform. You take an action to write a short options paper.
- Tuesday: Working session with a product director to map the capabilities behind a new market entry. In the afternoon, an architecture forum where two teams present ADRs on event schema ownership.
- Wednesday: Deep work. You update the integration roadmap and draft the options paper from Monday.
- Thursday: One-to-ones with tech leads (your federated architects). A vendor demo for a SaaS tool that three departments want to buy separately.
- Friday: You present the options paper to the CTO and CPO and get a decision. You publish the ADR and update the radar. Some reading or learning time.
Notice how little of that is drawing diagrams, and how much is connecting conversations that would otherwise happen in isolation.
What good looks like
Signs that an enterprise architect is effective:
- Leaders pull them into decisions early instead of finding out about them late.
- Teams can explain the principles and use them without asking.
- Significant decisions are written down and can be found.
- The roadmap is actually used in planning and funding conversations.
- There’s measurable reduction in duplication, run cost, or risk over time.
At Quillfeather
Your setup as Quillfeather’s first enterprise architect:
- Reporting line: the CTO. That gets you close to technology decisions quickly, but the CPO and the Head of Payments may see you as “the CTO’s person.” You’ll need to earn neutrality by visibly weighing their concerns.
- Engagement model: federated, by necessity. You’re one person and there are 18 teams. Your federated community is the dozen or so senior engineers and tech leads who already make architecture decisions, including PayNest’s lead engineer and FixIt Pro’s tech lead.
- Hats you’ll wear: enterprise architect (the expansion plan), business architect (no capability map exists yet), and occasionally domain architect for identity and data, since those are the most urgent cross-cutting problems.
- Where your time will go first: strategy alignment (the board’s technology plan) and current-state understanding (you can’t plan a route without knowing where you’re starting from). Principles, governance, and practice-building come next, but not all at once.
Reflection
- If you took an EA role at your current organization tomorrow, which reporting line would you have? What risks come with it?
- Who already acts as an architect in your organization, whatever their title? They’re your future federated community.
- Look at the job functions table. Which do you already do as an engineering manager? Which are new?