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
Revised 28 Sept 09: I’ve attached the final version of the longer
paper and have put the short (1-page) version inline here.
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
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:
It is similar to the spiral model of software development  in
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) . 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.
 L. Bass, P. Clements, and R. Kazman. Software Architecture in
Practice. Addison-Wesley, second edition, 2003.
 B. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21(5):61–72, 1988.
subscribe via RSS