Blick von oben

Es war an einem dieser Mittwoche: Endlose Meetings, und dieses Mal war unser Gesellschafter mit dabei. Nehmen Gesellschafter an einem Meeting teil, sind die Ambitionen immer sehr groß – verschwindend klein wird hingegen das Konkrete. Eine neue Anwendung sollte auf den Markt. Sie war grob skizziert und sollte umgesetzt werden. So weit, so gut. In der Regel mache ich es mir als Entwicklungsleiter dann immer einfach: Ich bitte darum, genau zu spezifizieren, was umgesetzt werden soll. Erst danach setze ich mich an die Umsetzung. Im Wissen darum, dass ich mir hiermit viel Zeit erkauft habe.

Gefährliches Spiel auf Zeit

In diesem Fall war es anders. Ich wusste, dass die Spezifikationen so bald nicht kommen würden, die Erwartung aber trotzdem blieb, dass wir in einem Jahr liefern. Mit meinem Vorgehen, auf Zeit zu spielen, würde ich mich und meine Entwicklungsabteilung also nur in die Enge treiben und in der kurzen Zeit zwischen fertigen Spezifikationen und Release für Stress und Hektik sorgen. Wenig Entwicklungszeit bedeutet dann auch immer schlechte Qualität, viel ungeplante Nachsorge und noch mehr Hektik.Was also tun? Jetzt schon eine App schreiben aufgrund der vagen Spezifikationen? Eine App, die man nachher wieder komplett umbauen kann, weil sie nicht das tut, was gefordert ist? Die Änderungswünsche werden uns dann am Ende Kopf und Kragen kosten. Oder selbst mit den zukünftigen Nutzern zu reden, was denn genau gewünscht sei? Dazu fehlten mir die Lust und die Zeit. Und wenn die Entwicklungsabteilung zu viel mit den Endkunden zu tun hat und Consulting und Produktmanagement außen vor sind, dann ist die Akzeptanz des Produktes innerhalb der Firma und somit auch das Engagement der Kollegen begrenzt. Warum sollen sie sich um etwas kümmern, das sie nicht selbst erfunden haben?

Immer schön flexibel bleiben

Mein Problem ließ sich also so umreißen: Baue möglichst schnell etwas, das aber flexibel sein muss und bei dem erst in einem Jahr feststeht, wie es genau aussehen soll. Am besten baue es so, dass du dich nachher mit den Details gar nicht mehr auseinandersetzen musst. Denn sobald ein Entwickler Felder auf Formulare zieht, sitzt er immer zwischen den Stühlen. Da gibt es die Fraktion, die der Meinung ist, möglichst alle Informationen und Felder sollten auf den Screen, und die anderen, die eher puristisch eingestellt sind. In diesen Strudel will ich mich und meine Leute nicht bringen. Am besten wäre, dass die Nutzer entscheiden, wie was auszusehen hat, und eine Änderung wäre dann schnell von denen, die die Nutzer befragen, umgesetzt.Neben diesem Problem beschäftigten mich noch andere Fragen. Ich war bei der Firma angetreten, um die Entwicklung effizienter zu gestalten. Das klappt nur mit Automatisierung und Standardisierung. Es gab Situationen, da entwickelten wir für einen Kunden eine spezielle Software über ein Jahr hinweg. Und die Pflege und Weiterentwicklung dieser individuellen Software belastet dann das ganze Team. Bei Wartung und Upgrades handelt es sich zudem um Leistungen, die schwer zu verrechnen sind.

Don’t repeat yourself

Doch leider ist es immer noch so, dass wir immer wieder „das Gleiche in Grün“ machen, und wenn man sich nach einigen Jahren die „alten“ Anwendungen anschaut, merkt man, wie altbacken sie wirken, weil die ganze Innovation inzwischen weitergegangen war, aber eben nicht für jedes Projekt die Zeit verfügbar war, sie dort zu implementieren.Der dritte Punkt, der mich umtrieb, hat mit dem Web im Allgemeinen zu tun. Mehr als die Hälfte der Entwickler und viele Partner, die wir haben, sind noch in der On-Premises-Welt zu Hause. Sie entwickeln oder betreuen also Anwendungen, die ein Setup haben und bei denen UI und Logik quasi mehr oder weniger im selben Layer liegen.Wie schaffen wir es, sie in die Web-Welt mitzunehmen? Wie kann man Kompetenzen aufbauen oder an bestehende Kompetenzen anknüpfen? Wie immer gilt: Web zu machen ist an sich nicht so schwer, aber gutes, performantes, sicheres, modernes Web, das ist eine andere Nummer. Und dies ist inzwischen State of the Art.Webentwicklung erfordert oft ein komplettes Umdenken, wenn man es gleich von Anfang an richtig machen will. Der API-First-Ansatz, der SPA-Ansatz (Single Page Application), all das ist Desktop-Entwicklern fremd. Aber nur so kommen wir zu Webanwendungen, die die Erwartungen der Kunden erfüllen. Das jemandem beizubringen und ihn hier zu schulen und abzuholen, ist ein weiter Weg. Ein Weg, den man sich leisten können muss, ein Weg, der Zeit erfordert und die Möglichkeit, Fehler zu machen.

Quo vadis?

Da sitze ich also nun mit meinen Problemen, und die Frage ist: Was tun? Als Pilot bin ich es gewohnt, immer wieder aufzusteigen und die Welt aus einer gewissen Distanz zu sehen. Und dann wieder zu landen, um im Konkreten meine Schritte zu gehen. Und wenn ich mal mit all den Problemen, die ich eben beschrieben habe, abhebe, dann sehe ich von oben ein klares Bild. Ich sehe, wie sich unsere Consultants und Partner mit ein paar Klicks ihre Anwendung selber bauen, weil sie von uns die Werkzeuge dazu bekommen haben. Oder noch besser, wie eine KI das tut und auf Anforderungen reagiert, die die Consultants ihnen diktieren. Und ich sehe, wie wir Entwickler am Strand sitzen, Cocktails schlürfen und auf eine E-Mail mit dem Betreff „Ich brauche mal eben“ gelassen antworten: „Das geht schon, verwende dazu einfach unseren Assistenten.“ Kurz gesagt: Ohne unsere Hilfe bauen unsere Consultants in der nötigen Zeit skalierbare, sichere und coole Webanwendungen.Was ist jetzt nach der Landung zu tun? Wie komme ich zu dieser Vision? Was wäre die Strategie?Für mich war sonnenklar: Man muss entweder eine Low-Code- oder No-Code-Plattform einkaufen oder – wenn das zu teuer oder nicht machbar ist – sie eben selbst entwickeln. Mit zu teuer meine ich, wenn nicht nur die Anschaffungskosten, sondern auch die laufenden Runtime-Kosten deutlich höher sind als das, was die Kunden am Ende zu zahlen bereit sind. Wenn eine Low-Code-Plattform eine monatliche Gebühr pro Benutzer fordert, dann kann ich mit dieser Plattform nicht wachsen. Ich kann nicht skalieren, weil die Kosten mitwachsen. Wenn allerdings die Firmenstrategie auf ein Framework setzt, dann sollte sie damit wachsen können. Ein Wechsel danach ist nicht mehr so leicht möglich.

Make or buy?

Eine Eigenentwicklung birgt allerdings viele Risiken: Werde ich mit den bestehenden Ressourcen in der Zeit fertig? Wie schnell kann ich Innovation ins Framework bringen? Denn wenn wir zu langsam sind, beispielsweise bei der Anbindung von Mailkonten oder Kalendern, dann hat das große Auswirkungen für die Firma. Zudem erfordert eine Eigenentwicklung eine gewisse Kapitalkraft. Man muss eine Durststrecke aushalten können, in der quasi nichts Produktives oder besser gesagt nichts Verkaufbares entsteht.Dass der Weg aber Richtung Framework ging, zeigte noch eine weitere Entwicklung: Wir hatten unsere Entwicklung in zwei Teams aufgeteilt. Eines war federführend für Projekte zuständig, also die Entwicklung von individueller Software für einen speziellen Kunden. Das zweite Team verantwortete die Entwicklung von Produkten. Und bei der Entwicklung von Produkten gilt im Unterschied zum Projekt: Das Featureset kommt vom Produktmanagement und der Kunde kommt entweder mit dem Funktionsumfang klar, oder es ist nicht der richtige Kunde.

Produkt = Projekt = Produkt

Mit der Zeit wurde uns klar, dass die Unterscheidung zwischen Projektentwicklung und Produktentwicklung sich nicht wirklich konsequent durchhalten lässt. Die Projekte haben oft Funktionen gebraucht, die in den Produkten waren und deren Entwicklung für einen einzelnen Kunden unwirtschaftlich wäre. Auf der anderen Seite passen Produkte nie zu 100 Prozent. Je anpassbarer sie sind, desto besser – was ­ihnen wiederum Projektcharakter verleiht. Auf gut Deutsch: Die scharfe Grenze zwischen Projekten und Produkten verschwindet. Jedes Produkt muss projektfähig (also anpassbar) sein, und in jedes Projekt muss ich Bestandteile eines Produktes einbinden können.Die nachhaltigste Antwort auf all diese Herausforderungen, aber eben auch die anstrengendste war es, eine No-Code-Plattform zu entwickeln. Bewusst mit No Code zu beginnen und später Ansätze der Erweiterung für Low Code zu ermöglichen.

Auf krummen Wegen

Was sich jetzt anhört wie eine glasklare Entscheidung und ein absolut stringenter geradliniger Weg, war alles andere als das. Ich hatte bereits in der Vergangenheit ein webbasiertes ERP-System geschrieben, das auf möglichst wiederverwertbaren Komponenten aufbaute, aber aufgrund des Zeitdrucks doch zu spezifisch wurde. Da gab es eine Artikel-Klasse, die konkret eine Rabatt-Property hatte, und somit war aller generischer Ansatz wieder dahin. Aber ich wusste, worauf es ankam, welche Fehler wir damals gemacht hatten, und nahm mir zwei Wochen Zeit, um ein wenig Prototyping zu betreiben. Lassen sich ein API und eine Datenbank schreiben, denen es egal ist, ob sie einen Artikel oder einen Kunden speichern? Kann ich trotzdem performant filtern, sortieren et cetera? Nachdem die ersten Tests vielversprechend waren, hatten wir alle die nötige Blauäugigkeit, die immer wichtig ist, wenn man etwas Großes beginnt, und so kam es zum Startschuss.Erst etwas später und durch das frühe Vorstellen der Ideen in den verschiedenen Abteilungen in unserer Firma und nach außen schärfte sich der Blick auf das, was wir da begonnen hatten und aus dem wir nicht mehr herauskamen: Wir schrieben tatsächlich eine No-Code-Plattform (siehe Kasten Begriffsdefinitionen).

Wir teilten also unser Team auf in professionelle Webentwickler, die ein Framework bereitstellen, und die Anwendungsentwickler, die zusammen mit den Kunden, dem Marketing und dem Produktmanagement dann die eigentliche App schreiben.

It’s a product, stupid!

Dabei entdeckten wir – welch Wunder: Die Entwicklung einer Plattform verläuft wie die Entwicklung eines eigenen Produktes und bedarf all dessen, was auch ein normales Produkt braucht: eine genaue Abgrenzung des Featuresets, eine Roadmap mit Milestones und Epics, einen Produktmanager, das kontinuierliche User-Feedback, ein ansprechendes UI, Verständlichkeit und Usability und so fort.Und dabei muss man immer abwägen, wie viel Freiheit man dem Consultant oder Anwendungsentwickler geben will. Ist es zu wenig, kann man gewisse Aufgabenstellungen nicht umsetzen. Ist es zu viel, ist der Anwender schnell überfordert. Er kann Fehler machen, also Einstellungen vornehmen, die zu einem unerwünschten Verhalten führen.Als Entwickler einer solchen Plattform sieht man sich daher gezwungen, viele Entscheidungen bereits im Vorfeld zu treffen, um das Leben für die Anwender einfacher zu machen. Es ist also sehr komplex, eine Plattform zu entwickeln, die alle Eventualitäten berücksichtigt und dafür eine Lösung hat. Der Nachteil dabei: Entscheidungen, die man hier trifft, sind nicht immer transparent für den Anwender, und wie bei allem gibt es nie einen goldenen Weg. Was für Szenario A richtig ist, passt möglicherweise für Szenario B nicht. Jeder, der Software entwickelt, kennt dieses Problem. Genau aus diesem Grunde gibt es ja Controls, die nur Entwickler bedienen können, weil sie 200 Eigenschaften haben.

Wir denken für euch

Ein konkretes Beispiel ist das Resizing einer Tabellenspalte. Was soll passieren, wenn ein Anwender eine Tabellenspalte verändert? Soll die Breite der Spalte sein eigenes Setting sein und die Einstellung der Anwendung überschreiben? Wie kann er es zurückstellen? Will er, dass alle Spalten proportio­nal verkleinert werden, wenn man die Tabelle verkleinert? Was ist die Mindestbreite? Richtet sie sich nach dem Datentyp? Beim Datum ist das klar, aber bei einer Zahl? Wir wissen ja nicht, ob die Zahl später der Preis, die Anzahl der Positionen oder der Umfang in Millimetern ist.Klassisch löst man solche Probleme, indem man dem Benutzer alle Einstellungen zur Verfügung stellt: MinWidth, MaxWidth, Width, Flex, Auto, Grow und so fort. Aber wo wäre dann der Unterschied zu einem Entwicklungswerkzeug? Und vor allem: Wer kennt den Unterschied zwischen Auto und Grow?Dass für die Entwickler oder Anwender einer Low-Code-/No-Code-Plattform die Folgen ihrer Einstellung nicht transparent sind oder dass viele Dinge implizit passieren, sorgt für Verunsicherung. Dieser Kontrollverlust kann Angst und somit eine Aversion gegen die Software auslösen. Auf der anderen Seite ist es sehr bequem, sich über viele Dinge keinen Kopf mehr machen zu müssen. Hier ein weiteres Beispiel:Bei einem No-Code-/Low-Code-Framework wird eine gewisse Abstraktionsebene zwischen die auscodierte Komponente und den Anwendungsentwickler gelegt. Über eine ­deklarative Metasprache wird das gewünschte Verhalten erzeugt. Diese Metasprache hat einen starken Fokus auf die Semantik; im Vordergrund steht also die Bedeutung des Codes, nicht die Ausformulierung mit allen Varianten. Meist werden die Metadaten über eine Benutzeroberfläche eingestellt, im Idealfall über einen Assistenten. Es gibt aber auch Low-Code-­Plattformen, die die Definition eines Formulars über eine eigene Sprache ermöglichen. Hier ein Beispiel: Wenn wir Entwickler Code schreiben, wird der in etwa so aussehen:

Ein Low-Code-Framework sollte dagegen nur noch semantischen Code ermöglichen, beispielsweise:

Der Code ist Nonsens, das gebe ich zu. Mir geht es nur da­rum, dass bei einer Low-Code-Plattform die Logik dafür, wer Formulare speichern darf, wie die Formulare an Listen gebunden werden und Ähnliches, schon vom Framework übernommen wird. Dass es keine Einstellung dazu gibt, welche Schriftart oder Schriftgröße der Titel der Seite haben soll. Das Framework hat eine Idee, wie eine Anwendung zu funktionieren hat, und übernimmt Aufgaben wie Rechteverwaltung beim Speichern und Anzeigen, das Featureset einer Liste und so weiter.

Status by Status

Bei einer No-Code-Plattform muss es Möglichkeiten geben, Abläufe über eine grafische Oberfläche zu definieren, die wie in Bild 1 gezeigt aussehen könnte. Also beispielsweise Status für Workflows in einer Liste anzugeben und dann mögliche vordefinierte Aktionen wie das Senden eine Mail oder das Zuweisen einer Aufgabe zu erledigen (Bild 2). Es ist kein Platz für viel Logik, will man nicht mit Editoren für Formeln oder MiniCode doch wieder das Coding in das Framework bringen. Das bedeutet aber auch, dass Anwendungen, die auf No-Code-Plattformen basieren, nicht viel Geschäftslogik enthalten können/sollen. Auf der anderen Seite reicht das reine Zusammenstellen von Tabellen und Formularen in der Regel nicht aus, um damit einen gewissen Mehrwert für den Benutzer zu bieten. Was also tun? Ein ewiges Dilemma.

Entwickelt man ein No-Code-Framework, braucht es dazu eine gewisse Legitimation. Was zeichnet genau dieses Low-Code-Framework aus, was kann es besonders gut und was nicht? Spätestens die Kollegen in der Marketingabteilung, wenn nicht vorher schon der Geldgeber, wollen wissen, warum man ein Framework entwickelt und eben nicht etwas von der Stange nimmt.Für uns war klar, dass wir im HR-Umfeld entwickeln und dass das Framework damit bestimmte Funktionalitäten mitbringen muss. Diese müssen sehr abstrakt und flexibel sein.

Unique or best – or both!

Also ging es erstmals in die Research, was denn eine HR-Software auszeichnet. Was unterscheidet sie von einer ERP-Anwendung? Für mich waren das: Jeder Wert einer Spalte braucht eine Gültigkeit. Ein Mitarbeiter kann heute in der Stiehlerstraße 10 wohnen, ab dem 14.9. aber in der Hunnenstraße 13. Die Datenstruktur, die darunter liegt, muss also Information je nach Gültigkeitszeitpunkt zurückgeben. Das Zweite war, dass gerade im HR-Umfeld die Rechtestruktur sehr komplex ist. Berechtigungen müssen bis auf Feldebene gehen. Ein Mitarbeiter darf die Telefonnummer seines Kollegen sehen, aber nicht dessen Gehalt oder die Liste seiner Krankheitstage. Und ob er das sehen darf, liegt daran, ob er in der gleichen Abteilung ist. Der dritte Punkt war also, dass alle Berechtigungen und Funktionen letztendlich in eine Organisationsstruktur eingebunden sein müssen. Die Aufgabe, den Urlaub zu genehmigen, muss immer der Vorgesetzte erfüllen. Das ist nach Organigramm aber immer eine andere Person. Oder für die Verwaltung der Büros ist der Niederlassungsleiter zuständig.Mir geht es hier nicht um die Beschreibung, welche Funktionen wir in unserer Plattform implementiert haben. Mir geht es darum, dass die Plattform genau zu der Aufgabe passen muss, für die ich sie verwende. Und dass der Mehrwert dann entsteht, wenn man so zu einer semantischen Programmierung kommen kann. Beispielsweise: Schicke eine Mail an den Stellvertreter.

Produkt = Code plus Metadaten

Ich habe jetzt viel davon gesprochen, wie es ist, eine No-Code-Plattform selbst mitzuentwickeln. In der Regel werden Sie vielleicht eher eine fer­tige solche Plattform einsetzen. Damit verändert sich natürlich für Sie der Begriff dessen, was ein Programm ausmacht. Denn in Zukunft ist das nicht mehr nur ein Docker in der Version 1.0 oder eine Datei SetupV1.2.exe. In Zukunft besteht ein Programm immer aus dem Code des Frameworks und den Metadaten, die den Aufbau der Formulare, den Ablauf des Workflows und die Struktur der Datenablage beschreiben. Das bringt neue Komplexität ins Spiel, denn Metadaten und Programmver­sion müssen zusammenpassen.Und wenn das Framework so weit geht, dass es auch dem Kunden erlaubt, Metadaten zu ändern und anzupassen, was bedeutet es dann noch, ein Update auszuliefern? Was macht dieses Update dann mit den Anpassungen der Kunden? Und wenn die Plattform immer dieselbe ist, wie ist es dann, wenn der Kunde zwei Anwendungen hat? Laufen diese auf der gleichen Datenbank, oder legen Sie pro Anwendung eine eigene an? Ja, was ist denn überhaupt eine Anwendung noch, wenn sie sehr schnell für User A ganz anders aussehen kann als für User B? Weil es ja doch „nur“ eine Konfiguration ist. Sie sehen, dass ein solches Framework ganz neue Fragestellungen aufwirft.Warum sollte man als Entwickler überhaupt Low-Code-Plattformen ernst nehmen, wo doch Programmieren unsere Kernkompetenz ist? Und reden wir hier von einem Hirngespinst oder einem realen Szenario? Ich habe Ihnen im Kasten Zahlen und Fakten ein paar Informationen zusammengestellt, und ich war selbst überrascht, wie sehr ich in meiner Wahrnehmung bisher die Relevanz solcher Systeme übersehen hatte. Bei meiner Recherche kam auch heraus, dass wir in Deutschland dem Trend Low Code/No Code hinterherhinken. Zur Ehrenrettung muss man sagen, dass ich bereits in Ausgabe 3/2021 der dotnetpro [1] davon gesprochen habe, dass unser Ziel eigentlich „No Code“ sein sollte. Nur war das damals etwas anders gemeint …

Fokus, Fokus, Fokus!

Tatsächlich geht es bei den No-Code-/Low-Code-Ansätzen weniger darum, Entwickler überflüssig zu machen, als vielmehr darum, ihre Zeit sinnvoller und effizienter einzusetzen. Low-Code-Plattformen reduzieren den Anteil repetitiver Aufgaben enorm und ermöglichen uns, sich auf komplexe und kreative Aspekte unserer Projekte zu konzentrieren. Nehmen wir eine einfache Benutzerverwaltung als Beispiel: Warum Authentifizierungslogik und Schnittstellen stets neu implementieren, wenn dies mit wenigen Klicks erledigt werden kann?Ein anschauliches Beispiel liefert der Automobilzulieferer Bosch. Dort setzt man intern auf Low Code, um Entwicklungsprozesse deutlich zu beschleunigen. Ein Dashboard, das Produktionskennzahlen aggregiert, entstand in drei Tagen statt der üblichen drei Wochen. Schnelleres Feedback, frühzeitige Erkennung von Problemen und enorme Kosteneinsparungen sind unmittelbare Vorteile. Zusätzlich steigt die Motivation der Entwickler, denn monotone Aufgaben fallen weg.Low Code bedeutet auch, Softwareentwicklung in die Hände von Beratern und Fachanwendern zu geben. Frameworks und Toolkits ermöglichen es Menschen ohne tiefgehende Programmierkenntnisse, eigenständig Webapplikationen zu entwickeln. Der von uns entwickelte Web-App-Builder etwa reduziert die Time to Market erheblich. Sein Fokus liegt dabei auf einer prozessbasierten, flexiblen Zusammenarbeit rund um Personen, Daten und Inhalte. Durch die Verknüpfung von vorhandenen HR-Systemen entsteht schnell ein Mehrwert für Kunden.Plattformen wie Mendix zeigen bereits heute, dass Low Code nicht nur für einfache Aufgaben geeignet ist, sondern sich damit auch komplexe, geschäftskritische Anwendungen abbilden lassen. Siemens nutzt Mendix beispielsweise, um IoT-Lösungen zur Anlagenüberwachung zu erstellen. Das Entwicklerteam besteht dabei nicht nur aus Programmierern, sondern auch aus Ingenieuren und Fachanwendern, die eigenständig Änderungen durchführen können. Diese Demokratisierung verbessert nicht nur die Nutzerzufriedenheit, sondern reduziert auch aufwendige Korrekturschleifen.Natürlich gibt es Anwendungen, bei denen Low Code an Grenzen stößt, etwa bei hochspezialisierten Aufgaben mit komplexer Businesslogik oder besonderen Performance-Anforderungen. Hier setzen viele Unternehmen auf hybride Ansätze. Die Microsoft Power Platform beispielsweise erlaubt eine nahtlose Integration von individuell programmierten APIs und Azure Functions, wodurch komplexe Backend-Funktionalitäten flexibel erweitert werden können. Solche hybriden Lösungen bieten sowohl die Schnelligkeit und Flexibilität von Low Code als auch die tiefgehende Kontrolle und Anpassbarkeit von traditionellem Code.

It’s all about the money

Wirtschaftlich gesehen sind Low-Code- und No-Code-Plattformen äußerst attraktiv. Laut Studien lassen sich Entwicklungszeiten um bis zu 70 Prozent reduzieren. Das bedeutet enorme Kosteneinsparungen und ermöglicht gerade Start-ups und KMUs schnelle und kostengünstige Prototypenerstellung und Innovationen. Bubble.io etwa ermöglicht es Nutzern, komplette Webapplikationen ohne Programmierkenntnisse zu erstellen. Das Start-up Qoins validierte seine Geschäftsidee mit Bubble.io schnell und kostengünstig – heute verarbeitet das Unternehmen Millionenbeträge.Die Zukunft der Softwareentwicklung liegt nicht ausschließlich in Low Code – aber sie findet sicherlich auch nicht mehr ohne dessen Einsatz statt. Low Code und No Code verändern nachhaltig, wie wir entwickeln, wie wir mit Fachabteilungen zusammenarbeiten und welche Rolle KI zukünftig in der Softwareentwicklung spielt. Entwickler, die diese Möglichkeiten verstehen und nutzen, werden in der Lage sein, schneller, kreativer und wirtschaftlich erfolgreicher zu agieren. Die Integration von KI und flexiblen Frameworks wird hierbei ein entscheidender Faktor sein – für Entwickler und Unternehmen gleichermaßen.

KI als Zuckerguss obendrauf

Dadurch, dass man bei den Frameworks eine semantische Zwischenschicht – die Metadaten – eingeführt hat, bietet es sich geradezu an, einer KI die semantischen Regeln beizubringen und so intelligente Empfehlungen zur Anordnung von UI-Elementen oder zur Gestaltung von Workflows geben zu lassen. Also die KI diese Metadaten erzeugen zu lassen und am Ende doch eine hundertprozentig sichere und funktionale Anwendung zu haben.Eine KI könnte daher in Zukunft den Entwicklungsprozess noch aktiver unterstützen. Man könnte sich beispielsweise ­eine Plattform vorstellen, die automatisch erste Versionen von Anwendungen generiert, basierend auf Anforderungen, die der Nutzer in natürlicher Sprache beschreibt. So könnte ein Nutzer etwa sagen: „Ich benötige eine App, die Vertriebszahlen visualisiert und den Vertriebsmitarbeitern automatisiert wöchentliche Berichte schickt. Informationen zum Aufbau un­serer Firma findest du auf unserer Website.“ Eine KI könnte daraus automatisch eine grundlegende Applikationsstruktur erstellen, diese mit vorgefertigten Modulen kombinieren und dem Nutzer zur weiteren Anpassung präsentieren. Dies würde die Entwicklung erheblich beschleunigen und gleichzeitig die Einstiegshürden für Nichtprogrammierer nochmals senken.Für uns bietet die selbst entwickelte No-Code-Plattform auch vertrieblich ein riesiges Plus. Denn ein Vertriebler kann schnell für den ersten Verkaufsprozess eine kleine Anwendung zusammenklicken. Um ehrlich zu sein, wollen wir aber den Vertrieb ebenfalls auf „No Code“ umstellen: Über ein Webportal kann sich ein Anwender nicht nur seine Anwendung konfigurieren, sondern bekommt dazu gleich die passende Kostenübersicht und kann monatlich kündigen.

Fazit

Es ist klar, dass nicht alles Gold ist, was glänzt. Ich kenne viele Entwickler, die No-Code-/Low-Code-Plattformen skeptisch gegenüberstehen, da sie befürchten, dass diese Tools tradi­tionelle Programmierfähigkeiten entwerten könnten. Zudem gibt es Bedenken hinsichtlich der Skalierbarkeit und Wartbarkeit der so erstellten Anwendungen. Anwender haben die Angst, in eine Sackgasse zu geraten, wenn die Anforderungen einmal so komplex werden, dass sie nicht mehr durch die Plattform abgedeckt sind. Und für ITler mag es der Horror sein, wenn sie nicht wissen, wie sicher genau die Daten sind, die sich hinter einem Framework verbergen.Für mich ist es wichtig, dass wir nicht immer an der Zeile Code kleben bleiben, die vor uns aufleuchtet, dass wir uns davon lösen, abheben und aufmachen zu neuen Möglich­keiten. Es ist wichtig, unsere Arbeit hin und wieder aus der Vogelperspektive zu betrachten und zu schauen, was davon vielleicht in einem Framework besser aufgehoben ist.Das ist eine andere Art zu entwickeln. Vollkommen klar. Aber ich denke, inzwischen haben wir doch alle eingesehen, dass wir nicht auf jedem Gebiet die Helden sein können, dass spätestens seit dem Siegeszug der KI unsere Arbeit in Zukunft viel mehr Orchestrierung ist, dass wir also immer mehr zu Dirigenten mutieren, anstatt im Orchestergraben von Sitzplatz zu Sitzplatz zu springen und dabei zu glauben, nur weil wir Musiker sind, könnten wir jedes Instrument spielen.

Fussnoten

1. Bernhard Pichler, Abläufe ohne Code, dotnetpro 3/2021, Seite 114 ff., http://www.dotnetpro.de/A2103LowCode
2. Marketing Scoop, http://www.dotnetpro.de/SL2506-07LowCode1
3. Kissflow.com, http://www.dotnetpro.de/SL2506-07LowCode2
4. Fadabase.io, http://www.dotnetpro.de/SL2506-07LowCode3
5. Saasworthy.com, http://www.dotnetpro.de/SL2506-07LowCode4
6. Userguiding.com, http://www.dotnetpro.de/SL2506-07LowCode5
7. Baserow.io, http://www.dotnetpro.de/SL2506-07LowCode6