It is common for developers to start coding without a formalised architecture, and gravitate to the traditional layered (n-tier) architecture pattern (see Conway’s Law).

The software n-tier architecture pattern deals in implicit layers,
by organising source code modules into namespaces (packages in java).
The layers are easily violated, resulting in disorganised modules that lack a clear separation of concerns – eventually devolving into the big-ball of mud anti-pattern, characterised by tightly-coupled, brittle code.

Lacking an architecture, it is hard to determine the architectural characteristics of a system:

• is it scalable?
• how is its performance?
• how maintainable is it?
• and how responsive?

Lacking an architecture, one would need to fully understand the inner working of every component and module.

This is where architectural patterns play a role. A pattern has an associated set of architectural characteristics. Some are scalable. Others support agility. Patterns also have trade-offs (something often ignored). You need to choose right.

References

[Richards2015]: Mark Richards, ‘Software Architecture Patterns’, O’Reilly: 2015