Architecture Antipatterns

Antipatterns

Cargo-Culting

Adopting processes, technologies or methodologies without understanding why and how they work, in the expectation to achieve the same benefits as the role model.

Domain Allergy

Some architects focus solely on technology, and consider the business problem domain to be somebody else’s boring problem.

Emotional Attachment

Very often, people involved in software development have certain preferences for frameworks, programming languages, or architectural approaches to which they cling, regardless of whether these preferences solve the current problem.

Horizontalism 🚧

this antipattern describes the division of applications into layers managed by individual teams, hindering the delivery of end-user value.

Infrastructure Ignorance 🚧

Ignoring the target environment, e.g. hardware performance, network topology and quality, power limitations during (initial) design or/and development.

Malignant Growth

Malignant growth describes the uncontrolled/badly managed growth of software systems, which leads to hardly maintainable and error prone systems.

Misapplied Genericity

Building a solution that is so generic that it ends up satisfying no one.

Never change a running system 🚧

“Never change a running system” - probably everybody working in IT has heard this sentence. This can be an anti-pattern when there is the “system” and nobody wants to touch it in fear of breaking something.

Over-Engineering

Systems have an unnecessary complex architecture. A simpler approach would be sufficient to fulfill the business requirements.

Over-Modularization

Software projects are divided into several modules at run time (e.g. services, lambdas) or build time (e.g. Maven modules, packages). This modularization has disadvantages compared to a modularization into fewer modules.

Under-Modularization

Software systems are divided into too few modules at run time (e.g. containers) or build time (e.g. Maven modules, packages). This modularization has disadvantages compared to a modularization into more modules.

Case Studies and Examples

App Development with a cross platform framework

When developing an App for an insurance company, the decision was made to build the app with a cross platform JavaScript framework.

Emotional Attachment to a DIY Middleware

A software development company for insurance software developed its own CORBA like middleware that integrated an ORB, DCOM services and a lot more nifty features.

Generic Product model for 12 insurance products

When developing a replacement for an old insurance system based on COBOL and hierarchical databases, a decision was made to use a generic product modeling system.

Global eCommerce B2B offering

An e-commerce service provider offered online stores to its clients. You could say the business it was in was literally providing e-commerce services

Life Insurance System with Ingenious Legacy Tech Stack

An insurance company developed a large and complex system to handle its life insurance policies.

Over-Configurability in a (huuuuge) eCommerce System

A huge organization developed and operated a system for selling special kinds of goods to their customers.

Splitting a checkout system into too many services

The project should replace the existing, monolithic and hard to scale checkout system with a modern, scalable and loosely coupled implementation.

Super-generic framework in logistics

A very large logistics company hired a consultancy which to implement a web shop for buying products of that logistics company.

The Financial Corp. App Productline for 100+ countries

A large financial corporation developed one mobile app product line for all their country entities around the world to provide self-service functionality for viewing and changing policy data.

Flattening the Hierarchy

Two huge domain classes represent all legal forms for companies, unions and foundations.

Use every service AWS offers

A data analytics platform - within a larger system - used basically every single AWS service which is available.

Using a BPMN engine for the store checkout process

As the existing store checkout system of an international commerce company got more complicated over time, the company’s management decided to initiate a project to implement a new system based on modern technologies.

Maintainers

Christian is a Consultant at INNOQ. He is a backend developer with a huge interest in architecture, distributed systems, software fault tolerance and algorithms.

Theo is a Senior Consultant at INNOQ and has been working in software development for 10+. He is passionate about cloud-native applications, distributed systems, domain-driven design, DevOps and agile software development.

Felix is a Senior Consultant at INNOQ. He likes to deal with IT security, test-driven development and the operation and further development of existing systems.

Andreas is Principal Software Architect at adesso SE. He is a JVM veteran, multilingual developer and pragmatic software architect.

Other Contributors (i.e. whith a PR for a typo) will be listed in our contributors list.