Software "architecture" is just software design removed from software development, often performed by other people than those who develop the software, and pretty much a terrible idea. Agree? Disagree? Why?
@bitbear Yes, someone within the team needs to have the overview - the more the better. I agree with this. Sounds like you agree with me: architecture is a development consideration - a role, not a position.
@christian I agree it’s more of a role than a position.
“Software Architect” can also work as a position as long as they are aware of the correlation between distance from code and unrealistic architectures, and continually combat architectural issues rooted in what over time develops into code illiteracy.
Combatting these issues doesn’t necessarily mean the architect needs to write code themselves, but it’s the best solution, imho.
Other strategies are to listen to the team, take advice from developers with architectural traits, remain humble to other developer’s opinions and experiences, and incorporate that feedback into the architecture iteratively.
@christian it's possible to be a valuable architect without being proficient in all the languages involved. for example, an architect can be comfortable with Terraform and OpenAPI exclusively, and still design good systems that meet developer and business requirements, so long as they accept input from stakeholders.
The ivory tower archetype comes from those who produce output without accepting input, and it's far from exclusive to architects. I've seen managers, product owners and others all fall into that trap.
@craignicol I strongly disagree that someone who only knows Terraform and OpenAPI can make meaningful decisions about software architecture.
@christian I would say it depends what they are designing. OpenAPI can describe domain models as well as any other language, and can describe security, relationships. And Terraform is the world of scalability and resilience, which many developers need assistance in. Between them, an architect can describe the data structure, the data and user flows, and discuss the functional and non-functional requirements.
I wouldn't expect them to estimate the work, or write all the acceptance criteria, but they should be able to speak a common language that would guide the front-end, the database, the integration, and the analyst developers, and aid them to map their work to the requests from all the stakeholders.
@christian I disagree.
Some software architects may operate like this, but their architectures are as removed from reality as building architectures drawn by architects who have no hands-on experience with materials like steel, rock, glass and concrete. Both kinds of ivory tower architects will produce architectures that are impossible to build in real life.
Most software architects I know does not necessarily consider themselves to be software architects.
But assembling large heterogeneous systems consisting of various materials, applying different patterns of communication to different parts of the system and ensuring that both individual parts and the whole make sense, is most definitely software architecture and is an essential skill and interest to have in order to produce usable and maintainable systems.
Not all developers have or needs to have this skill, though. But someone within a team do, or else they’ll produce unmaintainable big balls of mud.