However, such values are somewhat abstract, making it a challenge to apply to real-world scenarios. I then proposed eight principles that build on the values and provide practical guidelines for applying them.
I now want to consider the practice of architecture, in particular, those practices that are counter-productive. Here are nine anti-patterns of architecture.
30,000 feet and climbing.
While architecture is all about the big picture, it still needs to have enough detail to provide guidance for those who have to deliver solutions based on the architecture.
An architecture without sufficient detail leaves significant issues to be filled in by the designers and developers, typically while working on low-level detail. At this point, they will struggle to keep sight of the big picture and any decisions made will reflect this. Consequently, we start losing the benefits that we are trying to achieve by having the architecture.
This often comes about because of a lack of just-in-time design and communication.
If the architect has got a wrong understanding of the domain, the architecture will have little in common with what the development team are working on. In this case, the designers and developers will ignore the architecture and do their own thing. As with the previous anti-pattern, they will probably lose the big picture and thus any benefits that might have been possible with a proper architecture.
Not involving everyone and a lack of communication can cause this.
An architecture that is too low-level and stuck in the mud may unnecessarily constrain the solution.
While doing the detailed modelling, the designers and developers use the architecture to keep sight of the big picture. If we do detailed modelling in architecture, we are likely to lose sight of the big picture ourselves, rendering the architecture useless.
This can be the result of forgetting simplicity.
We don’t need all the bells and whistles. Simplicity is preferred to complexity and creates more robust and maintainable solutions.
The documentation should be lean and mean, containing just enough information to fulfil its purpose. Going beyond this point requires more effort in creation and maintenance, is going to be harder to read and understand, and is less likely to be kept up-to-date. Such effort is unnecessary and thus wasted time.
This is the result of forgetting simplicity.
Industry terms are a powerful way of conveying a lot of information with the use of a simple term or phrase. However, it can also be used to mask a lack of understanding (e.g. see the pointy-haired boss), sounding good but lacking the detail that the development team needs.
A lack of communication and just-in-time design can result in this situation.
Ivory tower architecture.
Architects who work solo, even disallowing questions and involvement, risk creating an architecture that seems good in theory but falls apart when someone tries to apply it.
Such an approach relies on the assumption that everything can be known at the start and the architect knows it all. Without further guidance from the architects, the designers and developers will adapt as they go, potentially losing sight of the big picture and the benefits that the architecture should provide.
This typically is caused by not involving everyone and not learning from the past.
The risk is that the architecture is never communicated because “it’s not ready yet.” Remember that the architecture evolves over time and we should provide advice when it is needed.</>
The documentation should be just good enough. It should be sufficiently accurate, consistent and detailed. It doesn’t need to be perfect. The focus should be on content over presentation.
A wrong understanding of quality and a lack of just-in-time design can lead to this situation.
Decisions should be made in the best interests of the organisation, not the architect. For example, “What will look good on my CV?” This leads to whatever is the current cool technology being used, despite not being necessary or even appropriate. Some architects go for what is easy or what will make them look good, overriding the requirements of the project and the needs of the stakeholders.
This is a result of forgetting that architecture is about delivering working solutions.
Tester can’t draw the high-level design.
While the tester shouldn’t be expected to know the architecture in its entirety, they should at least understand the key points and drivers. If they don’t it may indicate a wider problem with communicating the architecture to the whole team, including the designers and developers who are supposed to be following and implementing it. Those who don’t know or understand the architecture will do their own thing, and probably introduce technical debt.
This also has a direct impact on the testers themselves, because if they don’t understand the high-level design, they won’t be able to identify the potential problem areas that they need to test. Their testing will be incomplete and we won’t be able to have the same degree of confidence in the quality of the delivered solution that we otherwise might have.
A lack of communication or focus on quality can lead to this situation.
In my earlier posts, I described five values that should drive our behaviour and eight principles to provide guidelines to help us apply those values to our work. The nine anti-patterns I have described here are common problems that I have seen across many organisations. In the next (and final) post in this series, I will explain why I have developed this approach to architecture.
Post by Colin Garlick