Architect Personas

I’ve sat through many architect events over the past few years and one thing that always strikes me is how different one self claimed “architect” attendee can be from another. For example, I saw two architects sitting together at a recent event – one was clearly very interested in the impact of architecture on the long term IT strategy of the company, the other was interested in how best to use SQL data access patterns in an application for the company. Both had the architect title on their business card, but both were clearly different types of architects.

This causes two problems. Firstly, it makes for an interesting conversation between the two - “Hey, this guy is too high level! He’s just a business guy!” or “What’s this guy doing at this event? He’s a developer!” Secondly, this makes planning architect events and content a nightmare. There are very few sessions that find a sweet spot for both of these roles, and as a result session scores and feedback suffer as a result.

In his blog, Mike Platt alluded to three types of architects which I tend to agree with. I call these “Architect Personas”. I believe there are three types of Architect Persona today – the Enterprise Architect, the Solutions Architect, and the Infrastructure Architect. Here's my take:

Enterprise Architect

Also known as: Strategic Architect, Chief Architect, Business Architect

Role: The Enterprise Architect is concerned about the strategic vision of application and services within the organization. He or she is responsible in part for strategic direction and ensuring all applications comply with internal policies, and may be in charge of setting the direction for methodologies, tools and frameworks used. I personally think that Strategic Architect is a more fitting title here because I think there is a disconnect between Enterprise Architect (the role) and Enterprise Architecture (when used to describe architecture for an Enterprise), but Enterprise Architect seems to have built up some momentum over the past few years, so I'm happy to go along if it means we all speak the same language.

Solutions Architect

Also known as: Application Architect, Software Architect, Data Architect, Integration Architect

Role: The Solutions Architect is responsible for the design or one or more applications or services within an organization, usually within the scope of a division. Many people I’ve chatted to believe that Software Architect is more applicable here, but in my opinion the design for many applications and services spans beyond just the creation of software – for example, a data-heavy application or the integration of a series of applications. As a result, I believe the term Solutions Architect is a good fit in many cases. The Solutions Architect works with the Enterprise Architect for strategic direction (both conforming to, and helping to define).

Infrastructure Architect

Also known as: Technology Architect, Systems Architect

Role: The Infrastructure Architect’s domain includes responsibility for the design of the datacenter, deployment and maintenance of applications/services across the organization. This role includes working with the Solutions Architect to design for scalability, reliability, managability, performance, and security, and the Enterprise Architect for strategic direction (both conforming to, and helping to define). 

So, are these three distinct roles? I don’t necessarily think so. Instead, I prefer to think as the three types of architects as a spectrum. To show this, I use the following diagram.

 

The position in the triangle can determine weighting towards one or more roles. I use this diagram in interviews where I’m trying to find out what “type” of architect a person really is. For example, someone with a strong background in infrastructure, yet who is also closely connected to the strategic view of applications throughout the organization could place themselves here:

 

 

When I think about my background, I tend to place myself here:

 

I feel I’m strongest as a Solutions Architect (and if I had to choose, I would probably call myself this on a business card), yet because of my previous work I’ve also acquired a lot of knowledge around infrastructure – which pulls me to the right of the diagram. However, because of my strong focus on technology, my strategic/business skills may not be as strong as someone who has come from an MBA or CPA background.

So, this took a little longer that I intended, but I am interested in people’s thoughts. Are the three personas accurate – or do you see different roles in organizations today? Also, if we started using these personas to target content and events would this make sense? Would you be more or less likely to attend an architect-focused event if it was personalized around the three roles?