| Architecture By Implication |
|
This AntiPattern is characterized by the lack of architecture specifications for a system under development. Usually, the architects responsible for the project have experience with previous system construction, and therefore assume that documentation is unnecessary. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/architecture-by-implication |
| Autogenerated Stovepipe |
|
This AntiPattern occurs when migrating an existing software system to a distributed infrastructure. An Autogenerated Stovepipe arises when converting the existing software interfaces to distributed interfaces. If the same design is used for distributed computing, a number of problems emerge. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/autogenerated-stovepipe |
| Backend Fixation |
|
Considering the frontend a less important detail, putting too much emphasis on the backend part of a system |
behavior |
Micro |
|
|
|
|
|
|
|
|
|
|
| Big Ball of Mud |
|
A big ball of mud is a software system that lacks a perceivable architecture. |
structure |
|
Under-Modularization |
Jumble |
|
|
|
|
|
|
|
http://laputan.org/mud/ |
| Calls in Series |
|
Just as bulbs in the old serially wired Christmas Tree lights would cause an entire string to fail, so does any service failure cause the entire call stream to fail. |
|
|
|
Christmas Tree Light Anti-Pattern, Microservice Calls in Series Anti-Pattern |
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-calls-in-series-the-xmas-tree-light-anti-pattern |
| Conference driven development |
|
Your developers come back from a conference and have learned about many new cool tools or ways to do things. Now they need to try them in their daily project, regardless if they benefit the project or not. |
|
|
|
|
|
|
|
|
|
|
|
|
| Cover Your Assets |
|
Document-driven software processes often produce less-than-useful requirements and specifications because the authors evade making important decisions. In order to avoid making a mistake, the authors take a safer course and elaborate upon alternatives. The resulting documents are voluminous and become an enigma; there is no useful abstraction of the contents that convey the authors' intent. Unfortunate readers, who may have contractual obligations dependent upon the text, must pore through the mind-numbing details. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/cover-your-assets |
| Data Fan Out |
|
Data Fan Out, the topic of this microservice anti-pattern, exists when a service relies on two or more persistence engines with categorically unique data, or categorically similar data that is not meant to be processed in parallel. “Categorically Unique” means that the data is in no way related. |
|
|
|
|
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-data-fan-out |
| Data Fuse |
|
The Data Fuse, the topic of this microservice anti-pattern, exists when two or more unique services share a commonly deployed data store. This data store can be any persistence solution from physical file services, to a common storage area network, to relational (ACID) or NoSQL (BASE) databases. When the shared data solution “C” fails, service A and B fail as well. Similarly, when data solution “C” becomes slow, slowness under high demand propagates to services A and B. |
|
|
|
|
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-data-fuse |
| Decoupling Illusion |
|
Functional changes required by different stakeholders require changes to overlapping services |
structure |
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Design By Committee |
|
A complex software design is the product of a committee process. It has so many features and variations that it is infeasible for any group of developers to realize the specifications in a reasonable time frame. |
|
|
|
Gold Plating, Standards Disease, Make Everybody Happy, Political Party |
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/design-by-committee |
| Distributed Monolith |
|
System made up of arbitrarily sized, tightly coupled modules communicating over network interfaces |
structure |
|
Over-Modularization |
Microservices Gone Bad |
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Domain-last Approach |
|
Major driver for organizational structure is roles and technical capabilities, not business domain |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Entity Service |
|
Services boundaries are chosen to encapsulate “wide” business entities |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Frontend Monolith |
|
Anemic services joined by a monolithic frontend application that contains most of the business logic |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Golf Course Peer Pressure |
|
Introducing solutions because they are part of something that has been successfully applied at a competitor or business partner |
behavior |
Micro,Macro,Domain |
Cargo-Culting |
|
|
|
|
|
|
|
|
|
| Grand Old Duke of York |
|
Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts (whom we call implementationists) Abstractionists are comfortable discussing software design concepts without delving into implementation details. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/the-grand-old-duke-of-york |
| Gravitational Feature Pull |
|
Wrongly assuming responsibilities because the responsible party won’t, or because it’s easier to just add here than where it makes sense |
|
|
|
wrong-end fixation (in Anlehnung an Backend Fixation) |
|
|
|
|
|
|
|
|
| Innovation Addiction |
|
Trying to add too many new things and ignoring the value of mature approaches |
behavior |
Micro,Macro |
|
|
|
|
|
|
|
|
|
|
| Jumble |
|
When horizontal and vertical design elements are intermixed, an unstable architecture results. Vertical design elements are dependent upon the individual application and specific software implementations. Horizontal design elements are those that are common across applications and specific implementations. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/jumble |
| Micro Platform |
|
Standardization of service-internal runtime aspects |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Network Ignorance |
|
Treating the existence of a network between components as an implementation detail, yielding an error-prone solution with bad performance |
behavior |
Micro,Macro |
|
|
|
|
|
|
|
|
|
|
| Over-Isolation |
|
Creating pseudo-independent building blocks that have to interact constantly, creating unneeded and useless overhead |
|
Micro,Macro |
Over-Modularization |
|
|
|
|
|
|
|
|
|
| Pattern Mis-Transfer |
|
Applying useful patterns or architectural styles to a context where there not usefully applicable |
|
Micro,Macro |
Knowledge Tunnelling |
|
|
|
|
|
|
|
|
|
| Reinvent The Wheel |
|
Custom software systems are built from the ground up, even though several systems with overlapping functionality exist. The software process assumes "greenfield" (build from scratch) development of a single system. Because top-down analysis and design lead to new architectures and custom software, software reuse is limited and interoperability is accommodated after the fact. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/reinvent-the-wheel |
| Service Fan Out |
|
Fan Out, the topic of this microservice anti-pattern, exists when one service either serves as a proxy to two or more downstream services, or serves as an integration of two subsequent service calls. Any of the services (the proxy/integration service “A”, or constituent services “B” and “C”) can cause a failure of all services. When service A fails, service B and C clearly can’t be called. If either service B or C fails or becomes slow, they can affect service A by tying up communication ports. Ultimately, under high call volume, service A may become unavailable due to problems with either B or C. |
|
|
|
|
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-service-fan-out |
| Service Fuse |
|
The Service Fuse, the topic of this microservice anti-pattern, exists when two or more unique services share a commonly deployed service pool. When the shared service “C” fails, service A and B fail as well. Similarly, when service “C” becomes slow, slowness under high demand propagates to services A and B. |
|
|
|
|
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-service-fuse |
| Service Mesh |
|
Microservice Anti-Pattern: A “Mesh” is any solution that violates repeatedly the anti-patterns of “tree lights”, “fuses” or “fan out” |
|
|
|
|
|
|
|
|
|
|
|
https://akfpartners.com/growth-blog/microservice-anti-pattern-service-mesh |
| Stovepipe Enterprise |
|
Multiple systems within an enterprise are designed independently at every level. Lack of commonality inhibits interoperability between systems, prevents reuse, and drives up cost; in addition, reinvented system architecture and services lack quality structure supporting adaptability. At the lowest level are the standards and guidelines. These work like architectural building codes and zoning laws across enterprise systems. The next level up in the hierarchy is the operating environment , which comprises infrastructure and object services. The top two layers include the value-added functional services and the mission-specific services. By selecting and defining all of these technologies independently, Stovepipe Enterprises "create islands of automation," isolated from the rest of the enterprise. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/stovepipe-enterprise |
| Stovepipe System |
|
The Stovepipe System AntiPattern is the single-system analogy of Stovepipe Enterprise, which involves a lack of coordination and planning across a set of systems. The Stovepipe System AntiPattern addresses how the subsystems are coordinated within a single system. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/stovepipe-system |
| Swiss Army Knife |
|
A Swiss Army Knife, also known as Kitchen Sink, is an excessively complex class interface. The designer attempts to provide for all possible uses of the class. In the attempt, he or she adds a large number of interface signatures in a futile attempt to meet all possible needs. |
|
|
|
Kitchen Sink |
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/swiss-army-knife |
| Uncreative Chaos |
|
Having too few rules and guidelines so that everything ends up being different without any positive benefit to it |
|
Macro |
|
|
|
|
|
|
|
|
|
|
| Unhealthy Ecosystem Affinity |
|
Becoming too attached to one particular solution approach so that everything is always solved with its associated tools, methods, and the community supporting it, even when it is not a good match for the problem at hand. |
behavior |
Micro,Macro |
|
|
|
|
|
|
|
Over-Configurability in eCommerce |
|
|
| Unjustified Re-Use |
|
Extremely generic utility functions to reduce logic redundancy |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Vendor Lock-In |
|
A software project adopts a product technology and becomes completely dependent upon the vendor's implementation. When upgrades are done, software changes and interoperability problems occur, and continuous maintenance is required to keep the system running. In addition, expected new product features are often delayed, causing schedule slips and an inability to complete desired application software features. |
|
|
Vendor-driven Architecture |
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/vendor-lock-in |
| Vendor-driven Architecture |
|
Relying too much on a vendor so that every architecture is more like a shopping list |
behavior |
Micro,Macro |
Golf Course Peer Pressure,Vendor Lock-In |
buzzword compatibility, Vendor Lock In |
|
|
|
|
|
Use every service AWS offers |
|
|
| Warm Bodies |
|
Having too many developers in one project. Adding more developers to an ongoing project. |
Organizational |
|
|
Deadwood, Body Shop, Seat Warmers, Mythical Man-Month |
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/warm-bodies |
| Wolf Ticket |
|
A Wolf Ticket is a product that claims openness and conformance to standards that have no enforceable meaning. The products are delivered with proprietary interfaces that may vary significantly from the published standard. |
|
|
|
|
|
|
|
|
|
|
|
https://sourcemaking.com/antipatterns/wolf-ticket |
| Cargo-Culting |
done |
Mimicking architectural approaches that have been applied by some role model organization, expecting to achieve similar success |
behavior |
Micro,Macro |
Golf Course Peer Pressure,Pattern Mis-Transfer |
Conference-driven Architecture |
|
|
|
|
|
"Using a BPMN Tool for everything in the checkout process, because a competitor uses it too" |
Lisa Maria Moritz,Tobias Erdle |
|
| Domain Allergy |
done |
Being unwilling to understand the business domain of the problem space, fleeing into technology problems instead |
behavior |
Domain |
|
|
|
|
|
|
|
"Two huge domain classes represent all legal forms for companies, unions and foundations" |
|
|
| Emotional Misattachment |
done |
Falling in love with your own framework/library/tool/method so that you can not let go even when something superior becomes available or is a better match, a.k.a. sunk cost fallacy a.k.a. Concorde effect |
|
|
|
|
|
|
|
|
|
|
|
|
| behavior |
Micro,Macro |
Knowledge Tunnelling |
|
|
|
|
|
|
The Insurance App Productline for 100+ countries,"Using a BPMN Tool for everything in the checkout process, because a competitor uses it too" |
|
|
|
|
|
| Misapplied Genericity |
done |
Building a solution that is so generic that it ends up satisfying no one |
structure |
Micro,Macro,Domain |
Configurability Fallacy |
|
|
|
|
|
|
Super-generic framework in logistics,The Insurance App Productline for 100+ countries |
|
|
| Never change a running system |
done |
|
behavior |
|
|
|
|
|
|
|
|
|
|
|
| Over-Engineering |
done |
Using an architectural approach that is way too complicated for the problem at hand, possibly adding way too many technology choices for their own sake |
structure |
Micro,Macro |
|
|
|
|
|
|
|
Super-generic framework in logistics,Use CQRS for almost every problem,"Using a BPMN Tool for everything in the checkout process, because a competitor uses it too" |
|
|
| Over-Modularization |
done |
Cutting things into too many too small parts |
structure |
Domain,Micro |
Under-Modularization |
|
|
|
|
|
|
|
|
|
| Under-Modularization |
done |
Having too few chunks that are too big |
structure |
Domain,Micro |
Over-Modularization |
|
|
|
|
|
|
"Two huge domain classes represent all legal forms for companies, unions and foundations" |
|
|
| Anemic Service |
todo |
Services designed to solely encapsulate data, with logic left to the caller |
|
|
|
|
|
|
|
|
|
|
|
https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns |
| Centralization Bottleneck |
todo |
Creating a bottleneck at development time, deployment time or run time by an architectural choice that requires centralized responsibility |
Organizational |
Micro,Macro,Domain |
|
|
|
|
|
|
|
The Insurance App Productline for 100+ countries,"Using a BPMN Tool for everything in the checkout process, because a competitor uses it too",Life insurance system with ingenious legacy tech stack |
|
|
| Configurability Fallacy |
todo |
Assuming making everything configurable is easier than hard-coding things, missing that configuration that is too complicated is programming in disguise |
|
Micro,Macro |
|
|
|
|
|
|
|
Global eCommerce B2B offering,Over-Configurability in eCommerce |
Stefan Tilkov,Gernot Starke |
|
| Detail Exposure |
todo |
Violation the principle of information hiding by exposing private details to the outside world, creating an unnecessarily strong dependency |
structure |
Macro |
|
|
|
|
|
|
|
"Two huge domain classes represent all legal forms for companies, unions and foundations" |
|
|
| Failing Rigidity |
todo |
Creating a set of rigid rules that inhibit development so much developers find ways around them |
|
Micro,Macro |
|
|
|
|
|
|
|
Life insurance system with ingenious legacy tech stack |
|
|
| Horizontalism |
todo |
Architecting the solution so that indivual teams can work on different layers of the application, but no team can deliver actual end user value on its own |
structure |
Micro |
Layerism,Generic Conway Failure |
|
|
|
|
|
|
The Insurance App Productline for 100+ countries |
|
|
| Knowledge Tunnelling |
todo |
Trying to apply an approach or method that is idiomatic in an environment you know well to an environment you are new to, where it is not a good match |
behavior |
Micro,Macro |
|
|
|
|
|
|
|
Life insurance system with ingenious legacy tech stack |
|
|
| Abstraction Bias |
will not do |
Over-abstracting everything into more and more generic abstractions, over-complicating things and yielding no additional value |
structure |
Micro,Domain |
Misapplied Genericity,Layerism |
|
|
|
|
|
|
Super-generic framework in logistics |
|
|
| Generic Conway Failure |
will not do |
Failing to consider the interplay between architecture and organization (communication) structure |
behavior |
Domain |
|
|
|
|
|
|
|
The Insurance App Productline for 100+ countries,Over-Configurability in eCommerce |
|
|
| Layerism |
will not do |
Having too many layers out of an exaggerated need to isolate oneself against dependencies |
structure |
Micro |
|
|
|
|
|
|
|
|
|
|