Architecture in an Agile World

This “Architecture in an Agile World” project started in fall 2009, with a discussion-based workshop at the ACM OOPSLA 2009 conference. This workshop explored some of the basic ideas of how best to use architectural thinking and software models in the context of agile development.

Agility is an important characteristic of product development in the business world - but in many problem domains, architecture is valuable too. The combination of agile and architecture-driven approaches is often essential to success - it creates some opportunities for discovering potential problems early in the development cycle.

There is a fair amount of disagreement about the nature of the relationship between agility and architecture. Philippe Kruchten and George Fairbanks have probably the most moderate points of view on this topic.

Overview talk

This article (arch_agile_notes.html) is an overview talk on Agility and Architecture (from March 2016).

Workshop reports

There are two major OOPSLA/SPLASH workshops that discussed many of the issues:

  • Architecture in an Agile World - workshop at the OOPSLA 2009 conference:
  • Architecture in an Agile World - workshop at the SPLASH 2010 conference:

    Useful articles on Agile and Architecture

    The following articles provide useful background to understand the costs and benefits of doing some architecture work in agile projects.

    Useful architecture techniques for agile projects

    The following articles explain several useful techniques to use in order to build lightweight and flexible architectures:

    Useful quotes

    A good quote from Kent Beck:

    A good quote from Eric Evans:

    A good quote from Luke Hohmann:

    Architecture smells

    Is my agile project doing an adequate amount of architecture work? One way to tell is to look for “architecture smells” – indications that you are doing extra work that could be avoided with more attention to architecture.

    If your code has some of these “smells,” the code may be trying to tell you something – your developers have been somewhat undisciplined in their design and coding work, and therefore you haven’t been spending enough time on addressing architectural issues.

    The following partial list of architecture smells was proposed in the SPLASH 2010 workshop:

    1. Code that nobody wants to change
      • (they are afraid to change it because it is complex or cryptic, and they don't want to break anything)
    2. Missing metaphor
      • (the team and customers need a common shared understanding and vocabulary about the problem)
    3. Overreliance on “refactoring iterations” to fix technical debt
      • (It is generally OK to have some refactoring iterations that are driven by architecture changes and evolution.)
    4. Abstractions that are hard to understand or communicate
    5. Missing -ility stories / tests / strategies
      • (A related issue: If you have many successive failures of -ility tests in a series of iterations, it might be a sign of a lack of progress on making improvements to the architecture.)
    6. Untestable code
      • (In the book Working Effectively With Legacy Code, Michael Feathers defines the term “legacy code” to mean “code without any tests.” If you have a lot of code that is difficult to test, that code will be never really improve until you start building tests that make it possible to understand the code’s actual behavior.)
    7. Unbalanced test suite
      • (too many unit tests, not enough functional tests)
    8. Test churn
      • (Small design changes trigger a number of changes in the automated tests – could be caused by poor technique in the implementation of tests, but there might be some architecture issues as well.)
    9. Problems in design evolution – the problem is sometimes called “you can’t get there from here.” You have a design that is too rigid.
    10. Inconsistent use of infrastructure
      • (For example, there are some modules that use a standard messaging component while other components use some special local messaging code. It isn’t really “wrong,” but it increases the learning curve for new project members, and it might cause long-term maintenance issues.)
    11. General violations of architecture standards
    12. Missing boundary stories
      • (How does your system interact with other systems? What end-to-end stories do you need to write to understand the interface requirements between your system and external systems?)
    13. Duplication without reason
      • (Examples: using two different databases, multiple interface mechanisms.)
    14. A number of incidents in operations
      • (If the system is hard to use, easy to make configuration mistakes, or it is easy to get things into an error state – this might indicate that you missed some requirements or you might have some other architecture gaps to address.)

    Last modified: Oct. 25, 2018