Recently I've had a few conversations along the lines of "what is architecture?" The natural follow on to that question is "what is an architect?" (I'll come back to that later).
Firstly, what is architecture? This is an interesting one. Depending on who I speak to I may get very different answers. It may well come down to the type of organisation people work in or perhaps the role they play within the organisation.
The best, or at least the most succinct, answer I've come across is that architecture is any decision that is hard to change later. This sounds very good to me because it plays to my feelings about drawing out diagrams and discussing a big picture and then talking over the consequences of arrows going from one place to another and what may happen if that bit is different and how that could affect the other bits it touches. But this definition also plays to my prejudice about what an architect should be. If we accept that architecture is a decision that is hard to change later then we must also believe that an architect makes such decisions or is responsible for such decisions. This idea would also closely align with how we think of as a bricks and mortar, as opposed to technology, architect.
But how often are people who either style themselves as architects or whose job title contains the word "architect" doing this kind of work, making these kind of decisions, and little else?
In my personal experience I have come across 2 other, more common, types of architects.
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, 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.
I'm interested at the moment in architectology. Why is it necessary and what does it say about the organisation that has them? The first question can be easily answered. You need them if you have a lot of legacy and a lot of knowledge silos. Somebody has to be there to help developers or BAs traverse the organisational silos in order to deliver value to the business.
What does it say about the organisation that has architectologists? Are they valuable or is there function waste? I haven't got a good answer to this question yet but instinctively it feels to me like they are waste. Instead of helping teams to traverse the silos and integrate to the legacy using the antiquated interfaces that exist it feels like the investment should be in decoupling the systems and creating a series of self service APIs that can be consumed by value adding applications. I'm currently investigating this idea more at my current client so hopefully we'll get to a better state and a better understanding of how we can get real value from the architects.
