Architecture By Implication - An Assumption Anti-Pattern

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.

Avoiding The Anti-Pattern This anti-pattern boils down to communication. We avoid it by spending time designing and documenting our architectural approach. Next, share those documents with all of the team members. The result is every member can see what the plan is. Finally, they are confident that the rest of the team has the same understanding. This solution is simple. However, we will see that many anti-patterns are easily avoided similarly.