The series switches gears to look at anti-patterns. We start with the mother of all anti-patterns, architecture by implication. Any time we have a pattern that includes assumptions, success is a challenge. Looking ahead, the next several episodes will explore familiar anti-pattern names. We will find that many coding anti-patterns can also be applied to architecture. Likewise, these are ways to approach enterprise solutions.
Architecture By Implication Defined
This anti-pattern is wrong in the implication part of it. Any architecture that involves implications and undocumented features is an anti-pattern. The core challenge is that pieces of our architecture are commonly known. That familiarity breeds a sense of “we all know this.” However, it is a dangerous assumption to make.
Our experience and understanding of a pattern or approach are not always the same as our teammates. Thus, we may think everyone is on the “same page” when multiple views are involved. That can be either the situation or the approach we are taking.
The Anti-Pattern In Action
Lack of documentation and minimal design often lead to this anti-pattern. It also occurs more frequently in larger teams than in smaller ones. A group of two or three people is more likely to be synchronized on the solution approach. Likewise, communication is more manageable and better with fewer people involved. Once the team grows to multiple teams or groups, documentation becomes critical. It is the first step in ensuring everyone has the same understanding of the approach.
A vital factor of this anti-pattern is point-of-view. When different groups look at a solution, they may have different views of its construction. That leads to gaps, blind spots, and incorrect assumptions. For example, look at the classic Volkswagon Beetle. It is easy to assume the engine is in the front of the car. However, it is in the rear. Think of how many problems can be caused by such an incorrect assumption.
