Warum proprietäre Frameworks heute nicht (mehr) sinnvoll sind

Einleitung

Ein Industrieunternehmen, das eine neue webbasierte Steuerungslösung für Maschinen entwickelt, muss die passende Architektur für Frontend, Backend und SPS finden. Eine klare Aufgabentrennung ist dabei entscheidend für den Erfolg: Das System soll so gestaltet sein, dass ein neues Maschinenmodell einfach an Kundenbedürfnisse angepasst, installiert und gewartet werden kann – ohne dass Servicetechniker Full-Stack-Entwickler sein müssen.

Aktuell steht eine Entscheidung zwischen zwei Anbietern an. Beide sind erfahren im industriellen Software-Engineering und haben bereits erfolgreich webbasierte Steuerungen und Visualisierungen umgesetzt. Der eine Anbieter führt ein selbst entwickeltes, proprietäres Framework ins Feld, welches schnellere und günstigere Resultate verspricht. Cudos hingegen setzt seit Jahren auf ein Ökosystem aus offenen Komponenten und Open-Source-Frameworks, kombiniert mit eigenem Know-how. Die Überzeugung dahinter: Ein proprietäres Framework ist langfristig oft teurer, weniger flexibel und risikoreicher in Bezug auf Weiterentwicklung und Wartung. Offene, modulare Architekturen bieten hier einen zukunftsfähigeren Weg.

Diese Situation hat uns dazu animiert, noch einmal tiefer über die ganze Sache nachzudenken und je länger wir darüber diskutiert haben, um so überzeugter waren wir, dass die Zeit von grossen proprietären Frameworks vorbei ist.

Im Folgenden haben wir die Ergebnisse dieser Diskussionen und Überlegungen noch einmal zusammengefasst. Wir freuen uns über jedes Feedback und jede konstruktive Kritik und würden den Blog ggf. gerne auch ergänzen und erweitern.

Was sind proprietäre Frameworks?

Ein proprietäres Framework ist eine umfangreiche, individuell entwickelte Softwareplattform, die viele Funktionen und Dienste in einer geschlossenen Lösung vereint. Anpassungen erfolgen oft über Parametrierungen oder eigene grafische Tools statt über direktes Coding. Der Aufbau erinnert an etablierte Systeme wie SCADA oder MES, deren Erweiterung durch Konfiguration statt durch klassische Softwareentwicklung erfolgt. Häufig bringen solche Frameworks eigene, spezialisierte Werkzeuge und sogar eigene „Programmiersprachen“ mit.

Vor- und Nachteile proprietärer Frameworks

Proprietäre Frameworks werden oft mit einem schnelleren Projektstart und weniger Risiken beworben. Ein wichtiger Vorteil ist, dass bereits branchentypisches Wissen integriert sein kann. Allerdings bezahlt man für diese vermeintliche Abkürzung oft später durch geringere Flexibilität, laufende Lizenzkosten und höhere Abhängigkeiten vom Anbieter.

Demgegenüber bieten komponentenbasierte Architekturen auf Basis von Open-Source- und Standard-Frameworks eine grössere Handlungsfreiheit, tiefere mittelfristige Kosten, starke Community-Unterstützung und die Vermeidung von Lock-Ins.

Die folgende Auflistung zeigt einen Überblick über die beiden verschiedene Systemansätze: "Proprietäre Frameworks" und "Komponentenbasierte Systeme". Sie vergleicht diese Ansätze anhand verschiedener Kriterien:

Proprietäres Framework

• Flexibilität: Eingeschränkt, Anpassungen nur im vorgesehenen Rahmen
• Einrichtungsaufwand: Niedrig, schneller Start durch vordefinierte Bausteine
• Anpassungsfähigkeit: Gering, bei neuen oder unvorhergesehenen Anforderungen eingeschränkt
• Kosten: Initialkosten tiefer, sofern Aufgabe sich gut für das Framework eignet. TCO oft höher, da Lizenz- und Wartungskosten anfallen und firmenspezifische Anpassungen teurer sind.
• Community Support: Gering, fokussiert auf einen Anbieter, dafür gibt es Spezialisten beim Anbieter und klare Ansprechpartner. Klare SLAs
• Lock-In-Effekt: Hoch, Abhängigkeit vom Anbieter
• Domänenwissen: Teilweise bereits integriert, z.T. hoch spezialisiertes Know-How integriert.
• Wartung: Anbieterabhängig, dafür klar definiert, SLA

Komponentenbasiertes System

• Flexibilität: Sehr hoch, vollständige Kontrolle über die Architektur
• Einrichtungsaufwand: Höher, da Komponenten integriert werden müssen
• Anpassungsfähigkeit: Hoch, nahezu jede Änderung ist möglich
• Kosten: Initialkosten höher. TCO oft tiefer, Open-Source-Komponenten sind oft kostenlos, Wartung günstiger, keine Lizenzkosten
• Community Support: Community Support sehr gross. Breite Dokumentation und Foren verfügbar. Gute KI Unterstützung. Nachteil: Wenig direkte Ansprechpartner und keine SLAs.
• Lock-In-Effekt: Gering, Austausch einzelner Komponenten möglich
• Domänenwissen: Muss selbst eingebunden werden, dafür flexibler
• Wartung: Durch Community getragen, durch eigenes Team getragen

Open-Source-Komponenten, Frameworks und ihre Vorteile

Von proprietären Frameworks zu Open-Source-Komponenten

Früher hat es eine grosse Daseinsberechtigung für proprietäre Frameworks und Bibliotheken gegeben. Die Programmiersprachen und Entwicklungsumgebungen kamen relativ schlank und ohne Komponentenframeworks daher. Sogar einfache Aufgaben wie Listenverwaltung, Stringmanipulation, Komponentensysteme etc. mussten selbst erstellt werden und haben zu vielen firmenspezifischen Frameworks mit z.T. beachtlicher Wiederverwendung geführt.

Heute steht eine grosse Anzahl mächtiger Open-Source-Komponenten und etablierter Standard-Frameworks zur Verfügung, die praktisch jede gängige Aufgabe abdecken. Diese Lösungen werden fortlaufend weiterentwickelt, getestet und durch eine weltweite Community dokumentiert.

Cudos nutzt bewusst etablierte Standard-Frameworks wie das .NET-Framework im Backend-Bereich und Angular im Frontend. Diese lösen bereits viele wiederkehrende Aufgaben (Webservices, Datenbank-Integration, Logging, Security, Internationalisierung, UI-Komponenten etc.) „out of the box“. Hinter diesen Lösungen stehen grosse Communities und Unternehmen, die für eine laufende Pflege, Aktualisierung und Qualität sorgen.

.NET-Framework

Das .NET-Framework bietet im Backend stabile Grundlagen für Webservices (ASP.NET), schnelle Kommunikationskanäle (SignalR), Datenbankintegration (Entity Framework), Dependency Injection, Logging, Monitoring, Identity Management und viele weitere Standardfunktionen einer modernen Webapplikation.

Angular-Framework

Angular deckt im Frontend fast alle relevanten Themen ab: komponentenbasierte Architektur, etablierte Komponentenbibliotheken (z. B. Angular Material), reaktive Programmierung (RxJS), Formularvalidierung, Routing, Internationalisierung und umfassende Testwerkzeuge. Auch hier gibt es automatisierte Security-Checks und hohe Codequalität durch eine weltweite Entwicklerbasis.

Effizienz durch Standards und grosse Community

Die starke Verbreitung dieser Frameworks führt zu einer enormen Qualität und Stabilität. Fast jede Herausforderung wurde irgendwo schon einmal gelöst. Eine schnelle Lösung ist damit oft nur wenige Klicks entfernt. Neue Entwicklerinnen und Entwickler können sich unkompliziert einarbeiten, da Wissen frei verfügbar ist.

Auch die laufende Weiterentwicklung erfolgt in der Regel „gratis“ im Hintergrund. Die Verwendung dieser verbreiteten Technologien senkt zudem das Risiko, dass Systeme plötzlich nicht mehr unterstützt werden. Der Personalmarkt ist breit, da viele Fachkräfte diese Standardwerkzeuge kennen.

Effizienzsteigerung durch KI

Mit gängigen Frameworks ist die Unterstützung durch KI-Tools (z. B. ChatGPT) besonders stark. Diese Werkzeuge können Code-Generierung automatisieren, bei der Einarbeitung helfen, Ideen liefern oder Code-Reviews simulieren. Je bekannter ein Framework, desto mehr kann die KI dazu beitragen, Entwicklungs- und Wartungsaufwände zu reduzieren. Proprietäre Systeme hingegen profitieren von KI-Unterstützung deutlich weniger, weil die Wissensbasis dazu meist gering ist.

Wiederverwendung von Komponenten und Modulen

Cudos setzt im Gegensatz zu monolithischen Frameworks auf die Wiederverwendung vieler kleiner Komponenten und bewährter Konzepte. So können etwa Anbindungen an Barcode-Scanner, serielle Schnittstellen oder OPC-UA-Bibliotheken flexibel integriert werden. Die Erfahrung zeigt, dass die Wiederverwendbarkeit von Code und Modulen besser ist, je kleiner und einfacher die Komponenten ist. Kleinere Bausteine sind leichter austauschbar, einfacher anzupassen und reduzieren die Hemmschwelle für den Einsatz in neuen Projekten.

Domänenwissen professionell integrieren

Ein häufiges Argument für proprietäre Frameworks ist das integrierte Domänenwissen. Tatsächlich müssen gewisse branchenspezifische Anforderungen (24/7-Betrieb im Browser, Feinheiten bei der Maschinenbedienung, robustes Fehlermanagement, Nutzerverwaltung für mehrere Bedienstellen, automatische Updates, begrenzte Speicher und Rechenleistung etc.) in den Standard-Frameworks gezielt abgebildet werden.

Cudos begegnet dieser Herausforderung mit erfahrenen Software-Architekten, systematischem Wissensaustausch und auch mit Checklisten. Diese stellen sicher, dass alle domänenspezifischen Anforderungen von Beginn weg berücksichtigt werden. Die Flexibilität der Open-Source-Welt ermöglicht es, diese Anforderungen elegant und langfristig wartbar in die Architektur zu integrieren.

Know-how statt Monolith: Experten als Komponenten-Orchestratoren

Anstatt ein einzelnes, proprietäres Framework zu verwenden, setzt Cudos auf eine Vielfalt bewährter Komponenten, die gezielt orchestriert werden. Dank langjähriger Erfahrung im Technologiemanagement kann für jede Aufgabe das optimale Baustein-Set zusammengestellt werden. Sehr wichtig ist auch, dass die entsprechenden Lizenzbedingungen für jede Komponente beachtet werden.

Bereits nach wenigen Wochen Projektlaufzeit ist ein solches, auf offenen Standards basierendes System in der Regel auf einem ähnlichen Niveau wie die auf den ersten Blick schneller startenden proprietären Frameworks. Spätestens dann, wenn spezielle Anforderungen auftreten, zeigen die offenen, modularen Architekturen ihre Stärke: Sie lassen sich ohne grosse Schmerzen anpassen, erweitern und weiterentwickeln.

Grosser Lieferumfang bereits nach 1-2 Sprints

Den Nutzen der Profi-Orchestrierer und erfahrenen Architekten sieht man bereits nach dem ersten Sprint (bzw. nach 3 Wochen Projektdauer). Am Ende der ersten ein bis zwei Sprints ist ein grosser Teil des Vorsprungs eines proprietären Frameworks schon fast aufgeholt.

Angenommen, es wurde eine gute Analysephase mit Requirements Engineering und Grobarchitektur für das zukünftige System erstellt, kann man typischerweise nach dem ersten oder spätestens zweiten Sprint folgendes erwarten:

• Komplett aufgesetztes CI/CD System (automatischer Build, automatischer Test, automatische Erstellung des Installers)
• Komplett aufgesetztes Grundsystem aus Backend, Datenbank, Logging, Konfiguration, Frontend, Kommunikation, Sicherheit, Lokalisierung, …
• Erster Vertikaler Durchstich (Von der Hardware über Backend bis zu Frontend), erste richtig funktionierende “Buttons” und “Statusanzeigen”

Danach kommen dann schon die sehr kundenspezifischen Anforderungen, welche so oder so von einem proprietären Framework auch nicht mitgebracht werden können.

Fazit

Die Zeit proprietärer Frameworks, die aus einer Hand alles liefern, neigt sich dem Ende zu. Die moderne Softwareentwicklung im industriellen Umfeld profitiert von der Flexibilität, Breite und ständigen Weiterentwicklung der Open-Source-Ökosysteme - mit gleichzeitig viel kleinerem Lock-In Problem. Dank KI-Unterstützung, Community-Support und schlanker Wiederverwendbarkeit kleinerer Module wird der Total Cost of Ownership positiv beeinflusst und die Time-to-Market reduziert. 

Domänenspezifische Anforderungen lassen sich durch professionelles Technologie- und Know-how-Management ebenso gut – oder sogar besser – umsetzen. Am Ende überwiegen die Vorteile offener, standardisierter Architekturen bei komplexen Systemen deutlich.