If you knew nothing about software development, you might imagine that the best developers were the ones who spent the most time writing code. Yet it has been clear for a long time that judicious application of other activities—such as analysis, design and testing—will result in better software. However, at some point, doing more analysis, design or testing becomes counterproductive since it steals time and resources away from other, more productive activities.
Designing an appropriate software architecture is one of those non-coding activities that can improve the quality of a system, but if developers spend too much effort on it, they will be stealing from other activities. Consequently, an important question is raised: How much design and architecture should developers do? Any realistic answer must balance design and architecture effort against other activities.
This article introduces the Risk-Driven Model of architectural design. It guides developers to apply effort to their software architecture commensurate with the risks faced by their project. That is, low-risk and highly precedented systems should skimp on architecture, while high-risk and novel systems should pay more attention to it.
This might seem like common sense, but it is not what happens today on most projects. Most commonly, a project’s software development process dictates both the amount of effort and the specific architecture techniques. Unless this process is tuned to risk, it results in too much or too little effort spent on architecture.
How Architecture is Done Today
There is active debate about how much architecture work developers should do and several answers have been proposed:
- No architectural design. Developers should just write code. Design happens, but is coincident with coding, and happens at the keyboard rather than in advance.
- Use a yardstick. For example, developers should spend 10% of their time on architecture and design, 40% coding, 20% integrating and 30% testing.
- Build a documentation package. Developers should employ a comprehensive set of design and documentation techniques sufficient to produce a complete written design document.
Any of these answers could be appropriate, but it depends on the project. The problem with these answers is that they do not help developers find a balance—they instead prescribe that balance in advance. What developers need is a way to decide which architecture techniques they should apply and which they should skip.
The Risk-Driven Model
The Risk-Driven Model helps developers decide how much architecture work to do. The essence of the Risk-Driven Model is these three steps:
- Identify and prioritize risks
- Select and apply a set of architecture techniques
- Evaluate risk reduction
It helps developers follow a middle path, one that avoids wasting time on techniques that help their projects only a little, but ensures that project-threatening risks are addressed by appropriate techniques.
The key element of the Risk-Driven Model is the promotion of risk to prominence. What you choose to promote has an impact. Most developers already think about risks, but they think about lots of other things too, and consequently risks can be overlooked.
Projects face different risks, so they need different architecture techniques. Some projects will have tricky quality attribute requirements that need up-front planned design, while other projects need tweaks to existing systems and entail little risk of failure. Some development teams are distributed, so they document their designs for others to read, while other teams are co-located and can write fewer documents.
Technique Choices Should Vary
Most organizations guide developers to follow a process with some kind of documentation template or a list of design activities. Templates can be beneficial and effective, but they can also inadvertently steer developers astray. Here are some examples of well-intentioned rules that guide developers to activities that may be mismatched with their project’s risks:
- The team must always (or never) build a full documentation package for each system.
- The team must always (or never) build a class diagram, a layer diagram, etc.
- The team must spend 10% (or 0%) of the project time on design or architecture.
It would be a great coincidence if an unchanging set of diagrams or techniques was always the best way to mitigate a changing set of risks. Standard processes or templates can be helpful, but they are often used poorly. Over time, you may be able to generalize the risks on the projects at your organization and devise a list of appropriate techniques. The important part is that the techniques match the risks.
Imagine an organization that builds a three-tier system. The first tier has the user interface, and is exposed to the internet. The biggest risks might be usability and security. The second and third tiers implement business rules and persistence; they are behind a firewall. The biggest risks might be throughput and scalability.
What often happens is that both teams follow the same company-standard process or template and produce, say, a module dependency diagram. The diagram is probably somewhat helpful, but it takes the space of more helpful techniques better matched to the project risks.
Following the Risk-Driven Model, the front-end and back-end teams would apply different techniques. For example, the front-end developers might create user interface mockups and analyze their design for intrusion vectors. The back-end developers might do performance modeling and impose constraints to enable scalability.
Are You Risk-Driven Now?
Many developers believe that they already follow a Risk-Driven Model, or something close to it. Yet there are telltale signs that many are not.
One sign is an inability to list the risks they confront and the corresponding techniques they are applying. Any developer can answer the question, “Which features are you working on?” but many have trouble with the question, “What are your primary failure risks and corresponding engineering techniques?” If risks were indeed primary, it would be an easy question to answer. Another sign is that all developers use the same techniques.
Most architecture templates have a section on risks, but that is not the same as using risks to decide which techniques to use. To be risk-driven in your architectural decision making, you need to have a rationale that ties your actions (i.e., use of architectural techniques) back to your risks.