Der wahren Kosten von Low-Code

Die tatsächlichen Kosten von Low-Code liegen nicht nur in den Lizenzgebühren. Sie entstehen vor allem durch die Zeit, den Entwicklungsaufwand und die zunehmende Komplexität, die damit verbunden sind, eine Plattform für Probleme einzusetzen, für die sie ursprünglich nicht konzipiert wurde.

Die erste Version ist selten das Problem. Moderne Low-Code-Plattformen wie Microsoft Power Platform ermöglichen es, fachliche Anforderungen innerhalb weniger Tage statt Monate in funktionierende Anwendungen zu überführen. Für den Grossteil interner Geschäftsprozesse ist genau das die richtige Lösung.

Die eigentliche Herausforderung beginnt, wenn die Anwendung über die Möglichkeiten der Plattform hinauswächst.

Mit der Zeit werden Geschäftsprozesse komplexer, Integrationen nehmen zu und die Erwartungen der Nutzer steigen. Um Schritt zu halten, entstehen Workarounds, die die Grenzen der Plattform umgehen sollen. Aus einem Workaround werden zwei, aus zweien fünf. Irgendwann funktioniert die Anwendung zwar noch, doch ein erheblicher Teil des Aufwands fliesst inzwischen nicht mehr in die eigentliche Lösung des Problems, sondern in die Anpassung der Plattform.

Der nächste Schritt besteht häufig darin, die komplexe Geschäftslogik in ein eigenes Backend auszulagern und über APIs bereitzustellen.

Doch damit stellt sich zwangsläufig eine weitere Frage.

Wenn auch das Frontend umfangreiche Interaktionen, individuelle Benutzeroberflächen oder komplexes Verhalten erfordert, warum sollte man das Low-Code-Frontend weiter an seine Grenzen bringen, anstatt eine individuell entwickelte Anwendung einzusetzen?

Das bedeutet nicht, dass Low-Code gescheitert ist. Ganz im Gegenteil. Meiner Erfahrung nach eignet sich Low-Code hervorragend für den überwiegenden Teil interner Geschäftsanwendungen. Entwicklungszeiten verkürzen sich, Fachbereiche können schneller iterieren und der operative Aufwand für die IT sinkt erheblich. Passt das Problem zur Plattform, gibt es nur wenige Ansätze, die ähnlich schnell und wirtschaftlich einen Mehrwert schaffen.

Die Herausforderung liegt vielmehr bei den wenigen Anwendungen mit komplexen Workflows, anspruchsvollen Geschäftsregeln, hohen Anforderungen an die Benutzererfahrung oder besonderen Leistungsanforderungen. Gerade diese Projekte verursachen überproportional hohen Entwicklungsaufwand, führen zu architektonischen Kompromissen und werden mit der Zeit immer schwieriger zu warten.

Die eigentliche Erkenntnis ist daher nicht die Diskussion Low-Code oder Pro-Code. Es geht darum, bessere Technologieentscheidungen zu treffen.

Unabhängig davon, ob eine Anwendung mit Low-Code oder mit tausenden Zeilen Code entwickelt wird, sollte der Entwicklungs-Prozess derselbe bleiben. Am Anfang stehen das Verständnis des fachlichen Problems, die Erhebung und Priorisierung der Anforderungen, die Bewertung langfristiger Risiken sowie der Entwurf einer Architektur, die sich weiterentwickeln kann. Erst danach sollte entschieden werden, welche Technologie diese Anforderungen am besten erfüllt.

Die Wahl einer Technologie sollte niemals ausschließlich auf Budget, Gewohnheit oder der Geschwindigkeit eines ersten Prototyps basieren. Investieren Sie zunächst Zeit, um das Problem zu verstehen, die langfristigen Auswirkungen zu bewerten und eine tragfähige Lösungsarchitektur zu entwerfen. Die Plattform sollte das Ergebnis dieses Prozesses sein – nicht dessen Ausgangspunkt.

Jede Technologie hat ihren idealen Einsatzbereich. Gute Technologieentscheidungen entstehen dann, wenn man weiß, wo dieser beginnt und wo er endet.

Stellen Sie sich eine interne Anwendung vor, mit der Mitarbeitende Kundenbestellungen erfassen und verwalten.

Die erste Version ist überschaubar. Mitarbeitende wählen einen Kunden aus, fügen Produkte und Mengen hinzu, erfassen die Bestellung und verfolgen deren Status. Die Benutzer sind interne Mitarbeitende, die sich über Microsoft Entra ID authentifizieren. Die Benutzeroberfläche besteht hauptsächlich aus Standardformularen und die Anwendung nutzt weitgehend die Standardfunktionen der Plattform.

Wenden wir die Entscheidungsmatrix auf die ursprünglichen Anforderungen an, ergibt sich folgendes Bild:

Zu diesem Zeitpunkt befindet sich die Anwendung klar im idealen Einsatzbereich von Low-Code. Die Anforderungen lassen sich weitgehend mit den Standardfunktionen der Plattform abdecken. Dadurch kann das Team die Anwendung schnell umsetzen, ohne unnötige architektonische Komplexität einzuführen.

Die Anwendung hat sich bewährt, doch die fachlichen Anforderungen haben sich weiterentwickelt.

Das Unternehmen möchte nun auch externen Kunden ermöglichen, Bestellungen direkt aufzugeben und zu verwalten.

Kunden benötigen eigene Identitäten und dürfen ausschliesslich auf ihre eigenen Produkte, Preise, Bestellungen und Dokumente zugreifen. Gleichzeitig ist die Preisgestaltung komplexer geworden und umfasst kundenspezifische Konditionen und Geschäftsregeln.

Produktverfügbarkeiten und Bestelldaten müssen über APIs mit mehreren Systemen ausgetauscht werden. Bestimmte Prozesse laufen inzwischen im Hintergrund und die kundenorientierte Benutzeroberfläche erfordert eigene Komponenten sowie eine stärker individualisierte User Experience.

Wenden wir dieselbe Entscheidungsmatrix erneut an, ergibt sich ein deutlich anderes Bild:

Die Anwendung hat sich von 8 auf 26 Punkte entwickelt.

Das bedeutet nicht, dass die ursprüngliche Entscheidung für Low-Code falsch war. Die ursprünglichen Anforderungen passten sehr gut zur Plattform.

Die Anforderungen haben sich verändert.

Auch die höhere Punktzahl bedeutet nicht automatisch, dass die Anwendung neu entwickelt werden sollte. Sie ist vielmehr ein Signal dafür, die bestehende Architektur und die ursprüngliche Technologieentscheidung erneut zu überprüfen.

Ein hybrider Ansatz könnte weiterhin sinnvoll sein: Die Low-Code-Plattform übernimmt bestimmte Teile der Benutzeroberfläche, während komplexere Geschäftslogik und Integrationen durch individuell entwickelte Services und APIs umgesetzt werden. Alternativ könnten sich die Anforderungen inzwischen so weit entwickelt haben, dass eine vollständig individuell entwickelte Anwendung in Betracht gezogen werden sollte.

Die Matrix trifft die Technologieentscheidung nicht. Sie bietet einen strukturierten Ansatz, um zu erkennen, wann sich die Anforderungen und Eigenschaften einer Anwendung so weit verändert haben, dass die ursprüngliche Technologieentscheidung neu bewertet werden sollte.

Eine gute Technologieentscheidung muss nicht zwangsläufig eine dauerhafte Technologieentscheidung sein.