“This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.”
One of the strangest functional roles that exist in corporate software development environments is that of the “software architect”. The very term evokes images of a senior engineer that has by virtue of his or her experience mastered his or her craft so well that they need not partake in trivialities such as writing code anymore.
Just like the architect in the movie ‘The Matrix’, these individuals can simply sit and make high brow proclamations about how software should be built. Afterwards they can marvel at the genius of what they have supposedly conceptualized while skeptically bemoaning the apparent failures on part of the people that had to execute on their vision.
The biggest problem with having these ivory tower styled architects is that if you are going to be conceiving of software design (and be a “technical person”), you simply have to be comfortable with the actual act of coding. That is after all the activity that makes the design real and has it own set of nuances and intricacies.
This means that no distinction should exist between architecture and the act of coding. It is an activity that should be a shared concern of an autonomous team building a system collaboratively.
Of course it helps being able to articulate architecture and highlight impacts of technical decision making especially in ways that non-technical people can understand. But that is a skill that every technologist should strive to perfect, not just the select few that carry the title of an architect.
The strangest version of this functional role is when someone that does not come from a technical background starts making proclamations about architecture and gets labelled as one. The subtleties of technology frameworks and practicalities of actually building coherent software systems would be completely lost on such an individual. Yet modern corporate environments are rife with these types of individuals who “build” systems every day.
So what is architecture then if anything at all?
Personally I like Martin Fowler’s view that if there is such as thing as architecture, it is essentially about two things. One is about creating a shared understanding in your teams and the other is actually investigating and answering the things in the projects that will be hard to change in the future.
The rest you can leave to your very capable and trusted development team.