Large-Scale Agile Design & Architecture: Ways of Working

This week I’ve read topic about architecture on the InfoQ - Large-Scale Agile Design & Architecture: Ways of Working
There is a lot of suggestions about Agile architecture and thoughts around Astronaut Architect, Power Point Architects and etc.
For some reasons such architects are really does not bring any benefits for the projects inside the big company, but from other side if the hierarchy with in company properly organized they will bring a lot of the benefits. Just of example, some of the main role of the PowerPoint architect to talk with managers or customers about why we need refactoring, why we need change something and what goal should be accomplished. The example provided by author regarding the selecting processor just confirm that company does not have good communications inside the development.

Also author is talking that real architecture is the source code and that is true, but when project starts and only limited people involved in to the initial stage the role of the architect and having initial architecture on the paper is really important. Architect and paper architecture are main information about what we are really building and used for teach developers about components they will work on. Architect should keep in mind all components and he is the primary decision maker for any cross components aspects. When team start coding, his role transforms to the Master gardener, who is looking around, check implementation, code quality, and how architecture grows.

However many important practices was introduced in this topic that may really help to build architecture. My favorite is Design Workshop. If you have team with preliminary same level this session will help you to establish the common vision for the development and help to identify holes in the architecture in the latest stages. For one of my project where we had star team we doing workshops very often and it helps us to deliver feature in time with maximum features and this code still alive in the production.

Also mentioned standard approaches about decoupling components, abstraction from specific realization, TDD, and other practice but this is an general things what everyone should.

The last thing I would like to emphasize regarding architecture in the Agile – you like architect should control implementation because due focus on the features development team has temptation implement something quickly and then left it as is for the final release. This situation like what author mentioned about garden. So keep your ayes opened, review code on regular basis to avoid surprise in the end.