The Tension Between Agile and Architecture Useful Definitions on Software Design and Architecture
Total Page：16
File Type：pdf, Size：1020Kb
The tension between agile and architecture Useful definitions on software design and architecture Peter Hendriks IT Architect at Info Support B.V. [email protected] @PeterHendriks80 blogs.infosupport.com/peterhe/ Agile and architecture: cats and dogs? Agile and architecture are often considered cats and dogs. Many "classic" software architecture methods are considered an enemy of agile principles: often describing heavyweight, upfront documents and decisions, and a hierarchy with architects wielding all technical decision power and responsibility. Although there are some new "agile architecture" concepts out there, these typically only address small parts of the problem and often require significant skill to practice correctly. There is even the notion that architecture is not needed anymore when applying agile practices. But what is "architecture" anyway? Architecture: a concept, process and role Like so many software development terms, "architecture" is not a very well defined thing. For starters, the term architecture is used for wildly different categories: The architecture concept: the notion that certain aspects and design choices of a system are more important and fundamental. The architecture process: the way architecture concerns are addressed in the way teams The architect role: the person considered responsible for architecture We’ll look at each category to establish how "agile friendly" architecture actually is. A definition of architecture: the concept "Worries about the hard stuff - whatever that organization thinks is hard“ - Martin Fowler and Ralph Johnson, thought leaders in agile and design, on architecture "Design is the structure or behavior of an system whose presence resolves or contributes to the resolution of forces on that system.“ - Grady Booch, one of the fathers of modern software design, on design "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.“ - Grady Booch, now on architecture Architecture versus design A design has correlated, but different goals. Design may be needed to allow communication, collaboration and complex problem solving. Since all architecture is design, these goals matter for architectural significant design decisions as well. Design often exists in multiple levels of detail, with the lowest level being the code. High level design is often considered the architecture. Most of the time this makes sense: high level design naturally contain a lot of decisions that are hard to change after the system is built. Considering high level design as the only architecture is risky: you might want to do too much of it, while missing decisions with a high cost of change at lower levels. Architecture in the context of system design An example model of system design, relevant forces, and architecture Features Laws Operational costs Security Monitoring & control Performance Stakeholder needs Existing systems System Technology changes Common practices Team changes Environment Future Design Design Productivity Licensing deals Extendable Corporate standards Design Design Design Achievability Technology capabilities Team skills Project budget (time/money) Framework support The need for the architecture concept in agile Architecture-as-a-concept assumes that certain parts of a system will be hard to change. It also assumes that design decisions here will be considered more significant, because of the greater short-term risk and possible long-term limitations for the evolution of the system. It's safe to say these assumptions are still valid for systems built in an agile fashion. Common agile practices, like automated testing and short iterations, drive down the overall cost of change. In that sense, agile reduces the amount of architecture needed. But there is no silver bullet here, there will still be "hard stuff". Making wrong decisions here will still seriously hurt or kill an agile project. The other way around, agile practices, like working in small teams, releasing early and often or being testable, often add extra demands on the system design, even at the architecture level. Also, some architectural design decisions, like applying modularity, may reduce cost of change and support other important agile values. In order for agile to be a successful approach to building a system, the architecture must support it. So, where is the problem? Architecture still matters for agile projects. Some things that need to be built in almost every system just don't change easily after the fact. Only relying on "refactoring" will not cut it. There is very little debate on the need for architecture-as-a- concept in an agile project, once you focus on design decisions with a high cost of change. In some aspects, architecture is even a critical element for the success of important agile practices. However, when we look at architecture as a process, the tension becomes more apparent. Defining the architecture process If we consider that architecture is about design decisions that have a high cost of change, then an architecture process should strive to lower the rate of change on these decisions once they are committed to. As a secondary goal, the process should help to identify what changes will be more costly to make, making the software development process more predictable and improving the confidence of the team. Agilists should feel a tension here. Lowering rates of change and long term predictions does not feel very agile. It isn't, and in a way, this is where the ideals of agile meet the boundaries of practical reality. Why change a design decision? Reason for change: Considering these goals, it becomes apparent • The decision was wrong; the resulting system does not work that the architecture process should involve all disciplines in a software development team. • A change in a force invalidates the decision • A more optimal decision is found Investigating and negotiating stable insight is key to predict whether the design decision will last Some countermeasures: for a longer period. • Investigate unclear and changing forces Testing design assumptions as soon as possible • Consult existing experience and expertise and fixing problems before building an entire • Early evaluation of the decision system on them can help immensely. • Delay the decision • Add abstractions that are more stable Planning the system evolution around tough choices, or adding abstractions, can postpone or alleviate effects of change. Deliberate vs accidental architecture During the evolution of a system, not all design decisions with a high cost of change are deliberately made using an architecture process. This design that just happens is often called “accidental architecture”. Accidental architecture can be a judgment- or communication problem, but also a learning effect of building the system. We should expect that while the system is being built, we may periodically need to evaluate which design decisions matter most, and if existing decisions need adjustments. Agile places heavy emphasis on feedback early and often. This is a big help for an architecture process. We can continuously evaluate design decisions using the real system as it’s built. Also, we learn what matters for decisions that come up later. Tools and practices for architecture processes There are many established software architecture tools and practices available. These vary from complete and specialized process frameworks like TOGAF to various notations and metamodels, like UML and ArchiMate, to best practices, like design patterns and the SOLID design principles. There are design tools, like Enterprise Architect, or code analysis tools like Structure101, that can be very useful, but require skill to use. Often, a whiteboard is used, easy for everyone to participate, without the distractions of having to operating a complex tool while thinking about a difficult problem. Personally, I believe all these methods and tools can be applied in an agile fashion, if used in a small package form. However, they are often marketed as big and overarching things. This results in a lot of resistance in agile teams. The role of the architect So who is driving the architecture process? In the "classical" architecture process, an architect creates a detailed Big Design Up Front (BDUF). The architect is a senior specialist, who knows what's the best way to build the system and anticipates how design forces will behave during the lifetime of the system. He/she designs the system before the "construction" team starts, so they don’t have to wait during the period needed to create the BDUF. Then, the process aggressively limits any deviation to the original architecture. As an industry, we have learned that this is an naïve approach. It assumes an all-knowing architect, a completely predictable future, and a team that just reads a document and then knows what to do. However, consider the architecture process we've just discussed. Even in an agile team, this definitely There is complex decision making, multi-discipline collaboration seems like a candidate for a specialist role, and communication, and specialized design methods and tools. especially for larger systems, where the Experience with both the problem domain and the technologies amount of architecture rapidly increases used to build the system are essential to effectively predict and and the stakes are much higher. communicate design decisions and their effects. Is the architect