• iterative and incremental life cycles,
• focus on small releases,
• collocated teams, and
• a planning strategy based on a release plan driven by a feature or product backlog and an iteration plan handling a task backlog. 4
set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition. Software architecture is concerned with not only structure and behavior but also usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics. 5
• architectus reloadus, the maker and keeper of big decisions, focusing on external coordination, and
• architectus oryzus, mentor, prototyper, and troubleshooter, concentrating more on code-facing and focusing on internal coordination,
• Understand the context. There's a vast array of software development situations, and although "out of the box" agile practices address many of these, there are outliers that we need to understand. What's the system's size, domain, and age? What's the business model and the degree of novelty and hence of risk? How critical is the system? How many parties will be involved?
• Clearly define the architecture: its scope and the architect's role and responsibility. Don't assume a tacit, implicit understanding. 11
• Define an architecture owner, just as you define a product owner and project leader. But don't let the architects lock themselves in an ivory tower, polishing the ultimate architecture for an improbable future system. Architects are part of the development group.
• Exploit architecture to better communicate and coordinate among various parties, particularly multiple distributed teams, if any. Define how to represent the architecture, on the basis of various parties' need to know.
• Use important, critical, and valuable functionality to identify and assess architectural issues. Understand interdependencies between technical architectural issues and visible user functionality to weave them appropriately over time (the zipper metaphor).
• Understand when it's appropriate to freeze the architecture to provide developers the necessary stability to finish a product release, and what amount of technical debt will then accumulate.
• Keep track of unresolved architectural issues, either in the backlog or in the risks. Deferring decisions to the last responsible moment doesn't mean ignoring them but can add risks that must be managed like other risks in the project.
Pekka Abrahamsson is a professor of computer science at the University of Helsinki. He's been an active member of the agile community since 2002. His current responsibilities include managing a Flexi-ITEA2 research project, which involves 35 organizations from seven European countries. The project aims to develop agile approaches in the domain of global, large, and complex embedded-systems development. Abrahamsson has a PhD in software engineering from the University of Oulu. He is a member of the IEEE Software Advisory Board. Contact him at firstname.lastname@example.org.
Muhammad Ali Babar is an associate professor at the IT University of Copenhagen. His research interests include software architecture, agile approaches, and global software development. Ali has a PhD in computer science and engineering from the University of New South Wales. Contact him at email@example.com.
Philippe Kruchten is a professor of software engineering at the University of British Columbia. He's a founding member of the International Federation for Information Processing Working Group 2.10 on Software Architecture, and the cofounder and chair of Agile Vancouver. In a previous life he led the development of the Rational Unified Process, which was more agile in its intent than practitioners have made of it, and which embodied an architectural method. Kruchten has a PhD in information systems from Ecole Nationale Superieure des Télécommunications. He is a member of the IEEE Software Editorial Board. Contact him at firstname.lastname@example.org.