Is the role of Software Architect still relevant in an Agile development shop? Given that Agile methodologies shun big up front design and take design-as-you-go approach, should there be a person or persons designated to look after the system architecture? The answer is unequivocally yes for any system of any significant size. For any significant system, there are key technology decisions that need to be made up front before development can even begin. For example, whether the system is going to be a desktop application or a web application? Will it be hosted on Windows or UNIX? Which programming language and class libraries to use? Key technology and architectural approaches must be vetted out carefully before coding can begin. Once coding begins, some architectural oversight has to be in place to ensure the system follows the planned architectural pattern. There is still plenty to do during the development Sprints. However, in an Agile environment, a Software Architect must adapt his or her approach towards creating, implementing and overseeing system architecture:
- Live in the moment! Defer decisions to the last responsible moment. Let the architecture emerge. Only decide what needs to be decided right now. Set the direction and let the developers fill in the rest. To maintain oversight, pair program with developers especially in key areas where security, performance and scalability aspects of the application are at stake. In addition, review unit and functional tests.
- Consider yourself part of the development team. To garner any respect or following from the development team, an Architect must be an excellent technologist. Absolutely write some production code. This is in addition to developing proof of concepts, prototypes, design patterns, and perhaps some base classes to kick start the development. At the outset of a new system (or subsystem) development, an Architect must validate the approach by creating a skeletal version of the application that hits all key technologies that will be utilized and simulate all application tiers that would be deployed in the production system.
- Communicate in the language of the developers (e.g. class diagrams, code examples, whiteboard, not PowerPoint slides). High level artifacts do not resonate well with developers who are focused on what needs to be done right now to complete stories in the current Sprint. Maintain a development WIKI where engineers can document significant design decisions. For one, this makes engineers think harder about the design decision they are making and perhaps just as importantly provides some continuity as different Agile teams work on the same feature over time.
- On top of all of the above, an Architect must have the temperament and patience to listen and balance the needs of all stakeholders. An Architect must be able to effectively communicate the system design, at different levels of detail, to internal (e.g. sales, marketing, documentation, executive team) and external stakeholders (e.g. users, customer leadership team, customer IT department) and explain how the system design meets everyone's business goals.
