If I had to pick one thing that differentiates the kinds of people that build features and those that build systems, I would have to say it was risk-driven thinking. Risk-driven thinking is not a product, nor is it really a process, like Agile, agile or waterfall. Rather, risk-driven thinking is a state of mind. To characterize it in a few words, risk-driven thinking is about consciously considering the needs of a system and acting commensurately. More specifically, it is an approach to building software whereby you explicitly identify the risks your project faces and the qualities it needs to exhibit in order to architect a solution that satisfies those demands.
I hesitate to call risk-driven thinking a process, because it is such a loose approach. Therein lies its beauty. Where many approaches go to one extreme or another, to be risk-driven is to only do enough; never too little, and never too much. Your level planning and attention to detail should scale commensurate to the scale, complexity, and novelty of the task at hand.
When not to architect
Before we get too deep, there is one thing to mention. It is OK, not to architect something. There comes a time when you look at a feature, a deadline, even a whole project and actively say: “This is a low-risk/low-size/tight-schedule thing and we do not need to plan and architect it beyond something very basic.” There are plenty of situations where this is a totally reasonable decision (that is to say you decided to take that action, it did not merely fall in your lap).
The whole of risk-driven architecture revolves around making these kinds of decisions and trade-offs. A big part of the whole exercise of design and architecture is just acknowledging what it is you face. If you take an honest look at what you’re doing and it’s alright to take on the risk, then go for it. Put another way, if the costs of architecting a system outweigh the benefits, then maybe it is not the best use of time.
If everything works out fine, then you now have a better idea what is an acceptable risk to take. If it fails, then maybe you’ll give pause to those kinds of situations when you encounter them again.
While we’re here feeling better about ourselves, it’s important to note: it’s also OK to make mistakes. Architecture is not omnipotence. Just because you decide to design something does not suddenly mean you’re immune to making a bad call here and there. Architecture is about learning from your successes and mistakes to build up a body of knowledge. Keep in mind, you’re not going to be great at designing applications the moment you decide to make an effort. It’s going to take time and practice.
One great way to get better at Architecture and Design is by practicing on personal projects. The next time you have a cool idea you want to implement, consider taking a step back and maybe over-architect things a little. Yes, this probably is one of those low-risk projects that could do without much design, but you’re trying to exercise a new skill here. It’s a little like going to the gym; you did not need to show up and abuse your body, but you do it anyways because it makes you stronger.
Architecting your own projects is also a great way to develop a sense of the bigger picture. Instead of diving in and getting myopic right off the hop, you exercise some of the more difficult soft skills that go along with starting and running a project.
Just like real exercise, it’s important to remember not to over-do it. You could try to apply every tip, trick and technique you learn in this book (and others) to your next project. You’ll probably walk away bored and dejected, though. Rather than burn yourself out with too much process, add in little-by-little over time as you get more comfortable. Not only will this be a more gentle and manageable introduction to Architecture, you’ll have the opportunity to observe how changes to your own process affect the outcome. Again, by only changing one variable at a time, you can be much more present to its effect.