Aligning Architecture Work with Agile Teams

THE PRAGMATIC Editor: Eoin Woods Endava ARCHITECT [email protected]

Eoin Woods

AGILE SOFTWARE DEVELOP- lems with factors such as security, • customer collaboration over MENT is a very commonly practiced system monitoring, or systems in- contract negotiation, approach for software delivery, and tegration, which product owners • individuals and interactions over today the software architect’s role in don’t tend to prioritize. However, processes and tools, and making key project design decisions this is where software architects can • response to change over follow- is broadly recognized. However, in help, because they address exactly ing a plan. my experience, difficulties frequently these areas. arise when agile development teams In an earlier column in this de- Although the manifesto acknowl- and software architects work to- partment, Eltjo Poort explained how edges that all these items have value, gether. These difficulties—caused by the Risk- and Cost-Driven Architec- it elegantly makes the point that differing priorities, languages, and, ture approach helps architects align working software, customer collaboration, individuals and interactions, and responding to change are the most important. Certain architecture practices Few people would disagree with these principles—who honestly pre- encourage architecture work that fers completed documentation over supports agile development. software that works? What’s re- markable is the strong community that’s formed around these simple statements to create agile software development. sometimes, development philoso- their work with agile teams.1 In this phies—often result in development column, I propose some other, more Software Architecture teams dismissing software architec- general, ways to achieve this. I’ve previously defined and charac- ture as “big design up front” and, in terized the software architect’s role,3 turn, architects producing architec- Agile Software Development but I’ll summarize it again here: ar- tural work that isn’t useful for agile Agile software development can re- chitects are responsible for the de- teams. fer to many specific software devel- sign decisions that are risky, costly, Conflict between architects and opment methods, the best known hard to change later, or all three. agile teams is also problematic for being Scrum and Extreme Program- The architect also organizations, causing them to miss ming (XP). What unifies agile ap- the benefits that accrue when archi- proaches is their commitment to the • focuses on design work; tects and agile development teams well-known agile manifesto,2 a phi- • meets the needs of a wide stake- work effectively together. Agile losophy that values holder community (well beyond teams are often great at delivering users and acquirers); useful software in a timely manner, • software that works over com- • addresses systemwide concerns but I’ve seen them encounter prob- prehensive documentation, (which are often nonfunctional);

ing important design decisions and Allow for change People over processes and tools rationale4 and verbally explaining • Deliver incrementally • Share information using simple tools them regularly so that they become • Capture clear architecture principles • Have customers for every deliverable • Capture decisions and rationale part of the project’s aural tradition. • De ne components clearly Define components clearly.As sys- Collaboration over contracts Software over documents tems evolve, new components are in- • Work in teams, don’t just deliver documents • Create “good enough” architectural artifacts troduced, existing ones are changed, • Focus design on stakeholder concerns • Deliver something that runs and component interactions are al- • Focus on architectural concerns • De ne solutions for cross-cutting concerns tered. Architects need to clearly define each component: each one needs a good name, a clear set of respon- FIGURE 1. Practices for successful agile architecture. sibilities, well-defined communica- tion interfaces, and a precise set of required dependencies. Without this • balances competing concerns site: architects should initially make knowledge, it’s very difficult for the to find acceptable solutions to a minimum number of key decisions system structure to evolve coherently. design problems; and and then a flow of decisions when • provides the leadership required needed to meet the system’s deliv- People over Processes and Tools to ensure that the system’s ar- ery goals. This approach allows the The agile manifesto reminds software chitecture is well understood work to respond to changing pri- architects that people, not processes and supports its successful orities and the increased knowl- and tools, create the software. The implementation. edge that’s available as the project following key practices reflect this. progresses. In practice, I’ve found Working Together that initially you need just enough Share information using simple Having worked as a software archi- architecture work to define the key tools. A key part of a software ar- tect with many agile teams over the system structures, address the main chitect’s job is communicating the last 10 years, I’ve realized that cer- risks, and get the work started. You architecture to relevant stakehold- tain architecture practices encour- can then refine the architecture as ers, such as infrastructure designers, age architecture work that supports the project develops. Eltjo Poort ex- end users, and compliance officers, agile development. These practices plained how to use risk and cost to as well as the development team. Al- were inspired by and draw on dif- drive this decision flow.1 though sophisticated modeling tools ferent aspects of the agile manifesto can be valuable, particularly for the (see Figure 1). Capture clear architecture prin- software architect, I’ve found that Let’s briefly explore each practice ciples. Agile teams need each team effective stakeholder communica- to understand how they fit together. member to be able to make good de- tion is best achieved through sim- sign decisions. Architects can sup- ple, familiar mechanisms such as Allow for Change port this by defining clear principles wikis; presentations; and short, ac- The agile manifesto urges architects that help team members understand cessible documents. to embrace change rather than rely why the architectural structures exist on a plan. The following practices and the architecture’s most impor- Have customers for every deliver- make architecture work more ame- tant characteristics. Such principles able. It’s easy to write a seemingly nable to change. give team members a mental frame- important document before consid- work they can use when extending ering who should read it. This ap- Deliver incrementally. When work- and changing the architecture. proach often results in a document ing on a significant piece of design that no one wants. To focus the ar- work, it’s tempting to seek perfec- Capture decisions and rationale. In chitecture work on high-value areas, tion before sharing it. However, ag- a similar way, architects can help the architects should have a defined pur- ile principles encourage the oppo- team understand decisions by captur- pose and audience in mind when cre-

14 IEEE SOFTWARE | WWW.COMPUTER.ORG/SOFTWARE | @IEEESOFTWARE THE PRAGMATIC ARCHITECT

ating deliverables, thereby maximiz- be a major focus of the architec- engaged in a way that teams find valu- ing their usefulness. ture work. Delivering clear, proven able. I’ve found this is best achieved solutions for each of the system’s by focusing on the cross-cutting con- Software over Documents important quality properties is tre- cerns in the system, such as common Agile software development em- mendously valuable because it frees design patterns, how the system will phasizes the value of software that the team to focus on design aspects be deployed, and how the critical works over documentation describ- that might be more interesting to the qualities (such as security or avail- ing how it should work. This princi- product owners, while still allowing ability) will be achieved. You might ple has inspired the following archi- them to achieve the required quali- remember the “architecting in the tecture practices. ties in the system. gaps” metaphor for identifying architecture work.5 Taking ownership of Create “good enough” architec- Collaboration over Contracts these “gaps” is a useful service that tural artifacts. Because a system’s The final aspect of the agile mani- architects can provide to the team. architectural models and documents festo urges software architects to can be quite significant pieces of collaborate rather than maintain work, architects take understand- formal boundaries and agreements. oftware architects and ag- able pride in creating comprehensive, Collaboration is key to effective ar- ile development teams have polished results. However, these de- chitecture work and is supported by S a mixed history of working liverables aren’t part of the final sys- the following practices. together, which is unfortunate but tem and should be fit-for-purpose rectifiable. With a little flexibility rather than polished to perfection. Work in teams, don’t just deliver and goodwill on both sides, software This isn’t an excuse for sloppy work, documents. A common complaint architects can channel their efforts but rather a guide for when it’s time about software architects is that they through practices aligned with agile to move on to the next task. work separately from the people af- development’s underlying principles. fected by their decisions. To avoid this, By using these practices, architects Deliver something that runs. Every architects need to collaborate with can work constructively with agile thing we do needs to be validated development teams, working directly teams and significantly contribute to and tested, whether it’s production with and in teams wherever possible. a project’s success. code or design principles and ideas. This allows ideas to flow both ways— In architectural design, this means helping the architect understand the References that rather than creating documents real problems to be solved and helping 1. E.R. Poort, “Driving Agile Architecting with Cost and Risk,” IEEE Software, vol. 31, full of theoretical ideas, architects the team use and develop the architec- no. 5, 2014, pp. 20–23. should deliver something that vali- ture as the system is built. 2. “Manifesto for Agile Software Develop- dates the architectural thinking. The ment,” 2001; www.agilemanifesto.org. 3. E. Woods, “Return of the Pragmatic Archi- best way to do this, in many cases, Focus design work on stakeholder tect,” IEEE Software, vol. 31, no. 3, 2014, is by developing examples and pro- concerns. Software architects can pp. 10–13. totype implementations that validate easily create architectures that are 4. P. Kruchten, R. Capilla, and J.C. Dueñas, “The Decision View’s Role in Software the key ideas, prove their feasibility, “scalable” or “flexible” or “effi- Architecture Practice,” IEEE Software, and allow them to be understood cient” without considering what the vol. 26, no. 2, 2009, pp. 36–42. and adopted quickly. system’s stakeholders really need. 5. E. Woods, “Architecting in the Gaps: A Metaphor for Architecture Work,” IEEE Therefore, another aspect of col- Software, vol. 32, no. 4, 2015, pp. 33–35. Define solutions for cross-cut- laboration is ensuring that the ar- ting concerns. Some design aspects chitectural design work aligns with EOIN WOODS is the chief technology officer are complicated because they affect stakeholder needs and focuses on the at Endava, a European IT services company. many aspects of the system’s imple- system’s most important aspects. Contact him at [email protected]. mentation (they “cut across” the system’s structure). These design deci- Focus on architectural concerns. Selected CS articles and columns sions normally address qualities like When working with development are also available for free at http://ComputingNow.computer.org. security or scalability and should teams, software architects must be

SEPTEMBER/OCTOBER 2015 | IEEE SOFTWARE 15