Have you not ever seen one of this super duper cool architecture diagrams? You know, the ones with dozens of colors and boxes, the ones that when you read them, you think: “WTF is this!?”
Not all architecture diagrams are like this, not at all, an architecture diagram is supposed to explain what are the different high level components of the application and how they interact with each other, but some times they don’t, and when this happens, you just have to believe they will just work as if by magic, that’s why I like to call this: “Magic architecture”.
Magic architecture, is bad, really bad, and is even worse when it comes from some other team in your company, because it will be more difficult to change.
How can we detect magic architecture?
As for many other phases in software development, the main indicator for magic architecture is WTFs/minute, but because this is quite a subjective measure, you may find the following useful to objectively determine if your project suffers from magic architecture.
All are implementation details.
Here is a common scenario: You receive an email from the architect with the latest architecture diagram, you open it and you see only 3 boxes: the input manager, the process manager and the output manager, you obviously think WTF!! So you just pick the phone and call the architect for more details, and the architect tells you: “oh, what is outside of the diagram are just implementation details”.
While the example I used is an exaggeration, it serves the purpose of showing how ridiculous is to draw something which is so vague that it actually doesn’t help to build the project at all.
Forgetting what’s the purpose of the architecture.
You receive an architecture diagram for your Hello world application, you open it, and to your surprise, the architect has included way too much, there is a messaging service, an authentication service, a database… When this happens, is usually because some architects are eager to show how “cool” their architectures can be, if so, is good to remind that the architecture has to provide with a structure to support absolutely all the product requirements, (well, at least the most important), AND no more than that.
Not doing an architecture diagram, but a shopping list.
This is one of the funniest architectures you can find, instead of showing the different components of the application, you get a list of the different tools/technologies to be used, like: “there will be a Websphere server which will read messages from Active MQ, depending on the messages it will store some information in Oracle, we will log with log4j”. A good architecture shouldn’t be tied with any technology or tool (this is actually quite hard to accomplish 100%, but to break this rule of thumb you should have a very good reason).
Before you leave…
Remember to consider if you need an architecture, probably if your application is not big, it won’t be necessary, but if it is, and you have a magic architecture, well you better expend some time trying to convince the stakeholders to change it.