Position paper for the OOPSLA 2002 Workshop on Agile Architecture.

Steve Berczuk
steve@berczuk.com
www.berczuk.com

Architecture and Agile Processes.

 "Architecture" is a description of the structure and perhaps also
 the goals of a system. When you make the architecture explicit by
 having a description of the various aspects of a system (ie, the
 logical model, physical model, use case model, etc) you enable a
 person making a change to a software system understand quickly where
 the change fits in, and the impact of that change on the overall
 system. This is is true regardless of the level of detail in which
 you describe the architecture, or even regardless of the mechanism
 (formal documents, comments in code, documentation using a modeling
 tool, or even if the architecture is 'in the head' of the architect,
 who is involved in changes to a system.

 Because an architecture can help you understand where and how to make
 changes to a system when you need to change its functionality, having
 an architecture can facilitate agile software development. The key to
 making an architecture a help, rather than a hinderence is in how you
 go about maintaining and using the architecture. The factors to
 consider are:

    * How much work you do in advance, vs how much you allow the
      architecture to evolve with requirements. Since refactoring is a
      part of agile methods, architectural evoloution is perfectly
      reasonable. You can start out with some general principles, and
      expand them as the needs of the project become more clear.

    * How you 'document' the architecture. Since your achitecture is
      evolving, you don't want to spend too much effort maintaining
      documentation that will change on a frequent basis. The right
      level of documentation will depend on the team. The important
      thing is that every member of the team understands the
      architecture well enough to decide how to make a code change
      that fits into the architecture, and the consequences of making
      a change that might violate an architectural principle (thus
      initiating a change to the architecture).

    * How well you communicate with the architecture role. The key to
      a coherent, working, maintainable system is that changes work
      well together. Agile practices are really about
      communication, and a coherent architecture is best maintained by
      communication. Developers and the architect need to know the
      impact of any change with respect to the architecture. 
 
 Architecture's relationship to agile development is much like the
 relationship of another 'process intensive' mechanism: software
 configuration management (SCM). SCM, when used properly, and to the
 appropriate degree, can enhance agility, and the same is true for
 architecture. (See my book "Software Configuration Management
 Patterns: Effective Teamwork, Practical Integration" for more on the
 role of SCM...) SCM can even have a role in establishing an
 architecture by helping to define the module structure, and by using
 policies to place appropriate levels of control on different parts of
 a system (ie: some parts being allow to change freely, others being
 more 'key' to the system principles).

 My basic approach to using any technique that imposes structure (SCM,
 architecture, etc) is to use enough of it so that your team does not
 have to waste time and energy on mundane issues that can be easily
 resolved by defining a simple framework. Even a 'simple' architecture
 can help developers decide how to build and evolve a system quickly.