What Does an IT Architect Do?

This is an interesting question for anyone thinking about working as an Architect but also for anyone else working in IT because there isn't a consistent set of definitions regarding architects within the industry. Architects who do more or less the same things with the same skills could variously be referred to as:

• Enterprise Architects
• Solution Architects
• Project Architects
• IT Architects
• Technical Architects
• Data Architects
• Application Architects
• Business Architects
• Cloud or SOA Architects
• Security Architects

There are many types of architects, yet they all share certain characteristics...

And the list goes on. What if anything differentiates these roles (1)? More importantly, what elements do these roles have in common (2), if any? Not too long ago in the history of IT, few people used the term Architect to describe anyone. Why has this changed (3) – we've gone from no architects to more than a dozen flavors in perhaps 15 or so years?

Let’s answer some of these questions:

1. The Architecture roles (listed above) are generally differentiated by some level of solution specific expertise in one area or another. This could involve methodology, toolsets, skillsets or even industry domain knowledge.
2. An Architect is not or at least should not be tied to one specific element of expertise – if he or she is focused in only one area then they become a Subject Matter Expert (SME) and not an Architect. This is an important and practical distinction because technology keeps changing – today’s stack will not be the same as tomorrows’. Architects must understand the entire stack as it evolves and change skill sets as that evolution occurs. All Architects are designers. All Architects are problem solvers. All Architects are by nature also systems and business analysts. 
3. The genesis of the Architecture role in IT is directly related to the rapid decentralization and added complexities associated with the PC and Client Server revolution (and everything else that has occurred since then). In other words, as IT environments and systems became more complex, it was apparent that a “complexity manager” was required. That person is the Architect. 

Why would we necessarily refer to a complexity manager as an Architect? The metaphor as designer is obvious – but just as important is the idea that the Architect is the one who has the vision and understanding to see how all of the various pieces ought to fit together. An Architect, in either realm is by nature also an integrator.

So, how does an IT Architect differ from a traditional Architect (the folks who design blueprints for buildings)? Perhaps the most interesting difference between the two roles is that there is often an expectation within IT that the Architect or Designer is also the Builder. In the world of brick and mortar construction, it is very rare to see builders follow a career path from hanging drywall and pouring foundations to drafting the design for the entire building. Yet, in Information Technology it is relatively common to see developers become architects.

There is a good reason why this happens in IT but there is also a problematic result as well. The reasons why it happens are because:

1. the architecture career path is still unclear and we have to get Architects from somewhere and 
2. unlike with buildings, Architects in IT need to understand more of the technology associated with what gets built. 

We need that understanding because IT is much more dynamic than building design – we ‘reinvent’ our industry about every 5 to 10 years now. Some people still consider Frank Lloyd Wright’s work to be cutting edge and he’s been dead for more than 50 years – clearly IT and traditional architecture move at a different pace.

The problematic outcome of this situation is that many Architects tend to view the design and analytic processes associated with architecture to be inferior to ‘just building something’. This viewpoint more or less contradicts the true mission of what Architecture is supposed to do and the problem that it solves. In other words, Architecture has arisen to manage complexity; yet rapid build with minimal analysis is the number one culprit behind increasing complexity in the first place. This type of Architect could be referred to as an Architect in name only because it generally implies that they would not be practicing many of the key attributes associated with Architecture. This also potentially opens up a larger debate regarding Agile versus non-Agile IT, and that debate will never go away. The important takeaway from that debate though is when you reach the systems of system level; architecture becomes increasingly important.

Contrary to popular belief, Architecture and Agile Methodology actually complement one another.

There is a another consideration in understanding the role of the IT architect as well – without industry standard expectations in relation to what the Architect role actually represents – there can be wild inconsistencies across or even within organizations that utilize architects.  So, how could we solve this dilemma? Here are some suggestions:

1. Develop an industry standard set of role descriptions for IT Architecture. (there are groups that have developed standards for Enterprise Architects, but that is entirely too narrow to handle the larger set of expectations associated with IT architecture).
2. Ensure that any Architect in any role, anywhere – is given the top level training or expectations that are common across all architecture first (before drilling down). 
3. Help foster the distinctions between lead developers, tech leads, SMEs and Architects. This will help organizations determine when they really need an Architect as opposed to one of the other roles. If the roles are mixed it is highly likely that one part or the other of the combined role is going to get shortchanged – and that could lead to a number of unforeseen consequences. 

There are several other key attributes that help to distinguish IT Architects from other roles in IT; these include:

• Architects are often asked to act as liaison between other solution stakeholders. Sometimes Architects even become the official solution advocates.
• While sometimes asked to be advocates, Architects also tend to be the key resource in determining when a solution needs to be dropped. An Architect must be impartial when making such decisions.  
• Architects are complexity experts or managers – in other words typically Architects are dealing with “Systems of Systems” scenarios. Thus, the Architect has to be concerned not just with how the solution will operate in its own context, but how it will function in the context of the larger ecosystem. 
• Architects act as honest brokers in being able to question assumptions and drive change in order to mitigate potential risks. While other roles may be involved in this; typically Architects have the best vantage point to deal with it.
• Architects are change agents – more-so than any other IT role. Architects are asked to either envision or evaluate new technology and lead the move towards it.

The IT Architect is a relatively new role; it is often interpreted differently but it is uniquely positioned to become ever more important. As this role continues to help evolve the IT landscape, it too will evolve.


Copyright 2013,  Stephen Lahanas

#Semantech