Architektur-Komplexität jenseits des Hypes

Warum Qualifikation, Nachhaltigkeit und Verantwortung den Unterschied machen

In meinem vorherigen Beitrag „Jenseits der Unendlichkeit: Der Standish Chaos Report 2020 und die Notwendigkeit eines Paradigmenwechsels in der Softwareentwicklung“ habe ich bereits gezeigt, wie starre Prozesse und die Illusion der vollständigen Planbarkeit Projekte zum Scheitern bringen können. Dort hob ich hervor, dass Vertrauen, Teamdynamik und emotionale Intelligenz wichtiger sind als jedes noch so schicke Tool, das uns verspricht, die Arbeit leichter und schneller zu erledigen. Zum Earth Day möchte ich auf die Verantwortung eingehen, die wir als Entwickler*innen haben, und darauf aufbauend mit einigen Mythen aufräumen. Eines davon ist sicher, dass Low‑Code / No‑Code und KI-gestützte Plattformen allein durch visuelle Editoren und smarte Algorithmen die inhärente Komplexität großer Softwareprojekte beherrschen könnten. Softwareentwicklung ist komplex und chaotisch.

Gleichzeitig muss man sich immer wieder bewusst machen: Lernen ist keine Konsumhandlung. Die Vorstellung, komplexe Systementwicklung lasse sich über ein Fünf-Minuten-Video oder ein No-Code-Click erlernen, ist schlicht gefährlich. Lernen ist ein Prozess, der Zeit, Fehler, Reflexion und Wiederholung erfordert. Entwickler*innen brauchen Wissenshunger und die Fähigkeit, komplexe Systeme nicht nur zu benutzen, sondern sie in ihren Tiefen zu verstehen. Der vielzitierte Fachkräftemangel ist daher in Wahrheit oft ein Qualifikationsmangel – es fehlen nicht Menschen, sondern Menschen mit Tiefe.

Und genau hier – im Jahr 2025 – wird deutlich, dass Qualifikation auch Umweltschutz bedeutet. Wer Systeme ganzheitlich denkt, achtet nicht nur auf schnelle Umsetzbarkeit und Komfort beim Entwickeln, sondern auch auf Nachhaltigkeit: auf Rechenzeit, Energieverbrauch, technische Langlebigkeit – und damit auf die ökologischen Kosten unseres Handeln. Zum Earth Day 2025, der unter dem Motto „Du machst den Unterschied“ steht, wird einmal mehr klar, dass auch wir als Entwickler*innen und Architekten*innen Verantwortung tragen – für unseren Code, für die Infrastruktur, die wir mitgestalten, und damit letztlich für den Planeten, auf dem wir leben.

Ein interdisziplinäres, gut ausgebildetes und motiviertes Team mit einer klaren Architekturvision und einer progressiven Teamleitung, der sich nicht als Boss versteht, sondern als Coach agiert und für das Team arbeitet, die Kommunikation fördert und Freiräume erzeugt, und schnelle Entscheidungen trifft, kann oft deutlich effizienter agieren als riesige Projektorganisationen mit 150 und mehr Mitarbeitenden. Ein kleines Team mit zehn fokussierten Entwickler*innen, das sein System iterativ weiterentwickelt, ist häufig nicht nur schneller, sondern liefert auch qualitativ hochwertigere und ressourcenschonendere Ergebnisse – ganz ohne schwerfällige Prozesse oder bürokratische Reibungsverluste.

Wichtig sind hier auch schnelle, selbstbewusste Entscheidungen, wie der vorletzte Standish CHAOS Report: "Decision Latency Theory – It’s All About the Interval" zeigt. Ein Beispiel aus meiner Erfahrung: In einem Inhouse-Versicherungssystem konnten für einzelne, alte Tarife im Großrechnersystem nicht abgebildet werden. Dieses wurde durch ein kleines, fokussiertes Team in nur 8 Monaten in eine modulare, C++-basierte Server-Architektur überführt – es wurde mit weniger Teammitgliedern umgesetzt als ursprünglich geplant, mit signifikant besserer Performance – und damit auch einem kleineren ökologischen Fußabdruck. Das war möglich, da sich das Team auch räumlich außerhalb der Strukturen der Versicherung befand, und ein Vorstand dem Ansatz vertraute, und das Team abschottete. Und nur weniger Monate später konnten in dem System alle Tarife gerechnet werden. Parallel wurden neue Modelle zur Speicherung eingeführt, ohne das das ganze System migriert werden musste, so dass auch neuartige Tarife umgesetzt werden konnten. Und in einer späteren Ausbaustufe folgte in wenigen Wochen ein eigenständiges, kreatives In- und Exkassosystem auf Basis einer Finanzbuchhaltung. Dabei hat sich die Grundarchitektur evolutionär weiterentwickelt.

Verantwortung für Umwelt und Nachhaltigkeit

Ich habe seit 15 Jahren in verschiedenen Vorträgen und Veröffentlichungen immer wieder die Verantwortung angesprochen, die wir als Entwickler*innen für unsere Umwelt haben. Der 22. April ist der World Earth Day, dieses Jahr steht auf der Internetseite die Frage: "Who says you can’t change the world?" als Eyecatcher. Leider höre ich in der IT immer wieder Aussagen, dass die jeweils eigene Software keinen "(so großen)" Einfluss hat. Das ist aber des zentrale Problem bei Nachhaltigkeit, niemand fühlt sich verantwortlich, obwohl alle sie befürworten. So lesen wir ja auch oft, dass Deutschland mit knapp 2% der Emissionen kaum eine Rolle spielt, und deshalb keine Bemühungen notwendig sind, andere doch erst einmal beginnen sollten. Wieder der Finger, der auf andere zeigt. Aber in der Veränderung zu mehr Nachhaltigkeit befindet sich eine Chance, aber wir beleuchten anstatt diese Chancen zu thematisieren, immer nur die Probleme.

Dabei kann jeder einzelne von uns dazu beitragen, dass nach der technologischen Revolution auch die Verantwortung für unsere Umwelt beginnt, nennen wir sie die umweltzentrierte Revolution. Wir können die Entscheidungen anderer nicht beeinflussen, unsere eigenen aber schon. Jede Veränderung beginnt mit einer Entscheidung und einem ersten, meist kleinen Schritt.

Wir müssen uns aber erst der Probleme bewusst werden, um diese Entscheidung zu treffen.

Einer Bitkom e.V. Studie zufolge verbrauchten Rechenzentren und Unternehmens IT im Jahr 2020 bereits rund 3% des gesamten deutschen Stromverbrauchs. Der gesamte Bereich der Kommunikationstechnik soll verschiedenen Studien anderer Quellen entsprechend 2020 schon 7% des Gesamtstromverbrauchs betragen haben. Und das bei wachsender Tendenz, bis 2030 könnte sich das im Worst Case verdreifachen. Und meist sind die Daten, die wir in im Ausland befindlichen Rechenzentren verarbeiten, nicht berücksichtigt.

Die Realität zeigt, der globale Energieverbrauch durch Informationstechnologie wächst weiter exponentiell. Viele zeigen dann mit dem Finger auf die Hardware, die den Strom verbraucht. Dabei ist es unsere Software, die diesen Verbrauch verantwortet. Jeder ineffiziente API‑Aufruf, jede unnötige Datenbewegung und jedes aufgeblähte Framework treiben den CO₂‑Ausstoß. Genauso wie die Nutzung von irgendwie interpretierten Programmen, anstatt native Software zu nutzen. Unternehmen müssen Green IT‑Best Practices einführen, und dazu gehört die Auswahl der Technologie und eine entsprechende Architektur. Dann folgen auch Energiemessungen für CPU, RAM und Netzwerk. Awareness‑Trainings und ökologische Kriterien müssen bereits in die Architekturphase integriert werden. Und diese müssen im Entwicklungsteam bewusst "gelebt" werden.

Effiziente Software ist grüne Software. Die Wahl typisierter, kompakter und performanter Systeme ist keine ästhetische Entscheidung. Die Systemauswahl darf nicht auf die Bequemlichkeit der Entwickler*innen abzielen, sie hat reale ökologische Konsequenzen. Software entscheidet heute über Serverlast, Rechenzentrumsgröße und letztlich den ökologischen Fußabdruck digitaler Prozesse.

Tools erlauben es, Software-Effizienz sichtbar zu machen und gezielt zu verbessern. Das ist ein wichtiger Baustein des Entwicklungsprozesses. Aber sie sollten unseren Blick nicht verstellen, denn sie werden oft missbraucht, um Alibis für schlechte Systementscheidungen zu finden, oder etwas schlechteres in besseren Licht erscheinen zu lassen. Auch hier würden wir viele Vergleiche in anderen Bereichen finden, wie die Diskussion über "Technologie- Offenheit" im Gebäude- oder Verkehrsbereich, und andere Debatten. Wir erleben "Green Washing" leider in allen Bereichen, auch in der Softwareentwicklung.

Zusammenfassend lässt sich deshalb sagen: Wir machen den Unterschied. Entwickler*innen werden mit der richtigen Einstellung zu Klimaschützer*innen – und Architektur wird zur Frage der globalen Verantwortung.

🌍 Call to Action – Du machst den Unterschied

Zum Earth Day 2025 ist es an der Zeit, nicht nur über grüne Software zu sprechen, sondern sie aktiv zu gestalten. Hier einige konkrete Ansätze, wie du als Entwickler*in einen Unterschied machen kannst:

• Denke nachhaltig bei Architekturentscheidungen: Modularität, Wartbarkeit und ressourcenschonende Frameworks helfen, langlebige und performante Systeme zu bauen.
• Optimiere Datenflüsse und Speicherbedarf: Jede optimierte Datenbankabfrage spart Rechenzeit – und Energie.
• Vermeide technische Schulden: „Quick & dirty“ kostet langfristig nicht nur Zeit, sondern auch CO₂.
• Nutze Green Hosting und Cloud-Anbieter mit nachhaltigem Energieprofil.
• Hinterfrage, ob jede Funktion wirklich notwendig ist – weniger Features bedeuten weniger Komplexität und oft weniger Last.
• Sensibilisiere dein Team: Nachhaltigkeit beginnt im Mindset
• Qualifiziere dein Team: Qualifikation ist einer der entscheidenden Faktoren

Fazit: Architektur ist nie neutral. Jede Entscheidung zählt – auch für unsere Umwelt. Du machst den Unterschied. 🌱 Und echte Qualifikation ist der Schlüssel dafür.

Deshalb möchte ich im folgenden auf einige Punkte eingehen.

Wissen ist nicht laut – und darum oft unsichtbar

Ein weiterer, zunehmend relevanter Aspekt ist die gesellschaftliche Wahrnehmung von Expertise. Im Zeitalter von LinkedIn, TikTok und viralen Thought-Leadership-Zitaten wird Aufmerksamkeit zur Währung, nicht Wissen. Kompetenz äußert sich heute deshalb eher leise – und wird darum oft überhört. Wer versucht Komplexität zu erklären, statt sie zu simplifizieren, wirkt schnell elitär. Fakten werden schnell mit Schlagworten und nicht bewiesenen Thesen beantwortet. Wer auf tiefes Lernen setzt, statt auf schnelle Meinungen, gilt als langsam und langweilig. Und Expert*innen werden dann oft sogar angegriffen, da die Expertise eine Gefahr für Bequemlichkeit und die eigene, fehlende Qualifikation wahrgenommen wird.

Psychologisch lässt sich dieses Phänomen mit der kognitiven Leichtigkeit erklären: Menschen bevorzugen Aussagen, die sich einfach und schnell verarbeiten lassen. Doch genau diese Präferenz macht echtes Lernen unbeliebt. Lernen ist heute nicht nur anstrengend – es gilt in manchen Kreisen sogar als „uncool“. Schon vor 10 Jahren warnten Hochschulprofessor*innen, dass der Leistungsdurchschnitt der Studierenden in Deutschland deutlich gesunken ist. Und heute, 10 Jahre später, hat sich dieses Bild noch mehr verschlechtert. Und das dieses schon in der Schule beginnt zeigen ja die Pisa Studien.

Eliten – verstanden als durch Fleiß, Erfahrung und intellektuelle Neugier gewachsene Kompetenzträger – gelten nicht als Vorbilder, sondern als suspekt.

Dabei ist genau das Gegenteil notwendig: kontinuierliches Lernen, tiefe Systemkenntnis und Bereitschaft zur Selbstreflexion. Entwickler*innen müssen mehr als Code googeln können – sie brauchen ein mentales Modell des Systems, das sie gestalten. Doch in vielen Teams wird diese Fähigkeit weder gefördert noch geschätzt. Die Folge: flache Lösungen, gefährliches Halbwissen und ineffiziente Systeme, die durch Prozessdenken kaschiert, aber nie wirklich beherrscht werden.

Und die Bereitschaft der großen Firmen, ihre Mitarbeitenden zu qualifizieren, hat in den letzten 20 Jahren kontinuierlich abgenommen. Gerade von größeren Firmen ging ein starker Impuls an die Hochschulen, schneller und eindimensionaler auszubilden. Und anstatt sich auf Konferenzen, wie der #ADCKonf zu treffen und auszutauschen, werden "Schnellkurse" im Internet konsumiert.

Die Falle der Low‑Code / No‑Code-Plattformen

Low‑Code-Ansätze versprechen, Entwicklungszyklen zu verkürzen und den Fachkräftemangel zu mildern. Dabei ist dieser Gedanke nicht neu, denn auch klassische Entwicklungssysteme haben oft mit "Rapid Application Development (RAD)" geworben, und Lösungen mit Mausklicks nicht nur in kürzerer Zeit, sondern auch mit weniger Qualifikation versprochen. Aber wir müssen uns wirklich fragen, ob weniger Qualifikation der Schlüssel zum Erfolg ist, und ob es Sinn macht, die Herausforderungen mit mehr unqualifizierteren Entwickler*innen lösen zu wollen. Ich verweise hier auf meinen Artikel "Was wir von Evolutionsbiolog*innen für die Softwareentwicklung lernen können", den ich vor einigen Monaten geschrieben haben. Dieser basiert auf einer Diskussion, die ich vor 20 Jahren auf Xing geführt habe. In der heutigen Zeit wäre das der Vergleich, ob Bakterien (Micro Services) die überlegene Lebensform sind, oder ein komplexes, vielschichtiges Lebewesen, wie der Mensch.

An diesen Hype der RAD- Tools schließt sich der neue Low- Code Hype nahtlos an. In der Praxis entstehen jedoch häufig schlechte Architekturen und Black‑Box‑Lösungen, deren Intransparenz das Debugging zur Tortur macht und bereits ab einer niedrigen Komplexitätsschwelle eine Weiterentwicklung erschwert. Wieder wird ein Prototyp mit einer konkreten, effizienten Anwendung verwechselt.

Dahinter steht oft auch eine Unterschätzung der Hardware: Erfahrene Architekt*innen müssen CPU-Caches, Speicherallokation und Kopiermechanismen verstehen, um unnötige Datenbewegungen zu vermeiden. Es geht nicht nur darum, ein Problem zu lösen, wer nachhaltige Software schreiben möchte, muss auch auf die Ressourcen und den Stromverbrauch achten. Flexibilität entsteht nicht durch Drag‑and‑Drop, sondern durch domänenspezifische Abstraktionen, die Entwickler*innen aufgrund ihrer Qualifikation entwerfen. Modelle entstehen zu erst in unseren Gedanken, werden meist auf formlosen Medien "skizziert" und in der Diskussion mit anderen konkreter. Wer glaubt, dass man diese Phase einfach überspringen kann, und gleich mit Mausklicks beginnt, hat schon den Grundstein für einen Misserfolg gelegt. Zwar lässt sich, wie von mir bereits im vorhergehenden Artikel angedeutet, mit Metadaten‑Generatoren und Regelwerken ein Großteil repetitiver Aufgaben automatisieren, doch gesamte Geschäftsprozesse erfordern intuitive, kreative Lösungen, die kein Tool auf Knopfdruck liefert.

REST vs. CORBA: Effiziente Kommunikation für interne Systeme

Dieser Trend zur Vereinfachung zeigt sich auch in anderen Technologien. Dabei wird der positiver Aspekt, den bestimmte Technologien haben, oft durch eine Verallgemeinerung pervertiert. Ein Beispiel hierfür sind RESTful APIs und damit stateless Architekturen. Sie dominieren nicht nur das öffentliche Web, doch für interne, latenzkritische Umgebungen sind sie ungeeignet. Trotzdem finden sich oft Vergleiche, dass sie schneller und leistungsfähiger sind. Nur verglichen zu welcher Technologie? Die Text-basierten Protokolle HTTP/JSON erzeugen einen erhöhten Datentransfer und einen Parsing‑Overhead, also zusätzliche Round‑Trips und hohe Netzwerkbelastung. Trotzdem bezeichnet man sie oft als "leichtgewichtig". In einem HFT‑System (High Frequency Trading), können wenige Millisekunden durch REST den Unterschied zwischen Gewinn und Verlust bedeuten. In einer medizinischen Anwendung entscheiden sie über Leben und Tod, und in einer Steuerung von Energieanlagen kann ein Kollaps und Blackout erzeugt werden. Aber nicht nur diese Arten von Anwendungen sind entscheidend, denn in jedem System bedeutet es, dass textbasierte Schnittstellen zu einem höheren Ressourcenbedarf führen, also mehr Energie verbrauchen, als notwendig. Und diese Energie ist nicht endlos verfügbar, gerade unter dem Aspekt der globalen Erwärmung müssen wir endlich lernen, die verfügbaren Ressourcen verantwortungsbewusst zu nutzen.

Demgegenüber steht CORBA: Mit binärem Marshalling, strenger Typisierung per IDL und einem zustandsbehafteten Kommunikationsmodell wird eine hohe Effizienz erreicht. Auf dem Server wird eine Objektinstanz erzeugt, die über mehrere Aufrufe hinweg bestehen bleibt – der Client ruft lediglich gezielte Methoden auf, anstatt große Datenmengen zu übertragen. Die Daten bleiben auf dem Server, werden nur bei Bedarf angefordert, und die eigentliche Businesslogik liegt dort, wo sie hingehört: zentralisiert auf einem skalierbaren System.

In einem Vergleich haben wir den Kommunikationsaufwand verschiedener Technologien für einen einfachen Fall verglichen. Bei einer reinen XML- Lösung werden ungefähr 950 Byte übertragen. Damit verglichen benötigt eine JSON- Lösung nur 700 Byte, was eine Einsparung von 25% ausmacht. Damit ist für jeden sofort klar, das eine JSON Lösung überlegen ist. Mit Protokollerweiterungen und Frameworks versucht man dieses weiter zu steigern. Aber eine CORBA Lösung instanziiert nicht nur auf dem Server, sie benötigt durchschnittlich nur 277 Byte für die Daten, das sind 60% weniger als bei JSON. Nicht mitgerechnet die Overheads für die jeweiligen Protokolle, der bei CORBA auch niedriger ist. Das zeigt, dass Vergleiche immer zur richtigen Basis gemacht werden müssen, um Entscheidungen zu treffen.

Aber CORBA minimiert nicht nur Latenzzeiten, sondern erlaubt es auch, Änderungen an der Businesslogik zentral auszurollen, was Testaufwand, Rolloutzeiten und Fehlerquellen reduziert. Dank Open‑Source‑Implementierungen wie TAO oder JacORB entfallen die früher hohen Lizenzkosten, und mit IDL‑Compilern können Entwickler*innen Skeletons und Stubs generieren, die sich wie native Objekte verwenden lassen – typisiert, sicher und performant. Und CORBA ist nativ, es ist nicht auf eine Plattform beschränkt, und unterstützt unterschiedliche Programmiersprachen.

Zudem basiert CORBA auf einem stateful Architekturprinzip, das im Gegensatz zu REST nicht für jeden Aufruf alle benötigten Daten überträgt. Stattdessen erfolgt eine Instanziierung auf dem Server, wodurch komplexe Geschäftsprozesse direkt dort verarbeitet werden können. Das spart nicht nur Datenvolumen und vermeidet unnötige Serialisierung, sondern erlaubt auch eine feingranulare Lastverteilung und extrem schnelle Reaktionszeiten.

Ich erinnere mich an ein Projekt einer großen Verwaltung, bei dem die Umstellung von einem CORBA System zu dem (modernen) RESTful System unüberlegt erfolgte, und sich das Datenvolumen vervielfachte. Dadurch musste eine größere Anzahl neuer Server angeschafft werden. Mit CORBA und einer vernünftigen Architektur der Anwendung lassen sich also bis zu 70% des Kommunikation‑ Overhead einsparen und gleichzeitig eine stabilere, auf Typsicherheit basierende Architektur erzeugen. Gerade für firmeninterne, komplexe Systeme ist CORBA deshalb nach wie vor eine technologisch überlegene Alternative, die heute durch Open Source Lösungen nicht nur verfügbar, sondern auch wirtschaftlich attraktiv ist.

Anwendungsstrukturen in der Datenbank – zwischen Realität und Abbildung

In modernen Unternehmensdatenbanken müssen reale, oft hochkomplexe Geschäftsmodelle abgebildet werden. Diese Strukturen sollten nicht nur darauf ausgelegt sein, einzelne Anwendungsfälle zu bedienen, sondern als zentrale Basis für die übergreifende Datenhaltung dienen, die Integration verschiedener Unternehmensbereiche sowie die Schaffung von Synergien im gesamten System. Dabei sollten sie flexible anpassbar und erweiterbar sein. Die Datenbankstruktur bildet damit die Realität in einer möglichst vollständigen und konsistenten Weise ab – unabhängig von den jeweiligen Anforderungen einzelner Anwendungen.

Im Gegensatz dazu verfolgt die Anwendungsentwicklung in der Regel einen spezialisierteren und vereinfachten Blick auf diese Realität. Anwendungen konzentrieren sich auf konkrete Teilaspekte oder Fachprozesse und abstrahieren die dahinterliegenden Datenmodelle entsprechend ihrer spezifischen Logik. Das führt zu hierarchischen „Sichten“ auf die Daten – eingeschränkte Perspektiven, die zwar für den jeweiligen Zweck optimiert sind, aber nicht das vollständige Modell repräsentieren. Daraus ergibt sich ein inhärenter Konflikt zwischen den Datenbankarchitekt*innen und den Anwendungsentwickler*innen.

Aber deshalb ist es auch essenziell, dass die Anwendungsentwicklung nicht die Struktur des zentralen Datenmodells vorgeben darf. Eine Anwendung bildet immer nur eine reduzierte Perspektive auf ein komplexeres System ab, eine Sicht unter vielen – sie sollte sich also an das übergeordnete, durchdachte Datenmodell anpassen, nicht umgekehrt. Gerade bei komplexen, transaktionsintensiven Systemen führt eine einseitige oder aus dem Quellcode automatisch abgeleitete Modellierung zu ineffizienten Datenstrukturen. Solche Strukturen neigen dazu, nur kurzfristige Anforderungen zu erfüllen und langfristig an Flexibilität und Skalierbarkeit zu verlieren. Außerdem sehe ich oft den Trend, dass jede Anwendung nur die eigenen Daten verwaltet, was Synergien fast unmöglich macht. Aber anstatt den Problem im Modell zu suchen, argumentiert man heute eher mit Denormalisierung oder nutzt NoSQL Datenbanken.

Effiziente Datenmodelle entstehen nicht automatisch, sondern erfordern die Expertise von Datenbankarchitekt*innen und Modellierer*innen. In der Praxis dominieren bei solchen Systemen relationale Modelle, da sie auf soliden mathematischen Grundlagen (insbesondere der Mengen- und Prädikatenlogik) basieren und technisch ausgereift sind. Normalisierte Datenbanken ermöglichen dabei eine mehrdimensionale Sicht auf Daten, reduzieren Redundanz, sichern Datenintegrität und erlauben es, verschiedene fachliche Sichten effizient zu integrieren.

Nur durch diese Trennung von Modell und Anwendung lassen sich leistungsfähige, konsistente und langfristig wartbare Informationssysteme aufbauen.

Das SQL-Revival: Mehr als nur Tabellen

In meinem letzten Artikel habe ich betont, wie wichtig Vertrauen, Teamdynamik und Fachkompetenz sind. Diese Prinzipien gelten auch für unsere Datenbanken: Moderne SQL-Systeme sind weit mehr als simple Tabellenlager. Trotzdem kann ich in vielen Beiträge die Meinung von Autor*innen lesen, die No SQL- Datenbanken präferieren und Denormalisierung predigen. Wieder sehe ich einen Trend, Fragen der Architektur in den Hintergrund zu schieben. Und auch hier bin ich überzeugt, dass es oft eine Frage der fehlenden Qualifikation ist. Zu gerne wollen viele Manager*innen dem "einfacheren" Weg folgen, und die Abhängigkeit von hochqualifizierten Softwareentwickler*innen zu reduzieren.

Dabei haben sich in den letzten Jahren auch die SQL- Datenbanken weiter entwickelt. Mit Common Table Expressions (CTE) lassen sich komplexe Graphstrukturen und Hierarchien elegant und performant in eine verständliche Abfragestruktur bringen. Window Functions ermöglichen zeilenübergreifende Berechnungen innerhalb einer einzigen Abfrage – etwa zur Ermittlung gleitender Durchschnitte oder Rankings – und sparen dadurch kostenintensive Round‑Trips in die Anwendungsschicht. Materialisierte Views, Indexed Views und User-Defined Functions (UDFs) helfen, Geschäftslogik direkt auf Datenbankebene zu kapseln.

Damit erfüllen Datenbanken das, was vor 50 Jahren zur Entwicklung der Datenbanksysteme geführt hat. Die Unabhängigkeit der Daten von den sie verarbeitenden Programmen. Die Programme werden dadurch maßgeblich entlastet, was am Ende zu weniger Fehlern führt, da die Gesamtkomplexität der Anwendung reduziert wird.

Besonders hervorzuheben ist auch hier die strenge Typisierung moderner SQL-Datenbanken: klar definierte binäre Typen ergänzt mit CHECK-Constraints, ENUM-Typen und DOMAINs verhindern fehlerhafte Eingaben bereits zur Laufzeit. Und müssen nicht interpretiert werden. Dadurch wird eine hohe Datenqualität garantiert, Interpretationsspielräume entfallen – was wiederum die Kosten in der Anwendungsentwicklung drastisch reduziert. Die Datenbank garantiert nicht nur Integrität, sondern dokumentiert implizit die zugrunde liegenden Geschäftsregeln – ein klarer Vorteil gegenüber lose gekoppelten NoSQL-Systemen.

Außerdem kann man davon ausgehen, dass unstrukturierte Daten nicht nur schlechter auswertbar sind, weitere Programme hierfür werden benötigt. Unstrukturierte Daten führen am Ende zu mehr "Dunklen Daten (Dark Data)". Das ist überflüssiger Datenmüll, der zunehmend die Netze und Server belastet, und nach Schätzungen heute schon mehr als 50% ausmacht.

Moderne C++‑Entwicklung: Ein Paradigmenwechsel seit C++11

Auch bei der Wahl der Programmiersprache zeigt sich der Trend zu Vereinfachung und der Verlagerung der Verantwortung von den Entwickler*innen hin zu einer Technologie / Sprache. Dabei werden dann auch fragwürdige Vergleiche "hervorgezaubert" und C++ per Definition Unsicherheit unterstellt. C++ gilt dabei als zu komplex, nicht erlernbar. Also lässt sich hier auch eine Parallelität zu den vorherigen Aussagen finden, dass wir ein Qualifikationsproblem in der IT Landschaft in Deutschland haben.

C++ hat mit dem C++11-Standard ein neues Leistungszeitalter eingeläutet. Durch Rvalue-Referenzen und Move-Semantik können temporäre Objekte mittels std::move weiterverwendet werden, ohne teure Kopien zu erzeugen – ein Game-Changer für alle datenintensiven Anwendungen, egal ob Echtzeitsysteme oder nur eine Büroverwaltung. RVO und NRVO (Return Value Optimization/Named RVO) ermöglichen Compiler‑Optimierungen, bei denen Rückgabewerte direkt am Zielort konstruiert werden.

In‑place-Konstruktionen mit emplace_back und Zero-Copy-Strategien durch std::pmr-Allocators vermeiden Zwischenschritte. Concepts, constexpr-Funktionen und stark typisierte Interfaces heben Fehlerszenarien bereits in die Compile‑Time, was in Echtzeit‑ und Embedded‑Projekten entscheidend ist. Durch lock‑free Datenstrukturen, std::atomic und Coroutines lässt sich nebenläufige Programmierung schreiben, die sowohl Performance als auch Determinismus garantiert.

Diese Merkmale in Verbindung mit der strengen Typisierung machen modernes C++ zu einer der effizientesten Plattformen für nachhaltige, ressourcenschonende Softwarearchitekturen.

Kontinuität und Fortschritt: Das Prinzip C++

Die Evolution von C++ zeigt eindrucksvoll, wie wichtig es ist, eine Programmiersprache organisch und schrittweise weiterzuentwickeln, anstatt sie radikal neu zu erfinden. Bjarne Stroustrup, der Schöpfer von C++, bringt es auf den Punkt: "The primary value of a programming language is in the application written in it." – Der wahre Wert einer Sprache liegt in den Anwendungen, die mit ihr geschrieben werden. Um diesen Wert über Jahrzehnte zu bewahren und weiter auszubauen, folgt C++ einem evolutionären Ansatz. Ursprünglich als Brückentechnologie von C zur Objektorientierung und moderner Programmierung gedacht, war C++ von Beginn her auf Unterstützung verschiedener Paradigmen angelegt. Mit C++11 wurde ein fundamentaler Wandel eingeleitet: Move-Semantik, variadische Templates und ein erweitertes Typensystem (etwa durch type_traits) ebneten den Weg für moderne, generische und effiziente Programmierung. C++14 vertiefte diese Grundlagen mit weiteren Sprachvereinfachungen und O ptimierungen, während C++17 unter anderem durch strukturierte Bindungen, if constexpr und Parallel STL wichtige neue Möglichkeiten eröffnete. C++20 brachte schließlich mit Concepts, Ranges und Coroutinen einen riesigen Schritt in Richtung expressiver und sicherer Programmiermuster. C++23 wirkt in vielen Bereichen wie ein Feinschliff und zugleich eine Vorbereitung auf C++26, das den Fokus verstärkt auf Sicherheit und Robustheit legt – etwa durch stärkere Typprüfung, verbessertes Lifetime-Management und neuen Sprachmechanismen zur Fehlervermeidung. Diese kontinuierliche Weiterentwicklung zeigt, dass C++ nicht durch revolutionäre Brüche, sondern durch gezielte, kompatible Erweiterungen langfristig relevant und leistungsfähig bleibt. So deckt es heute alle Bereiche ab, auch wenn es oft nur auf Low level- Anwendungen reduziert wird.

Da C++26 einen Fokus auf die Sicherheit legen wird, und viele in einer komplexen Sprache inhärent zu erwartenden Probleme reduzieren soll, ist es wichtig, sich schon heute mit C++26 zu beschäftigen, und jeder Compiler- Hersteller ist gefordert, C++26 zeitnah verfügbar zu machen.

Evolution statt Big Bang: Der systemtheoretische Blick

Ein oft übersehener, aber zentraler Grundsatz aus der Systemtheorie lautet: Ein funktionierendes komplexes System entsteht nicht aus dem Nichts, sondern entwickelt sich aus einem funktionierenden weniger komplexen System. Dieser Gedanke ist ein mächtiges Argument gegen großangelegte Rewrites und technologische Big Bangs – und für iterative, schrittweise Architekturentwicklung.

Auch in der Welt der Programmiersprachen zeigt sich dieser evolutionäre Pfad. C++ hat sich über Jahrzehnte hinweg transformiert, ohne dabei seine Wurzeln zu verlieren. Diese Entwicklung ist nicht zufällig, sondern Ausdruck eines stabilen, sich kontinuierlich verfeinernden Systems.

In dieser Logik liegt auch eine klare Botschaft: Die Schwächen heutiger Softwaresysteme liegen selten in den Werkzeugen – sondern fast immer in der Architektur. Wer glaubt, allein durch den Wechsel zu einer neuen Sprache oder einem neuen Framework nachhaltige Qualität zu erzeugen, ignoriert die Systemebene. Ohne Architekturbewusstsein werden auch neue Technologien scheitern – oft schneller und spektakulärer als die alten. Es ist nicht die Technologie, die das System rettet – es ist das Denken, und die emotionale Intelligenz und Kreativität der Architekten*innen, die Kraft der Selbstorganisation eines flexiblen Teams.

Wir brauchen keine neuen Hypes – wir brauchen mehr Qualifikation. Mehr Erfahrung, mehr Tiefgang, mehr echtes Systemverständnis. Jugend und frische Perspektiven sind ebenso gefragt wie das Wissen alter Hasen. Grady Booch sagte einmal sinngemäß: „Die Architekturen unserer Anwendungen müssen von da Vincis gemacht werden – und es wäre naiv zu glauben, dass es mehr da Vincis in der IT gibt als im echten Leben.“ Genau deshalb dürfen wir nicht blind auf den Nächstbesten hören, der die Bühne betritt. Wir müssen wieder auf echte Expertise setzen – auf das stille Können, nicht auf lauten Applaus.

Der Blick über den Tellerrand hilft: Auch Entdecker wie Kolumbus oder Vasco da Gama kannten ihr Ziel nicht bis ins Detail – aber sie hatten eine Vision, ein starkes Team, einen verlässlichen Sponsor, und das handwerkliche Können, ihre Schiffe durch Ungewissheit zu steuern. Es braucht diese Mischung aus Orientierung und Offenheit, aus Können und Mut. Diese Haltung finden wir auch im CHAOS Report 2020, mit seinen Prinzipien: "Good Place", "Good Team", "Good Sponsor" – ergänzt durch ein oft unterschätztes Element: "Good Coach". Und hier schließt sich dann auch der CHAOS Report 2018 "Decision Latency Theory – It’s All About the Interval" an, denn es braucht den Mut zu Entscheidungen. Dieser Report zeigt, dass die Verzögerung bei Entscheidungsprozessen ebenfalls ein Ursache höherer Projektkosten ist. Die Ergebnisse dieses reports zeigen, liegt die mittlere Entscheidungszeit unter einer Stunde, steigt die Erfolgsrate auf 58%, überschreitet sie fünf Stunden, sinkt der Erfolg auf 18%. Das deckt sich mit unseren Erfahrungen, nach dem eine weniger gute Entscheidung heute immer besser ist, als eine optimale am nächsten Tag, und erklärt den Vergleich mit dem Kanufahren im Gebirgsbach, den ich im letzten Artikel benutzt habe.

In der Praxis bedeutet das: Architektur darf nicht vollständig „vorgezeichnet“ werden, sondern muss sich evolutionär entfalten – unter realen Bedingungen, mit echtem Feedback. Gute Teams starten mit einem stabilen, performanten und verständlichen Kernsystem – und entwickeln es iterativ weiter. Das ist kein Zeichen von Unsicherheit, sondern von Stärke. Und notwendige Entscheidungen müssen schnell getroffen werden, auch mit dem Risiko falsch zu liegen. Dafür benötigen wir qualifizierte, selbstbewusste und selbstreflektierende Mitarbeiter*innen.

Fazit: Expertise schlägt Hype

Komplexität verlangt nach Kompetenz, nicht nach magischen Abkürzungen. Und Softwareentwicklung ist komplex – im mathematischen wie im menschlichen Sinne chaotisch. Setzen Sie – wie in meinem letzten Artikel beschrieben – auf die Prinzipien "Good Place", "Good Team", "Good Sponsor". Investieren Sie in Domänenwissen, strikte Typisierung (wie sie C++, SQL oder CORBA bieten), und nachhaltige Architekturmuster, um wartbare, leistungsfähige und langfristig tragfähige Systeme zu bauen.

Meine über 35-jährige Erfahrung in der Softwareentwicklung zeigt: Nur wer Systeme wirklich versteht, kann sie langfristig tragen. Wer sich nur von Technologie zu Technologie hangelt, wird Systeme in immer kürzeren Zyklen neu erfinden – aber nie wirklich lösen. Wir brauchen wieder mehr Respekt vor Handwerk, Tiefgang und Expertise. Nicht mehr Noise – sondern mehr Substanz.