Jul 15, 2015 - which tend to feature in a product owner's priorities. However it is exactly these areas that software architects usually address. In an earlier ...
Aligning Architecture work with Agile Teams Eoin Woods Endava 15th July 2015. Agile software development is a very widely practiced software development approach and nowadays there is also broad recognition of the role of the software architect in the process of making the key design decisions for a project. However in my experience there are often difficulties when agile development teams and software architects work together. This can be caused by differing priorities, different language and sometimes different development philosophy. The result can be development teams dismissing software architecture as “big design up front” and in turn, architects doing a poor job at producing architectural work that is useful for agile teams. Difficulties when architects try to work with agile teams can be a real problem for organisations, causing them to miss the benefits to be gained when this relationship works well. Agile teams often do a tremendous job at delivering useful software in a timely manner, but can encounter problems coping with factors such as security, system monitoring or systems integration, none of which tend to feature in a product owner’s priorities. However it is exactly these areas that software architects usually address. In an earlier Pragmatic Architect column [1], Eltjo Poort explained how the Risk and Cost Driven Architecture approach can help architects to align their work with agile teams. In this column, we will suggest some more general ways in which to achieve this.
Agile Software Development The term “agile development” is applied to a wide variety of specific approaches, some of the best known being Scrum and Extreme Programming (XP). What unifies agile approaches is an unifying philosophy summarised in the wellknown Agile Manifesto [2]. The agile manifesto states that its philosophy values: • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Individuals and interactions over processes and tools • Responding to change over following a plan While the manifesto acknowledges that the items at the start of each point do have value, the second item in each point is valued more highly. While it is difficult to disagree with these principles (who honestly prefers completed documentation over working software?), what has been remarkable has been their ability to inspire the strong community that has formed and created the practice of “agile development”.
(c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
Software Architecture We have previously defined and characterised the role of the software architect in this column [3] and so let’s just summarise it again, as making the design decisions that are risky, costly, hard to change later, or all three. And let us remind ourselves that it tends to include: • • • • •
A focus on design work; Meeting the needs of a wide stakeholder community (well beyond users and acquirers); Concerning ourselves with the system wide concerns (which are often non-functional); Balancing competing concerns to find acceptable solutions to the design problems; and Providing leadership where required to ensure that the architecture of the system is well understood so that it can be implemented successfully.
Working Together Having worked as an architect with many agile teams over the last 10 years, I realised that there were some architecture practices that really helped us to cooperate and get the architecture work done in a way that supported agile development. These practices were inspired by the principles of the agile manifesto and address different aspects of it, as shown in Figure 1. Allow for Change • • • •
Deliver incrementally Capture decisions and rationale Capture clear architecture principles Define components clearly
Collaboration Over Contracts • Work in Teams Don’t (Just) Deliver Documents • Focus design on stakeholder concerns • Focus on architectural concerns
People Over Processes & Tools • Share information using simple tools • Have customers for every deliverable
Software Over Documents • Create “good enough” architectural artefacts • Define solutions for cross-cutting concerns • Deliver something that runs
Figure 1 - Practices for Agile Architectural Working
Let us briefly explore each of these practices, to understand how they fit together. Allow for Change The Agile Manifesto urges us to embrace change rather than rely on following a plan. The following practices help to make architecture work more amenable to change. (c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
•
•
•
•
Deliver Incrementally – when working on a significant piece of design work, there’s a natural tendency to want perfection before sharing it. However our agile principles encourage us to do the opposite and to make a minimum number of key decisions initially and then to make a flow of decisions as needed to meet the system’s delivery goals. This allows the architecture work to respond to changing priorities and increased knowledge. In practice I have found that initially you need just enough architecture work to define the key system structures and you can then refine each aspect of the architecture as it is needed, as the project develops. In his recent article in this column, Eltjo Poort explained how to use risk and cost to drive this flow of decisions [1]. Capture Clear Architecture Principles –agile teams need to empower team members to make good design decisions themselves. A good way to support this is to define a clear set of architecture principles that help people understand why the architectural structures exist and the most important characteristics of the architecture. Principles provide team members with a mental framework to use when they extend and change the architecture. Capture Decisions and Rationale – on a related point, help the team to understand why certain decisions were made by capturing important design decisions and rationale [4] and keep explaining them verbally so that they become part of the project’s aural tradition. Define Components Clearly - as the system evolves, new components will be introduced, existing ones changed and component interactions altered. To allow coherent evolution the components need to be well understood, meaning that each one needs to have a good name, a clear set of responsibilities, a clear set of well-defined interfaces through which it communicates and a clear set of dependencies that it requires. Without this knowledge, it is very difficult to evolve the system structure coherently.
People over Process & Tools The Agile Manifesto reminds us that people create the software, not the processes and tools. When considering architectural work there are two key practices that reflect this. •
•
Share Information Using Simple Tools – a key part of a software architect’s job is to communicate the architecture to relevant stakeholders, be they infrastructure designers, end-users, compliance officers or the development team. I have found that effective communication normally requires the use of simple approaches that people are already familiar with. While sophisticated modelling tools can be valuable, particularly for the architect themselves, other stakeholder communication is often best achieved through familiar mechanisms such as wikis, presentations and short, accessible documents. Have Customers for Every Deliverable – it’s easy to write a document that seems to be important at the time, and then only later start considering who should read it. This often results in a document that no one wants! To focus the architecture work on high value areas, all deliverables need
(c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
to be created with a definite purpose and audience in mind, so maximising the chances that they will be useful. Software over Documents Agile software development emphasises the value of working software over documentation describing what might be. There are several practices for architecture work inspired by this principle. •
•
•
Create “Good Enough” Architectural Artefacts – the architectural models and documents for a system can be quite significant pieces of work in themselves and there’s an understandable pride in creating a comprehensive and polished result. However these deliverables aren’t part of the final system and so they should be fit-for-purpose rather than polished to the point of perfection. This isn’t an excuse for sloppy work, but rather a guide for when it’s time to move on to the next task. Deliver Something that Runs – everything we do needs to be validated and tested, whether it’s production code or design principles and ideas. In the case of architectural design, this means that rather than documents full of theoretical ideas, it’s important to deliver something that validates the architectural thinking. In many cases while it’s not production software, the best way to do this is to create examples and prototype implementations that validate the key ideas, prove that they really work and them to be understood and adopted quickly. Define Solutions for Cross-Cutting Concerns – some aspects of a systems design are complicated because they cut across a lot of the system’s implementation. These design decisions normally address qualities like security or scalability, and should be a major focus of the architecture work. Delivering clear, proven solutions for each of the system’s important quality properties is tremendously valuable because it allows the team to focus on other aspects of the design and achieve the required qualities without a lot of research and rework.
Collaboration over Contracts The final aspect of the Agile Manifesto urges us to collaborate with each other rather than to rely on formal boundaries and agreements. Such collaboration is key to effective architecture work and is supported by the following practices. •
•
Work in Teams Don’t (Just) Deliver Documents – a common complaint about architects is that they are a long way from the people suffering the results of their decisions. To avoid this, architects need to work collaboratively with development teams, working directly with and in teams wherever possible. This allows a two-way flow of ideas, helping the architect to understand the real problems they need to solve and helping the team to understand what the architecture really means. Focus Design Work on Stakeholder Concerns – another aspect of collaboration is making sure that architectural design work is addressing the most important aspects of the system. It’s easy to create architectures that are “scalable” or “flexible” or “efficient” without considering what the system’s stakeholders really need. Making sure that the design work
(c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
•
being undertaken aligns with stakeholder needs helps to focus it in the right places. Focus on Architectural Concerns – when working with a development team, it’s important that the software architect is engaged in a way that the team find valuable. I’ve found that the best way to achieve this is to focus on the cross-cutting concerns in the system, such as common design patterns, how the system will be deployed and how the critical qualities (such as security or availability) will be achieved. You may remember that a metaphor we used in the last column to identify architecture work was “architecting in the gaps”. Taking ownership of these aspects of a system is a useful service that the architect can provide to the team.
Summary Software architects and agile development teams have a mixed history of working together harmoniously, which is unfortunate but in my experience, rectifiable. With a little flexibility and goodwill on both sides, it is quite possible for the software architect to channel their efforts through a set of practices that align with the underlying principles of agile development. These practices combine to allow the architect to work constructively with agile teams and make a real contribution to the success of the project.
References [1]. Eltjo R. Poort, "Driving Agile Architecting with Cost and Risk", IEEE Software, vol.31, no. 5, pp. 20-23, Sept.-Oct. 2014, doi:10.1109/MS.2014.111. [2]. Manifesto for Agile Software Development, www.agilemanifesto.org, retrieved 15th July 2015. [3]. Eoin Woods, "Return of the Pragmatic Architect", IEEE Software, vol.31, no. 3, pp. 10-13, May-June 2014, doi:10.1109/MS.2014.69 [4]. Philippe Kruchten, Rafael Capilla, Juan Carlos Dueñas, "The Decision View's Role in Software Architecture Practice", IEEE Software, vol.26, no. 2, pp. 36-42, March/April 2009, doi:10.1109/MS.2009.52 [5]. Eoin Woods, "Architecting in the Gaps: A Metaphor for Architecture Work", IEEE Software, vol.32, no. 4, pp. 33-35, July-Aug. 2015, doi:10.1109/MS.2015.98
(c) 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works.
