This is my learning note from the book Fundamentals of Software Architecture: An Engineering Approach written by Mark Richards and Neal Ford. All the contents are mostly distilled and copied from the book. I recommend you to buy this book to support the authors.
There is an art to making architecture decisions. Not surprisingly, several architecture anti-patterns emerge when making decisions as an architect. The programmer Andrew Koenig defines an anti-pattern as something that seems like a good idea when you begin, but leads you into trouble. Another definition of an anti-pattern is a repeatable process that produces negative results.
Covering Your Assets Anti-Pattern
The first anti-pattern to emerge when trying to make architecture decisions is the Covering Your Assets anti-pattern. This anti-pattern occurs when an architect avoids or defers making an architecture decision out of fear of making the wrong choice.
There are two ways to overcome this anti-pattern. The first is to wait until the last responsible moment to make an important architecture decision. The last responsible moment means waiting until you have enough information to justify and validate your decision, but not waiting so long that you hold up development teams or fall into the Analysis Paralysis anti-pattern. The second way to avoid this anti-pattern is to continually collaborate with development teams to ensure that the decision you made can be implemented as expected. This is vitally important because it is not feasible as an architect to possibly know every single detail about a particular technology and all the associated issues. By closely collaborating with development teams, the architect can respond quickly to a change in the architecture decision if issues occur.
Groundhog Day Anti-Pattern
Once an architect overcomes the Covering Your Assets anti-pattern and starts making decisions, a second anti-pattern emerges: the Groundhog Day anti-pattern. The Groundhog Day anti-pattern occurs when people don’t know why a decision was made, so it keeps getting discussed over and over and over.
The Groundhog Day anti-pattern occurs because once an architect makes an architecture decision, they fail to provide a justification for the decision (or a complete justification). When justifying architecture decisions it is important to provide both technical and business justifications for your decision.
When justifying architecture decisions it is important to provide both technical and business justifications for your decision. For example, an architect may make the decision to break apart a monolithic application into separate services to decouple the functional aspects of the application so that each part of the application uses fewer virtual machine resources and can be maintained and deployed separately. While this is a good example of a technical justification, what is missing is the business justification—in other words, why should the business pay for this architectural refactoring? A good business justification for this decision might be to deliver new business functionality faster, therefore improving time to market. Another might be to reduce the costs associated with the development and release of new features.
Reference Architecture Anti-Patterns list
The following AntiPatterns focus on some common problems and mistakes in the creation, implementation, and management of architecture. Lack of commonality between systems in terms of design and technology is the cause of frustrating inability to provide interoperability and reuse between related systems. Improved enterprise architecture planning can be used to align system developments.
| AntiPattern | Synopsis | Refactored Solution | |
| Architecture by Implication | System that is developed without a documented architecture; often due to overconfidence based on recent success. | Define architecture in terms of multiple viewpoints corresponding to system stakeholders. | |
| Autogenerated Stovepipe | Automatic generation of interfaces for distributed, large-scale systems from fine grain header files. | Separation of the architecture-level framework design from the subsystem-specific design is essential to manage complexity. | |
| Cover Your Assets | Document driven software processes often employ authors who list alternatives instead of making decisions. | Establish clear purposes and guidelines for documentation tasks; inspect the results for the value of documented decisions. | |
| Design by Committee | Committee designs are overly complex and lack a common architectural vision. | Proper facilitation and software development roles can lead to much more effective committee-based processes. | |
| Intellectual Violence | People sometimes use obscure references to esoteric papers, theories, and standards for intimidation or short-term gain. | Individuals and the organization should encourage and practice mutual education and mentoring. | |
| Jumble | Interface designs are an un-factored mixture of horizontal and vertical elements, leads to frequent interface changes, lack of reusability. | Partition architectural designs with respectto horizontal, vertical, and metadata elements. | |
| Reinvent the Wheel | Legacy systems with overlapping functionality that don’t interoperate. Every system built in isolation. | Use architecture mining and “best of breed” generalization to define a common interface, then object wrapping to integrate. | |
| Spaghetti Code | An ad hoc software structure makes it difficult to extend and optimize code. | Frequent code refactoring can improve software structure, support software maintenance, and iterative development. | |
| Stovepipe Enterprise | Uncoordinated software architectures lead to lack of adaptability, reuse, and interoperability. | Use enterprise architecture planning to coordinate system conventions, reuse, and interoperability. | |
| Stovepipe System | Ad hoc integration solutions and lack of abstraction lead to brittle, un-maintainable architectures | Proper use of abstraction, subsystem facades, and metadata leads to adaptable systems. | |
| Swiss Army Knife | Over-design of interfaces leads to objects with numerous methods that try to anticipate every possible need — leads to designs that are difficult to comprehend, utilize, and debug, as well as implementation dependencies. | Defining a clear purpose for the component and properly abstracting the interface is essential to managing complexity. | |
| The Grand Old Duke of York | Four out of Five developers cannot define good abstractions; this leads to excess complexity. | Project teams should have designated architects who are abstractionists, i.e. possess the architecture instinct. | |
| Vendor Lock-In | Proprietary, product-dependent architectures do not manage complexity and lead to a loss of control of the architecture and maintenance costs. | Providing an isolation layer between product-dependent interfaces and the majority of application software enables management of complexity and architecture. | |
| Warm Bodies | Large software project teams make for ineffective organizations and overruns. Heroic programmers are essential. | Small projects (4 people in 4 months) are much more likely to produce software success. | |
| Wolf Ticket | A technology is assumed to have positive qualities due to its open systems packaging or claimed standards compliance. Few standards have test suites (< 6%) and few products are actually tested for conformance. | Discover the real truth behind the claims. Question authority. Assume nothing. Shift the burden of proof to the marketing organization. Talk directly to the technical product experts and developers. | |
Transforming Leadership 
2 thoughts on “[Summary] – Fundamentals of Software Architecture An Engineering Approach – Part 8: Architecture Decision Anti-Patterns”