Exploring Archetypes of Architects

During a brainstorming session in a recent OOPSLA workshop I participated in we were discussing what qualities make for a "good" architect in an agile world. I jotted down this list during the discussion based on the group brain dump. Some archetypes are "good" while others are "bad" but I don't think any of them necessarily describe the perfect architect. When you're designing software, what kind of architect are you? What kind do you prefer to work with?

The Megalomaniac Architect: "You will implement the system as I have designed it because I am the most important person on this team, the project will fail without me, and I am the only one smart enough to know everything that needs to be known!"

The Benevolent Dictator: "Implement the system precisely as I have designed it and I will make your work easier." [via Dennis Mancl]

The "Everything’s a Nail!" Architect: All problems can be solved by a single tool, idea, or way of thinking. He’s got a hammer…and everything he sees is a nail.

The Diva: "I’m the architect of this system! Are you questioning my ability to design? If you’re not going to appreciate my talents, maybe I’ll just go to another team."

The Magician: Excellent at high level abstraction, vague on how the design actually achieves architectural drivers.

The Over-Accommodating Architect: "You want that change? No problem." There are no trade-offs to consider when making architectural decisions.

The Chess Master: To achieve victory, it is simply a matter of being able to see enough moves ahead. Every element in the architecture can be strategically placed in a perfect position to checkmate your opponent: requirements changes.

The PowerPoint Architect: "Architecture is just pretty pictures!"

The Ninja: Infiltrates a project from the outside, crafts an amazing design, then disappears into the shadows before anyone realizes he’s gone. Ninjas do not suffer fools and their designs are technically correct, thorough, and beyond your ability to comprehend.

The Navigator: Creates a map (with legend) and uses it to plot a course through implementation, testing, and deployment.

The Movie Producer: Leads the team indirectly by providing technical design support. [via George Fairbanks]

The Coach: Teaches the team about architectural practices and concepts as well as the design.

The Puppeteer: Able to manipulate multiple levels of abstraction simultaneously to design the architecture, the Puppeteer effortlessly manages the various threads influencing the design (commonly known as architectural drivers).

The Seasoned Veteran: He’s tried a lot of things and is pretty good at all of them including programming, design, processes, and management. Thanks to his experience, having walked 10,000 miles, he understands the role of architecture across the lifecycle, has seen many different situations, and is an excellent technical practitioner. [via Bill Opdyke]

The Long-Bearded Wise Man: A little philosophical but always willing to share an enlightened thought that will help resolve whatever concerns are ailing the project, though somewhat indirectly.

The Team Captain: A bona fide member of the team, playing on the field with everyone else, leading the team from the field.

The Design Evangelist: Excited about the architectural drivers and architecture to the point of near fanaticism. His enthusiasm for architecture and the system’s design is infectious and helps maintain conceptual integrity of the system.

The Student: Takes time to learn about the problem domain and the customer’s needs to the greatest extent possible so that he understands and solves the right problems. [via Gail Harris]

What other archetypes have you worked with? Which archetypes do you think might combine to make the perfect software architect?


  1. If you have the student, then you may have the Professor: Knows all theory and is very good at teaching to others and finding problems with their works, but has no idea of how the street really is.

    You can also add Pseudo-Architects:
    1. One Fang: Those who are experts on one technology or platform, many years of experience, and know about architecting, but lack the rest of the one mile wide, one inch deep knowledge.
    2. Dark side forcers: Those that know all of one side (IT) but lack the business and process insight.
    3. The promotional ones. Those that went up the promotion ladder, and found that the next step after senior engineer was becoming an architect, and are promoted just because of years and experience (and to be able to pay them more).

    1. Excellent call on the Professor. While my profs here at CMU have tons of experience with software architecture, (mostly with large avionics/DoD systems which isn’t always applicable to smaller systems) some haven’t been in the trenches for a few years which occasionally leads to interesting advice.


Post a Comment

Popular posts from this blog

Dealing with Constraints in Software Architecture Design

If you aren't Agile… Then what are you?

Managing Multiple Ruby Versions with uru on Windows