Software Architecture and Agile Outline 2 Agility Architectural

Software Architecture and Agile

Outline • • • 2 Agility Architectural needs How Much Architecture? Three pillars of Architecture Guidelines for the Agile Architect Developing Agile Architecture

Agility • Agile processes were a response to a need for projects to – – be more responsive to their stakeholders be quicker to develop functionality that users care about show more and earlier progress in a project’s life cycle be less burdened by documenting aspects of a project that would inevitably change. • These needs are not in conflict with architecture. • The question for a software project is not “Should I do Agile or architecture? ” Instead ask: – “How much architecture should I do up front versus how much should I defer until the project’s requirements have solidified somewhat? ” – “How much of the architecture should I formally document, and when? ” • Agile and architecture are happy companions for many software projects. 3

Architectural needs • The Software Architecture must support: – Experimentation: Allows the discovery of requirements through experimentation. – Evolution: Allows the constant evolution of the system’s functionality to meet the dynamically varying customer needs. – Adaptation: Allows the existing code base to be easily adapted to satisfy any change in requirements – Extension: Allows the easy extension of the system’s functionality through modular features. • If the Software Architecture is not adaptable, the Agile process will fail. • Consequences: Increasing Technical Debt, endless Refactoring. 4

Question � How much design should be done up front? � Up front = Before starting the implementation (coding) 5

1. Traditional Approaches to Architecture Practice – BAUF (Big Architecture Up Front)

Big Design Up Front • BDUF = Do detailed design before starting to code. • Problems: – Requirements are incomplete. – Requirements may change. – “The Scrum product backlog is allowed to grow and change as more is learned about the product and its customers. ” 7

2. Emergent Design • “With emergent design, a development organization starts delivering functionality and let the design emerge. ” • First iteration: – Implement initial features. • Next iterations: – Implement additional features. – Refactor. 8

3. Just Enough Design • “Just enough sits somewhere in the chasm between big design up front's analysis paralysis and emergent design's refactor distractor. ” – Simon Brown • Question: How much design is “just enough”? 9

Agile • These processes were initially employed on small- to medium-sized projects with short time frames and enjoyed considerable success. • They were not often used for larger projects, particularly those with distributed development. 10

Agile Architecture • Although agile methods tell you to “embrace change” – change is not necessarily free – it depends on what changes. – if the developers are agile, reacting to every user request then you can easily get a very high rate of “ping pong” churn in some requirements. • In such circumstances a strong architecture does three things: – it reduces the cost of change, – it provides a reference against which the sillier requirements can be challenged, and – it can provide mechanisms which allow incorrect requirements to be rapidly reversed out. 11

How Much Architecture? • There are two activities that can add time to the project schedule: – Up-front design work on the architecture and up-front risk identification, planning, and resolution work – Rework due to fixing defects and addressing modification requests. • Intuitively, these two trade off against each other. • Boehm and Turner plotted these two values against each other for three hypothetical projects: – One project of 10 KSLOC – One project of 100 KSLOC – One project of 1, 000 KSLOC 12

© L e n B a s s , P a u l C l e m e n t 13 s How Much Architecture?

How Much Architecture? • These lines show that there is a sweet spot for each project. – For the 10 KSLOC project, the sweet spot is at the far left. Devoting much time to up-front work is a waste for a small project. – For the 100 KSLOC project, the sweet spot is around 20 percent of the project schedule. – For the 1, 000 KSLOC project, the sweet spot is around 40 percent of the project schedule. • A project with a million lines of code is enormously complex. • It is difficult to imagine how Agile principles alone can cope with this complexity if there is no architecture to guide and organize the effort. 14

The Lifeblood of Agile Is Frequent and Accurate Feedback Double-Loop Learning • Key success factor for agile processes is reflecting on your way of working • The Retrospective meeting is meant for that • The development process itself should also be flexible and adaptive • This also applies to architecture! 15

The Three Pillars of Architecture 16

The Social Pillar: Collaboration is Key Waterfall (BAUF) 17 Agil e

The Process Pillar: Continuous Architecture Across the Life Cycle

The Structural Pillar: Modularity is key Modular Monolith Using Componentized Architecture Microservice Architecture Structural Architectural Agility 19

Architect All the Way Down

Architect All the Way Down Views of a System — Class, Package and Module

Architecture All the Way Down Helps Bring Down the Ivory Tower

How Does the Agile Architect “Embrace Change”? 23

Software Architecture in Agile Development Process • Evolutionary Architecture – Agility is “the ability to make change cheap” – Architecture is “what’s difficult to change” – Think about how to make change cheap • It's about “Just Enough” – – Boundaries, Structure, Vision and Leadership Understand how the significant elements fit together Provide the foundations and vision to move forward Mitigate the key risks • Refactoring • Spikes and Tracers • Pragmatic 24

Refactor Mercilessly • Refactoring is the process of improving your existing code without changing its behavior • Refactoring improves the non-functional attributes of your codebase • Refactoring helps you manage the technical debt that increases maintenance cost and hinders your ability to understand the software system • Architectural refactoring emphasizes continuous improvement of the architecture 25

Validate and Enforce the Architecture • The focus is determined by a set of quality attribute scenarios that represent the most important of the concerns of the stakeholders • Proving initial architectural vision with code and ensuring that the vision survives change are separate issues. – – validate performance. validate portability. validate transactional correctness. validate layering. • Architectural tests will help validate that the implementation is working and aligned with the architectural vision 26