The tension between agile and architecture

1,155 views

Published on

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? This infodeck gives an overview on architecture as a concept, a process and a role. It is delivered as stand-alone slides, and should be useful for anyone involved in building software systems.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,155
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
33
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

The tension between agile and architecture

  1. 1. The tension between agile and architecture Useful definitions on software design and architecture Peter Hendriks IT Architect at Info Support B.V. peterhe@infosupport.com @PeterHendriks80 blogs.infosupport.com/peterhe/
  2. 2. Agile and architecture: cats and dogs?Agile and architecture are often considered cats and dogs.Many "classic" software architecture methods areconsidered an enemy of agile principles: often describingheavyweight, upfront documents and -decisions, and ahierarchy with architects wielding all technical decisionpower and responsibility.Although there are some new "agile architecture" conceptsout there, these typically only address small parts of theproblem and often require significant skill to practicecorrectly. There is even the notion that architecture is notneeded anymore when applying agile practices.But what is "architecture" anyway?
  3. 3. Architecture: a concept, process and roleLike so many software development terms, "architecture" isnot a very well defined thing. For starters, the termarchitecture is used for wildly different categories:The architecture concept: the notion that certain aspects anddesign choices of a system are more important andfundamental.The architecture process: the way architecture concerns areaddressed in the way teamsThe architect role: the person considered responsible forarchitectureWe’ll look at each category to establish how "agile friendly"architecture actually is.
  4. 4. 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
  5. 5. Architecture versus designA design has correlated, but different goals. Design may be needed to allowcommunication, collaboration and complex problem solving. Since all architecture isdesign, 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. Highlevel design is often considered the architecture. Most of the time this makes sense: highlevel design naturally contain a lot of decisions that are hard to change after the system isbuilt.Considering high level design as the only architecture is risky: you might want to do toomuch of it, while missing decisions with a high cost of change at lower levels.
  6. 6. Architecture in the context of system design An example model of system design, relevant forces, and architecture Features Operational costs Laws Security Monitoring & control Performance Stakeholder needs Existing systems System Technology changesCommon practices Team changes Environment Future Productivity Design Design Licensing deals Extendable Corporate standards Design Design Design Achievability Technology capabilities Team skills Project budget (time/money) Framework support
  7. 7. The need for the architecture concept in agileArchitecture-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, becauseof the greater short-term risk and possible long-term limitations for the evolution of thesystem.Its 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 theoverall 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 decisionshere will still seriously hurt or kill an agile project.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 changeand support other important agile values. In order for agile to be a successful approachto building a system, the architecture must support it.
  8. 8. Where is the problem?Agile is about embracing change. You want to change because the oldgoal has become suboptimal. You want to build “the right thing”.Architecture is about recognizing that some design decisions areexpensive to change. It will be suboptimal to change those often. Youwant to build “the thing right”.Architecture is a natural effect of building complex systems, and as such,also a factor for agile teams. Agile and architecture can complement eachother very well, building “the right thing in the right way”.However, there is a tension here. When we look at architecture as aprocess, this becomes more apparent.
  9. 9. 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 amount of these decisions, and 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. Lowering rates of change and long term predictions does not feel very agile. It isnt. In a way, this is where the ideals of agile meet the boundaries of practical reality.
  10. 10. Why change a design decision?Reason for change: Considering these goals, it becomes apparent that the architecture process should involve all• The decision was wrong; the resulting system does not work 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 lastSome 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.
  11. 11. Deliberate vs accidental architectureDuring the evolution of a system, not all design decisions with ahigh cost of change are deliberately made using an architectureprocess. This design that just happens is often called “accidentalarchitecture”.Accidental architecture can be a judgment- or communicationproblem, but also a learning effect of building the system.We should expect that while the system is being built, we mayperiodically need to evaluate which design decisions mattermost, 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 continuouslyevaluate design decisions using the real system as it’s built. Also, we learn what matters for decisions that come up later.
  12. 12. 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.
  13. 13. The role of the architectSo who is driving the architecture process? In the "classical" architecture process, an architect creates adetailed Big Design Up Front (BDUF). The architect is a senior specialist, who knows whats the best way tobuild the system and anticipates how design forces will behave during the lifetime of the system. He/shedesigns the system before the "construction" team starts, so they don’t have to wait during the period neededto 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, acompletely predictable future, and a team that just reads a document and then knows what to do.However, consider the architecture process weve just discussed. Even in an agile team, this definitelyThere 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 theExperience with both the problem domain and the technologies amount of architecture rapidly increasesused to build the system are essential to effectively predict and and the stakes are much higher.communicate design decisions and their effects.
  14. 14. Is the architect part of “the team”? Agile focuses on small, empowered teams. In most cases, the biggest challenge for an architect is collaborating with everyone involved creating the system. From a team perspective, the best way to collaborate is to be part of the team. An architect ideally does hands-on work. Reading and writing code, for instance, is useful for a software architect to feel the effect of design decisions. It is also a great way to earn the respect of the team. Being part of the team makes it easier to do hands-on work. In larger enterprises, the architecture may span multiple teams and systems. In this case, the architect operates on a different level, often called enterprise architecture, outside the team. Usually, this architecture is perceived different, with other main stakeholders and design goals, but still is very important for a team building a system. For an architect, trust is a key aspect of being successful. Face-to-face communication and close collaboration, whether as formal part of the team or not, helps to build trust, and provides a lot of learning opportunities.
  15. 15. Wrap-up• Software architecture is all about design decisions with a high cost of change • This is the nature of complex systems; while agile reduces cost of change overall, it does not eliminate the need for critical elements to stay stable• Architecture in your process is about managing these decisions • This involves your entire team, and is needed throughout the lifetime of the system• Architects should not be positioned as an all-knowing oracle • But shaping a good architecture for a large enough system requires responsibility, expertise and experience that should not be considered a common skill set• Architecture is essential for agile success • Systems built using agile need to work, and need to last, too • Many agile practices rely on advanced architecture design

×