Kein Standard-Framework: Warum eigene Architektur sich lohnt

Kein Standard-Framework: Warum eigene Architektur sich lohnt

Standard-Frameworks sind für Webanwendungen optimiert. Langlebige Business-Software stellt andere Anforderungen – an Stabilität, Spezialisierung und Wartbarkeit. Warum eine eigene Architektur in diesem Kontext die bessere Grundlage ist.

PHP-Frameworks wie beispielsweise Laravel, Symfony oder CakePHP haben die Entwicklung von Webanwendungen erheblich vereinfacht. Sie bieten Authentifizierung, Routing, Datenbankzugriff und Template-Rendering als fertige Bausteine. Die große Community, umfangreiche Dokumentation und ein breiter Talentmarkt machen sie zur pragmatischen Wahl für die Mehrheit der Projekte.

Aber die Anforderungen an langlebige Business-Software unterscheiden sich grundlegend von denen einer typischen Webanwendung. Dieser Artikel beschreibt, wo diese Unterschiede liegen und wie eine spezialisierte Architektur ihnen begegnet.

Was Business-Software von Webanwendungen unterscheidet

Eine Webanwendung, also ein Blog, ein Online-Shop, eine Marketing-Website, hat typischerweise einen überschaubaren Lebenszyklus. Sie wird erstellt, geht live, wird einige Jahre gepflegt und irgendwann durch einen Nachfolger ersetzt. Standard-Frameworks sind genau dafür optimiert: schneller Start, breite Funktionalität, große Community.

Business-Software folgt einer anderen Logik. Eine Anwendung, die Rechnungsstellung, Zeiterfassung, Lagerverwaltung oder Fuhrpark-Management abbildet, ist auf 5 Jahre und mehr angelegt. Sie wächst mit dem Unternehmen, bildet neue Prozesse ab, integriert sich in bestehende Systeme. In diesem Kontext verschieben sich die Prioritäten: Nicht die Geschwindigkeit des ersten Prototyps entscheidet über den Erfolg, sondern die Wartbarkeit über den gesamten Lebenszyklus.

Drei Aspekte machen den Unterschied besonders deutlich.

Betriebsstabilität statt Release-Druck. Standard-Frameworks folgen eigenen Release-Zyklen mit jährlichen oder zweijährlichen Major-Versionen. Jedes Major-Upgrade bringt Breaking Changes und erfordert Anpassungen im gesamten Stack. Für Software, die über Jahrzehnte laufen soll, wird jedes Upgrade zu einem eigenen Projekt, mit Aufwand, der zunächst keinen neuen Nutzen für die Anwender liefert. Jedoch: Entweder investiert man kontinuierlich in solche Upgrades, oder man bleibt auf einer veralteten Version und verliert nach einer Zeit den Zugang zu Sicherheitsupdates. Beides ist für geschäftskritische Software keine akzeptable Option.

Fachliche Tiefe statt generischer Breite. Generische Frameworks bieten Bausteine für generische Probleme. Sobald Anforderungen spezialisierter werden - native Multi-Tenant-Architektur, branchenspezifische Compliance, komplexe Abrechnungslogik, integrierte Zeiterfassung mit Projektbezug - muss das Framework erweitert oder umgebaut werden. Je stärker die Anpassung, desto weniger profitiert man vom Standard. Der Framework-Overhead bleibt, der Nutzen sinkt jedoch, und bei jedem Upgrade müssen die eigenen Anpassungen erneut getestet werden.

AI-gestützte Entwicklung und Wartung. AI-Coding-Tools arbeiten am effektivsten auf überschaubaren, konsistenten Codebasen. Große Frameworks bringen tausende Klassen und Abstraktionsschichten mit, die den Kontext für AI-Assistenten unnötig vergrößern. Eine schlankere, auf den Anwendungsfall zugeschnittene Codebasis ermöglicht präzisere AI-Unterstützung. Dieser Vorteil gewinnt mit der mit zunehmendem AI-Einsatz in der Softwareentwicklung noch weiter an Bedeutung.

Architektur für Business-Software

Die Prowedo Platform ist seit 2005 im produktiven Einsatz und wurde über zwei Jahrzehnte auf Basis konkreter Geschäftsanforderungen weiterentwickelt.

Modulares System

Die Plattform besteht aus 26 Core-Modulen und über 20 Business-Paketen. Infrastruktur-Module (Database, Session, Mail, Security, UI) bilden die technische Basis. Business-Pakete (CRM, Rechnungsstellung, Zeiterfassung, Lagerverwaltung) implementieren fachliche Funktionalität. Jedes Paket hat eine einheitliche Struktur: Models, Controllers, Widgets, Konfiguration.

Entscheidend ist die Entkopplung: Neue Funktionalität entsteht als neues Paket, ohne bestehende Module zu verändern. Das reduziert Regressionsrisiken und hält die Wartungskosten über den gesamten Lebenszyklus kalkulierbar.

Erweiterbarkeit ohne Seiteneffekte

Neue Geschäftsanforderungen sind nicht alle zu Beginn einer Anwendungsentwicklung bekannt, sie entstehen auch im laufenden Betrieb. Statt eines klassischen Dependency-Injection-Containers, wie ihn die meisten Frameworks vorsehen, nutzt die Plattform ein hierarchisches Allocation System. Neue Funktionen werden an bestehende Abläufe angehängt, ohne deren Logik zu verändern. Ein neuer Genehmigungsschritt in der Rechnungsfreigabe, eine zusätzliche Validierung bei der Zeiterfassung, eine Benachrichtigung an ein Drittsystem, all das lässt sich nachrüsten, ohne bestehende Prozesse anzufassen. Das Risiko von ungewollten Seiteneffekten sinkt, und Erweiterungen können unabhängig voneinander entwickelt und getestet werden.

Expliziter Datenbankzugriff

Die Plattform nutzt einen eigenen Query Builder mit typisiertem Adapter-Pattern statt eines ORM. Kein verstecktes N+1-Problem, keine magischen Lazy-Loading-Überraschungen, keine Framework-spezifische Abfragesprache. Für Business-Software, bei der Datenbankzugriffe oft komplex und performance-kritisch sind, ist Transparenz wichtiger als Abstraktion.

Dreistufige Multi-Tenancy

Multi-Tenancy ist ein architektonischer Grundpfeiler, keine nachgerüstete Erweiterung. Die Plattform arbeitet mit einer dreistufigen Hierarchie: Application, Tenant und Object. Jedes Business-Paket unterstützt Multi-Tenancy nativ. Das ermöglicht White-Label-Szenarien und mandantenfähige Anwendungen ohne zusätzliche Third-Party-Abhängigkeiten. Getrennte Verwaltung unterschiedlicher Tochterunternehmen, Standorte oder Abteilungen? Kein Problem.

AI-optimierte Codebasis

Eine überschaubare, konsistente Codebasis ist der beste Ausgangspunkt für AI-gestützte Entwicklung. Ohne das Rauschen eines großen Frameworks können AI-Assistenten die gesamte Architektur erfassen und gezielt unterstützen: von der Feature-Entwicklung bis zur Qualitätssicherung.

Im Vergleich

Die folgende Tabelle stellt die Architekturentscheidungen gegenüber.

Aspekt	Standard-Frameworks	Prowedo Platform
Erweiterbarkeit	Framework-Konventionen, Plugin-System	Modulare Packages, unabhängig erweiterbar
Datenbankzugriff	ORM mit Abstraktionsschicht	Explizite Queries, transparent und performant
Mandantenfähigkeit	Nachgerüstet via Third-Party	Nativ dreistufig (App / Tenant / Objekt)
Upgrade-Zyklus	Jährlich / zweijährlich (Major)	Nach Bedarf, keine Zwangsupgrades
AI-Unterstützung	Große Codebasis erschwert AI-Kontext	Schlanke Codebasis, optimiert für AI-Tools
Lock-in	Gebunden an Framework-Ökosystem	Volle Kontrolle über Code und Architektur

Fazit: Architektur ist eine Geschäftsentscheidung

Für Webanwendungen mit Standard-Anforderungen - Content Management, APIs, schnelle Prototypen - sind etablierte Frameworks die richtige Wahl. Der breite Talentmarkt und das reiche Ökosystem sind klare Vorteile.

Für Business-Software mit einer geplanten Lebensdauer von 5 Jahren und mehr, mit Multi-Tenancy, branchenspezifischer Compliance oder dem Anspruch auf volle Kontrolle über den Stack, gelten andere Regeln. Hier bestimmt die Wahl der technischen Basis die Wartungskosten über Jahrzehnte und die Fähigkeit, auf neue Anforderungen zu reagieren – sei es ein neuer Geschäftsprozess oder die Integration von AI-gestützten Workflows.

Eine spezialisierte Architektur mit modularem System bietet kalkulierbare Kosten, keine Zwangsupgrades und Software, die mit dem Unternehmen wächst. In Kombination mit dem Baukastenprinzip entsteht eine Plattform, die individuelle Anforderungen abdeckt, ohne bei jedem Projekt bei null anzufangen. Wie der Artikel zu PHP im AI-Zeitalter zeigt, profitieren stabile, gut verstandene Codebasen besonders stark von AI-gestützter Entwicklung.

Sie planen Business-Software, die langfristig tragen soll? Ein kurzes Gespräch klärt, ob eine spezialisierte Architektur zu Ihren Anforderungen passt.