From the trenches: Communicating the value of architecting within agile development

Deciding not to architect is an architectural decision. Postponing key architectural decisions while focusing on iteration-at-a-time development and customer-visible features negatively affects the success of large-scale projects. On the other hand, indulging in analysis paralysis in search of the best architecture that will sustain the system for its entire lifespan has the same effect. This is a reality that both the agile and architecture communities have accepted, especially in the context of large projects. But given that neither little-to-no-architecture nor big-up-front-architecture delivers the desired results to project stakeholders, what is the solution?

Communicating the value of architecting within agile development is a year-long project that Nanette Brown, Robert Nord, and I have just begun at the SEI with the goal of better understanding and measuring where the sweet spot is for just enough architecting to support agility in the context of large projects. Understanding how architecture-related tasks and features appear in iteration and release planning is an essential aspect of finding the right balance. We observe, as have many others such as Jim Highsmith in the latest edition of Agile Project Management, that foregoing planning in the haste of development does not necessarily equate with agility. Customer-visible features come to be because of the underlying organization of the software. Every system has an architecture, explicitly designed or not. The separation of architecture, code, and features might aid in project management, yet the reality is that they are not clearly separable.

Architecture can focus planning, backlog management, and refactoring. It can help prioritize features that are architecturally significant. However, this requires eliciting architecture-related features, assigning value and cost to them, and having mechanisms that treat customer-visible features simultaneously with architectural features based on their dependencies. Philippe Kruchten describes these concepts and their relationship to each other quite clearly with the metaphor of painting. We are also collaborating with him and his team at the University of British Columbia.

We often get asked at the SEI, What are you currently working on?” On one hand, I’m glad that people care. On the other hand, I feel responsible that, in the search for solutions, we should not overlook the simple and the obvious. Being overly protective of ideas can lead to overthinking and overanalyzing, common pitfalls in any project, and contrary to agility: open communication, frequent feedback, courage, and simplicity.

In response, we have decided in this project to practice the principles of agility. We will make frequent posts here talking about what we are currently thinking, what we have read that we thought was valuable, what we applied, and what we think will not work as we progress on this project.

Ipek Ozkaya – SEI

About these ads

8 responses to “From the trenches: Communicating the value of architecting within agile development

  1. I am glad there is discussion in this field. Clearly architecture has its own logic, and that logic does not fit into project management time boxes.

    There is an architecture process, and architecture governance, and in my view until project management acknowledge this, agility will simply mean tactics to deal with short term thinking in technology deployments.

  2. This is a very useful and needed topic, looking forward to future posts. Many organizations struggle with the “swing” between traditional design/planning and agile iterations, some with poor results. There is a balance to be had, some discovery to be made IMHO.

  3. George Hielscher

    There is always an architecture, whether it is de facto or designed. When architectural decisions are not made before more detailed designs and coding, they are made by the coders. It is really hard for coders to make architectural decisions, since the architecture affects more than just the current area being designed and coded. Adding architectural design decisions to the detailed design/coding tasks just slows down those tasks.

    If the detailed design/coding tasks include architectural decisions, the architectural decisions are “distributed” (assuming multiple coders), and generally uncoordinated. In this case, conflicting architectural decisions are likely (inevitable if many decisions are made), which is costly to fix later in the project. The path to the final (or staged) results will take longer.

    “Agile” architectural decisions don’t need to take long (for the first-cut, initial decisions). But to avoid repeating the decision processes (for each coder), those decisions need to be centrally managed. Over time, additional architectural decisions will be made, and those also must be centrally managed. To avoid duplication of effort and conflicting decisions, the architectural decisions must be concisely documented and adequately communicated. So projects need coordinated architectural design to be “agile”.

    Personally, I prefer up-front architectural design, with clear descriptions of decisions made and decisions still to me made. But I recognize that de facto architecture can also work well if it is managed carefully. In any case, an “agile” project needs a centralized architectural design.

  4. In my opinion, Agile does bring negative impact on architecture. The way to work around it is probably to build collective architectural view on the product/system to start with and add a architectural design evaluation within each iteration to see whether it makes sense to make apropriate architectural changes within the iteration and amortize the architectural change to the current iteration if it makes sense.

  5. There is often some tension between architecture and coding, similar to the antagonism that can exist between project management and development. Process versus technology, planning versus work. The trick is to encourage the different streams of work so that they are mutually supportive and feed into each other, with each workflow contributing to the overall success of the system. Agile can help by keeping iterations short. Some initial overall Architecture up front can lay the foundation for more detailed design during subsequent iterations, possibly involving coders. The key point is to ensure that Architecture and Design are performed before coding.

  6. Pingback: From the Trenches – Software by Numbers « SATURN Network Blog

  7. Pingback: From the Trenches: Hard Choices Game « SATURN Network Blog

  8. It is great to see this usual conflict approached by SEI!

    Diego Fontdevila and me tackle some techniques and ideas around this particular issue on an article published on the last issue of the Architect Journal:

    Software Architecture in the Agile Life Cycle

    http://msdn.microsoft.com/en-us/ff476940.aspx

    If some of the content is useful to you or if we can help in any way to your work, please let us know.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s