Governance für No-Code: Wie lassen sich durch Power Apps & Co. erstellte Applikationen im Zaum halten?

Wie meine Kollegin Kristina Dörfl und ich in unserem vorangegangenen Artikel dargelegt haben, ist eine Applikationsentwicklungslösung für Anwender:innen aus den Fachbereichen ein gutes Tool, um die persönliche und teambezogene Produktivität zu steigern: Langwierige Aufträge an die IT erübrigen sich; anstatt Codezeilen zu tippen, können die Citizen Developer mit grafischen Elementen arbeiten. Und sie brauchen nicht auf den Compiler zu warten, um Ergebnisse zu sehen.

Aus Sicht der IT gibt es dagegen viele Probleme: Wenn alle ihre eigenen Anwendungen programmieren, geht der Gesamtüberblick rasch verloren. Das Microsoft-Tool „Power Apps“ beispielsweise hat über 1000 zertifizierte Konnektoren zu anderen Systemen. Dadurch könnten Security-Vorgaben ausgehebelt und sensible Daten plötzlich in die Hände von Unbefugten gelangen.

Last, but not least droht die Gefahr einer Schatten-IT, also von IT-Komponenten, die an der IT vorbei beschafft oder entwickelt werden. So verliert die IT den Überblick darüber, welche Applikationen im Unternehmen existieren. Vor allem aber kann sie nicht nachvollziehen, mit welchen anderen Systemen diese interagieren. Die Konsequenzen dieser „IT-Anarchie“ reichen von relativ unkritischen Doppelentwicklungen über Zuständigkeitskonflikte bis hin zu ernsthaften Security- und Privacy-Verletzungen.

Verwaltung – Überwachung – Warnung

Was hier fehlt, ist eine umfassende Governance, welche auch die vom Citizen Developer entwickelten Applikationen einschließt. Auf eine kurze Formel gebracht, empfehlen wir: verwalten, überwachen und warnen.

Zunächst geht es darum, die Umgebung zu verstehen und eine unternehmensspezifische Strategie zu entwickeln. Es muss zum Beispiel dafür gesorgt sein, dass die Umgebung nicht ausufert. Zum Komplex „Verwalten“ gehört auch ein rollenbasiertes Berechtigungskonzept. Hier wird festgelegt, welche Personen welche Daten nutzen dürfen. Entsprechend müssen bestimmte Konnektoren, etwa zu den HR-Systemen, für die Applikationen ausgeschaltet werden.

Ergänzend kann die Governance, also diejenigen Mitarbeiter:innen, die für die Verwaltung von eigenen Applikationen zuständig und meist in der IT angesiedelt sind, Regeln für den Umgang mit bestimmten Datentypen definieren. Vielleicht beschließt sie aber auch, kritische Daten nicht in der Microsoft-eigenen Datenplattform „Dataverse“, sondern zum Beispiel in einer gesonderten SQL-Datenbank zu halten. Ein weiterer Punkt betrifft die Bereitstellungsumgebungen (etwa DEV, TEST oder PROD). Inwieweit muss die gemeinsame Nutzung derselben Entwicklungsumgebung eventuell eingeschränkt werden? Gleichzeitig kann auf einer Testumgebung dem Citizen Developer mehr Freiraum gegeben werden.

Nutzungsrichtlinien, mit denen Sicherheits- und Compliance-Maßnahmen durchgesetzt werden sollen, sind selbstverständlich nur dann sinnvoll, wenn ihre Berücksichtigung auch überwacht wird. Die Einhaltung einiger Regeln lässt sich mit technischen Mitteln sicherstellen, beispielsweise durch das Ausschalten von Konnektoren. Compliance-Regeln werden hingegen oft unwissentlich verletzt. In diesem Fall sollte die Governance umgehend eine Warnung erhalten. Solche Alerts lassen sich für die übergeordnete IT einrichten.

Zwei Varianten des Umgangs mit No-Code

Im Prinzip gibt es zwei prototypische Vorgehensweisen für den Umgang mit No-Code-Entwicklungen: Entweder das Unternehmen erlaubt erst einmal alles und schränkt die Freiheit ein, sobald es Probleme gibt. Oder das Unternehmen untersagt zunächst alles und gibt dann Schritt für Schritt – nach sorgfältiger Risiko-Nutzen-Abwägung – bestimmte Anwendungsbereiche unter Auflagen frei. Große Unternehmen werden vermutlich eher die zweite Variante wählen, während Start-ups zur ersten tendieren. Unsere Erfahrungen zeigen auch, dass es schwieriger ist die Privilegien über Zeit zu entziehen, anstatt bedarfsorientiert Funktionen freizuschalten.

Wie strikt die Governance gehandhabt wird, hängt ebenfalls von Art und Größe des Unternehmens ab.

• Unternehmen aus dem nicht-kritischen Umfeld verhalten sich hier vermutlich eher liberal. Das gilt insbesondere, wenn es sich um kleine Personal-Productivity-Tools für einen überschaubaren Anwenderkreis handelt.
• In Unternehmen, die stärker durch Aufsichtsgremien reguliert sind, sieht das sicher anders aus. Hier muss meist die Firmen-IT-Strategie verfolgt werden, damit die App beispielsweise eine Bezeichnung nach den unternehmensweiten Namenskonventionen erhält und den unternehmensweiten Security- und Compliance-Regeln entspricht.
• Enterprise Applications, also Software, die für die Nutzung durch ganze Unternehmen und nicht einzelne User konzipiert ist und meist mehrere Programme umfasst, sind ein Thema für sich. In den meisten Fällen erfordern sie eine Projektplanung, die Themen wie Datensicherheit, Privacy und Compliance berücksichtigt. Von daher wird diese Art der Anwendungen eher selten mit No-Code-Tools erstellt, obwohl das mit der entsprechenden Governance durchaus möglich wäre.

Ein effektives Mittel, um Governance durchzusetzen, ist ein Center of Excellence (CoE). Dazu finden Sie mehr in diesem Artikel.

Quelle Titelbild: AdobeStock/lexiconimages