Agility, Risk, and Uncertainty, Part 2: How Risk Impacts Agile Architecture

I was recently invited to write an article based on my doctoral research for the Pragmatic Architect column of IEEE Software magazine. It turned into an article that was too large for one column, so we split it into two. The first, Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture, was published in the March/April edition of the magazine, and the second, Agility, Risk, and Uncertainty, Part 2: How Risk Impacts Agile Architecture, was published in the May/June edition.

If you don’t subscribe to this magazine, you can read part 1 in a previous blog post, and part 2 below.

Abstract: The amount of technical risk (and the underlying uncertainty) in a software development project can affect the amount of architecting that developers perform up-front. Software architects must determine the proper balance between risk and agility for their projects.

In part 1 [1], I introduced the findings of my research into the dilemma software architects face in agile environments: determining the effort to put into architecting up front, before development [2]. To reduce that effort as much as possible, agile architects try to design an agile architecture—that is, they use an agile process to create a modifiable, change-tolerant architecture. To do this, architects can use five tactics: keep designs simple, prove the architecture with code iteratively, use good design practices, delay decision making, and plan for options.

Here, I examine how risk (and the underlying uncertainty) affects the amount of architecting that developers must perform up-front.

Technical Risk

Along with benefits, agile architecture introduces technical risk, which relates to the uncertainty of technologies and design or the system itself. A major source of this uncertainty is a poorly designed architecture [3]. For example, decisions might have been made without sufficient effort and evidence that they satisfy architecturally significant requirements (ASRs). Perhaps the decisions were made implicitly, resulting in an emergent architecture. Such decisions can lead to a system that fails to meet ASRs and, in extreme cases, fails completely by “dying the death of a thousand cuts.” [4]

Preventing failure means more design effort to reduce uncertainty to a level that’s satisfactory to the team and stakeholders. The greater the risk and the wider its impact, the earlier it must be addressed, and the more detailed the architecture must be. Risk has always been a key driver of architecture design. For example, Tom Gilb’s 1988 book Principles of Software Engineering Management has often been quoted: “If you don’t actively attack the risks, they will actively attack you.”[5]

George Fairbanks proposed an approach in which the amount of architecture design is determined entirely by the need to reduce risk to a satisfactory level [6]. This reduction is done on the basis of either no up-front design, some yardstick measure based on a fixed proportion of time, a comprehensive set of design and documentation techniques, or an ad hoc approach that decides how much design each project requires. Fairbanks commented that although the ad hoc approach is the most common, it’s also highly subjective and provides no lessons on which to base decisions for future projects.

The classic definition of risk is the product of the probability of failure and the impact of that failure. My research participants stated that the main reason for a high probability of failure is system complexity. Complexity has three facets: scale (the number of things being considered), diversity (the number of different things), and connectivity (the number of relationships between the things) [7]. For agile architecture, complexity is caused by ASRs that perhaps conflict with each other, have a small solution space, or require compromises. Other sources of complexity are legacy systems (that are no longer being actively maintained) and the integration of multiple systems, an increasingly common requirement.

Other sources of failure include unique problems that haven’t yet been solved and the use of unknown or new and unproven technologies.

For critical systems, the cost of failure is high—perhaps people might be harmed or even lives lost. So, teams put in more architecture design effort to reduce risk. For example, compared to a team building a corporate website, a team building a medical system on which lives depend will require significantly more architectural effort and scrutiny to ensure that the ASRs are met before development starts.

Another consideration is the team’s and customer’s risk tolerance: a risk that’s acceptable to one team might be unacceptable to another. One team building a procurement website might deem the uptime to be of utmost importance. If a website visitor can’t sign up or make a purchase because the website failed, he or she will likely become lost to the business. In contrast, the stakeholders of a team building a competing system might be satisfied with a less robust system and possible financial loss if the system fails, if that means they can get their system live sooner (and start generating revenue earlier) for lower cost.

How Technical Risk Impacts the Agile Architecture

My research found that reducing risk negatively impacts a team’s ability to design an agile architecture. The more the team needs to reduce risk, the more architecture design is necessary, and the earlier decisions must be made. So, tactics that aim to keep designs simple and delay decision making become less effective.

The optimal amount of up-front architecture design is therefore a balance between risk and agility. If a team ensures that it does only enough up-front architecture design to reduce risk satisfactorily, it can maximize its use of agile-architecture tactics and hence its ability to react to changes in requirements and the environment. The more agile a team is, and the more agile the architecture they design is, the more requirements volatility they can manage.

This balance means that in a highly critical and highly complex system that requires more effort to mitigate risk, the architecture will be less agile and less able to adapt to change. So, the architecture will be less able to support a system with highly unstable requirements.

On the other hand, a noncritical business website with little risk will require nothing more than a small, highly emergent agile architecture that can successfully support a system with highly unstable and continuously evolving requirements. Such systems are often built using frameworks that provide a “precooked architecture”8 that further reduces system complexity, sometimes to the point at which minimal architectural decisions must be made up front.

To manage highly unstable requirements, teams should use suitable frameworks (where possible) to reduce system complexity. They should also aim to improve their ability to design agile architectures through experience and striving for a more agile environment.

Addressing technical risk requires earlier and more detailed architecture designs, particularly in complex and critical systems. However, such designs reduce a team’s ability to use the five tactics I mentioned at the beginning of this article.

So, as I mentioned before, the right amount of up-front effort is just enough to reduce risk to a level that’s satisfactory to the team and stakeholders. This amount will affect the team’s ability to design an agile architecture, which in turn affects its ability to manage unstable requirements.

References

1.      M. Waterman, “Agility, Risk, and Uncertainty,Part 1: Designing an Agile Architecture,” IEEE Software, vol. 35, no. 2, 2018, pp. 99–101. 

2.      M. Waterman, J. Noble, and G. Allen, “How Much Up-Front? A Grounded Theory of Agile Architecture,” Proceedings of 37th International Conference on Software Engineering (ICSE 15), 2015, pp. 347–357. (Also read preprint version)

3.      P. Kruchten, TheRational Unified Process: An Introduction, 3rd ed., Addison-Wesley Professional, 2004.

4.      G. Booch, “The Defenestration of SuperfluousArchitectural Accoutrements,” IEEE Software, vol. 26, no. 4, 2009, pp. 7–8. 

5.      T. Gilb, Principles of Software Engineering Management, Addison-Wesley, 1988.

6.      G. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, Marshall & Brainerd, 2010.

7.      P. Kruchten, “Complexity Made Simple,” Proceedings of Canadian Eng. Education Assoc. Conf., 2012..

8.      P. Kruchten, H. Obbink, and J. Stafford, “The Past,Present, and Future of Software Architecture,” IEEE Software, vol. 23, no. 2, 2006, pp. 22–30.

Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture

I was recently invited to write an article based on my doctoral research for the Pragmatic Architect column of IEEE Software magazine, for a non-academic audience. It turned into an article that was too large for one column, so we split it into two. The first, Agility, Risk, and Uncertainty, Part 1: Designing an Agile Architecture, was published in the March/April edition of the magazine. If you don’t subscribe to this magazine, you can read the article below; part 2 (How Risk Impacts Agile Architecture) will follow shortly.

Abstract: Software architects in agile environments face the dilemma of determining how much effort goes into architecting up front, before development starts. This is an issue that agile methodologies and frameworks don’t address and that’s becoming more critical as agile development gets used for a wider range of problems. This article is the first of two that discuss findings of recent research based on the experiences of 44 agile practitioners, to help shed light on the problem.

Software architects in agile environments face the dilemma of determining how much effort goes into architecting up front, before development starts. This is an issue that agile methodologies and frameworks don’t address and that’s becoming more critical as agile development gets used for a wider range of problems. This article is the first of two that discuss findings of my recent research based on the experiences of 44 agile practitioners [1], to help shed light on the problem.

If architects (whether individual architects or the development team as a whole) spend too much time architecting up front, they’ll struggle to be agile. This is partly because they’re making architectural decisions too early—decisions that could later prove to be wrong or subject to change. It’s also because this excessive effort will delay development and the opportunity for early customer feedback.

On the other hand, too little architecting results in ad hoc decisions that might not support the system’s architecturally significant requirements—the requirements that impact the architecture. If the team is spending all its time fixing architectural problems that should have been thought through up front, it’s not delivering customer value. And, just as if the team spent too much time architecting, it will struggle to be agile.

Somewhere in between is the optimal level of architecting that maximizes the team’s architectural agility. How can we determine this optimal level? To answer that, we must realize that the optimal level depends highly on the team’s context. This context includes whether the requirements are stable, the amount of technical risk, how early the customer wants to start using the system (perhaps earning revenue from it), the team’s agility, how agile-friendly the team’s environment is (such as business and administration or project stakeholders), and the team’s architectural and technical experience.

The Agile Architecture

The context determines the team’s ability to design an agile architecture—one that supports the team’s agility and hence its ability to respond to change. I define agile architecture using two dimensions:

• It has been designed using an agile process.
• It’s modifiable and tolerant of change.

The former means that the architecture isn’t a static set of decisions—it evolves as the system evolves and as the team revisits architectural decisions. The latter means that the architecture can adapt more easily as the system changes.

Neither dimension by itself is necessarily sufficient for the architecture to be agile. An architecture can be designed using an agile process but not be particularly modifiable and tolerant of change. As Simon Brown said, “In my experience … teams are more focused on delivering functionality rather than looking after their architecture.”[2] An architecture can be designed to be modifiable and tolerant of change, but if it’s not designed using an agile process, it can’t fully welcome change (the second principle of the Agile Manifesto; agilemanifesto.org) as an intrinsic characteristic.

My research found that teams design agile architectures using five tactics:

• Keep designs simple.
• Prove the architecture with code iteratively.
• Use good design practices.
• Delay decision making.
• Plan for options.

Each tactic differently impacts the required responsiveness to change and the amount of up-front design. Table 1 summarizes these impacts.

Table 1. Tactics for designing agile architecture and their impacts.

Tactic	Impact on responsiveness to change	Reduces up-front design effort?
Keep designs simple	Increases modifiability	Yes
Prove the architecture with code iteratively	Increases modifiability	Yes
Use good design practices	Increases modifiability	No
Delay decision making	Increases tolerance to change	Yes
Plan for options	Increases tolerance to change	No

Keeping designs simple is all about designing only for what’s immediately required: no overengineering or gold-plating, no designing for what might be required (called YAGNI—You Ain’t Gonna Need It—in Extreme Programming [3]). Simplicity reduces the detail in the design and the up-front effort. It increases the ease with which the design can be modified because there’s less design to change. Of course, simplicity guarantees that the architecture will need to be updated later as the system grows and the requirements evolve. However, that’s desirable because the decisions are delayed until the team has the best understanding about how to implement them.

Proving the architecture with code iteratively means simultaneous design and development, which is particularly useful if uncertainty exists about whether the architecture will meet the requirements. Simultaneous design and coding lets the team prove the architecture with real code, rather than through analysis, and refine the design if necessary. This lets the team come up with the simplest solution that works. So, like the simplicity tactic, this increases modifiability and reduces the up-front effort.

Good design practices to improve modifiability include separation of concerns (for example, service-oriented architecture, microservices, and encapsulated modules) and using quality management tools to ensure good design at the class level. Although good design practices should be an architect’s goal no matter what development process he or she uses, they’re especially important in agile development because they reduce the effort required to change the design. Good design practices don’t reduce the up-front effort; indeed, they can increase it because they require extra discipline. However, the benefits they bring are worth that extra effort [2] because changes can be isolated and limited to small parts of the system.

Delaying decision making is related to simplicity: this tactic aims to reduce the impact of trying to predict requirements that aren’t fully understood yet. Decisions are left as late as possible without delaying development, which allows the team as much time as possible to understand the requirements. Delaying decisions makes the architectural decisions more tolerant of change: fewer decisions must be revisited as requirements change, and the design requires less change.

Planning for options means the team makes decisions that retain flexibility and don’t close off future options. The architecture is designed to be easily extended. Although planning for options is related to good design practices, it’s less about general modularity and encapsulation and more about understanding what might need changing later and ensuring that the design isn’t optimized so much that it makes those changes difficult. This tactic doesn’t reduce up-front effort (and might increase it if, for example, the team uses extra levels of indirection to make changes to a particular technology layer easier).

The participants in my research used some or all of these five tactics to produce smaller, simpler, and more agile architecture designs that grow and evolve as the participants’ understanding of the systems develops. Hence, these tactics support their teams’ ability to respond to change.

In tension with minimizing design effort and deferring decisions as long as possible is the architect’s need to reduce technical risk. Risk has a big impact on architects’ ability to design an agile architecture and thus how much up-front design they do. I’ll discuss this impact in Part 2.

References

[1] M. Waterman, J. Noble, and G. Allen, “How Much Up-Front? A Grounded Theory of Agile Architecture,” Proceedings 2015 International Conference on Software Engineering (ICSE 15), 2015, pp. 347–357. (Also read preprint version)
[2] S. Brown, Software Architecture for Developers, Leanpub, 2013.
[3] M. Fowler, “Is Design Dead?,” Extreme Programming Examined, G. Succi and M. Marchesi, eds., Addison-Wesley Longman, 2001, pp. 3–17.

New research - how does a software development team make the transition to agility?

I am excited to see Rashina Hoda has a new paper published at this week's ICSE conference.

Rashina is an academic at Auckland University in New Zealand; I was a colleague of Rashina's as she was finishing her PhD at Victoria University of Wellington just as I was starting out on mine in 2010.

At Auckland Rashina has continued her research into agile software development. This latest paper, co-authored with James Noble, is "Becoming Agile: A Grounded Theory of Agile Transitions in Practice"; the conference, ICSE (International Conference in Software Engineering) is the most highly ranked and prestigious software engineering research conference in the world, and is being held in Buenos Aires this week.

As the paper title suggests, her current research is focused on what actually happens when a software development team starts along the path to agility. Through interviewing a number of agile team members and using the Grounded Theory method for analysis, she has found that there are five dimensions to becoming agile:

1. development practices
2. team practices
3. management approach
4. reflective practices
5. culture

Rashina found becoming agile is a continuous process of transforming the team across each of these dimensions as they become more experienced and proficient in agile development.

Development practices refer to the engineering and development practices that teams use, it includes using an iterative and incremental approach with frequent reviews and releases, technical practices such as pair programming and testing, as well as user stories,  daily stand-up meetings and artifacts. Teams that are new to agile methods focus on the iterative and incremental delivery model, while retaining many traditional practices. As they become more familiar with agile methods, they migrate to using more agile practices, while the most experienced agile teams are solely - and effectively - using recognised agile practices.

Team practices refer to project and task management practices - who drives practices such as requirements specification, prioritisation, estimation and collaboration with the customer. Teams new to agile are more manager-driven, teams transitioning to agile development are manager-assisted, and more experienced teams are team-driven.

The management approach (including project managers and team leads) is all about task assignment, problem solving and pushing collaboration with the business (requirements elicitation and clarification). A team new to agile relies on the manager to do this for the team, while in an agile team the manager is all about empowering the team to do these tasks for itself. In between, a transitioning team's manager helps the team adapt to an agile environment.

Reflective practices are all about reflection and learning. A new agile team is limited in its reflective practices; as teams become more agile the practices become more focused, until in experienced teams the practices are embedded in the team's regular activities.

The final dimension is culture. This includes organisational culture, team culture and individual traits that impact the work culture of the team. A new team's culture is likely to be hierarchical - information and decisions flow down to the team from senior management via subject manager experts and/or tech leads. As the team becomes more experienced, it evolves towards a more open and inclusive culture. The most agile teams can communicate and collaborate directly with customers, make their own decisions and control the work they do.

Rashina then describes the relationship between the dimensions - for example, how progress along one dimension affects progress along another -  which she calls hypotheses. There are four hypotheses:

H1: Transition along the development practices dimension is necessary for transition along the team practices and management approach dimensions. The iterative delivery model and technical practices such as TDD and pair programming are the first step along the path to agility; team-driven project management practices and team empowerment follow.

H2: Team practices and management practices reflect and adapt to each other. The success of team practices supports the success of management processes; the self-organising roles play an important part here. Often teams start with managers playing the roles (for example) of mentor, coordinator and translator; as the team becomes more experienced, the team members themselves take on these roles.

H3: Transition along the team practices and management practice dimensions is necessary for transition along the reflective practices dimension. Reflective practices are really only effective once the team is already a long way along the development practices, team practices and the management approach dimensions.

H4: Culture (organisational, team and individual) is an overarching dimension that affects the other four. For example, a highly agile organisational culture allows the team to improve its agility along the other four dimensions, while a poor agile organisational culture will stifle a team's agility.

Rashina suggests that teams can use this research to track their progress along the five dimensions and their overall agility, and hence motivate continuous improvement. Researchers can use these findings to explain variations across dimensions and between different teams.

I believe this research is very important because it tells teams what to focus on as they strive for agility. Whether the team leaps into agile development boots-and-all by (say) adopting Scrum or by transitioning to agile development gradually over time, it tells them they should focus on the core development practices, such as iterative delivery, stand-ups, test-driven development and prioritised user stories, before trying to become experts in team decision-making, self-organisation and team empowerment. After that the team is able to focus on improving its process - not simply by adopting agile processes that they haven't yet tried, but by critically examining their own process and looking for areas of improvement - such as where they can reduce the feedback cycle, where they can reduce time to address issues or implement new high-value features. The theory of constraints is likely to be very useful here. Note this does not mean that these dimensions should be implemented in sequence, one after the other! Rather it means that the effectiveness of the dependent dimensions is reduced if the team hasn't yet evolved in the earlier dimensions.

In parallel, the culture of the team, its members and the organisation needs to evolve to be more open and sharing to maximise the effectiveness of the team's agile practices.

Rashina (and James) have written an academic paper that is very important to the practical agile world.

• Download Rashina and James's paper 

The agile architect: who makes the architecture decisions?

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:

• 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. 

Each of these bullet point options (methods) is discussed below.

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.

Preprint version of agile architecture paper for ICSE conference

I have had an abridged version of my thesis accepted for the ICSE conference in Florence in May. We have uploaded a preprint version of the paper; the final version will be available from IEEE library after the conference.

An emergent architecture is only half the story

I have heard many stories of architects supposedly working in agile environments that suggest these architects aren't maximising their agile potential. These stories often describe architects who believe that an evolving architecture is simply one that in which the emergent decisions are made in parallel with development;  they neglect continuously refactoring the architecture to ensure that the architecture always represents the best design for the product as it is understood at that time.

In my thesis I define an evolving architecture as:

"An evolving architecture consists of emergent decisions, in which the architecture emerges as architecture design decisions are made, and refactored decisions, in which previous architecture decisions (whether up-front or emergent) are changed." (page 41)

 Yes, it is difficult to refactor architecture – many definitions of architecture include the decisions that are hard to change (including my own) – but agile architects use a number of tactics to increase agility:

1. Keep designs simple 
2. Prove the design with code iteratively
3. Use good design practices
4. Delay decision making (aka "just enough anticipation")
5. Plan for options.

These tactics all make it easier to either continuously refactor the architecture or reduce the need to refactor (see my earlier post).

I wish to mention two important implications of an agile architecture here:

Firstly, agile development is all about delivering a value stream. The customer does not receive the whole product at once at the end of the project: the product is delivered in regular increments from as early as possible in development. This does not only let them deliver feedback to the team; it may also allow them to start using the product early and get income or value from it.  Even what the traditional software development lifecycle would call the maintenance phase is just another part of the value stream.

Consider: how would you design your architecture differently if you took into account what you know about the whole agile development cycle, including maintenance? If you knew that the product may change drastically over its lifetime in ways that cannot be imagined at the start? An agile architecture looks different from one that is not designed to evolve and be refactored.

For more on value streams, take a look at the "NoProjects" movement, such as Allen Kelly's recent "#NoProjects/#BeyondProjects" blog post and the related presentation. 

Secondly, note the term is value stream – not cost. Value to the customer may be at the expense of increased cost: that is, they may be prepared to suffer higher overall cost if it means more value in the form of earlier and/or more income.

Consider: would you be prepared to (and able to) continuously refactor the architecture, perhaps multiple times, as the product evolves, if it means delivering more value to the customer? In particular, this may mean initially designing a much reduced and simplified architecture that will be suitable for a much shorter period of time, but allows an initial release to be made  much sooner, and which will need to be refactored (perhaps completely) as the product matures.

See also Martin Fowler's recent blog post on Sacrificial Architecture.

Agile software development creates change

In my research, I defined agility as:

"...a software development team’s ability to create change, respond to change and learn from change so that it can better deliver value."

Someone commented to me that the "create change" part of this definition was unusual: what does it mean?

Agile software development actively encourages the customer to change the requirements of the product being built – to maximise the value they get from the product – with the development team "embracing" this change. As the customer sees (and hopefully uses) the evolving product, they become confident that they can refine and add new (high priority) requirements that maximise the value they get from the product, rather than  pulling new requirements from a bucket of preconceived ideas. Agile development gives the customer confidence that changes can be made successfully and easily. In contrast, traditional development methods discourage change by making change difficult.

 While not specifically talking about agile software development, the author Donald Gerwin defined creating change as: "...driving new change that would never have occurred were it not for the entity’s actions, e.g., creating more uncertainties for rivals, thus establishing a powerful competitive advantage." (*) 

While responding to change is the crucual part of the definition of agility, creating change and learning from change are also important.

(*) Manufacturing Flexibility: A Strategic Perspective, Donald Gerwin, 1993. (Sorry, not available for free.)