Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

When discussing different architectural styles such as 3-tier, CQRS & co. you hear a variety of reasons why X is better than Y. Besides the fact that better is never absolute but depends on the actual context, the arguments often are nothing but gut feelings (or intuition, to use a more professionally sounding word).

Now I was wondering how to actually score a software architecture professionally. I guess that I am not the first person on this planet who thinks about evaluating different architectures and comparing them. So what should I watch out for to get a feeling which architecture is better or worse suited for my specific case?

This morning I though about it for a while and I came up with a variety of questions that help me. So far I have got the following items on my list:

  • How testable is an architecture (tightly integrated systems are harder to test than loosely coupled ones, and some architecture support their own style of testing)?
  • How much decoupling and cohesion does an architecture favor (decoupling is usually better than tight coupling, strong cohesion is usually better than loose cohesion)?
  • How well does it scale (it should work in the small, but without any changes as well in the large)?
  • How does the architecture influence performance (some architectural styles may come with performance benefits / penalties in specific areas)?
  • How large are the things I need to change when requirements change (the less I need to change the better)?
  • How extendable is it (an extendable system has pre-defined extension points and concepts for extension)?
  • How well does it integrate with 3rd-party software (a good architecture is open to being connected to other system)?
  • How does it respond to faults (fault tolerance and error handling are ideally already conceptually integrated)?
  • How reliable is it (the system should survive outages, crashes, …)?
  • How does the architecture behave with respect to the CAP theorem (at least if it's a distributed application, you may have a variety of focuses)?
  • How understandable is it (the less I need to explain to someone new to the architecture, the better, in other words: strive for simplicity)?
  • How well is it documented (a well-known and established solution is better than a newcomer)?
  • How big is the community around it (a large community makes it easier to find people to work with, trainers, …)?

What do you think of this list? Are these questions reasonable? What is missing? Or is my approach completely wrong?

share|improve this question

closed as too broad by gnat, gbjbaanb, GlenH7, Kilian Foth, MichaelT Jan 18 '14 at 1:50

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

Those are nice questions. Now think about how would you answer them. Because most of them don't really have metric you can follow. –  Euphoric Jan 15 '14 at 8:31
Just count the number of code lines. That's always been a reliable system in the past. –  Neil Jan 15 '14 at 9:21
Counting LOC doesn't help at all, especially not if you're thinking about which architecture to use before you start coding. –  Golo Roden Jan 15 '14 at 9:27

3 Answers 3

An extremely important factor is the team that's going to implement the architecture.

If the team is uncomfortable, unfamiliar or "opinionated" with the technologies and techniques involved in the architecture, the resulting friction will impact all other areas. Typically, teams and people don't have enough time to adopt more than 1 or 2 new technologies in a single project's duration.

As an example, a team that's uncomfortable with RDBMSs isn't going to use optimistic concurrency or they will probably use hard-coded SQL statements, or use an ORM with horrible mappings, impacting scalability, testablitity and ease-of-mind for all involved.

A team with Java background will probalby design a less-than-optimal .NET solution, even if the architecture is spelled out in the finest detail possible.

In 2006 I had the wonderful idea of using a composite UI architecture .NET, without understanding that 2 of the 4 members of the new team had only ever worked in monolithic VB6 applications. And I added Scrum to the mix, when they've only ever worked in a bureaucratic waterfall environment.

share|improve this answer
That's right, but let's suppose that you can choose the appropriate team for a given architecture, and that you do not have to work with a given team (which may be hostile to the architecture chosen). –  Golo Roden Jan 15 '14 at 9:01
You asked what's missing. The development team requirements are an important part of any architecture. So are the support team requirements - who is going to support the system, what should they know or what do they know? Your system will be supported by a customer's existing support team and they won't be happy if they have to learn a ton of new stuff or perform a ton of manual maintenance –  Panagiotis Kanavos Jan 15 '14 at 9:27
I agree basically a team will struggle building things in ways they don't understand or like, but once a particular strategy is chosen, it can still be evaluated. It would be difficult to evaluate every single potential strategy, but a given team may narrow it down to a few. –  JeffO Jan 15 '14 at 14:09

Problem with those kind of questions, is that you cannot properly measure them. For those questions to be usable in any way, you need some kind of metric you can create from code. And for that you need solid definition of whatever you are asking. What you mean by testable, what do you mean by scaling, what do you mean extensible? And how do you measure all of those.

Yes, people did try creating such metrics and comparing different systems with them. But sooner or later they realize that those metrics never really work. Or worse, they drive the structure of the system in completely undesirable way, because developers are trying to cheat this metric.

Obligatory : http://www.osnews.com/story/19266/WTFs_m

share|improve this answer
These questions are what architecture is about. Architectural questions can't be measured as a rule (no qualitative question can). Actually, recent research into code metrics shows that most code metrics are strongly correlated to lines of code - they are nothing more than estimators for the LOCs. –  Panagiotis Kanavos Jan 15 '14 at 8:45
Hm, well, perhaps I'm not looking for a perfect metric, perhaps it just helps to be sure that you have thought about all the relevant areas. And for that, I guess, questions like the ones above are helpful. Hence, a little rephrase: You already said (in your comment) that these questions are quite nice, but do you think there's anything missing? If so, what? Apart from that, definitely true what you wrote :-) –  Golo Roden Jan 15 '14 at 8:47

There are existing techniques designed specifically to analyze software architectures and determine how well a given architecture meets a set of needs. An example of this would be the Software Architecture Tradeoff Analysis Method (for sofware systems) and the System Architecture Tradeoff Analysis Method (for multidisciplinary systems), developed by the Software Engineering Institute.

Unfortunately, an in-depth explanation of these methods is beyond the scope of a single answer, but the SEI does provide a number of resources that may be helpful if you follow the links. The purpose of these methods are to examine risks associated with the architecture of a system. They require knowing which quality attributes and business drivers are important to stakeholders and being able to create scenarios to analyze the approaches, all of which do require technical and domain knowledge.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.