“Architect” Should Be a Role, Not a Position
What happens when a senior developer becomes…more senior? It often happens that they get promoted to “architect”. Sometimes an architect doesn’t have to have been a developer, if they see “the bigger picture”. In the end, there’s often a person that holds the position of “architect”; a person who makes decisions about the architecture of the system or systems being developed. In bigger companies there are “architect councils”, where the designated architects of each team gather and decide wise things…
But I think it’s a bad idea to have a position of “architect”. Architect is a position in construction – and it makes sense there, as you can’t change and tweak the architecture mid-project. But software architecture is flexible and should not be defined strictly upfront. And development and architecture are so intertwined, it doesn’t make much sense to have someone who “says what’s to be done” and others who “do it”. It creates all sorts of problems, mainly coming from the fact that the architect often doesn’t fully imagine how the implementation will play out. If the architect hasn’t written code for a long time, they tend to disregard “implementation details” and go for just the abstraction. However, abstractions leak all the time, and it’s rarely a workable solution to just think of the abstraction without the particular implementation.
That’s my first claim – you cannot be a good architect without knowing exactly how to write the whole code underneath. And no, too often it’s not “simple coding”. And if you have been an architect for years, and so you haven’t written code in years, you are almost certainly not a good architect.
Yes, okay, YOU in particular may be a good architect. Maybe in your particular company it makes sense to have someone sitting in an ivory tower of abstractions and mandate how the peons have to integrate this and implement that. But even in that case, there’s a better approach.
The architect should be a role. Every senior team member can and should take the role of an architect. It doesn’t have to be one person per team. In fact, it’s better to have more. To discuss architecture in meetings similar to the feature design meetings, with the clear idea that it will be you who is going to implement the whole thing. Any overdesign (of which architects are often guilty) will have to be justified in front of yourself – “do I want to write all this boilerplate stuff, or is there a simple and more elegant way”.
The position is “software engineer”. The role can be “scrum master”, “architect”, “continuous integration officer”, etc. If the company needs an “architects’ council” to decide “bigger picture” integrations between systems, the developers can nominate someone to attend these meetings – possibly the most knowledgeable. (As many commenters put it – the architect is often a business analyst, a manager, a tech lead, most of the time. Basically “a senior developer with soft skills”. And that’s true – being “architect” is just one of their role, again)
I know what the architects are thinking now – that there are high-level concerns that developers either don’t understand or shouldn’t be bothered with. Wrong. If your developers don’t understand the higher level architectural concerns, you have a problem that would manifest itself sooner or later. And yes, they should be bothered with the bigger picture, because in order to fit the code that you are writing into the bigger picture, you should be pretty familiar with it.
There’s another aspect, and that’s team member attitudes and interaction dynamics. If someone gets “promoted” to an “architect”, without being a particularly good or respected developer, that may damage the team morale. On the other hand, one promoted to “architect” can become too self-confident and push design decisions just because they think so, and despite good arguments against them.
So, ideally (and that’s my second claim) – get rid of the architect position. Make sure your senior team members are engaged in architectural discussions and decision making – they will be more motivated that way, and they will have a more clear picture of what their development efforts should achieve. And most importantly – the architectural decisions won’t be detached from the day-to-day development “real world”, nor will they be unnecessarily complicated.
What happens when a senior developer becomes…more senior? It often happens that they get promoted to “architect”. Sometimes an architect doesn’t have to have been a developer, if they see “the bigger picture”. In the end, there’s often a person that holds the position of “architect”; a person who makes decisions about the architecture of the system or systems being developed. In bigger companies there are “architect councils”, where the designated architects of each team gather and decide wise things…
But I think it’s a bad idea to have a position of “architect”. Architect is a position in construction – and it makes sense there, as you can’t change and tweak the architecture mid-project. But software architecture is flexible and should not be defined strictly upfront. And development and architecture are so intertwined, it doesn’t make much sense to have someone who “says what’s to be done” and others who “do it”. It creates all sorts of problems, mainly coming from the fact that the architect often doesn’t fully imagine how the implementation will play out. If the architect hasn’t written code for a long time, they tend to disregard “implementation details” and go for just the abstraction. However, abstractions leak all the time, and it’s rarely a workable solution to just think of the abstraction without the particular implementation.
That’s my first claim – you cannot be a good architect without knowing exactly how to write the whole code underneath. And no, too often it’s not “simple coding”. And if you have been an architect for years, and so you haven’t written code in years, you are almost certainly not a good architect.
Yes, okay, YOU in particular may be a good architect. Maybe in your particular company it makes sense to have someone sitting in an ivory tower of abstractions and mandate how the peons have to integrate this and implement that. But even in that case, there’s a better approach.
The architect should be a role. Every senior team member can and should take the role of an architect. It doesn’t have to be one person per team. In fact, it’s better to have more. To discuss architecture in meetings similar to the feature design meetings, with the clear idea that it will be you who is going to implement the whole thing. Any overdesign (of which architects are often guilty) will have to be justified in front of yourself – “do I want to write all this boilerplate stuff, or is there a simple and more elegant way”.
The position is “software engineer”. The role can be “scrum master”, “architect”, “continuous integration officer”, etc. If the company needs an “architects’ council” to decide “bigger picture” integrations between systems, the developers can nominate someone to attend these meetings – possibly the most knowledgeable. (As many commenters put it – the architect is often a business analyst, a manager, a tech lead, most of the time. Basically “a senior developer with soft skills”. And that’s true – being “architect” is just one of their role, again)
I know what the architects are thinking now – that there are high-level concerns that developers either don’t understand or shouldn’t be bothered with. Wrong. If your developers don’t understand the higher level architectural concerns, you have a problem that would manifest itself sooner or later. And yes, they should be bothered with the bigger picture, because in order to fit the code that you are writing into the bigger picture, you should be pretty familiar with it.
There’s another aspect, and that’s team member attitudes and interaction dynamics. If someone gets “promoted” to an “architect”, without being a particularly good or respected developer, that may damage the team morale. On the other hand, one promoted to “architect” can become too self-confident and push design decisions just because they think so, and despite good arguments against them.
So, ideally (and that’s my second claim) – get rid of the architect position. Make sure your senior team members are engaged in architectural discussions and decision making – they will be more motivated that way, and they will have a more clear picture of what their development efforts should achieve. And most importantly – the architectural decisions won’t be detached from the day-to-day development “real world”, nor will they be unnecessarily complicated.
Hi, what’s the biggest project team you were part of?
Hi Bozho,
First, thanks for a very good blog post.
I have certainly felt your very same pains at certain point in my career. So I mostly agree with your points. Still I am not fully convinced that the architect position should be eradicated from all organizations.
To begin with, according to wikipedia(https://en.wikipedia.org/wiki/Software_architect) there are different types of archtiects. The first type is enterprise architect. This is a visionary type of archtiect that does mostly raodmaps and very high level stuff. Such an architect would decide things like: whether an organization should use JEE or Spring. I have for Ericsson(100k+ employees) and they had good reasons to use JEE over Spring. Such a decision is unfortunately not purely technical; it boils down to cost, politics etc. Therefore it cannot be done by an engineer wearing the Architect hat. Another example from my practice would be the decision to use open source software over paid software. This is again a very high level decision which has to be made by an archtiect. I have worked for a bank where you cannot simply grab some open source component from internet and use it. I can give more real world examples but hopefully that is not necessary. Would you agree there should be a position Enterprise Architect in certain organizations(e.g. large or heavily regulated etc)?
Next, lets take a look into the solutions architect. Let me again give you a real world example – i have worked on a project consisting of two teams: backend team responsible for processing data and loading it into a datawarehouse and front-end team creating UI for displaying the data. At that time we did not have an architect so backend team implemented a good(on its own) system which was loading proeprly all data into the datawarehouse as per the requirements. In much the same way, frontend team implemented a good(on its own) system that represented a shiny contemporary UI. And both would work just fine for some of our clients. However, one of our major clients simply has too much data. The backend system would process that(although with substantial amount of hardware) but the frontend cannot display it simply because it has to qwery tables with well over 200 million records. Nobody in the team have anticipated this. We were fairly senior team(e.g. senior engineers with around 6 years of experience) but we definitely needed an architect to focus on Non Functional Requirements who would have both team in mind. And if that is not too much I will give one more example. In another company i have worked, i have implemented a java based test automation system from the ground up. Management liked it a lot and asked me to implement the same for another team. Then another and so on. One year later, we realized that there are also other teams in the organization who are building similar systems. All this systems share the same features. But they we all build independently with zero code reuse. Therefore we realized that we need an architect who will coordinate these teams so that they can re-use common components. Still not convinced that in some organizations the position of Solutions architect might be needed?
Finally, lets take a look into application architect. I think that what you are describing in your post is exactly this type of architect. I would mostly agree with you here – if you have a small team of developers(e.g. 6 or so), building a fairly small application(e.g. that can be built in a year or so) then most probably you do not even need a full blown architecture. You simply need a one page high level design document. Probably true that you do not need a dedicated architect for that.
I feel that you claim Architect position should be removed because you have came across bad architects in your practice. But not all architects are bad. A good architect is not completely disconnected from the dev team as you describe; instead she is taking feedback from the team to create the architecture. A good architect does not prescribe how engineers should do their work; instead she is pointing out high level concerns that they could potentially overlook. And before all, a good architect does not think she is better than anyone in the team; instead she realizes that she is just an engineer doing something slightly different than coding.
Please let me know your thoughts.
Kinds regards,
Mihail
@Mihail – thanks foryour comment. I have seen some good architects as well. And they also think they shouldn’t be in that “position” 🙂
But you are right, I exaggerate the downsides a bit, and oversimplify things. Of course nobody should start firing architects tomorrow.
Many arguments I’ve read so far revolve around the soft skills the architect should possess, as opposed to a regular developer. But that doesn’t contradict the role vs position point.
@Bozho, thanks for your reply.
Probably I did not emphasize that enough in my previous comment, but the point I was trying to make is that most(but not all e.g. me excluded:) Architects are not developers. The Architect has a mostly political role; architect is a liaison between business and dev. He/she is a PowerPoint expert spending most of his/her time writing documents, attending meetings, negotiating with stakeholders and making presentations. Most of the developers I know(including me) would not go anywhere near this sort of nonsense; or at least not on a full time basis.However some organizations need someone to do this full-time because there is a lot of work involved.
The architect usually produces an Architecture document which is a beefy paper(often over 100 pages) describing the system so that it makes sense to different stakeholders. That includes business people who usually do not have a clue about technology. Who in the world would like to explain technical concepts to non techy people? Certainly not a developer:) You need a cold blooded architect for that.
So I think Architect should be a position when it comes to Enterprise architect and Solution Architect simply because it has nothing to do with coding. When it comes to Application architect, it should be a role e.g. the technical lead should drive the creation of the architecture collaboratively with the rest of the team.
Does that make any sense?
Yes, it does. In those cases I’d just probably rename the title. From “X architect” to something like “Technical business analyst” or “Overview communicator” 🙂
What about having a Chief Architect for larger projects/products? Would it make sense for a person in this role to provide architectural guidance/direction, in collaboration with Lead Engineers? I’ve seen this work well at the Program Level, with a Chief Architect, collaborating with Technical Leads at the Scrum level.
Un arquitecto claro que debe poseer habilidades blandas, ya que en una presentación con gerentes simplemente no le vas a mostrar un diagrama de clases, MER, secuencia o UML. Se usa un diagrama de contexto para ello o en algunos casos un modelado de negocio con BPM. Lo que usted describe es un arquitecto de papel o peores, los cuales no tienen conocimiento de programación o en el caso del arquitecto de papel no validan que los desarrolladores estén implementando la solución diseñada. para llegar a ser un buen arquitecto tuvo que ser un excelente desarrollador, enfocarse en estilos arquitecturales, patrones de diseño, poseer mucha experiencia, adicional a ellos las habilidades blandas y la capacidad para producir un ROI a la empresa.
To be honest I am appalled by this post. The first sentence that hit me “architects is a position in construction” – this understanding itself is so flawed. Architect comes from greek word which means chief builder.
Sure we were not in a digital world before – so chief builder usually meant building some structure or monument. But the definition stays the same.
What do you call a director ? would you say it should be someone directing movies ? or the Agile methodology ? its built for manufacturing companies. but its being adopted in so many tech companies(even though i dont like it – it still works well for so many projects) .
Secondly coming to the position – You have developers joining in and moving out of projects. Developers might be skilled in programming but they dont necessarily understand the whole picture.
Because your same logic can be applied to construction companies. Any person working in the construction of a building should be aware of what they’re building. So why stop with architects, we wont need managers either. We just need a bunch of developers who can understand client needs and work on the implementation – as they can be capable of understanding the whole picture, they should also be capable of knowing what to test. So testers, managers, architects etc are not needed at all. as basically you’re considering all these roles can be played by the developers.
You have to try to experiment this in real time to see how large projects would fail just because they did not listen to a solution architect : )