Once you articulate a vision of how software architecture could be done well, which includes the creation of models that enable analysis, the next question is, “What analyses can I do?” At this point we can either go down the path of somewhat obscure academic efforts such as rate monotonic analysis or queuing theory and pretend that they are appropriate for mainstream use. Alternately, we could admit that there really aren’t many architecture analyses yet. Let me suggest a third path.
Human brains are remarkable at processing information, but quite dependent on the form of that information. Imagine trying to navigate from NY to LA if you were given an alphabetical listing of the street segments in the country. This would thwart a human but impede a computer only slightly. That’s because people have lots of visual processing capabilities that we use to find a route on a map. Maps are drawn to work with those capabilities, for example by drawing major roads thicker than minor roads.
Analysis of software architecture can do something similar. If a human is searching for single points of failure in an architecture, he’s going to have a hard time if he only looks at the source code. However, the fact that all requests flow through a single load balancer would jump out when looking at an allocation view.
The follow-on question is: Do standard architecture views (like allocation, runtime, and module) provide the right representations for humans to leverage their built-in analysis? I do not (yet) have a way to give a refutable answer to this question, but my experience is that Yes, the standard architecture views are good, but No, they are not ideal. The standard architecture views are general-purpose, which gives them leverage on almost all domains. The flip side to this is that they provide no domain-specific leverage. For example, a calendar has the nice property that all the Mondays are in the same column – a domain-specific encoding that you wouldn’t get from the standard architecture views.
subscribe via RSS