English | EN Bring Down Your Solution Architects!
Apr 22, 2014
The adoption of agility rises each year in business. I speak here not just only about project processes but about mindset. This change in mindsets can be attributed to the arrival of new generations (Y and Z) that promote community and not hierarchy; highlight a new weak link: the ivory tower architect.
This architect is still part of those who think that the developer is at the bottom of the food chain, the “architect” title then rhyming with supervisor. His behavior generally includes the following:
- Not communicating his choices or challenging them
- Being a specialist Big Design Up Front (BDUF)
- Being a “non-coding architect”
- Often becoming a bottleneck on projects
At a time when “adaptation” has become a key word, it is difficult to argue that the best solution may come from a single brain that is not part of the team. In addition most people agree a business specification that is too detailed, at project start, is not viable in most cases. But it should also be obvious to architecture that not being precise and thought through by project stakeholders can become a handicap and a cause of failure.
Below is a sample conversation architects should be having with PMs:
- “(Architect) What does it means? Will you tell us that the architect is no longer useful? We can no longer make architecture upstream? An architect must also do coding? “
- “(PM) The architect role is changing and must change; we now talk about: agile architect.”
- “It’s just an architect who knows agility, just a buzz word, no?”
- “No, it’s more like this… “
The agile architect must meet the agile manifesto and ensure an agile architecture. They must also work with the team.
On the technical side
Of course architecture and design are important, but the agile architect must find a balance between adaptation and anticipation to deal with the complexity of systems. An agile architecture must give way to the emergence of ideas. He must:
- Design—but minimal. How can we claim to choose the best solution without challenging with the team or live part of the project from the inside?
- Accompany and improve the development team. Close to the customer, the architect’s role is to anticipate the critical, technical points. These reflect upstream and allow the team to make the best decision with all the necessary information. The final conception must be done with the whole team.
- Protect the team progress. And to do that, the architect must be very agile and polyvalent—juggling a lot of different roles (yes … including coding!)
On the human side
The agile architect, because of his leadership, is a glue for the team; he is a mediator and a mentor, always connected to the project and the team. He assists the team in making its own decisions, is humble, and wants to transmit his knowledge, not shine. It is much more rewarding to have accompanied a person in order to make the right decision, than simply telling someone what he has to do.
And he embraces changes.
He must continue to code to be legitimate, and it is natural. Developing a solution is the essence of his art. He is an expert developer and trainer, and he is passionate. This role evolves at the same time that the developer job finally takes its nobility. I would even add that this role must evolve even if a project is not delivered in an agile way.
About the author
