This post presents
the results of my PhD thesis in a nutshell (part 2 of 2). The first part introduced my research and talked about agile architecture. This part discusses the theory of agile architecture.
The final version of my thesis can now be downloaded from the VUW library if you want to read it in its full academic glory.
A theory of agile architecture
I have called the findings of this research ‘a theory of agile architecture.’ The theory describes how agile teams determine how much up-front effort to put into architecture design. Most importantly, up-front architecture depends on context; this research describes six ‘forces’ that make up the context:- F1. Requirements instability
- F2. Technical risk
- F3. Early value
- F4. Team culture
- F5. Customer agility
- F6. Experience
- S1. Respond to change
- S2. Address risk
- S3. Emergent architecture
- S4. Big design up-front
- S5. Use frameworks and template architectures
The agile architecture forces
The six forces are:Requirements instability (F1) refers to the project having some or all of its requirements undefined at the start of development, or changing during development. This force is the main motivation for using agile development and for designing an agile architecture.
Technical risk (F2) is exposure to a potentially negative outcome because of uncertainty with the technology, the design or the system itself. Technical risk is often caused by architectural complexity brought about by demanding non-function requirements (or architecturally significant requirements) and is mitigated by more up-front design to reduce uncertainty.
Early value (F3) is the customer's need to derive commercial value (that is, cash flow) from the system being developed before it would otherwise be ready. To provide early value, a team reduces the planning horizon and spends less time on up-front architecture design. An early value system may also be in the form of a minimum viable product (MVP).
Team culture (F4) is a collaborative and people-focused culture based on trust: that is, an agile team culture. F4 increases the team's ability to communicate rapidly and hence reduces the time needed to respond to change.
Customer agility (F5) refers to the agility of the environment, such as the agility of the customer or the team's own organisation and any other stakeholders. As well as the team being agile, the environment must support the team's agility.
Experience (F6) refers to the team's architectural and technical experience. Experienced team members are more able to use tacit knowledge to make faster and fewer explicit decisions, and so can reduce up-front effort and respond to change faster.
F4, F5 and F6 all impact upon the team's agility, rendering it more or less able to design an agile architecture.
The agile architecture strategies
The five strategies are:Respond to change (S1) is the key strategy for designing an agile architecture, and uses the tactics described in my previous post. The better the team is able to use these tactics, the more able it is to respond to change and reduce up-front effort.
Reduce risk (S2) is a strategy that uses more up-front design to mitigate technical risk as early as possible. S2 is in tension with S1's tactic of delaying decisions: teams have to balance mitigating risk with the architecture's ability to respond to change.
Emergent architecture (S3) is a strategy that results in as few up-front decisions as possible – which typically may be simply selecting the technology stack and the top level architectural styles and patterns. S3 is a strategy that takes S1 to the extreme, with all decisions delayed, whether or not the requirements are likely to change. S3 does not mitigate any risk up-front, and is therefore not suitable for complex systems with demanding ASRs.
Big design up-front (S4) is a strategy in
which all (or most) architecture decisions are made up-front. S4 is most likely used by
teams that have a non-agile customer (or manager) who requires the team to
complete the design before development starts. S4 reduces the team's ability to respond to change.
Use Frameworks and template architectures (S5) reduces the effort required for architectural design by providing 'precooked' architectural solutions in the form of frameworks, templates, reference architectures and standard off-the-shelf libraries and plug-ins. Frameworks reduce complexity and hence risk, and make it easier to change subsidiary architectural decisions. This is particularly important for agile development because the reduced effort allows a team to respond to change more quickly and hence become more agile.
Relationships between the forces and strategies
Respond to change (S1): Requirements instability (F1) is a trigger for S1: if requirements are unstable, the team starts designing their architecture (and system) so that it can be changed. Team culture (F4), customer agility (F5) and experience (F6) are all success factors for S1: the more agile the team is, the better it will be at designing an agile architecture.
Implication: It is incorrect to say that the more unstable the requirements are, the less up-front design we need to do. Rather, the more agile the team is, the more able the team is to respond to change, and therefore the less up-front design it may need to do, and therefore the more unstable requirements it is able to manage.Address risk (S2): Naturally, technical risk (F2) drives the need for S2 – largely an up-front activity, particularly for system-wide risk. Thus S2 is in tension with – and must balance – S1.
Implication: Because technical risk is caused by complexity, it is complexity and not size that determines how much effort teams put into up-front architecture design. (Although size can increase the impact of complexity.)Emergent architecture (S3): The need for early value (F3) motivates S3; being highly successful at S1 (and hence being highly agile with an agile-friendly customer) is crucial. Because addressing risk (S2) increases up-front effort, emergent architectures can only be designed in low-risk systems with low complexity.
Implication: An emergent architecture (or at least, less up-front architecture) may mean more architectural design later and more overall work over the life of the project – but for the start-up, that's acceptable – no, preferable – because once they have early adopters and cash flow they can pay for that extra work later. It's all about value and not necessarily cost.Big up-front design (S4): An agile team would typically use S4 when one (or more) of the success factors are missing: agile team culture (F4), customer agility (F5) or architecture and technical experience (F6); most often this is when the customer is not agile, needing a traditional fixed price contract or needs budget approval for a particular set of functionality.
Standard frameworks and template architectures (S5) provide "precooked" architectures, reducing complexity, risk and effort, and allow the architecture to be more easily changed.
All of the relationships between the forces and strategies are summarised in this figure:
The agile architect
Architectural decisions are made either 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 – by consensus or by an architecture owner, are made by the teams and approved by external architects, or are researched by the teams and the decisions are made by the external architects. In the latter cases the external architects ensure the architectures of the teams' sub-systems met system-wide requirements or constraints that are 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.
No comments:
Post a Comment