Enterprise architects occupy a strange position in technology organizations. We're not executives, but we influence strategy. We're not individual contributors, but we need to understand technical depth. We're not managers, but we shape how teams work together. The confusion about this role is partly why many organizations struggle with architecture. This post covers what enterprise architects actually do, why the role matters, how it differs from people leadership, and how to build an architecture practice that doesn't become a bureaucratic dead weight.
What Enterprise Architects Do
An enterprise architect is responsible for defining how technology systems should fit together to serve the organization's strategy and constraints.
More specifically, architects:
Understand the business: What problems is the organization trying to solve? What constraints matter most (cost, time to market, compliance, security)? What are the strategic initiatives for the next 2-3 years?
Understand the current state: What systems exist? How do they talk to each other? What's working well? What's broken? What technical debt exists? Where is the organization fragile?
Define the target state: Given the business strategy and current state, what should the technology landscape look like in 2-3 years? What systems should exist? How should they integrate? What capabilities need to be built?
Create the path: How do you get from current state to target state? What's the sequencing? What projects need to happen in what order? What do you stop doing?
Provide guardrails: Once a direction is set, architects define principles, patterns, and standards that keep teams aligned without micromanaging. These become the rules of the road.
Resolve conflicts: When two teams want incompatible things, the architect steps in. When a business unit wants something that violates architecture principles, the architect negotiates. When multiple valid approaches exist, the architect chooses one for consistency.
Communicate the vision: Architects must be able to explain the strategy to executives in business terms, to engineers in technical terms, and to project managers in timeline and resource terms. The same architecture looks different depending on who you're talking to.
Challenge assumptions: A good architect isn't a yes-man. If a strategic initiative is being built in a way that conflicts with long-term architecture, the architect should raise it. If a team is solving a problem in isolation when cross-team coordination would be better, the architect should flag it.
What Enterprise Architects Provide
The value of architecture isn't always obvious, especially when the organization has never had architecture. Some common deliverables:
Architecture Documentation
Clear description of:
- The current technology landscape
- The target architecture
- Principles and standards that govern decisions
- Reference architectures for common patterns
- Technology choices (what databases, what frameworks, etc.)
This seems simple, but most organizations lack this. Engineers spend weeks debating whether to use PostgreSQL or MySQL because there's no documented standard. Teams duplicate work because they don't know what exists elsewhere.
Decision Framework
Architecture provides the rules for making decisions. Instead of every decision escalating to executives, teams know:
- What decisions require architecture review
- What decisions they can make autonomously
- What tradeoffs are acceptable
- When they should ask for help
This actually accelerates decision-making, not slows it down.
Technical Leadership in Strategic Programs
When the organization is undertaking a major transformation (cloud migration, monolith-to-microservices, new data platform, etc.), architects should be leading it from a technical perspective. Not executing day-to-day, but ensuring the approach is sound.
Risk Identification
Architects see across silos. That means architects often spot risks that individual teams miss:
- Duplicate expensive systems in different business units
- Incompatible technology choices that will cause integration problems later
- Teams going down paths that conflict with long-term strategy
- Security or compliance gaps
- Scalability problems in systems that will need to grow
Standards and Governance
Architects define what good looks like:
- Code standards (languages, frameworks, testing practices)
- Infrastructure standards (how cloud resources are provisioned and managed)
- Security standards (encryption, authentication, network segmentation)
- Data standards (where data lives, how it's governed, quality expectations)
- Integration patterns (how systems talk to each other)
These aren't arbitrary. They exist to make the organization more effective, reduce costs, and mitigate risks.
The Value of Architecture
When architecture is working well, you see:
Faster delivery: Teams know what the rules are, so they spend less time debating and more time building. New teams onboard faster because there's a documented standard.
Lower costs: No duplicate systems. No "we each bought different solutions to the same problem" problems. Teams use managed services appropriately because there's guidance on when to.
Better security and compliance: Security isn't bolted on later; it's designed in. Compliance standards are built into architecture from the start.
Resilience: Systems are designed to fail gracefully. Dependencies are explicit. Teams understand the broader impact of their decisions.
Reduced technical debt: Architectural decisions are made deliberately, not by accident. Teams don't wake up in five years with a system that nobody wants to maintain.
Agility: Paradoxically, good architecture enables faster change, not slower change. You can safely experiment within guardrails. You can reuse patterns instead of reinventing.
When architecture is missing or weak, you see the opposite: slow delivery, high costs, security gaps, brittle systems, and massive technical debt.
Enterprise Architects vs. People Leaders: Why They Must Be Different Roles
This is where many organizations go wrong. They make their most senior technical person (or their best manager) into both the architect and the leader of the technical organization.
This is a mistake. Here's why:
Different Incentives
A people leader is evaluated on the performance and satisfaction of their team. This creates an incentive to:
- Hire the best people
- Give them good projects
- Support their career growth
- Keep them happy and retain them
An architect is evaluated on the quality and alignment of technical decisions across the organization. This sometimes means:
- Telling a team their favorite technology choice won't be used
- Blocking a project because it conflicts with architecture
- Requiring teams to follow standards that feel restrictive
- Making decisions that benefit the organization but hurt an individual team
These goals can conflict. If your architect is also the manager of half the engineering org, which hat do they wear when making a decision that hurts their team but helps the company?
Different Skills
People leadership requires:
- Strong listening and interpersonal skills
- Ability to develop talent
- Judgment about hiring and promotions
- Conflict resolution at a personal level
- Advocacy for compensation and resources
Architecture requires:
- Ability to see across silos and synthesize patterns
- Technical depth and breadth
- Strategic thinking about technology
- Communication across different audiences (business, engineering, operations)
- Willingness to challenge ideas without regard to politics
These are not the same skills. You can be a great engineer and mediocre manager. You can be a great manager and weak architect. Good people leaders and good architects do exist, but they're rare, and even when they exist, asking someone to excel at both is unfair and ineffective.
Scope Mismatch
A people leader typically oversees 5-20 people. Their span of control is bounded. An architect must influence the entire technical organization, often 100+ people, possibly spread across many teams, regions, and business units. They can't do both jobs well simultaneously.
The Solution: Separate Roles
The right structure has:
Engineering leaders (VPs, directors, managers) who own specific teams or business units. They are responsible for delivery, team health, hiring, and development.
Architects (enterprise architect, solution architects, principal engineers) who operate across organizational boundaries. They define principles and standards, resolve cross-team conflicts, and guide long-term strategy.
These roles should cooperate closely, but they are distinct. An architect might report to a CTO or VP of Engineering, but they should not directly manage the teams they're guiding. If an architect is your manager, it creates a conflict of interest.
Practical Implications
In a healthy organization:
- The architect has a seat at planning meetings, but isn't setting team priorities
- The architect defines standards, but the team lead decides how to implement them within those constraints
- The architect challenges architectural decisions, but the team lead decides staffing and project sequencing
- When they disagree, there's a clear escalation path to resolve it
When done well, this enables both strong teams and strong architecture. When done poorly (architect acts like a manager, or manager doesn't respect architecture), you get dysfunction.
Common Enterprise Architecture Patterns
1. Centralized Architecture Team
Structure: A dedicated team of architects, usually 3-8 people reporting to a CTO or VP of Engineering.
Strengths:
- Clear accountability
- Can do deep strategic work
- Consistent standards
- Can focus on governance
Weaknesses:
- Can become a bottleneck
- May feel disconnected from reality
- Risk of ivory tower syndrome
- May lack technical credibility if not embedded in projects
When to use: Large organizations (500+ engineers) with complex multi-team coordination needs.
2. Distributed Architects
Structure: Senior engineers/architects embedded in each business unit or platform team. They coordinate informally or through a lightweight architecture council.
Strengths:
- Close to the work
- Good technical credibility
- Understands business context deeply
- Can move fast
Weaknesses:
- Inconsistent standards
- Local optimization instead of global optimization
- Hard to maintain coherent vision
- Architects get pulled into execution
When to use: Organizations with autonomous business units where consistency isn't critical.
3. Hybrid Model
Structure: A small central architecture team (2-3 people) plus distributed architects in each major team. The central team sets strategic direction; distributed architects guide their teams.
Strengths:
- Coherent strategy with local empowerment
- Architects are both strategic and grounded
- Scales well
- Balanced governance
Weaknesses:
- Requires good coordination
- Distributed architects need strong collaboration skills
- Still requires discipline
When to use: Most large organizations. It's the sweet spot.
Best Practices for Building an Architecture Practice
Start with Current State Analysis
Before you can define where you're going, understand where you are:
- Document existing systems and their relationships
- Understand technology choices and why they were made
- Identify technical debt and pain points
- Talk to teams about what's working and what's broken
This sounds obvious, but many organizations skip this step and jump to a target state that doesn't reflect reality.
Make Principles Explicit
Instead of implicit rules that architects enforce subjectively, write down your principles. Examples:
- "We prefer managed services over self-managed infrastructure"
- "We build for multi-tenant capability, even single-tenant requirements"
- "Security is designed in, not bolted on"
- "We optimize for operational simplicity over feature richness"
- "We value team autonomy within architectural guardrails"
Principles are the foundation for decisions. When a team asks "can we use this technology?" the answer is "does it align with our principles?" That's much more defensible than "because I said so."
Create Reference Architectures
Don't just say "use microservices." Show a concrete example:
- Here's how we do web applications: API Gateway → microservices on Kubernetes → RDS database
- Here's how we do data platforms: Data lake in object storage → Spark for processing → BI tool on top
- Here's how we do integrations: Event streaming for async, API Gateway for sync
Reference architectures accelerate decision-making and ensure consistency without removing all local flexibility.
Use Lightweight Governance
The goal is not to approve every decision. The goal is to catch the ones that matter. A good governance model:
- Self-service for low-risk decisions: Use a database? Update your network security groups? Go ahead.
- Architecture review for medium-risk decisions: New system? Major technology shift? Bringing in a new SaaS? Bring it to architecture.
- Exception process for decisions that violate principles: If you really need to, there's a path, but you have to justify it.
The process should take days, not months. If architecture review is slowing you down, it's broken.
Measure and Communicate
Architecture isn't magic; its value should be measurable:
- Time from decision to implementation
- Incident rate and mean time to recovery
- Cloud spend trends
- Security incidents by category
- Developer satisfaction with tooling and standards
Track these metrics and communicate them. When architecture works, people see it. When it doesn't, fix it.
Involve the Right People
Architecture decisions should involve:
- Technical experts: Engineers who understand the current systems and technical constraints
- Business representatives: People who understand the strategy and constraints that matter most
- Security and compliance: Architects are great, but they miss things. Bring in people focused on security.
- Operations: The people who will have to run whatever you design
Architecture is not done by architects alone. Architects facilitate and synthesize, but the input should be broad.
Accept That You'll Change Direction
Your target architecture is not sacred. As the business changes, as technology evolves, as you learn what works and what doesn't, you'll revise it. That's not failure; that's learning.
Document your decisions and the reasoning behind them so that future revisions build on what you learned, not what you assumed.
Don't Let Architecture Become a Moat
The worst architecture practices become a way for senior people to protect their territory and block ideas. That's anti-pattern.
Good architecture:
- Enables teams to move faster, not slower
- Explains the why, not just the what
- Listens to challenges and updates when they're valid
- Helps teams succeed, not blocks them
If your architecture practice is seen as an obstacle, fix it. The right answer might be less centralized control, not more.
Common Mistakes
Mistake 1: Architecture Without Execution
An architect who never executes loses credibility. You can't tell engineers how to do their jobs if you haven't done them recently. Spend some time in code, in deployments, in incidents. Stay grounded.
Mistake 2: Governance Without Empowerment
If architects make all the decisions, teams are passive. The opposite is true: architects should define guardrails and let teams decide how to operate within them.
Mistake 3: Ignoring the Business
Some architects focus purely on technical purity: "The right architecture would use this design." But if the business can't afford it or doesn't need it, you're building the wrong thing. Architecture must be informed by business reality.
Mistake 4: Too Many Standards
Standards exist for a reason, but too many becomes restrictive. You want enough standards to ensure consistency without stifling innovation. It's a balance.
Mistake 5: Treating Architecture as a Career Dead End
If your best senior engineers move into architecture and then feel trapped, they'll leave. Architecture should be a legitimate path forward for technical leaders, with real authority and interesting problems, not a place where great engineers go to die.
Conclusion
Enterprise architecture is not about creating perfect designs. It's about making intentional choices that serve the organization's strategy, reducing friction between teams, and enabling both speed and quality at scale.
A good architecture practice doesn't slow you down; it speeds you up because teams know the rules, reuse proven patterns, and don't waste time debating things that have already been decided.
A bad architecture practice feels like a tax: architects blocking things, making slow decisions, and preventing teams from shipping.
The difference is usually whether architects are seen as enablers or gatekeepers, whether principles are explicit or implicit, whether governance is lightweight or bureaucratic, and whether architects have credibility from understanding both the technical and business landscape.
If you're building an architecture practice, focus on credibility first. Understand the current state deeply. Make decisions based on principles, not politics. Measure outcomes. Involve the right people. And remember: the goal is to help the organization move faster, safer, and more efficiently. If you're not doing that, you're doing architecture wrong.