Why software reference architectures in agile projects are more than “just” templates

by Matthias Galster (mgalster@ieee.org)
Associate Editor: Mehdi Mirakhorli (@MehdiMirakhorli)

In one of our research projects we looked at how reference architectures are used in agile projects. Software engineers often use existing reference architectures as “templates” when designing systems in particular contexts (such as web-based or mobile apps). Reference architectures (from a third party or designed in-house) provide architectural patterns (elements, relationships, documentation, etc.), sometimes partially or fully instantiated, and therefore allow us to reuse design decisions that worked well in the past. For instance, a web services reference architecture may describe how a web service is developed and deployed within an organization’s IT ecosystem. On the other hand, industry practice tends towards flexible and lightweight development approaches¹ and even though not all organizations are fully agile, many use hybrid approaches². Since reference architectures shape the software architecture early on, they may constrain the design and development process from the very beginning and limit agility. Nevertheless, in case studies that we conducted with software companies that use Scrum as their agile process framework, engineers reported extra value when using reference architectures. That extra value goes beyond the typical reasons for using reference architectures (such as being able to use an architecture template, and supporting standardization and interoperability). This additional value comes from three things: architectural focus, less knowledge vaporization, and team flexibility.

• Architectural focus. We found that reference architectures inject architectural thinking into the agile process. Architectural issues often get lost in agile projects and the architecture emerges implicitly. A reference architecture supports the idea of a system metaphor in agile development. The clear picture of core architectural issues helps communicate the shared architectural vision as a “reference point” within agile teams across sprints. Since reference architectures already confine the design space, they also help balance the effort spent on up front design. In fact, we have observed that this outweighs the effort required to learn about a reference architecture. Furthermore, reference architectures provide a “harness” for agile teams to try out different design solutions. This helps reduce the complexity of the design space and potentially limits the amount of architectural refactoring.
• Less knowledge vaporization. Agile promotes working products over documentation. Reference architectures usually come with supporting artefacts and documentation, so large parts of the architecture don’t need to be documented and maintained separately. For example, if projects use NORA (a reference architecture for Dutch e-government), software engineers can focus on documenting product or organization-specific features rather than the whole architecture and all design decisions. In the example of NORA, this would include features and architecture artefacts implemented in individual municipalities.
• Team flexibility. Reference architectures facilitate communication within and across Scrum teams since there is a shared understanding of common architectural ideas. We have found that this not only benefits individual teams, but also allows engineers to move across different projects and / or teams, and to work on more than one project at the same time (as long as the same reference architecture is used). This facilitates cross-functional teams, as promoted in agile practices.

The above list includes preliminary findings and there are certainly other benefits (and benefits related to software architecture in general), depending on a particular project situation. We also report more details in our paper “Understanding the Use of Reference Architectures in Agile Software Development Projects” published at the 2015 European Conference on Software Architecture.

References:

¹M. Keeling: Lightweight and Flexible – Emerging Trends in Software Architecture from the SATURN Conferences. IEEE Software 32, 3, 7-11, 2015.

²L. Vijayasarathy, C. Butler: Choice of Software Development Methodologies – Do Project, Team and organizational Characteristics Matter? IEEE Software, in press.

You may also like:

• Keeling, M., "Architecture Haiku: A Case Study in Lean Documentation [The Pragmatic Architect]," in Software, IEEE , vol.32, no.3, pp.35-39, May-June 2015 doi: 10.1109/MS.2015.59
• Madison, J, "Agile Architecture Interactions (was: Agile Architecture Insertion Points)," in Software, IEEE , vol.PP, no.99, pp.1-1 doi: 10.1109/MS.2010.27
• Richardson, E., "What an Agile Architect Can Learn from a Hurricane Meteorologist," in Software, IEEE , vol.28, no.6, pp.9-12, Nov.-Dec. 2011
  doi: 10.1109/MS.2011.152