Making Software

Does the Architecting Need to Be Done Up Front?

Many Agile projects succeed by doing a lot of architecting, but by spreading it out across the life cycle through refactoring. This is an effective process as long as the project stays small and noncritical, but can run into “easiest-first” difficulties otherwise.

One example is when a small project grows large and finds that tacit interpersonal knowledge and local refactoring do not scale up very well, as in the lease management project described in [Elssamadisy and Schalliol 2002]. Another class of difficulties arises from choosing commercial off-the-shelf (COTS) products to get a quick start and early customer satisfaction, but finding that the COTS products do not scale up to handle increased workloads and that their source code is unavailable for refactoring. A related problem is when a project delays a pervasive concern such as security—scheduling it for the sixth quarter, for instance—only to find that security is a pervasive quality attribute that cannot be bolted on or refactored into the project’s previous architectural commitments. Thus, such evolution requirements need to be anticipated and architected-for in advance.