Architect Archetypes

Image by IIIerlok_Xolms from iStock

IN THIS SECTION, YOU WILL: Get an overview of external resources on various architectural leadership archetypes and frameworks.

KEY POINTS:

Will Larson’s Staff Archetypes: Defines key technical leadership roles that balance team guidance, problem-solving, and organizational influence in engineering.

Gregor Hohpe’s Movie Star Architects: Uses movie metaphors to critique unrealistic expectations placed on IT architects, advocating for flexible and grounded leadership.

Gergely Orosz’s Software Architect Archetypes: Identifies a spectrum of software architect types, from theoretical thinkers to hands-on coders, each with distinct strengths and potential pitfalls.

TOGAF View: Categorizes architects based on their focus areas—enterprise, business, data, application, technology, and security—ensuring alignment with business and technical goals.

In today’s rapidly evolving technology landscape, the roles and responsibilities of architectural leaders are more critical than ever. Defining these roles is essential to driving organizational success and maintaining a cohesive vision. The frameworks and archetypes developed by thought leaders such as Will Larson, Gregor Hohpe, and Gergely Orosz, as well as industry standards like TOGAF, can provide invaluable inspiration and guidance for architects and engineering leaders.

Each approach highlights different aspects of the architect’s role—from leadership and strategic alignment to technical expertise and hands-on involvement. By exploring these perspectives, architecture heads can define their unique responsibilities more effectively, ensuring that they not only guide their teams but also help shape the future of their organizations. Whether focusing on team collaboration, tackling complex technical challenges, or ensuring long-term business alignment, these archetypes offer a roadmap for success in architectural leadership.

Will Larson’s Staff Archetypes

Source: Will Larson’s Guides / Staff archetypes

Image by courtneyk from iStock

In Will Larson’s view, the four common archetypes of Staff-plus roles he encountered are:

The Tech Lead: This role guides the approach and execution of a specific team. Tech Leads work closely with a single manager, though sometimes they collaborate with two or three managers within a focused area. Some companies have a similar variant called the Tech Lead Manager, which sits on the engineering management ladder and includes people management responsibilities.
The Architect: Architects are responsible for setting direction, ensuring quality, and shaping the approach within a critical area. They blend deep technical knowledge, an understanding of user needs, and leadership at the organizational level.
The Solver: Solvers dive into complex, often ambiguous problems and chart a path forward. Some specialize in a particular area over time, while others move from one problem area to another based on organizational priorities.
The Right Hand: This role acts as an extension of an executive’s influence, leveraging their scope and authority to manage particularly complex teams or initiatives. They provide additional leadership capacity to leaders of large-scale organizations.

Gregor Hohpe’s Movie Star Architects

Source: Gregor Hohpe’s Movie Star Architects

Image by selimaksan from iStock

Gregor Hohpe explores the different archetypes of IT architects through movie metaphors, critiquing the unrealistic expectations often placed on them.

The Master Planner (The Matrix): Hohpe compares the Matrix architect to an enterprise IT architect, who is often seen as an omniscient decision-maker. He critiques this view as flawed because architects, unlike fictional figures, cannot have complete control or knowledge of complex systems. Instead, they make decisions based on incomplete or biased information. Hohpe cautions against idealizing the role of the all-knowing architect and urges IT architects to acknowledge their limitations and avoid overconfidence.
The Gardener (Edward Scissorhands): Hohpe contrasts the rigid “Master Planner” with a more suitable metaphor: the Edward Scissorhands gardener. Like a gardener tending an evolving, organic environment, an IT architect should foster balance and harmony within an ever-changing system, adjusting and nurturing rather than micromanaging. Hohpe emphasizes flexibility and adaptability over rigid control, suggesting that architects should allow for growth and change in the systems they manage.
The Tour Guide (Vanishing Point): Drawing from Vanishing Point, Hohpe presents the architect as a tour guide, a hands-on figure offering guidance rather than command. The architect stays involved, helping teams navigate risks without micromanaging. This approach depends on management’s support, as the tour guide’s influence is subtle and hard to measure. Without it, like in Vanishing Point, where the protagonist loses his guide, projects can spiral into failure.
The Wizard of Oz: Hohpe uses the Wizard of Oz to illustrate how IT architects are often seen as powerful figures who can solve any technical challenge, much like the majestic Wizard. However, like the “Mighty Oz,” this perception is often an illusion. While projecting authority can help architects gain influence in large organizations, Hohpe warns that they should remain grounded in their technical expertise and avoid becoming too detached from reality.
Superheros: In Gregor Hohpe’s view, architects are often seen as “superheroes” who can solve any technical problem, lead digital transformations, and stay on top of the latest technologies. However, this is an unrealistic expectation. Instead, Hohpe suggests, based on Amir Shenhav’s view’, that architects should be viewed as “super glue” — the ones who hold together architecture, technical details, business needs, and people. This role is more about being a connector or catalyst, ensuring the different elements of a project or organization work cohesively. However, architects must deeply understand the pieces they are bringing together to be effective.

In summary, Hohpe critiques the idealization of IT architects as all-powerful figures and argues for a more grounded, flexible approach that balances influence with hands-on involvement.

Gergely Orosz’s Software Architect Archetypes

Source: Software Architect Archetypes

Image by pixelfit from iStock

In Gergely Orosz’s view, software engineers and architects can be grouped into several archetypes, each with distinct characteristics, strengths, and challenges. These archetypes range from the theoretically inclined to the more grounded in practical, hands-on coding.

The Ivory Tower Architect: This engineer is distant from day-to-day work, making top-down decisions with limited interaction with those implementing their designs. Their detachment can lead to misunderstandings and missed objections from their peers.
The Painfully Precise: This engineer is meticulous about technical accuracy, often derailing conversations by focusing on minor errors, which can frustrate colleagues and obscure the bigger picture.
The Theory Addict: An engineer who leans heavily on theoretical knowledge from books and case studies. While they can provide innovative solutions, they may lack practical experience, potentially leading to unrealistic or impractical suggestions.
The Philosopher: Like the Theory Addict, the Philosopher enjoys in-depth debates but often gets lost in theoretical discussions. Their exhaustive discussions may hinder decision-making, especially when paired with more practical engineers.
The Superior Linguist: This type excels in technical jargon, using it to demonstrate their knowledge. While they can help less experienced engineers by teaching, they may dismiss those without linguistic prowess.
The Walk-Away Advisor: An experienced engineer who offers advice early in a project but doesn’t stick around for implementation. This can leave teams struggling if initial advice turns out to be flawed.
The Coding Machine: A hands-on, high-output coder who quickly delivers results. This archetype challenges the assumption that architects must be removed from coding, showing that some engineers excel through relentless coding.
The Integrator: Known for their deep understanding of systems, this engineer can easily modify and integrate them. Their pragmatic approach helps avoid unnecessary rewrites, though they may struggle with promotions in environments that value theoretical contributions more.
The Approachable One: Despite their seniority, this engineer remains accessible and involved with the team. They’re natural mentors, helping others grow through code reviews and informal guidance.
The Detailed Documenter: This archetype excels at creating detailed documentation that helps spread knowledge. Depending on their approach, their documentation may be practical or theoretical.
The New and Shiny Chaser: Enthralled by the latest technologies, this engineer loves trying cutting-edge tools and frameworks. However, their tendency to adopt untested approaches can lead to unforeseen issues.
The Old Schooler: The opposite of the New and Shiny Chaser, this engineer sticks to tried-and-true technologies. Their preference for stability may clash with colleagues eager to innovate, but it helps prevent surprises in development.

Orosz’s view highlights that while each archetype has strengths, it also has potential pitfalls that can affect team dynamics and project outcomes. He emphasizes the importance of balancing these archetypes to create a well-rounded team capable of handling theoretical and practical challenges.

TOGAF Architect Archetypes

Source: The TOGAF Standard

Image by simonkr from iStock

In TOGAF (The Open Group Architecture Framework), architects are categorized into various types based on their focus areas and roles within the enterprise architecture. The major types of architects, according to TOGAF, include:

Enterprise Architect
- Focus: Holistic view of the entire organization’s architecture.
- Responsibilities:
  - Aligning IT strategy with business goals.
  - Providing an overall structure integrating business, information, technology, and application architectures.
  - Ensuring that the architecture aligns with the organization’s objectives and strategy.
Business Architect
- Focus: Business processes, strategies, and organizational structure.
- Responsibilities:
  - Defining business capabilities and business processes.
  - Ensuring alignment between business goals and the IT landscape.
  - Developing business models and improving business performance.
Data Architect (Information Architect)
- Focus: Data management and the structure of information systems.
- Responsibilities:
  - Defining how data is stored, managed, and integrated across the organization.
  - Creating data models data flow diagrams, and ensuring proper governance of data assets.
  - Aligning data strategy with business and technical architectures.
Application Architect
- Focus: Application systems and how they interact.
- Responsibilities:
  - Defining application architecture and ensuring integration between different applications.
  - Selecting application components and ensuring scalability, flexibility, and reusability.
  - Creating blueprints for application components and aligning them with business needs.
Technology Architect
- Focus: IT infrastructure, platforms, and technical components.
- Responsibilities:
  - Managing the underlying hardware, software, and network systems.
  - Defining technology standards and ensuring technical architecture supports the business and application layers.
  - Optimizing and maintaining IT infrastructure for security, performance, and reliability.
Security Architect
- Focus: Security measures within IT and business environments.
- Responsibilities:
  - Ensuring that enterprise architecture includes robust security controls and meets compliance standards.
  - Designing security frameworks, access controls, and secure data flows.
  - Manage risks and align security policies with organizational objectives.

To Probe Further

Appendix 2: Tools for Developing Soft Skills

← Managing, Growing, and Hiring Architects

Appendix 2: Tools for Developing Soft Skills

Effective Communication →