Agile enthusiasts often warn about the dangers of “ivory tower” or “PowerPoint” architects who are out of touch with the reality of software development. No architect will ever admit to this charge, but unless you are getting your hands dirty with code there is a danger that you will only talk about systems in the abstract.

This is not to say that we don't need architects. Architectural decisions don't go away just because you have organised development into agile teams. You still need to have a strategic view of the technologies, standards and data that are shared across the enterprise and ensure they amount to a coherent whole. The challenge for architects is to communicate this to agile teams in a meaningful way that they can relate to.

Too senior to code?

In larger organisations this strategic view is looked after by specialists who do nothing else but think about system architecture. They may regard coding as something they have “evolved beyond” but risk getting left behind by the onward march of technology and continuous emergence of new techniques.

For example, coding practices such as Test Driven Development (TDD) and refactoring can directly influence design, though you generally need hands-on experience to really understand why. Without this direct familiarity an architect risks being ignorant of many of the more subtle dynamics involved in agile, collaborative systems design.

Rightly or wrongly, architecture is perceived as a senior role.  Architects are often recruited in at the same level as management and are generally paid on a similar scale. At the same time, many larger organisations are effectively undermining the value of programming by paying lower salaries or outsourcing it to cheaper, off-shore offices.

This can create disconnect between the perceived value of writing code and the relative seniority of the architect who is doing it. This shouldn't put architects off writing code as it can be a critical medium for communicating ideas to development teams.

Architects as mentors

Lean and agile thinking emphasises the role of "manager-teachers" who mentor others by engaging directly in their work. This is influenced by the management culture at Toyota where managers were encouraged get involved in the physical front-line of work rather than sitting behind their desks and relying on reports.

Assuming that empowered agile teams should be taking ownership of solutions, architects add the most value when they help teams to achieve a better solution through practical guidance. Architects should be technical leaders that are prepared to work directly with teams in developing their ideas. This generally means rolling up your sleeves and getting into some code.

Architects don't have to join the teams on a permanent basis, but they do have to collaboratively work with code. They should demonstrate the viability of solutions before trying to foster them on teams. A "walking skeleton" can be a useful approach here, providing a basic solution that demonstrates a narrow slice of the overall architecture. This can be socialised with teams using workshops or even pair programming.

Building empathy

The problem with empowered agile teams is that they have every right to ignore you. Architecture in an agile context becomes more of a consultative role where persuasion and influence is required over governance and control. An architect needs to build empathy and authority with development teams over the long term to be taken seriously.

An architect needs to make sure that design suggestions are realistic and credible rather than presenting something simplistic that lacks credibility with a team. Presenting ideas in terms of working code can often be more meaningful to developers than a PowerPoint deck.

Note that this does not mean that architects should create frameworks for teams. If a team feel they are having code forced on them it can undermine any sense of collective code ownership. The team should be given the freedom to reject your suggestions if they have better ideas.

A little sensitivity is always required when presenting ideas to teams. You should take care not to try and tell developers what their jobs are. It's hubris to imagine that you can foist code on seasoned developers who are accustomed to writing it day-in and day-out. They may well regard your efforts as naff and old fashioned.

It's unrealistic to imagine that an architect can join a development team full-time. This means that a respectful distance should be maintained so you are not seen to be overstepping your role. Software design in an agile context is a much more collaborative activity than the “big design up front” approach of old, so architects need to build credibility and empathy with development teams. They need to write some code.

Filed under Agile, Architecture, Favourite posts and Rants.