This article is based on my research findings and is derived from part of one of my PhD thesis chapters.
In agile software development, architecture design is not the sole responsibility of a single designated architect or team of architects. Architecture decisions are made collaboratively by active members of the agile team, rather than by so-called ivory tower architects with one-way relationships with the development team. A wide understanding of the architecture and collaborative decision-making help improve the communication within the team, and hence help make the team more agile.
When the scope of the system that the team is building extends to other teams (perhaps as a multi-team project or being within a multi-project organisation), keeping decision-making within the team is not enough: additional input is required from architects beyond the team who have an understanding of the overall business problem being solved and the overarching ASRs (architecturally significant requirements) – primarily the non-functional requirements.
On the whole, team involvement is a spectrum from full team involvement to very little team involvement:
The need to have an understanding of the business problem is consistent with Fowler’s definition of architecture: (this article may require a subscription or payment)
Consensus decision-making only works on small single-team projects, when there are no other teams to coordinate with. This method is rarely successful in medium-size or large teams because it is difficult for a large number of software engineers to reach agreement. In this case one of the team members needs to act as the architecture owner for the team (see below).
Some see the role of the architecture owner as a guidance and sanity checking role.
A team (any team) may largely comprise members with the title of ‘developer’ or ‘software engineer’; the title of the architecture owner is typically ‘lead developer’, ‘senior developer’, ‘technical lead’ – or (surprise!) even ‘architect.’ These different titles all refer to similar roles and could be considered synonyms. The architecture owner may also go by the title ‘team leader’ or ‘team manager’, although these names tend to suggest a contradiction with the agile practice of teams being self-organising.
It is most important to have someone with overall responsibility for the architecture when the project spans two or more teams, and it is not possible for the whole team to have an understanding of the overall business problem and architecture. Without someone with overall responsibility, different teams will lead to silos with each team designing their sub-system architecture in isolation, with the risk of the team not meeting the ASRs of the overall system.
The need to understand the architecture across multiple teams becomes more important as the size and complexity of the system, or the number of related systems being built, increases and more teams are involved.
In these instances, the architecture decisions that the team makes should be approved or reviewed by architects who are across the full context of the system being built, and who understand how the individual team's architectural decisions fit in with that system. These architects are likely to be external to the team, typically in the form of a dedicated architecture team, perhaps described as an architecture review board or an architecture governance committee. The development teams make the decisions, and the architecture team (or board) has the responsibility for ensuring architectural consistency across the system or systems, and in particular ensuring any high-risk ASRs such as privacy and security will be met.
Ideally this is just a rubber-stamping exercise.
(Note that addressing high-risk requirements requires more up-front architectural effort.)
The architecture team may be made up of team members from the different development teams who meet regularly (for example, weekly) to review architecture decisions made by the teams, or, in a larger organisation, the architecture team may be made up of dedicated members.
Some architecture teams proactively design a reference architecture that they can use to ensure consistency. (Note, as an agile architecture, the reference architecture must evolve over time as the products and their individual architectures evolve.)
If the software development is outsourced to an ISV (independent software vendor), the members of the architecture team may belong to the ISV (if the ISV has the overall responsibility for delivering the system), or they may belong to the customer itself (if the customer has only outsourced smaller components).
If the architecture team consists of the customer’s own architects, this gives the customer itself the final say in the architecture. The customer may go so far as to require its own architects to make certain architectural decisions, based on recommendations made by the team. The benefit of the customer being involved is they are in the best position to understand their system landscape and how the system being developed must fits in with that landscape, and so best understand the decisions to be made to meet their requirements (assuming they have the skills and abilities).
Agile teams generally view non-coding architects as undesirable because these architects are often disconnected from the system being built and so are not in the best position to architect it – there is plenty of literature and comment elsewhere on the impact of the “ivory tower architect.”
Many teams have constraints on their architectures imposed by the customer. These constraints are effectively architecture decisions made outside of the team, such as the technology stack to be used. Examples of such constraints include technologies chosen for strategic reasons and for support reasons. The customer’s decision to engage certain ISVs is also an implicit constraint if those ISVs are aligned with or only have expertise in certain technologies, which, in turn, may impose certain architectural styles:
Having the whole team involved with the architecture design process ensures the whole team has an understanding of the architecture, its rationale and its importance. This understanding improves the team’s ability to communicate and collaborate, and hence its overall agility.
In agile software development, architecture design is not the sole responsibility of a single designated architect or team of architects. Architecture decisions are made collaboratively by active members of the agile team, rather than by so-called ivory tower architects with one-way relationships with the development team. A wide understanding of the architecture and collaborative decision-making help improve the communication within the team, and hence help make the team more agile.
When the scope of the system that the team is building extends to other teams (perhaps as a multi-team project or being within a multi-project organisation), keeping decision-making within the team is not enough: additional input is required from architects beyond the team who have an understanding of the overall business problem being solved and the overarching ASRs (architecturally significant requirements) – primarily the non-functional requirements.
On the whole, team involvement is a spectrum from full team involvement to very little team involvement:
- decision-making can be consensus-driven across the whole team
- the team’s architectural decisions can be approved by a single, nominated team member
- architectural decisions can be made by the team and approved by members outside the team
- in some circumstances, decisions may be made outside the team.
Whole team consensus
When a team is small and it consists entirely of capable (probably senior) software engineers, then if it is working on a small standalone project or system, decisions can be made democratically or by consensus. The whole team plans the architecture and comes to a team-wide agreement. A common factor among teams making decisions by consensus is all the team members have similar levels of experience with the technology, and all have good domain knowledge and understanding of the business problem. There are probably no junior developers who do not have sufficient understanding to make the required architectural decisions.The need to have an understanding of the business problem is consistent with Fowler’s definition of architecture: (this article may require a subscription or payment)
“In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture’.”Those who make the architecture decisions are those who have a good understanding of the ASRs and how they fit into the context of the business.
Consensus decision-making only works on small single-team projects, when there are no other teams to coordinate with. This method is rarely successful in medium-size or large teams because it is difficult for a large number of software engineers to reach agreement. In this case one of the team members needs to act as the architecture owner for the team (see below).
Decision approval within the team
Large teams can avoid the problem of having to reach a team-wide consensus by having a designated architect who makes the final decisions, or has a ‘casting vote’. The designated architect is effectively the architecture owner [Ambler] or coordinator [Coplien and Bjørnvig]: they do not make architecture decisions on their own, but rather use their experience and knowledge of the business problem to confirm the decisions made by the team, or, in the case of lack of agreement, make the final decision.Some see the role of the architecture owner as a guidance and sanity checking role.
A team (any team) may largely comprise members with the title of ‘developer’ or ‘software engineer’; the title of the architecture owner is typically ‘lead developer’, ‘senior developer’, ‘technical lead’ – or (surprise!) even ‘architect.’ These different titles all refer to similar roles and could be considered synonyms. The architecture owner may also go by the title ‘team leader’ or ‘team manager’, although these names tend to suggest a contradiction with the agile practice of teams being self-organising.
It is most important to have someone with overall responsibility for the architecture when the project spans two or more teams, and it is not possible for the whole team to have an understanding of the overall business problem and architecture. Without someone with overall responsibility, different teams will lead to silos with each team designing their sub-system architecture in isolation, with the risk of the team not meeting the ASRs of the overall system.
The need to understand the architecture across multiple teams becomes more important as the size and complexity of the system, or the number of related systems being built, increases and more teams are involved.
Decision approval outside team
When the system being built is part of a much larger system or is one of many related systems being built (such as a product line), the team is unlikely to have a detailed understanding of the overall system and the business problem being solved. A single team cannot be sure that the architectural decisions it makes are appropriate for the larger scale.In these instances, the architecture decisions that the team makes should be approved or reviewed by architects who are across the full context of the system being built, and who understand how the individual team's architectural decisions fit in with that system. These architects are likely to be external to the team, typically in the form of a dedicated architecture team, perhaps described as an architecture review board or an architecture governance committee. The development teams make the decisions, and the architecture team (or board) has the responsibility for ensuring architectural consistency across the system or systems, and in particular ensuring any high-risk ASRs such as privacy and security will be met.
Ideally this is just a rubber-stamping exercise.
(Note that addressing high-risk requirements requires more up-front architectural effort.)
The architecture team may be made up of team members from the different development teams who meet regularly (for example, weekly) to review architecture decisions made by the teams, or, in a larger organisation, the architecture team may be made up of dedicated members.
Some architecture teams proactively design a reference architecture that they can use to ensure consistency. (Note, as an agile architecture, the reference architecture must evolve over time as the products and their individual architectures evolve.)
If the software development is outsourced to an ISV (independent software vendor), the members of the architecture team may belong to the ISV (if the ISV has the overall responsibility for delivering the system), or they may belong to the customer itself (if the customer has only outsourced smaller components).
If the architecture team consists of the customer’s own architects, this gives the customer itself the final say in the architecture. The customer may go so far as to require its own architects to make certain architectural decisions, based on recommendations made by the team. The benefit of the customer being involved is they are in the best position to understand their system landscape and how the system being developed must fits in with that landscape, and so best understand the decisions to be made to meet their requirements (assuming they have the skills and abilities).
Decisions made outside team
Finally, the architectural decisions may be made by architects who are not day-to-day members of the development team. This is unusual in agile development; my research had only one participant who was member of an architecture team that was responsible for coming up with the high-level architecture designs for a number of development teams, but was not a coding member of those teams.Agile teams generally view non-coding architects as undesirable because these architects are often disconnected from the system being built and so are not in the best position to architect it – there is plenty of literature and comment elsewhere on the impact of the “ivory tower architect.”
Many teams have constraints on their architectures imposed by the customer. These constraints are effectively architecture decisions made outside of the team, such as the technology stack to be used. Examples of such constraints include technologies chosen for strategic reasons and for support reasons. The customer’s decision to engage certain ISVs is also an implicit constraint if those ISVs are aligned with or only have expertise in certain technologies, which, in turn, may impose certain architectural styles:
“The customer decided the architecture when they went out and contracted all the parts.”
Summary
All the participants in this research described architectural decisions as either being made by members of the development teams or in agreement with members of the teams. No architects made decisions in isolation of the team. Decisions are either made and approved by the teams themselves, are made by the teams and approved by external architects, or are researched by the teams themselves and the decisions made by the external architects. In the latter cases the external architects ensured the architectures of the teams’ sub-systems met system-wide requirements or constraints that were perhaps not clearly visible to the teams themselves.Having the whole team involved with the architecture design process ensures the whole team has an understanding of the architecture, its rationale and its importance. This understanding improves the team’s ability to communicate and collaborate, and hence its overall agility.
