So... What Exactly Is IT Architecture, Anyway?
Maybe it's just me, or does everyone in IT seem to be an Architect of some sort or another these days?
Architecture seems to have become a fashionable IT buzzword, and this seeds confusion regarding the duties and responsibilities of architects. This can create risk for organisations that 'do' architecture, because the outcomes and value delivered to business by architecture can be poorly defined, leading to risk of diluted and confused outcomes. Subsequently, for those of us that are Architects, the long-term value of our profession might be called into question should our fundamental proposition be misunderstood.
This articles imagines definitions of different architecture disciplines, and compares them with with the duties often expected of architects within organisations. This is entirely my own opinion, and is derived only from my own reflections and experiences.
Architecture Definitions vs Real World
| Discipline | My Formal Definition | My Pragmatic Definition |
| Enterprise Architecture | Governance of IT services such that alignment with business strategy and outcomes are achieved. Use of techniques to achieve the above, particularly TOGAF and the Architecture Development Method (ADM) | Top-down knowledge of all IT services within an organisation, and how they integrate, typically recorded on a Visio diagram. Knowledge of how things work, and how they get done. |
| Solution Architecture | The creation of a High Level Design from a set of requirements. Governance of the evolving maturity of an engineered solution, typically with reference to the Systems Engineering framework. | A highly skilled and experienced technical expert who can design and implement IT changes and projects. |
'Domain-specific' Architecture(s) For example, Technical, Network, Cloud, Infrastructure, Service, etc. | Technical subject matter experts that may produce Low Level Designs within their field of expertise as part of the Systems Engineering framework | Technical subject matter experts that may also posses technical design accountabilities, although not necessarily driven by a framework. |
Managing Client Expectations of Architecture
To avoid potential confusion, when engaging with a client I try to focus on expected outcomes and value rather than role titles. For example, I tend to frame exploratory questions along the lines of:
- "...if an architect were successful, what would that success look like for your business?"
- "...with a successful architecture practice in place, what would be different?"
- "...what pain points do you have now that architecture will solve?"
This helps clients articulate their intended benefits rather than focusing on job titles.
From this articulation I can usually design a mix of Enterprise, Solution and Domain architectures to fit their needs without constraint of formal definitions.