Main image of article What Does an IT Architect Do?

What does an IT architect do? It’s an interesting question not only for those thinking about a career as an IT architect, but also for anyone working in IT, because there isn’t a consistent definition of the job within the industry. Architects who do more or less the same things with the same skills may be referred to as enterprise architects, solution architects, project architects, IT architects, technical architects, data architects, application architects, business architects, cloud or SOA architects, and security architects. How’s that for a list? And it’s not even complete. What if anything differentiates these roles? More importantly, what elements do they have in common? Not too long ago, few people used the term “architect” to describe anyone in IT. Why has this changed? Let’s take a look at some answers:

  1. Architecture roles are generally differentiated by some level of solution-specific expertise in one area or another. This could involve methodology, toolsets, skill sets 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 on only one area, then he or she becomes a subject matter expert and not an architect. This is an important and practical distinction, because technology keeps changing. Today’s stack will not be the same as tomorrow’s. Architects must understand the entire stack as it evolves and change their 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 a designer is obvious. But just as important is that the architect 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 buildings)? Perhaps the most interesting difference 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’s 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 IT it’s relatively common to see developers become architects. There is a good reason why this happens, though there is a problematic result as well. It happens because the architecture career path is still unclear -- we have to get architects from somewhere and IT architects 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 five to 10 years now. The problematic outcome 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 architecture and the problem that it solves. In other words, architecture arose to manage complexity, yet rapid build with minimal analysis is the biggest culprit behind increasing complexity in the first place. There is another consideration in understanding the role of the IT architect. Without industry standard expectations in relation to what the role actually represents, there can be wild inconsistencies across organizations that use them. How can we solve this dilemma? Here are some suggestions:

  1. Develop an industry standard set of role descriptions for IT architects.
  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’s highly likely that one part or another of the combined role is going to get shortchanged – and that could lead to a number of unforeseen and unfortunate 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 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 they’re typically 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. They question assumptions and drive change to mitigate potential risks. While other roles may be involved in this, architects typically have the best vantage point to deal with it.
  • Architects are change agents. More so than any other IT professional, architects are asked to either envision or evaluate new technology and lead the move toward it.

The IT architect is a relatively new role. Though how it’s defined is often interpreted differently, it’s uniquely positioned to become ever more important. As it continues to help evolve the IT landscape, so will it evolve as well.