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?
Comments
- Anonymous
December 12, 2005
I liked your idea of the triangle.
The issue I have with these definitions and they are similar to ones I have seen a number of times is that they tend to play well in the old world of applications, but not too well in the world of services. I think the issue is primarilly one of semantics, rather than pure role differences. Many organisations regard many services as infrastructure (email, desktop, etc.) and expect the infrastructure organisation to deliver them. For most people these services are what they use all day, every day. The people who do this fit into the definition of solution architect, but they are not software architects. So we end up in a situation where you have application focussed solution architects and infrastrustructure service focussed solution architects. This means that the Infrastructure Architect tends to only exist when supporting an application focussed Solution Architects. - Anonymous
December 13, 2005
I think this is a good start, however, as Graham alludes, it lacks granularity. I think you are correct in your Strategic Architect and Infrastructure Architect definitions, but I think the Solutions Architect requires more delineation. That is, I think you can create another triangle solely for the Solutions area in which you have Software Architect, Data Architect and, perhaps, Integration Architect. Some people are more accomplished in one area over the others. The individual who is accomplished in all three is a true Solutions Architect. - Anonymous
December 13, 2005
Our architect knows a little VB script, but is mostly just very tall. How would you classify an architect that refers to registers as "registries" and win32 as "windows thirty?" - Anonymous
December 13, 2005
This is a great topic. I tend to think that most software architects, covering all three personas, derive somewhat from the solutions architect persona. It seems like the titles data architect, integration architect, and application architect are misleading. I believe that application architect and senior developer are synonymous. The usage of senior rather than architect seems more appropriate when speaking about these sub-personas. I agree with Mitchell that the "individual who is accomplished in all three is a true Solutions Architect". And add that only then are they in the realm of architecture rather than seniority or just design. - Anonymous
December 13, 2005
This is a great topic. I tend to think that most software architects, covering all three personas, derive somewhat from the solutions architect persona. It seems like the titles data architect, integration architect, and application architect are misleading. I believe that application architect and senior developer are synonymous. The usage of senior rather than architect seems more appropriate when speaking about these sub-personas. I agree with Mitchell that the "individual who is accomplished in all three is a true Solutions Architect". And add that only then are they in the realm of architecture rather than seniority or just design. - Anonymous
December 13, 2005
This could run and run, but it’s a sign of the growing maturity of the IT profession that there's a discussion at all.
I have also found wild discrepancies in the genuine qualifications of both "Project Managers", and "Analysts".
Analysts in particular differ greatly in personality, dependant on whether they have been developers who have gravitated towards analysis and tend to like formal methods (UML etc), or whether they are business experts who have been dragged towards analysis because of their talent for explaining business processes. - Anonymous
December 13, 2005
Given that the word Architect derives from the greek words archos (chief, master, leader) and tekhne (art, craft, method, system, skill). It is no wonder that the work Architect when used without qualification is so overloaded.
I think that the above definitions are workable. I take on board the point that was made regarding data architect, integration architect, and application architect. I feel that these are specialism's of the solution architect role and need only be elaborated on verbally if a discussion necessitates it.
I doubt it is worth the effort to try to convey a persons exact job function on say a business card as most job titles in companies have been 'spun' so much that their exact meaning is obscured anyway. - Anonymous
December 15, 2005
The comment has been removed - Anonymous
January 04, 2006
I agree with your 'definition' and separation in three categories. I would like to see events targeting a specific role. I am more interested in Enterprise and Infrastructure Architecture but at times I would participate in Solutions events. This separation of events would allow for better time and content management.
Indeed, as per the other comments, you can brake down every other role and create an Architect position for every category in an organization but where would you stop. Having three architecture levels covering from vision, application and infrastructure would allow for an organizations systems to be complex if needed but not complicated. Having too many architects applying different frameworks and methodologies would guarantee a complicated system but not necessarely a complex one. - Anonymous
January 05, 2006
From my perspective, the trouble with this discussion (in general, not just this one) is that different levels of granularity are being mixed together... and the context within which they are being discussed varies by individual. Personally, I can see that all of the definitions above could be appropriate - but also can be seen as wrong in other instances.
However, I do fundamentally disagree with some of the options discussed. Having a general term "Software Architect" fundamentally ignores the Business aspects of solutions - after all, the Architecture is there to deliver business solutions and business benefit, not just IT or Software.
I also have a problem with assuming that Enterprise Architecture = Business Architecture although I know that it is being used in this way in some instances. As we move to a more services oriented world, so it becomes more important to be able to deliver more Services Oriented Business Architectures (i.e. how the business is structured/works). This is where Business Architecture fits.
In this case, I would see Enterprise Architect as providing the connection (roadmaps, guidelines, etc.) between this new Business Architecture and the (IT) systems needed to support and deliver it. - Anonymous
February 13, 2006
PingBack from http://marten.gustafson.pp.se/blog/2006/02/13/links-for-2006-02-13/ - Anonymous
April 27, 2006
In this post i asked what Architecture is. Michael Platt, in this post, describes 3 Architect Roles,... - Anonymous
April 27, 2006
In this post i asked what Architecture is. Michael Platt, in this post, describes 3 Architect Roles,...