How do you know that you’ve found the "right" architecture for your system? In this and the following few posts, I’ll try to shed some light on this topic, because it’s a question that seems to be pretty common among software architects. Then, when you believe that you’ve find the right architecture, how do you convince your colleagues about that? Since skilled software architects usually rely a lot on their well-developed intuition for what a "good" architecture looks like, it’s not easy to find objective arguments when someone’s got a different opinion.
Of course I’ve got a great answer to that question. Just use the Architecture Tradeoff Analysis Method (ATAM). It’s a process published by SEI, so it’s good, by definition. All SEI processes are good, right? CMM and all that, you know. So just stop reading now, you’ve got a good answer to the question. Thanks for listening. Bye.
Still reading? You’re right, the answer isn’t that simple, after all. Well, the ATAM in fact makes sense, even if it’s very heavy-weight. The underlying ideas are sound, so there are many pieces of wisdom to extract from it. But since you’re still reading (hopefully we’ve lost the "process guys" now!), you would probably not introduce even small parts of a full-blown process like this without understanding exactly what you would gain from it in your current situation. OK, so what’s my point, then?
My point is that there’s a relatively simple, common-sense (well, for a software architect) part of the method that can be used to answer whether an architecture is modifiable or not, and which also is very useful for communicating the properties of the architecture to other people. You can finally prove that you’re right! 
Also, I’d say its easier to get to an objective analysis of for properties like availability, performance och security (lots of papers written on those!), than for modifiability, so we’ll skip those for now.
So, I’d like to share my understanding of that important part of the ATAM, called the Software Architecture Analysis Method (SAAM); it is a simple method used for analyzing the modifiability of a software architecture. If a software architecture isn’t modifiable, it’s not much of an architecture, right? Systems always change after its architecture has been established, during development or later in its life cycle, so this is indeed a fundamental property to analyze. We’ll see that the SAAM indeed answers a large part of my initial question, at least with respect to the modifiability of an architecture.
So, enough talking. You want to know when your architecture is modifiable, and you want to be able to convince your colleagues, and perhaps even your customers, about that. How do you solve this problem?
First, I’d like to connect to two concepts about software design that most people know, who’ve been into software engineering, and that’s coupling and cohesion. High coupling means that we’ve got lots of connections between our components, and high cohesion means that related functionality is kept together within the system. High coupling means that a change in one component is likely to require a change in another component, and low cohesion means that most "features" of the system will be spread out over several components, so that a change in a feature will affect several components. So, in general, low coupling and high cohesion is "good" for modifiability.
In the next post on this, I’ll show why coupling and cohesion aren’t good enough for analyzing a software architecture, and how the SAAM is a generalization of those ideas, but anyway being much simpler to understand. More abstract and more concrete at the same time. Can you believe that? 
Filed under: Software Development
