Risk-centric model of software architecture
It’s been a while since I posted a blog entry because I’ve been head-down working on the book. Here’s a position paper for an OOPSLA workshop that I will be attending. The abstract is:
Developers are faced with a smorgasbord of architecture activities but few models telling them which activities to use. Alternatives include the documentation package model, which advocates a complete architectural description from many perspectives, and the evolutionary design model, which advocates no up-front architectural work. This paper introduces the risk-centric model, inspired by Attribute Driven Design (ADD) and the Spiral model. Risks are central, so developers: (1) prioritize the risks they face, (2) choose appropriate architecture techniques to mitigate those risks, and (3) re-evaluate remaining risks. It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. Like ADD, and unlike the Spiral model, the risk-centric model is not a full software development process and can instead be used inside a process such as XP or RUP.
Here is a draft of the paper: The Risk-Centric Model of Software Architecture
Revised 28 Sept 09: I’ve attached the final version of the longer paper and have put the short (1-page) version inline here.
Risk-Centric Model
Software engineering is a relatively new engineering discipline, yet, over the past few decades, knowledge has built up about how to reliably develop software and avoid pitfalls. So much knowledge has built up that no project can possibly apply every known software engineering technique. A similar situation is beginning to occur in the sub-field of software architecture. Our knowledge about software architecture has been greatly enhanced over the past few years and, as a result, developers have more architectural techniques than they can economically apply on a project. Yet, unlike the overall field of software development, developers have relatively little guidance on how to choose and apply software architecture techniques.
Current choices include the documentation package model, which advocates a complete architectural description from many perspectives, and the evolutionary design model, which advocates no up-front architectural work. Developers want to succeed yet they must economize time and money.
Unquestionably, many development teams have struck a balance on their own projects using their own criteria. What we need, however, is a repeatable and generic way to strike that balance. This paper introduces the risk-centric model for choosing a subset of architecture techniques that correspond to the risks facing the project.
The risk-centric model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It can be summarized in three steps:
- Identify and prioritize risks
- Select and apply a set of techniques
- Evaluate risk reduction
It is similar to the spiral model of software development [2] in that both focus on risk and work on the highest risk items first. However, the risk-centric model applies only to architecture, while the spiral model applies to overall software development. The spiral model is applied once to a project and ends when the software has been completed. In contrast, the risk-centric model will be used at the beginning of projects as well as time-to-time during the project. It ends when architecture risks have been mitigated.
The risk-centric model also adapts an important feature from Attribute Driven Design (ADD) [1]. ADD uses a mapping from quality attributes to tactics to address them. For example, ADD uses a mapping from the quality attribute “availability” to the tactic “ping/echo”, which can be used to achieve availability. Similarly, the risk-centric model uses a mapping from risks to architecture techniques that address them. For example, it can use the mapping from the risk “protocol may deadlock” to the technique “analyze protocol using FSP”.
The key element of the risk-centric model is the promotion of risk to prominence. What we choose to promote has an impact. Most developers already think about risks, but they think about lots of other things too. We do not want to waste time on low-impact techniques, nor do we want to ignore project-threatening risks. We want to build successful systems by taking a path that spends our time most effectively. That means only applying techniques when they are motivated by risks.
Today, most developers are guided to architecture activities by a process or template provided by their organization, rather than being guided by risks particular to their project. This is inefficient since each project faces different risks —- it would be surprising if an unchanging set of diagrams and techniques were always the best way to mitigate a changing set of risks.
[1] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley, second edition, 2003.
[2] B. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21(5):61–72, 1988.
