When to Spend Time Architecting


Thierry poses a question I’ve heard in several of my PM workshops this week and last week: When should the team do the architectural work?

Thierry’s concerned if his team continues to implement by feature, how can the team do the architectural work? If they take an iteration or two to deal with architecture, they stop churning out features. And, Thierry has an additional problem–his new module could be a stand-alone feature. But he has some other alternatives:

  • Implement three features and see where the architecture is going. If the team implements three relatively independent features, it may be clearer where the architecture is evolving. Once you see the evolution, maybe you can spend a short timebox (couple of days?) to define the architecture big picture, and let it continue to evolve within the framework the team has defined.
  • If trying some features doesn’t work, prototyping several architectures might. When you prototype, you don’t have to have releasable software; you just need enough to evaluate the architecture. If you prototype, maybe you don’t have to take the whole team to do so, and they can still be making progress.
  • Develop tests for the architecture. Get enough of the team in one room, have someone facilitate the discussion, and generate the questions/assessments/tests you’ll need to use to know whether an architecture will work.
  • Timebox the architecture development. Spend a day or two (I would definitely not spend more than a week) developing an architecture on paper, and then start implementing some features so I could see if I got it right.

I’m sure there are more options and I can’t think of them now.

If you do take time to do some architectural work, make sure it’s as little design up front, so you can test the architecture by implementing more features. Any time you do incremental development, you do run the risk of not realizing the architecture is sufficient until later in the project. But that risk is mitigated by having significant parts of the product already working.

Labels: architecture, incremental development

4 Replies to “When to Spend Time Architecting”

  1. In our current scenario, we have been using Scrum for several years in a small company. The team has been very focused (and very successful 🙂 in delivering value on top of a home grown architecture/framework.
    As we now have an opportunity to look at other framework options, the feeling is that we need time:
    – to install them, and
    – to understand their pros and cons.
    While I agree that we need to use real business scenarios for the comparisons, I think that something else happened too. Scrum gives you a framework for constant prioritization. Architectural R&D items never made it to the top of the backlog. The team is not ready for switching underlying technology overnight. The architecture R&D ‘debt’ grew. Now we have to pay it.
    In other words the issue here could be that there is not enough ‘slack time’ factored in the iterations. For example some time for ‘playing around’ with XYZ. Of course too much of it can be quite dangerous too.

  2. It looks like that the very term “architecture” starts suffering from what Martin Folwer calls semantic diffusion (http://martinfowler.com/bliki/SemanticDiffusion.html) or putting it in simple words starts loosing any clear meaning. For too many people architecture means too many different things. In fact there are very few real architectures in the world more or less all pre-scribed by the platfrom you choose. And you choose your platform based on initial requirements analysis. Is it a Windows XP rich client local or Web 2.0 remote application? How many concurrent users are expected? Etc., etc. All this stuff is usually known at an early stage. Then you add your orginization “values” such as “Microsoft socks”, or “we cannot take a risk of using open source” and volla! you find yourself with either Apache or IIS, or vanilla .NET or Swing. For mainstream data processing applications this IS their architecture. But applaication and system software are different. We have no proven record of applying agile approach for developing operating systems, compilers, databases or even Web Servers. I could hardly beleive that Brin and Page developed Google search enigne by slicing features without any preparatory architecture work. Perhaps they tried it several times, but that’s another story. Whenever you develop something really new you do it in a non-standard way.

Leave a Reply