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?