Die Idee, dass wir nun alle Projektleiter mit No-Code-Werkzeugen ausstatten und statt Excel-Listen mit den Mitarbeitern zu pflegen, gleich Apps generieren, optimiert generiert für Dateneingabe, Statusrückmeldungen, Arbeitsnachweise, you name it, bereit für den Produktivbetrieb, muss leider ein Wunsch bleiben.
Realistisch ist: Durch No-Code und Low-Code rücken die fachlichen und nicht-funktionalen Anforderungen näher an die Umsetzung. Die Umsetzung kann effektiver agieren. Für wenig exotische bzw. wenig innovative Geschäftsprozesse werden nicht mehr unbedingt spezielle Programmierer benötigt. Sodass Informationen durch die Organisation hinweg schneller und zuverlässig auflaufen und gesammelt werden können.
Besonders Prozessverantwortliche in Projekten oder Abteilung einer Organisation durften häufiger das Bedürfnis haben, Abläufe direkter beeinflussen zu können, als ständig durch alle Phasen der Softwareentwicklung zu müssen. Ein Exceldokument hier, ein Abrechnungsbogen da und zu dem spezielle Anforderungen vom Kunden. Für diese Prozesse gleich eine Entwicklermannschaft zu beauftragen, ist mindestens aufwändig und immernoch keine schneller Prozess. In den wenigsten Fällen ist es überhaupt finanziell sinnvoll. Schön wäre es, wenn nichttechnisches Personal die Workflows zusammenklicken könnten, oder?
Dieses Versprechen macht uns Low-Code und No-Code.
Den Wunsch, dieses lästige „Programmieren“ klickbar zu machen und damit die Möglichkeiten, die Programmierern im Allgemeinen vorbehalten sind, allen zugänglich zu machen, gibt es schon seit je her. Und gute Entwickler arbeiten auch selbst daran, sich selbst überflüssig zu machen. Seit der Nutzen von Software für Unternehmen oder Privatpersonen klar wurde, ist das praktisch so.
Den Entwickler herausrationalisieren
Gleich zu Beginn von Internet und Hypertextdokumenten (HTML) gab es im Officepaket von Microsoft das zweifelhaft berühmt gewordeme „Frontpage“. Die Idee war damals schon klar: Lasst und das lästige Programmieren aus der Gleichung kürzen, damit jeder Webseiten bauen kann. Das hat nicht funktioniert, zu komplex die Aufgabe. Mit Internetdiensten, die den Desktopnanwendungen in Funktion und Bedienung immer ähnlicher wurden (heute Progressive Webapps, abgekürzt PWA), war schnell klar: Das ist kein Problem, was man durch Ziehen und Klicken lösen kann.
Die Software „WordPress“ füllt diese Lücke seit Jahrzehnten bestmöglich aus, was ihr Beliebtheitsgrade widerspiegelt. Kleine- und mittlere Unternehmen klicken sich aus unzähligen Plugins ihre Webprojekte zusammen. Längst nicht nur einfach Internetseiten, sondern rudimäntare Plattformen, Communities, Webshops, Terminabspracheformulare, Feedbackfunktionen und andere Webapplikation (ich denke, man darf sie so nennen) werden da zusammen geklickt. Sicherlich bereits die Anfänge von Low-Code und No-Code.
Ein Spaß ist das meistens jedoch auch nicht und längst vermisst der Enduser bei den Ergebnissen eine gewisse Beständigkeit, Robustheit und Sauberkeit. Die Eingabemasken zu Erstellung der Applikation enthalten jetzt natürlich die Komplexität, mit der normalerweise die Programmierer in ihrem Code umgehen müssen. Jetzt werden unzählige Entscheidungsbäume, Automatisierungsregeln, Datentypen und sonstige komplexe Aufgaben eben über eine entsprechende komplexe Eingabemaske gelöst.
Der klare Vorteil ist schonmal, dass nun keine eigene Sprache gelernt werden muss. Es ist also möglich, so zu gewünschten Ergebnissen zu kommen. Man wird weniger auf Softwareingenieure angewiesen sein. Irgendjemand – muss weiterhin sagen, wie das Zusammenspiel von verschiedenen Anwendungen ablaufen soll, worauf es beim Komponieren von Anwendungen ankommt, wo die Anwendungen im Gesamtunternehmen, im Gesamtprojekt einzuodnen sind. Doch sie werden nicht mehr ständig für die gesamten Phasen der Anwendungsentwicklung benötigt.
Interessant ist dieser Trend auf jeden Fall. Das größte Problem, was wir an unnötigen Overhead derzeit noch haben, ist, dass viele Prozesse von den Entwickler wieder und wieder neu entwickelt werden. Diese Arbeitszeitverschwendung könnte durch Low-Code und No-Code bald der Vergangenheit angehören. Denn komplizierte Datenbankgestaltungen könnten tatsächlich der Vergangenehit angehören.
Ingesamt kann also der Einsatz von No-Code dazu führen, dass ein Entwicklerteam innerhalb eines Projektes oder Unternehmens effizienter und schlanker wird. Auch wird es möglich, dass juniorigere Kollegen robustere Ergebnisse erzielen, da sie durch den No-Code-Ansatz nicht anders können, als bereits reife Arbeiten wiederzuverwenden und das Rad daher nicht immer wieder neu erfinden (wie sie es sonst tendenziell tun).
