The role of the Architect in Agile Projects

When working on an agile project there are four principals from the Agile Manifesto that should focus the project/team. When considering the role of the Architect in the project you still have to conform to these principals. Traditional Architect engagements are at the start of the project with an exit usually shortly after the high level design is complete and some evidence of the implementation of this design has been reviewed.

There is a great article on The Shiny New Agile Architect that caught my eye and does a great job of explaining the responsibilities of the Architect. Much the same as for any project, that is run under any methodology, the Architect is focused on the impact the Non-Functional Requirements have on the final solution. Vikas Hazrati does a great job of distilling this down to some great traits.

The trait about architects building tests to test the architecture decisions is a very interesting one.

An Agile Architect writes system-level tests that stress the architecture.

Unit testing is a major component of any successful agile project it allows the team to respond to change in a controlled manner. Knowing that you can change your code and know that any functionality that you had previously been built still works is a powerful thing. Being able to make changes and know that your architecture still meets your non-functional requirements is even more powerful. Non-functional requirements are all about the quality of the software, having this baked in at the start through testing means it isn’t neglected. Retrofitting a design to deal with a quality issues is never an enjoyable experience.

The prioritisation of features/stories etc in an agile project is the job of the customer so often it is unclear how to build in the non-functional features/stories into the project. A customer should be able to prioritise tasks related to the implementation of non-functional requirements if they are expressed in business value terms. If you can express these requirements in business value terms then the business should be able to priorities them. The important thing here is to capture the dependencies between the functional and the non-functional requirements so that the business realise the impact of developing a quality requirement in the later stages of the project.

Yes the role of the Architect in an Agile project is very different to waterfall projects and the people who succeed in a waterfall project won’t necessarily succeed in an Agile project. I think the key point in the article is that there is still a need for an Architect it just comes down to effectively executing the role within the principals defined in the Agile Manifesto.

Tags: Agile, Architecture