Decide How Much to Design Up Front

Architecture is a necessary investment. Every software system has an architecture. One way or another, you will spend time designing it. If we spend time designing architecture up front, then we’ll reduce the cost of future rework. Of course, time spent planning architecture also delays implementation thus potentially delaying value for stakeholders. If we spend no time up front on architecture, then we are more likely to make changes to the architecture after developing parts of the software system.

Depending on the software system’s size and requirements variability, every software systems has a design sweet spot, an optimal amount of time to spend designing architecture before diving into implementation.

Find the Design Sweet Spot

In Architecting: How Much and When? [BWO10], Barry Boehm shows us that the combination of development time, architecture planning, and rework are major contributing factors to the overall project schedule. Rework includes activities such as fixing design defects, rewriting code, and undoing mistakes. To find the sweet spot, we must account for both design costs and the inevitable rework required to complete the software system.

The architecture sweet spot is highly dependent on the size, requirements volatility, and complexity of the software you’re developing. The graph from Boehm’s data [BWO10] shows how the amount of rework decreases as more time is invested in architecture planning. The solid green line represents the sum of architecture design effort (dashed blue line) and the cost of rework (dotted orange line).

In this case, spending less than about 20 percent of the original project schedule on architecture has a diminishing return. While the amount of rework decreases with a greater investment in architecture, the total project schedule increases. Similarly, spending less time on architecture raises the amount of rework, creating a longer overall project timeline.

In the same research, Boehm also shows how the sweet spot moves depending on the estimated size of the software system. Use this data to decide if the amount of time you plan to dedicate to up-front architecture design is in the right range.

This graph is packed with important implications, so let’s break down the essential points.

The bigger the software system, the greater the benefits you’ll reap from up-front architecture design.

From Boehm’s research, spending upward of 37 percent of the total estimated development schedule on architecture design for large (10,000 KSLOC, where a KSLOC is 1,000 equivalent source lines of code) software systems would be a wise decision.

Smaller (10 KSLOC) software systems gain little from up-front architecture planning.

From Boehm’s research, as little as 5 percent of the total estimated development schedule might be spent on up-front architecture design. In some cases, it can be faster to rewrite a small software system than to spend significant time designing architecture up front.

Expect violent thrashing if you invest little into architecture design.

Avoiding up-front architecture design in smaller software systems might be more cost effective and result in a shorter overall schedule, but rework will still be necessary. Be prepared for this and account for design churn in your plans. Bigger systems will experience even more thrashing with less architecture design up front.

The more you invest in architecture, the less rework will be required.

Planning architecture helps avoid mistakes. If you favor predictable project schedules over schedule efficiency, you will benefit from more planning up front, even on smaller software systems. Up-front planning is a must in larger software systems.

Size is a nice predictor since it’s easy to measure and estimate, but many teams also use complexity [WNA13] to decide how much architecture design work might be required. Large systems can be complex, but not all complex systems are large. If a solution is routine, then your team might get away with less up-front planning even when the system is large.

Another factor to consider is requirements volatility. Changes to architecturally significant requirements can invalidate the best-laid plans. If you anticipate a high degree of change, delay making binding decisions and focus on using lighter-weight design and documentation methods.

Example: Impact of Architecture on Total Schedule

Say we are developing a software system with an estimated size of 100 KSLOC and an initial development schedule of 100 days. Per Boehm’s data, if we spent 5 percent of our time on architecture, then the total project schedule would increase by about 43 percent. Had we spent a little more time on architecture, say 17 percent of the estimated development schedule, then the total project schedule would have increased by only 38 percent.

Of course, more architecture does not always mean we’ll have a shorter schedule. If we spent a third of the estimated development time on architecture, we’d increase the total development schedule. While we’d spend significantly less time on rework, the extra time dedicated to architecture doesn’t pay off since the overall project schedule increases by about 40 percent.

Here are the numbers assuming our estimated 100-day initial development schedule:

The Constructive Systems Engineering Model (COSYSMO) includes Boehm’s findings. I suggest you try the COSYSMO and COCOMO II tools with your project data.^[3]

Thanks to Boehm’s work, we have a general idea for how much time to spend on architecture design, but we still don’t know when to do the design work or when to adopt the different design mindsets introduced in Chapter 2, ​Design Thinking Fundamentals​. It turns out Boehm also has an answer for this (yes, he is that awesome). In Using Risk to Balance Agile and Plan-Driven Methods [BT03], Barry Boehm and Richard Turner propose using risk to decide when to focus on architecture. If we think about risk in the right ways, we can also use it to determine what to design and how to involve stakeholders in the design process.