Library

Strategic Architecting

This article was originally published in News at SEI on: March 1, 2006

For more than a century, since the “discovery” of the 80-20 principle by the Italian economist Vilfredo Pareto, scholars and practitioners alike have preached the merits of applying this principle in business. The popular thesis, as applied to software development, is that 80% of property X involves only 20% of property Y. For example, “80% of the defects are found in 20% of the code,” or “80% of the value is found in 20% of the features.” The implication of such results seems clear: Focus your efforts on the high-payoff. But the reality is less simple.

Unfortunately 80-20 rules are almost always retrospective: You can only confidently apply them after the system has been developed and you have collected data from your experiences. As Butler Lampson has written, “it is normal for 80% of the time to be spent in 20% of the code, but a priori analysis or intuition usually can’t find the 20% with any certainty” [Lampson 93]. Thus the real use of the 80-20 principle has been as a way to find out about all the opportunities you missed.

There have been several practical impediments to making strategic, up-front use of an 80-20 rule in software development:

How can you determine in advance where the 20% is?

What confidence is there that your currentproblem follows the same 80-20 pattern?

Does the expected benefit for the 80% outweigh the cost for focusing on the related 20% that (in theory) will deliver it?

What is the specific strategy (i.e. what problems to solve, using which techniques, and in what order) that will cause you to focus on the 20% in question?

While 80-20 rules have indeed found wonderful tactical application—for example, IBM’s classic OS 360 performance optimization—and have made reasonable strategic rules for business management, the above problems have made a disciplined approach to strategically managing software development elusive.

Clearly we would prefer to practice strategic software engineering, where we use methods that explicitly optimize expected value with respect to cost. Software architecture, in fact, provides a sound foundation from which to practice a strategic approach to software engineering. Consider the question of architecture flexibility; for example: How much flexibility should you build into a software architecture?

If you build in too much, your architecture, although highly flexible and easy to modify, will likely take a long time to create and suffer runtime performance problems. This is because flexibility is typically achieved by separating functions from each other with layers of abstraction, and these layers incur a runtime performance penalty. If you don’t build in enough flexibility, your architecture will be rigid, with lots of hard-wired dependencies or, worse still, will be a “spaghetti” architecture in which everything is tangled together with everything else—then you will likely have a quick time to market, but you might suffer in the long run when you need to modify the architecture.

Port and Huang have suggested that while there is no “right” amount of architecture flexibility, you can choose the amount you want and engineer your system to achieve this amount [Port 03]. In effect, you are choosing to optimize the expected value from your architecture (choosing the 20%) rather than blindly building the architecture and hoping that the 20% that you focused on is the correct 20%. In this case you would choose the amount of architecture flexibility based on the percentage of features that you anticipated would need to be modified.

At the Software Engineering Institute, we have created a number of methods that promote strategic thinking for software architecture. This is appropriate, since an architecture is, by design, strategic: it is meant to be the carrier of the earliest, most fundamental, and, hence, hardest-to-change design decisions. The Quality Attribute Workshop (QAW) helps a group of stakeholders elicit and refine the most important quality attribute scenarios that will shape an architecture, thus helping with problem 1 above, “How can you determine in advance where the 20% is?” The 20% will be centered around your highest priority functions and quality attribute scenarios.

The Attribute-Driven Design method aids in attacking problem 4: “What is the specific strategy … that will cause you to focus on the 20% in question?” The ADD method provides an explicit strategy for turning the high-priority quality attributes and functions into an explicit architecture that meets those requirements. And the Architecture Tradeoff Analysis Method (ATAM) and the Cost-Benefit Analysis Method (CBAM) help to address problems 2 and 3: “What confidence is there that your currentproblem follows the same 80-20 pattern?” and “Does the expected benefit for the 80% outweigh the cost for focusing on the related 20% that … will deliver it?” ATAM checks the elicited scenarios with a broad group of system stakeholders and checks the mapping of scenarios onto an architecture to understand how well the proposed solution fits the problem. And CBAM helps model and predict the expected benefit that particular architectural strategies will achieve.

More recently we have been investigating the use of real options theory from economics to aid in understanding the costs and benefits of architectural flexibility. We will report on this work in an upcoming installment of The Architect.

About the Author

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.