We’re Agile, we don’t need no stinkin’ architects!
It would seem that Agile principles are in direct conflict with a traditional software architect role — in an agile project, where the creation of working, tested code trumps everything else, nothing separates architecture from design and implementation. They are all wrapped up together in the practices we use to produce the code. Instead of traditional documents and diagrams, the architecture is going to be exposed through the software itself…
So what does an Architect do in an architecture-antagonistic TDD/Agile/XP shop?
Mark J. Balbes, PhD recently shared his experiences as an Agile Architect, and it was so compelling we just had to share.
Architecture Is a Frame of Mind
To Mark, architecture is a frame of mind. There is no room for an “ivory tower” architect that sits at a desk creating diagrams and making architectural rules for development teams to follow. Agile development favors person-to-person communication over written documentation. If you’re an agile architect, the best place to be is in the war room with the development team, working alongside them every day.
The architect’s role, then, is not to dictate to the team, but rather to guide, mentor and cajole the team in the right direction.
The War Room Is Where It’s At
The hustle and bustle of development is exciting and provides almost everything Mark needs to do his job. In the war room, Mark can listen to what is going on with the team, shepherd the team to keep the software development moving in the right direction and mentor team members on the concepts they may not be familiar with.
Mark has found that as an agile architect, listening is the most important skill. In the war room, he has positioned himself so he can hear all that goes on. Part of his job is to listen to the discussion, pick out the important aspects of each side, help the team see the advantages and disadvantages of each proposed solution then come to a consensus.
Mark also acts as a mentor to the team. While he is certainly not the strongest technical member of the team, he can often see potential solutions that the rest of the team misses because he is looking at the problem from a different perspective.
Shepherd the Team
Mark is a shepherd for the team. There’s a saying, “The road to hell is paved with good intentions.” That is definitely true for agile software development, where a series of small solutions can snowball into an unwieldy mess. The problem arises out of the agile philosophy of doing the simplest thing possible to solve a problem and not trying to solve tomorrow’s problems today. This philosophy works well most of the time. However, there are occasions when a series of simple enhancements builds to an unworkable or unmaintainable solution. It’s Mark’s job to see when that is happening and change course before his team wastes too much time and effort.
It’s All About the Code…
The agile architect is a jack-of-all-trades, doing what is necessary to ensure architectural integrity of the product. Listening, guiding, mentoring and cajoling are all part of the job. While the team owns the solution to a problem, it is the architect’s job to state what the qualities of the solution should be. And when something is particularly tricky or important, the agile architect rolls up his sleeves and gets to work coding with the rest of the team.
The agile architect must understand the current state of the software and know where it is going. He must spend his time with the team and be involved in all aspects of the project. The days of the ivory tower architect, sitting in an office producing diagrams and documents that may or may not be relevant, are dead.