How much a software architecture design should cost?
--
A lot! The importance of setting the right direction of a journey before your very first step, can never be stressed enough. While it should be obvious. But that’s a title for another story. This one is about what part of the budget for a software system development should go to the architecture design process.
I’ve recently been asked this question. Since I’ve always loved relating the software development to civil construction, I’ve asked a close friend of mine, an architect, what is considered a normal share for the design of a building. His industry is couple of thousands of years older — should be more mature, I guess.
A tough question… depends on the size… On one end of the spectrum are large, multifunctional public buildings, and the design takes around 1.5–2%. On the other end are small, single family houses, where the percentage can reach 10–14%…
But this is usually related to the total value of the finished building. The structural work also varies, but can go anywhere between 30% and 50% of the total cost.
That was a good starting point. And a bit surprising one. I felt like in software development, the share of architecture design efforts does not vary that much. I gave it a second thought… And a third one. Then realized how for so many years, I’ve missed an important difference point in the analogy between making a building, and making a software. The potential for effort amortization.
In both endeavours the design work can be easily reused — you work hard to think about a floor plan, that suits the whole ten story building. And it works for all of them. With some tweaks, of course. Similarly — you design the modules, libraries and protocols in a software product once for the whole system (ok, it could be twice, or more, sometimes, but again — this is a subject of another article). But, when it comes to actual development/construction — you simply cannot copy & paste a floor… You need to annoyingly and meticulously lay brick, after brick, on a same plan for each of the ten stories, until you have it built. While in software development you can copy and paste (although, you shouldn’t!), and most importantly — you can reuse “constructed” parts many times.
That explains the big variance in design share for civil construction — processes have different scalability. It also means that a software design architecture part should be closer to that of a single family house scenario. Additionally, since we often see the development part as the “structural work” only, and the content (which is part of the “finished building”) is not part of that calculation — the percentage of the software system architect design should go as high as 20%. Even more, I’d say.
That is not all. Having each copy (floor in our example) be individually “developed”, also means that it doesn’t pay off overthinking the structure and making it too reusable, because it can’t be. In software design, on the other hand, abstractions and structural reusability potential (if done properly) does pay off. Not to mention, that you don’t suddenly decide to add 3 more stories to a finished building. Civil architecture design finishes at last when the construction ends. In software design it doesn’t, which again — raises the bar for a good, thoughtful design, capable of handling unforeseen expansions smoothly.
As I was saying… a lot!
