The 5 Rules of IT Architecture

It is perplexing that after nearly 20 years since the emergence of IT Architecture as a discipline, there is still so much confusion surrounding what architects do (or more precisely, what they are supposed to do).

Many people in IT refer to themselves as "Architects" now - yet how can employers or colleagues quantify or otherwise validate that they are indeed actually Architects? I will propose five simple rules or tests to help clarify this:

Rule 1 - Architects architect, just as writers write. Architecture is by definition a design process. Any architect who doesn't or can't produce design is not functioning in the assigned role. An important corollary to this is that you cannot be an effective Architect and focus only on one 1 thing in IT - for example 1 tool / product. Architecture is a discipline, not SME knowledge in one particular area. The reason why this is the case is that most of the time focus on one product leads to a very myopic view of how to solve a problem (every issue begins to look like a nail for your one hammer).

Rule 2 - Architects follow a design process; whether it is geared towards EA frameworks or application design is somewhat irrelevant. What is crucial is that an approach is followed. Not having an approach means not having standard design expectations or deliverables. A lack of design diligence is analogous to a brick and mortar architect using cocktail napkins instead of blueprints to design skyscrapers.

Rule 3 - Architects are honest brokers, not blind followers. Why is this important? Well, it matters because the design process is where most key IT decisions get made. The Architect must take a certain level of responsibility for the outcomes associated with their work - just as brick and mortar architects do. If a client building a Summer house on the beach demands that the structure be built atop sand without concrete or wooden supports, the Architect must let them know the house will likely suffer a structural failure shortly after completion (if not before).

Rule 4 - Architects are problem solvers. Anyone working as an architect who deliberately avoids facing and resolving the tough issues is unlikely to achieve any sort of measurable project success.

Rule 5 - Architects must be able to communicate with the organization they are serving. This applies both to having personal effective communication skills, but also to the projects themselves. Projects that aren't transparent or collaborative tend to take longer and experience high failure rates.

IT Architects tend to be placed in high-profile, high-pressure roles. We who serve as IT Architects are constantly being judged not only personally but also as a profession. Part of the reason the latter half of the previous statement is true is due to the inconsistencies in outcomes for architecture-related projects.

However, if both Architects and their colleagues used the 5 rules above to define what should be happening, the outcomes for most architecture projects would improve dramatically.

Design requires visualization - effective visualizations can be notation-driven or conceptual (as in the above example) 

Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas