I recently read an interesting book chapter by Barry Boehm about what is the right amount of architecture to do  “up-front” before committing to the architecture. Boehm analyses his project database and concludes that for most solutions, a proper solution architecture validated up-front will eliminate many of the delivery overruns and shortfalls commonly experienced. The only exception is small, non-critical solutions in a volatile environment; in those situations, architecting generally has a negative ROI.

So what is “small”? Boehm’s analysis yields the following rough estimate of the optimum amount of architecture effort for various project sizes:

My only addition to this table is a translation of Boehm’s Lines of Code to project budget, based on the assumption that the need for architecture in pure software solutions has roughly the same budget relationship as that in IT-related solutions with a wider scope. Boehm also nicely shows that the optimum architecture effort goes down for solutions with a less stable context, and goesup for more business critical solutions.

RCDA on how much up-front architecture

RCDA does not consider architecting to be an “up-front” activity that has to be completed before implementation of the solution can start. In most projects, however, there is a moment that can be identified as the Architecture Milestone. This is the moment after which reversing key architectural decisions becomes very costly and time-consuming, the moment at which the delivery team commits to the architecture. This is a key milestone for solution architects. Solution architects need to know how much architecture needs to be done before this milestone.

In RCDA, the answer to the “how much architecture?” question is based on the view of architecting as a risk- and cost management discipline. Deciding how much architecture needs to be done before committing to the solution is a risk management decision.

Less up-front architecting generally increases the following risks:

• risk of not fulfilling architecturally significant requirements
• risk of rework (refactoring, repairs)

More up-front architecting generally increases other risks:

•  risk of overdesign (YAGNI)
•  risk of idleness (resources waiting to go to work)

As you can see, both options increase risks that can lead to delays in delivery and cost overruns. Which outweighs the other is determined by the solution and project context. The context factors are the same as in Boehm’s analysis:

• A volatile environment increases the probability of overdesign, making less up-front architecting better.
• A highly business-critical solution increases the impact of not fulfilling architecturally significant requirements, making more up-front architecting better.
• A large project increases the impact of both rework and idleness, these two risks compete with each other to determine whether more or less up-front architecting is better. When making the trade-off, take into account that the impact of idleness increases linearly with the project size, while the impact of rework generally increases at a superlinear rate, due to the extra coordination and dependencies between the elements of rework.

In short, RCDA’s view of architecting as a risk- and cost management discipline leads to the same conclusions as Boehm’s analysis, which adds a nice quantitative heuristic for solution architects to use.

References

“Making Software: What Really Works, and Why WeBelieve It“, edited by Andy Oram and Greg Wilson. Chapter 10: “Architecture: how much and when?”, by Barry Boehm.

“RCDA: Architecting as a Risk- and Cost Management Discipline” by Eltjo R. Poort and Hans van Vliet, Journal of Systems and Software (2012)