Shaw and Garland opened their seminal book "Software Architecture: Perspectives on an Emerging Discipline" with this sentence:
Barry Boehm used his COCOMO II model to determine the effects of size of architectural effort in "Architected agile solutions for Software-Reliant Systems": the more time you spend architecting, the more time you add to the overall schedule (naturally!); conversely, the less time you spend architecting, the more time you have to spend on rework and fixing up architectural problems. Add those two curves together and you get a U-shape, with a sweet spot at the minimum (see figure 5 on page 7). The cost of rework is higher with larger systems, so your sweet spot moves to the right - that is, more architectural planning.
But do we see this relationship in modern systems being built using agile methods? Not necessarily, it appears. Architecture is changing: for teams using modern development frameworks (such as .NET, Hibernate, Ruby on Rails), architectural decisions aren't nearly as intractable as they were in the old days -- they can be changed more easily during development. In fact, some decisions that used to be considered architectural may now be considered design decisions.
Frameworks do this by providing standard solutions to problems and therefore greatly reducing the complexity (and risk) of a system. In effect, they are decoupling the relationship between complexity and size: a system may be large but implemented entirely using predefined components and libraries, therefore greatly reducing the complexity and architectural effort required. On the other hand, a small system may not be easily built using predefined framework components and libraries, and needs significant architectural effort.
So while size and complexity are related, it is not an linear relationship and it is complexity that is the true driver of architectural effort, not size.
And what's the corollary of this? Perhaps it is modern frameworks are an important enabler for reducing the up-front effort required in agile software development.
"As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation".That is, the bigger and more complex the system, the greater the proportion of time that needs to be spent nutting out the architecture.
Barry Boehm used his COCOMO II model to determine the effects of size of architectural effort in "Architected agile solutions for Software-Reliant Systems": the more time you spend architecting, the more time you add to the overall schedule (naturally!); conversely, the less time you spend architecting, the more time you have to spend on rework and fixing up architectural problems. Add those two curves together and you get a U-shape, with a sweet spot at the minimum (see figure 5 on page 7). The cost of rework is higher with larger systems, so your sweet spot moves to the right - that is, more architectural planning.
But do we see this relationship in modern systems being built using agile methods? Not necessarily, it appears. Architecture is changing: for teams using modern development frameworks (such as .NET, Hibernate, Ruby on Rails), architectural decisions aren't nearly as intractable as they were in the old days -- they can be changed more easily during development. In fact, some decisions that used to be considered architectural may now be considered design decisions.
Frameworks do this by providing standard solutions to problems and therefore greatly reducing the complexity (and risk) of a system. In effect, they are decoupling the relationship between complexity and size: a system may be large but implemented entirely using predefined components and libraries, therefore greatly reducing the complexity and architectural effort required. On the other hand, a small system may not be easily built using predefined framework components and libraries, and needs significant architectural effort.
So while size and complexity are related, it is not an linear relationship and it is complexity that is the true driver of architectural effort, not size.
And what's the corollary of this? Perhaps it is modern frameworks are an important enabler for reducing the up-front effort required in agile software development.
