I’ve been having a few conversations recently about what IT architecture is – both from the perspective of developing the practice that I run at risual and from conversations with others who are looking to develop an IT architecture capability in their organisations. It’s become abundantly clear to me that the term means different things to different people and is often abused. And that’s without considering that some people would argue that IT folks shouldn’t be using the name “Architect” at all!
To be fair, it seems that even (construction) Architects are arguing over whether someone is an Architect or not. Which is somewhat amusing to me as the collective noun for an architect is… an “argument of Architects”. I kid you not!
In IT, for some organisations, becoming an Architect has become the term for a senior technical person who understands large chunks of the organisation’s IT. But that’s not what it should be. Architecture is not design. But design is part of architecture. Confused? Bear with me, please.
Etymology
Let’s look at the definition of the word “architecture”:
architecture /ˈɑːkɪtɛktʃə/ noun
1. the art or practice of designing and constructing buildings.”schools of architecture and design”
[e.g.] the style in which a building is designed and constructed, especially with regard to a specific period, place, or culture. “Georgian architecture”.
2. the complex or carefully designed structure of something. “the chemical architecture of the human brain.
[e.g.] the conceptual structure and logical organization of a computer or computer-based system.
Origin: mid 16th century: from Latin architectura, from architectus.
Oxford Languages
So there we have it, architecture is about conceptual structures and logical organisation. It is not about detailed design. Ergo, an IT Architect, is not just an experienced technician.
Unfortunately though, if we look at the definition of an “architect” it all starts to fall apart. The noun for the computing sense of the word is defined as “a person who designs hardware, software, or networking applications and services of a specified type for a business or other organization” and the verb (if you can consider that architecting is really a thing – I don’t!) is “design and configure (a program or system)”. Basically, in computing, we seem to be using Architect as a synonym for Designer!
Different types of architect
Maybe looking at definitions of words was not as helpful as it should have been. So let’s consider the types of Architect we have in the IT world:
Technical Architect
Sometimes referred to as a Domain Architect (reflecting that their knowledge relates to a particular area, or domain), the Technical Architect is probably the most common use of the architecture term in IT.
There may be variations reflecting a given domain – for example Software Architect, Data Architect, Infrastructure Architect, Security Architect.
Each of these will be able to take a logical building block (see Solution Architect) and define how this part of the solution should be achieved.
There will be elements of design – but that design should be broader than just technology and will often rely on specialists for expert knowledge.
Solution Architect
Solution Architects are concerned with solutions. By that, I mean that they view a problem as a set of requirements that need to be solved by a combination of people, business processes or technology and come up with a solution.
The solution will be constructed of logical building blocks. For example, a requirement to create a website may include components such as:
- Identity and access
- Mobile application/browser
- Web server
- Database server
- Operating system
- Hardware
- Network
Note that none of these are technologies. It doesn’t say Active Directory, Chrome, Apache and MySQL, running on Linux on VMware and with TCP/IP over Ethernet using Cisco switches and routers. Those technical decisions may be taken as to how to address the requirements and fill the building blocks, but the logical blocks themselves are conceptual – not detail!
The Solution Architect will lead experts and combine their recommendations/experience into a coherent solution to a business problem. They should also consider the whole lifecycle of the solution, from development, into service (operation) and. eventually, retirement.
This post from CIO Magazine is one view of a Solution Architect, although it could be considered to be describing a little bit of a unicorn…
Enterprise Architect
Often, architecture at enterprise scale is mistakenly referred to as Enterprise Architecture but Enterprise Architecture is a discipline in its own right. A enterprise-scale solution still requires a Solution Architect.
The Enterprise Architect is (or should be) interested in:
- Business
- Data
- Application systems
- Technology
Note that technology is just a small part of that (and last to be listed), although technology is probably pervasive in the others too.
I’ve read some great posts recently on what an Enterprise Architect is – so instead of re-defining it here, I’ll signpost to these:
- Enterprise Architecture (EA) Definition and Best Practices (Thousand Eyes).
- Developing a Standard Enterprise Architecture Practice (Intel).
- Five enterprise-architecture practices that add value to digital transformations (McKinsey).
There are recognised EA frameworks, such as TOGAF and the Zacmann Framework but one of the easiest ways to understand the work of an EA is to look at Svyatoslav Kotusev (@Kotusev)’s Enterprise Architecture on a Page.
Often, the Enterprise Architects are not part of the IT function (but the Technical and Solution Architects are). Instead, the EAs are part of the organisation’s strategic planning function.
In reality, many people will move up and down this spectrum. Sometimes, a Solution Architect will have to “roll up their sleeves” and help out with a technical situation. Or maybe they will elevate themselves into the some of the Enterprise Architecture role – particularly if there is no formal Enterprise Architecture function within an organisation. But two things are clear in my mind:
- Architecture is far more than just design.
- Enterprise Architecture is not the same as architecture-at-enterprise-scale.
Sitting in ivory towers?
I’ve seen technical people with disdain for Architects because they consider them to have little practical understanding of their world. Similarly, I’ve seen “Architects” struggle to extract themselves from the mire of technical detail – particularly if that’s what they love to work with.
It’s important to be mindful of the relevance of the architecture work that’s taking place. Principles are all well and good if they make sense and are followed – but, if the Architects sit in an ivory tower generating paperwork that is of no relevance to the rest of the organisation, them will be doomed to failure. Similarly, we talk a lot about technical debt – sometimes that debt needs to be paid off, and sometimes it’s there for a good reason.
Perhaps a better way to look at it is this view, from the Enterprise Architecture Professional Journal, in which the author cautions against the argument of Architects becoming an arrogance of Architects.
Like so many things in the world of work, communication is key. And developing good architecture skills requires good written and verbal communication skills. Then there’s stakeholder management, building relationships, commercial awareness and much more.
Next time…
This post is long enough already and the topic of developing skills is pretty involved. So, in a future post, I’ll look at some ways we can develop (IT) architecture skills – and at why there seems to be so little value in (IT) Architecture certifications.
[This is an edited version of a post that was originally published at markwilson.it]
