Many agile teams find that they need someone in the role of “architecture owner”, often the most technically experienced person in the team, who is responsible for facilitating the architectural modeling and evolution efforts. Architecture owners are the agile version of the traditional role of software architect. In many ways, an architecture owner is simply a solution architect who focuses on facilitating the evolution of the solution architecture over time instead of trying to formulate the detailed architecture early in the life-cycle then dictate it to the rest of the team. Architecture owners take an approach which is collaborative and evolutionary, not command-and-control and certainly not serial.
People in the role of architecture owner will focus on:
- Facilitating creation of the architecture, not enforcing it. They would often develop the architecture and then “present it” to, or more accurately force it upon, the development team. An architecture owner collaboratively works with the team to develop and evolve the architecture.
- Architectural spikes. An architectural spike is a technical risk-reduction technique popularized by Extreme Programming (XP) where you write just enough code to explore the use of a technology or technique that you’re unfamiliar with. For complicated spikes, architecture owners will often pair with someone else to do the spike.
- Transitioning architectural skills to other team members. Architecture owners typically have critical, “senior IT” skills, the type of skills which less senior IT people would like to gain. So, good architecture owners will focus part of their time on mentoring others, finding opportunities to pair with others, and even running IT education and training sessions such as formal classes or brown-bag lunch sessions.
- Mentoring team members in organizational technical guidance. Architecture owners are aware of, and often authors of, organizational technical guidance around coding guidelines, database guidelines, security guidelines, and so on. They will help to bring this valuable knowledge to the team, mentoring them in its appropriate application.
For any reasonably complex system, you’re going to need to invest some time architecting it. First, you’ll do some up front architecture envisioning to get you going in the right direction and then you’ll need to evolve the architecture over time as your project progresses. Although it’s convenient to believe that a Disciplined Agile Delivery (DAD) team will always be in agreement as to the architecture of the solution, the reality is that many agile developers are smart, strong-willed people and teams of such don’t always come to agreement.
Speaking about leadership, the person in the role of team lead will often also be in the role of architecture owner. This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.