The Difference Between IT Architecture & Subject Matter Expertise

This is a question that comes up very frequently in my line of work, although it isn't always posed as a question. The question in its most generic form goes something like this - "how much specific technical expertise should an Architect have." That's a tough one isn't it, especially if one considers themselves an IT Architect as a opposed to something much more specific (let's say a Hyperion or Informatica Architect).

We've defined IT Architecture in this blog but we haven't covered Subject Matter Expertise in great detail yet. What does it mean to be a SME?

Subject Matter Expertise, Defined
Being a Subject Matter Expert requires an in-depth understanding in one specific topic; that topic can be a field of practice, a theory or some particular product or tool (or set of related products). In the context of IT, that expertise necessarily implies the ability to perform any related tasks (configuration, design or development) at a more or less 'master' level. This further implies that the SME role often actually encompasses several typical roles; Architect, Lead Developer and Administrator.

So, this definition obviously begs a number of interesting questions:

1. Should Architects be expert in one or more technologies?
2. Can Architects become experts in many (or all of) the various technologies they work with?
3. How important is the discipline or practice of architecture as compared to Subject Matter Expertise?
4. Can someone who is only expert in one area then handle or deal with a large heterogeneous environment?

All of these questions are being driven to some extent by the expectations of organizations that would hire Architects or SMEs. Part of the dynamic that's present these days is that many enterprises want both things (the Architect and the SME) but only want to pay for one person to do it - thereby merging the roles. In some of those cases, this desire is somewhat justified in that there may be relatively little design effort required but a great deal of configuration, follow-on development and many coordinated deployments.

But is that really a question of whether one ought to have an SME skill set as opposed to an IT Architecture skill set - or is it a question of whether the assignments and team composition is correct? Let's consider some reactions to all these questions:

• It is not realistic to assume that any one technical resource will become expert in every technology within their particular environment. It is also not necessary.
• Architecture is much more focused on design than deployment - granted it plays an oversight role once things have left the drawing board, but that merely means the Architect is available for other design duties. It is unlikely in most cases that the designer will be the best development resource (either due to higher cost or the fact they spend more time designing than developing).
• Architects and SMEs can work together - as separate roles - quite effectively. There is no reason that both or either role has to be full-time - they can be brought in as necessary.
• It will be necessary at times for Architects to "dive-in" to one specific area or another to solve a problem. Sometimes in doing this the Architect then becomes an expert in that area. In many other times, the Architect understands the common technical standards, the underlying principles and perhaps key features but does not become the expert. That's ok as well, as long as what the Architect is trained to do is solve problems - regardless of the technology involved and that others have similar dedicated roles and skills sets that complement the team.

I've heard folks voice concerns that they want Architects who can implement rather than merely design. This is an interesting situation and perhaps reflects a bit the relative lack of consensus surrounding IT Architecture in industry. If we were to compare ourselves to our brick and mortar brethren, how common would it be for us to expect a building architect to be scaling a high rise to place beams or pour concrete or even to determine the proper layout of pipes and wires. The traditional architect designs with all of those considerations in mind, works with engineers and contractors to solve problems and is ultimately responsible for the outcome of the project. He / she is in an expert in what they do but not an expert in every possible technology involved in building today's high-rises.

IT and building construction are both similar and different at the same time. But the core question of expanding complexity is fundamentally the same. The more complex your environment, the more likely you will need a division of labor, and at one end of the spectrum you will find the Architect who has design command of all the relevant technologies within a unified solution context. At the other end you will have SMEs who know everything there is to know about individual pieces of that puzzle. Occasionally this is one and the same person - but not very often - nor should it be.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc