What is an architect? In my experience there are three types of architect.
Firstly, it is a job title bestowed on software developers after they have been designated as senior developers. This often involves no real change in duties except more management. Sometimes there may be an “architecture group” which the architects contribute to. The architecture group is responsible for architecture decisions which in practice means “anything we do that affects more than one team”.
Secondly, and this is probably the closest of the three to what people imagine when they hear “architect” is an architect who actually plans how to execute projects or products. This architect has a good understanding of technology stacks, how systems communicate and what it is that the business wants delivered. This architect should be capable of articulating what decisions were made and why they were made. They should also be sufficiently close to the development effort that they can still contribute to it.
Thirdly, there are “architects” who spend their time trawling through legacy code and reading legacy (probably out of date) documentation in order to understand the existing technology landscape of their organisation. These people probably don’t write code and possibly rarely even talk to people who write code. They explain, or attempt to explain, to development teams (or BAs) how things are and therefore what constraints exist on teams that attempt to create value for the organisation. These people are architectologists.
Architectology is an anti-pattern. If your organisation has architectologists then you probably have lots of legacy systems that exist in lots of silos and they probably have lots of insidious couplings, some obvious explicit couplings and some less obvious and more dangerous temporal couplings. I’ve seen this anti pattern in several companies into which I’ve consulted and I’ll explain how to spot an architectologist and what to do about it if you have them in your organisation.
About James Birnie
I’ve been working on commercial software since the late 1990s. Back then TDD was something you studied but never did, pipelines were something that carried oil and agile and lean were words used to describe gymnasts. In 2006 I joined a startup and worked there for 9 years which included at least 3 major rewrites, cloud migrations and an Agile transformation. In 2015 I joined ThoughtWorks and I’ve since worked on 3 major projects on 3 very different technology stacks in very different organisations.