Software Architectural Decision Making
A common question I get asked is "How do I make architectural decisions?" and my standard answer is "it depends". While it's a tongue in cheek answer, there is a bit of truth to it. While there are frameworks and methodologies to try and reign this problem in, the reality is that the practice of "software architecture" is inherently a mess and certainly a wicked problem. That having been said, I'll give some insight into "how I do it".
First off, let me say, often many "decisions" are predetermined by your primary objective or have such a strong force behind them that there is little value in contemplating alternative solutions. A good example would be "which programming language should I use to develop an Android application?". You really have one decision and it's pretty binary: "Do I use java or javascript?" Yes, from a technical perspective it's possible to use ANY programming language (either through cross compiling or using a runtime interpreter), but if your primary goal is to release an application that allows a user to "do something on their phone" agonizing over every possible option is a HUGE waste of time. On the other hand, if your primary goal is to illustrate how to write applications using ruby to be run on an android device, the decision is preordained (and frankly not really a decision). Moreover, in the latter case, the decision switches from "which language should I use?" to "what approach should I use for running ruby applications on android?".
In the former case above, suppose our primary objective is to write an application that allows users to track their workouts on their phone. In that case, the "language" you use is relevant, but only as a secondary concern. Some questions you have to now concern yourself with are "how many people know java versus javascript?" or "will I want to ultimately release the application in both iOS and Android?". Additionally, you have to concern yourself with "are javascript developers cheaper/faster or java developers?" and "which approach is easier to test and debug?".
However, in the latter case, some questions are: "do I want to highlight using ruby's dynamic nature?" or "illustrate how Ruby can lead to higher quality code?" or something else like "do I want to illustrate how rapidly Ruby applications on android can be developer relative to java?". This also opens up another can of worms you need to consider, such are "is the pool of developers for Ruby such that developing in that language is even VIABLE?".
As we can see, the number of considerations grows at an exponential rate and is extremely sensitive to initial conditions (i.e. what is the primary problem). If you change the "primary problem" entire swaths of decisions are irrelevant (why worry about javascript if your objective is to write things in ruby?). This problem is what makes architectural decision making particularly pernicious and I would contend mean it exhibits fractal characteristics of a nonlinear system. This is also why no one has yet come up with a comprehensive "system" for making these decisions. While many lay claim to methodologies and approaches (take a look at what IBM has to say about it, the fact is it is an extremely difficult problem to reason about.
My best advice is this: Architecture is like software meteorology, you can't predict the future, but you CAN some up with general models that work for defined scopes. What does this mean? Simply that trying to define software architecture is like trying to define what the weather is for the entire globe. The fact is, "it doesn't matter" if your primary objective is to determine if you want to go to the pool or not. All that really matters is the local weather and your preference for the kind of weather you like to go to the pool in. Moreover, you don't need to necessarily explain "why you chose to go to beach instead of a pool" because you realized your original desire was "to go swimming" and limiting your option to a pool might have been a mistake (for other reasons). Put another way, "software architecture is understanding what's important" and "making important decisions", that art is learning how to figure out what is important, the science is too complicated to think about.
Comments