von Neulich bin ich auf einen interessanten Begriff gestoßen: Citizen Developers. Gemeint damit sind Menschen wie du und ich, die auf irgendeine Weise Software entwickeln, ohne besondere IT-Kenntnisse zu haben. Das wirft gleich zwei Fragen auf: a) brauchen wir wirklich ein weiteres Buzzword und b) sind ausgebildete Entwickler etwa keine Bürger oder Menschen wie du und ich?
Spaß beiseite, der Begriff kommt aus dem Umfeld der No-Code-Bewegung, und hier wird es tatsächlich interessant. Denn laut Wikipedia ist damit eine bestimmte Gruppe von Software-Plattformen gemeint – in aller Regel SaaS-Angebote – mit denen Nicht-Techies per Drag-und-Drop Prozesse digital modellieren und damit eigene Anwendungen produzieren. Anstatt die Dinge also zu coden werden sie mittels grafischer Benutzeroberflächen modelliert.
Der größere Bruder dieser Plattformen – das sei der Vollständigkeit halber auch erwähnt – nennt sich übrigens „Low-Code“. Damit gemeint sind Angebote, die sich im gewissen Umfang durch eigenen Code anpassen lassen, um für mehr Flexibilität zu sorgen.
Digitale Prozesschen?
Wer einmal IFTTT oder Zapier benutzt hat, kennt das bereits. Mit diesen Services lassen sich sehr einfach Ketten von Auslösern und Aktionen bilden und damit kleinere Prozesse automatisieren: „wenn ich ein Foto mit der Frontkamera meines Smartphones aufnehme, lade es in den Selfie-Ordner in meinem Dropbox-Account“ – „wenn es an meinem Wohnort regnet, schicke per Gmail eine E-Mail an meine Schwiegermutter“. Das alles funktioniert, indem man sich über diese Plattformen bei Dropbox & Co. authentifiziert und mit ein paar einfachen Dropdowns und Buttons diese Aktionen definiert. Technies werden ahnen, dass sich dahinter eine mehr oder weniger ausgefuchste Kommunikation diverser APIs abspielt – nutzerseitig verschwindet diese Komplexität jedoch völlig.
Gut, werden jetzt Einige sagen, dann lassen sich halt Nerds ihre Privat-Prozesschen über diese Tools erledigen, was hat das denn für einen geschäftlichen Nutzen? Aber je tiefer man sich sich die Materie einliest oder eindenkt, desto klarer werden die Implikationen. Was wäre, wenn sich tatsächlich vieles von dem, mit dem wir es im E-Commerce jeden Tag zu tun haben, über derartige Mechanismen abbilden ließe? Ist nicht generell die Integration verschiedener Systeme sowieso unser täglich Brot und könnten wir so manches nicht mit einfachen „if this then that“-Logiken abhandeln?
Ein erstes Indiz dafür, dass wir möglicherweise die Relevanz dieser Art der Software-Produktion unterschätzen, ist die Tatsache, dass es dazu sogar einen Analysten-Report dazu gibt, nämlich den Gartner Magic Quadrant for Enterprise Low-Code Application Platforms. Hier vertreten sind etwa Plattformen wie Appian, über die Business-Anwender ihre Prozesse automatisieren. Aber auch bekanntere Namen wie Microsoft, Oracle und Salesforce haben mit Power Apps, APEX und Lightning jeweils Low-Code-Produkte im Angebot.
Wer soll das alles coden?
Aber wir müssen uns gar nicht in die Abgründe internationaler Business-Analysten-Terminologie begeben, um Argumente für einen No- bzw. Low-Code-Ansatz zu finden. Bei dem starken Wachstum des Onlinehandels und dem Ruf nach immer neuen „Experiences“ für immer neue Kanäle und immer neue Geräte stelle ich mir schon seit Jahren Fragen wie „wer soll das alles coden?“ und „wurde das nicht schon x-mal gecoded?“ Derzeit haben wir einen Onlineanteil von ca. 20% des gesamten Einzelhandelsumsatzes hierzulande, und schon jetzt müssen Unternehmen sehr kreativ sein, um gute Entwickler weltweit für sich zu gewinnen. Was passiert aber – auch und gerade Corona-bedingt – wenn sich der Anteil auf 30% oder mehr zubewegt? Wer soll das alles coden?
Denn – und so scheint ein ungeschriebenes Gesetz der Branche zu lauten – ohne Programmieren geht es nicht. Seit Mitte der 90er die ersten Shopsysteme auf den Markt kommen, hat sich ein Modus Operandi etabliert, in dem Systemhersteller auf der einen und spezialisierte Agenturen auf der anderen Seite gemeinsam E-Commerce-Projekte für Kunden umsetzen. Die einen sorgen für einen grundlegenden Standard, die anderen programmieren in Hunderten oder gar Tausenden Personentagen auf dieser Basis die besonderen Anforderungen der Kunden. Bei letzteren hat sich besonders im Enterprise-Umfeld deswegen seit Jahrzehnten eingebrannt: IT-Projekte dauern, sind teuer und jeder Änderungswunsch kann unkalkulierbare wirtschaftliche Konsequenzen nach sich ziehen. Und selbst wenn es im Unternehmen eine eigene IT-Abteilung geht, ist die in der Regel mit verschiedensten Aufgaben – Software-Updates, Evaluation eines neuen CRM-Systems, Anschaffung neue Drucker für die Buchhaltung etc. – so ausgelastet, dass die Anfrage eines jungen, engagierten Marketeers, der eigentlich nur einen kleinen A/B-Test auf die Produktdetailseite bringen wollte, als Jira-Ticket länger altert als ein mittelprächtiger französischer Rotwein.
Fairerweise muss man sagen, dass es natürlich Bewegungen gibt. Allen voran sparen Cloud-basierte Systeme das ganze Thema Server-Wartung und Updates von Betriebssystemen. Und Systeme wie commercetools und Spryker sorgen mit ihren Headless- bzw. API-Ansätzen dafür, dass Daten und Prozesse schneller in den unterschiedlichsten Kontexten verwendet werden können, und damit wesentliche kürzere Umsetzungszeiten und vergleichsweise geringe Gesamtkosten möglich sind. Trotzdem braucht es weiterhin extrem fitte Entwickler, die sozusagen die letzte Meile so programmieren, dass die jeweiligen Apps und Shops der Kunden live gehen können.
Ist Software-Entwicklung das neue Excel?
Kommen wir zurück zu unserem ambitionierten Junior-Entwickler. Zweifellos würde er sich freuen, hätte er die Möglichkeit, sich selbst zu helfen und erwähnten A/B-Test ohne Programmierung durchzuführen. Er würde sich damit einreihen in die Ahnenreihe kreativer Bürger-Entwickler, die in den letzten Jahrzehnten wahre Wunder mit Excel und Access vollbracht haben – nur mit moderneren Mitteln.
Für den E-Commerce sehe ich derzeit vor allem Shopify samt Ökosystem als de-facto-Standard für No-Code-Projekte. Das liegt zum einen an der Zielgruppe der kleinen und mittleren Unternehmen, die schnell online gehen möchten, ohne sich komplexe und teure IT-Projekte ans Bein binden zu wollen oder zu können. Zum anderen bedingt SaaS als alleinige Softwareauslieferungsvariante, dass Code-Änderungen – abgesehen von der Templatesprache – nicht möglich sind. Oder anders ausgedrückt: auch wenn Shopify oder beispielsweise Shopware eine ähnliche Zielgruppe haben, sind bei letzterem – sozusagen als ultima ratio – immer noch Core-Hacks oder neue Datenbanktabellen möglich. Shopify nutzt man – meist mit externen Apps – oder eben nicht.
Noch ein weitere Punkt ist mir in diesem Zusammenhang wichtig: die meisten mir bekannten Shopify-Projekte, und die erfahrensten Shopify-Agenturen haben einen viel stärkeren Marketing-Fokus als gewöhnlich. Die Frage nach dem Ursprung des Traffic wird viel eher diskutiert, Händler und Agenturen beschäftigen sich mit SEO, Performance-Marketing, Social-Media und Influencern. Dass es noch einer E-Commerce-Plattform bedarf, die für die Transaktionen und das Payment verantwortlich sind, gerät da fast zur Nebensache. Viele gehen recht hemdsärmelig vor, klicken sich im Learning-by-doing-Modus durch das System, installieren die eine oder andere App und machen sich in Facebook-Gruppen schlau. Und wenn man etwa die Anbindung an ein Lieferantensystem nicht hinbekommt, wird halt Shopify mit Zapier verbunden, eine Bestellung in einer bestimmten Kateogie löst eine Aktion aus, die in ein Google-Spreadsheet für den Lieferanten geschrieben wird. Fertig ist die Integration.
Du als Entwickler oder Architektur wirst bis hierhin immer unruhiger geworden sein und möchtest spätestens jetzt rufen: Das ist doch alles Bastelei! Das ist undokumentierter Bullshit, damit lassen sich doch niemals belastbare, revisionssichere, skalierbare Prozesse bauen! Und Datenschutz!
Stimmt natürlich. Ich würde mich auch sehr unwohl dabei fühlen, wenn etwa meine Bank die Überweisungsdaten per IFTTT in Trello-Karten schreiben würde. Und natürlich graust es mir bei dem Gedanken, dass sich Mitarbeiter aller Abteilungen wie wild No-Code-Anwendungen schreiben und ab der zweiten Woche niemand mehr weiß, wie irgendetwas funktioniert. Keiner kann ernsthaft eine Welt wollen, in der Günthers und Karl-Heinze aus der Rente reaktiviert waren, weil keiner der Jüngeren mehr das Produktverwaltungs-Excel versteht.
Und doch: in unserer Branche sprechen wir so gerne von Agilität, von Time-to-Market, von der Notwendigkeit zu Experimentieren; daher sollten wir zumindest anerkennen, dass bereits jetzt Jugendliche mit den genannten Tools binnen kürzerster Zeit und mit wenig Budget immer komplexere Prozesse modellieren, während sich Scrum-Teams bei Großkonzern ABC noch ihre Namen ausdenken.
(Bild: pexels.com)
