Should we define architecture from the ivory tower?

April 29th, 2019 Software Architecture 'Ivory Tower at St John''s College, Cambridge' by Connor Wang on Unsplash

Every now and then I encounter architecture defined from an ivory tower. Quite often the development teams dislike the disconnect of the architecture to real practical world. We see architects that have quite some development experience behind their belt. Experience they gained in the early 2000s. After which they got promoted to the architecture role.

Ivory Tower Architects

The architects living in the ivory tower, got there years, sometimes even decades ago. They built their knowledge as a developer in technologies that have since disappeared. And because architecture tends to be technology agnostic, they never updated their knowledge. Quite often they have their own office on a different floor, maybe even with a view. So they are very far from the mud on the ground-floor where actually software is build. They might not even know what CI/CD is. They have heard a bit on the cloud, but don't understand the differences between IaaS and PaaS. They define the architecture in a Word document and will handout some bound copies of the architecture to the team.

How on earth can this go right? Happily teams ignore those architects completely. They figure the architecture out themselves, making some mistakes on the path to a working solution. But being agile they resolve those mistakes as well. You say, those architects are ignored? Yes they are! And because the implemented solution is seldom validated against the architecture nobody cares, as long as there's a working solution.

Polder model architecture

Okay, it's clear to everyone I don't like architects that are directing from their ivory tower without any mud on their shoes. Another thing which happens sometimes, is an architect who wants to be friends with everybody or something like that. The architect doesn't make any decision by himself, for everything to decide he wants the team "to vote" for the best option. Or even worse he might ask everyone in the team to come up with a solution. I call the resulting architecture Polder model architecture, named after the Dutch polder model (consensus decision-making).

This will never create the best architecture. Just to be honest not everybody has the same experience and can think in broader solutions, yet. The guys with the loudest voice will most likely get the most attention for their solutions, which of course has a chance to be the best.

On the other hand, it doesn't harm to validate a solution with one or two peers.

The solution, a coding architect

The architects that I believe have the best solutions and are trusted the most are coding architects. A coding architect doesn't just define the architecture but can also validate the architecture himself. Besides the self validating, he checks parts of his architecture with the peers being expert in the specific topic. The architecture doesn't just consist of some documentation, but is supplemented with reference applications. The architecture is also taught to the teams in sessions which allows them to get answers to things being unclear. Ideally the coding architect joins teams to help setup their application and get up to speed when starting a new project.

What's your preference? Mine is clear, and rather harsh. Go for the coding architect.