Ein Monolith ist eine Softwareanwendung, die als eine einzige, eng gekoppelte Einheit gebaut, deployed und betrieben wird. Verschiedene fachliche Module teilen sich Speicher, Datenmodell und Laufzeit, was eine sehr direkte Kommunikation zwischen ihnen ermöglicht.
Klassische Beispiele sind ältere ERP-, CRM- oder Branchenlösungen. Auch viele moderne Anwendungen starten bewusst monolithisch, etwa basierend auf ASP.NET, Spring Boot oder Django, weil ein einziger Build, ein einziges Deployment und ein einziges Datenmodell die Entwicklung vereinfachen.
Einsatzzweck eines Monolithen ist Einfachheit – sowohl in der Entwicklung als auch im Betrieb. Solange Anwendungsgröße und Teamgröße überschaubar bleiben, sind Monolithen effizient. Sie geraten erst dann unter Druck, wenn Skalierungs-, Verfügbarkeits- oder Time-to-Market-Anforderungen die Grenzen einer einzelnen Codebasis sprengen.
Der Begriff wurde insbesondere im Kontext der Microservices-Diskussion ab 2014 (Adrian Cockcroft, James Lewis, Martin Fowler) populär – meist als Gegenbegriff. Gleichzeitig betont die "Monolith First"-Empfehlung Fowlers, dass die meisten Microservice-Architekturen aus erfolgreichen Monolithen heraus entstehen, nicht von Beginn an.
Eine besondere Variante ist der "Big Ball of Mud" – ein über Jahre unstrukturiert gewachsener Monolith ohne erkennbare Architektur. Brian Foote und Joseph Yoder warnen im gleichnamigen Aufsatz von 1997 davor, dass viele tatsächliche Architekturen genau so aussehen – unabhängig von den Diagrammen, die man Kunden zeigt.