Paulo Rosado: Dazu muss ich etwas ausholen. Ich bin von meinem Background her Computer Scientist und Fachinformatiker. OutSystems habe ich als meine zweite Company 2001 gegründet, nachdem ich meine erste, 1997 gegründete Company zum Höhepunkt der Internet-Blase verkauft habe. Vieles von dem, was wir tun und was die zwingende Idee für OutSystems war, basiert auf dem Schmerz und der Erfahrung, die ich und der Rest des Gründerteams in unseren Jahren davor gesammelt hatten.

Zum Thema Low-Code: Was sehen Sie als Alleinstellungsmerkmal von OutSystems?

Rosado: Es gibt wahrscheinlich zwei oder drei Dinge, aber der wichtigste Aspekt, der sich über die Jahre als ein sehr nachhaltiges Unterscheidungsmerkmal erwies, ist, dass wir viel entwickelt haben. Wir haben intern eine Menge Forschung über die Anatomie und die Erfahrung des Softwareentwickelns betrieben. Wir hatten auch schon immer Expertise im Language Design.

Und dann der Prozess: Wir haben wirklich viel über den Entwicklungsprozess geforscht. Im Laufe der Jahre haben wir erkannt, dass sich viele der Ideen, die wir am Anfang hatten, weiterentwickelt haben und entsprechend eine Menge Richtungsänderungen vorgenommen.

Eigentlich hätten wir nie gedacht, dass wir derart richtig liegen würden. Das Unterscheidungsmerkmal, das wir jetzt haben, ist, dass wir eine enorme Menge an Erfahrung vorweisen, die wir in unsere KI-Modelle einfließen lassen. Hinzu kommt die Art und Weise, wie wir die Entwicklungsumgebungen gestaltet haben, die Dinge, die wir mit der Plattform tun können, und die Zeit, die wir brauchen, um diese Dinge zu tun.

Aber es gibt noch einen anderen Punkt: 2001 haben wir eine sehr gute Entscheidung getroffen, als wir die Plattform auf der Grundlage einer so genannten losgelösten Architektur (Detached Architecture) aufgebaut haben. Bei dieser ist die Entwicklung der Anwendungen von der Architektur sowie von der Art und Weise, wie die Anwendungen ausgeführt werden, getrennt. In der Mitte gibt es eine Compiler-Technologie, die das übernimmt.

Welchen Vorteil hat das?

Rosado: Dieser Ansatz ermöglicht es uns, die zugrunde liegende Laufzeitumgebung grundlegend aktualisieren zu können, ohne die Modellierungs- und Entwicklungsumgebung zu ändern. Das geschieht zum Beispiel jetzt, weil wir uns entschlossen haben, unsere Architektur auch auf eine Cloud-native Architektur zu migrieren, die eine Milliarde Benutzer unterstützt.

Wir haben mittlerweile Kunden, die zu uns kommen und sagen, ich habe dieses bestimmte Portal, mit dem ich 150 Millionen Nutzer erreichen möchte. Und eine solche Skalierbarkeit erfordert ein enormes Maß an Rafinesse in der Datenschicht, in der Netzwerkschicht, in der Art und Weise, wie die Skalierbarkeit der Workloads erreicht wird. Das Detached-Modell eröffnet uns somit fast unbegrenzte Use Cases. Für die Kunden ist das ein Riesenvorteil und auch uns gibt es eine Menge Flexibilität.

Inwieweit? Können Sie das näher erklären?

Rosado: Mit Blick auf die Zukunftsfähigkeit. Als zum Beispiel vor etwa fünf Jahren dieser Container-Trend aufkam, war es klar, dass künftig viele dieser Anwendungen in Containern laufen würden. Wir betrachteten daraufhin das Problem unter dem Gesichtspunkt der Skalierbarkeit und erkannten, dass Container nur ein kleiner Teil des Problems waren und in Zukunft wohl vieles "serverless" funktionieren würde. Wir werden die nächste Generation von No-SQL-Datenbanken und SQL-Datenbanken schreiben müssen.

Heute, mit dem Launch der neuen Plattformgeneration, ist der Container-Aspekt zwar wichtig. Er macht aber nur etwa 20 Prozent der Gesamtkomplexität aus, um einen nativen Stack aufzubauen, der ein hohes Niveau an Skalierbarkeit und Sicherheit etc. unterstützt. Diese Abkopplung, die uns die Möglichkeit gibt, Entscheidungen zu treffen, ohne den Rest der Plattform ändern zu müssen, ist also enorm wichtig.

"Low-Code ist No-Code mit Erweiterungen in den Code hinein"

Low-Code oder No-Code - wo ist die Verbindung zwischen den beiden Begriffen? Wohin geht die Reise?

Rosado: Zunächst einmal geht es darum, den Unterschied zwischen Low-Code und No-Code zu verstehen. Im Grunde genommen sind alle diese Plattformen "No-Code", ich gebe Ihnen mal ein Beispiel. Wenn ich eines der größten Systeme nehme, das jemals auf Basis von OutSystems gebaut wurde, dann glaube ich nicht, dass da auch nur ein Prozent High-Code drin ist. Alles wurde mit No-Code, also auf der Grundlage dieser modellierenden visuellen Entwicklungsumgebung gebaut.

Es gibt aber einen Grund, warum es Low-Code genannt wird, und ich weiß das, weil ich damals derjenige war, der mit dem Forrester-Analysten John Rymer diskutiert hat, als er den Begriff Low-Code prägte. Er sagte zu mir: 'Ich denke, ihr verwendet keinen Code, daher sollten wir diese Plattformen No-Code nennen.' Und ich sagte nein, weil No-Code eine Einschränkung von dem, was man mit diesen Plattformen machen kann, darstellt. Denn man kann - soweit es geht - ohne Code arbeiten und wenn man an eine Grenze stößt, im Code weiterarbeiten.

Mein Vorschlag war dann, den Begriff Low-Code zu verwenden. Und so ist Low-Code eigentlich No-Code mit Erweiterungen in den Code hinein, viel mehr steckt nicht hinter dem Begriff. Die Leute sehen Low-Code-Plattformen als Plattformen mit sehr eingeschränkten Möglichkeiten - dabei sind wir im Grunde die leistungsfähigere No-Code-Plattform auf dem Markt, die es bei Bedarf ermöglicht, direkt in den Code zu springen. Deshalb gehören wir in die Kategorie Low-Code.

OutSystems unterstützt also beides?

Rosado: No-Code wird mit einfachen Dingen in Verbindung gebracht - für Mitarbeiter mit wenig Programmierkenntnissen. Deswegen gibt es einen Baukasten mit einer niedrigen Lernkurve. Und dann gibt es andere, wo die Lernkurve ein bisschen steiler ist. Wir decken alle diese Fähigkeiten ab. Wir haben sehr große Kunden, zum Beispiel in den USA, mit Hunderten, wenn nicht Tausenden von "No-Code"-Entwicklern, die mit unserer Plattform arbeiten, wir decken beides ab, No-Code und Low-Code.

Wir haben uns für den Begriff Low-Code entschieden, weil Low-Code näher an dem ist, was wir für den richtigen Ansatz für diese Plattformen halten, nämlich dem Kunden die Möglichkeit zu geben, die Software weiterzuentwickeln.

Wenn man zurückblickt, Ende der 80er, Anfang der 90er Jahre, schossen No-Code-Plattformen wie Pilze aus dem Boden. Eines der Probleme, die sie schufen, war, dass man damit am Anfang sehr einfach etwas erstellen konnte. Wenn man es aber weiterentwickelte, stand man plötzlich vor einer Mauer. Man konnte es nicht mehr verändern und plötzlich hatte man ein Stück Legacy.

Noch heute leiden No-Code-Plattformen unter dem gleichen Problem: Die Einstiegshürde ist sehr niedrig, man fängt an, etwas zu bauen, doch sobald man einen Change Request erhält, sobald die Software ein bisschen anspruchsvoller wird, stößt man an eine Grenze und kann nicht weitermachen.

Ein gutes Stichwort: In Sachen Technische Schulden werden ja Lösungen wie RPA oder auch Low-Code eher als Verursacher wahrgenommen, weil sie schnelle, aber nur vorübergehende Lösungen liefern. Stimmt das?

Rosado: Eine gute Frage. Nehmen wir zur Erklärung ein aktuelles Beispiel, etwa unseren Kunden Vopak, den weltweit größten unabhängigen Betreiber von Tank-Terminals. Vopak besitzt fast 80 solcher Terminals und eines der Dinge, die sie tun wollten, war die Schaffung eines Terminal-Management-Systems. Das ist eine sehr klassische IT-Idee, dieser Prozess 'Hey, lass uns eine große ERP-Plattform aufbauen, um unsere Terminals zu verwalten'.

Die Art und Weise, wie sie diese dann mit Hilfe von OutSystems aufbauten, war aber ganz anders. Wir empfahlen ihnen, unabhängige Softwareblöcke zu bauen, anstatt die Szenerie monolithisch abzubilden. Es ist also ein Grid aus verschiedenen Teilen - das Äquivalent in Code wären Microservices gewesen.

Nebenbei bemerkt, konnten sie dadurch deutlich agiler werden: Die Firma hatte das Projekt optimistisch für ungefähr dreieinhalb Jahre ausgelegt. Es war als Ersatz für ein ERP-System von JD Edwards mit vielen Anpassungen vorgesehen. Mit OutSystems wurde das Terminal-Management-System in der ersten Version, die in einem Terminal getestet wurde, in sieben Monaten fertiggestellt.

"Die Art und Weise, wie Software heute entwickelt wird, ist Patchwork"

Also gut viermal so schnell, nicht schlecht!

Rosado: Wenn man nun betrachtet, was man mit Low-Code oder RPA kann: Man kann eines dieser Teile mit Low-Code bauen, man kann Teile mit RPA zusammenfügen. RPA selbst hat wieder andere Probleme, die es in Low-Code nicht gibt. Es ist etwas aufwendiger und schwieriger zu warten, aber Low-Code ist im Grunde genommen ein schneller Weg, diese Blöcke zu bauen, und die Dinge, die man in der Vergangenheit gebaut hat, zusammenzufügen.

Der Vorteil an dem Erstellen von Software aus separaten Teilen ist, dass es viel einfacher ist, ein kleineres Teil zu warten als ein größeres. Wenn das System zu groß wird, wird es langsamer, bis es schließlich ganz lahmt, und dann muss man es in kleinere Teile zerlegen, und diese Teile kann man leicht an das Team weitergeben. Wir können es dann sehr schnell weiterentwickeln.

Und deshalb ist die Art und Weise, wie Software heute entwickelt wird, Patchwork. Ein Schwarm von autonomen Teams erstellt kleine Teile, die miteinander verbunden sind. Das Problem ist heute, wie man die Koexistenz all dieser kleinen Teile aufrechterhalten kann. Aber es gibt halt nichts umsonst auf der Welt. Das Problem mit der heutigen Software ist, dass sie sich täglich ändert. Und deshalb ist die Verwaltung dieser Veränderungen ein riesiges Problem.

Das heißt also, die Möglichkeit, später Änderungen vorzunehmen ist ähnlich wichtig, wie das Erstellen von Anwendungen?

Rosado: Eine Menge von Low-Code-Tools macht es einem einfach sehr leicht, etwas zu bauen, aber sie kümmern sich nicht um die Wartung. Heute findet die nächste Wartung aber nicht in fünf Jahren statt, sondern schon in der nächsten Woche.

Bei uns bezieht sich ein großer Teil der Forschung nicht so sehr auf die Entwicklung, sondern auf den gesamten Änderungszyklus und darauf, wie schnell wir uns weiterentwickeln und die Change Requests erfüllen können. Das ist es, was den Unternehmen Agilität verleiht.

Es ist also ein Teufelskreis, denn einerseits will man neue Funktionen haben, auf der anderen Seite muss man schauen, wie man diese Dinge integriert.

Rosado: Richtig, aber nur so kann man das heute bewerkstelligen, in einer Welt, in der alles beschleunigt ist. Es ist eine verrückte Welt, in der sich die Unternehmen viel schneller verändern und die Technologie, die das unterstützt, sich auch schneller verändern muss. Und das Problem bei Veränderungen ist, dass sie bei Software zu technischen Schulden führen.

Eines der grundlegenden Forschungsthemen von OutSystems lautet: Wie können wir den Wandel beschleunigen, ohne in technische Schulden zu verfallen? Wie können wir sicherstellen, dass die Änderungen, die man vornimmt, nicht später weitere Konsequenzen haben?

Und das sehen wir bei vielen konkurrierenden Plattformen und konkurrierenden Technologien, sogar auch bei softwarecodierter Software. Das ist der Grund dafür, dass Plattformen, die dieses Problem lösen, immer häufiger eingesetzt werden.

Wie ist das Verhältnis von Low-Code und Security-Risiken? Es wird ja teilweise noch mit Java-Code gearbeitet.

Rosado: Security ist ein interessanter Aspekt, denn Sicherheit ist heute mehr denn je ein bewegliches Ziel. Man denke nur an den Log4j-Bug, der vor kurzem fast jede Art von Java-Workload bei Unternehmen befallen hat. Wir haben immer noch einige Java-Stacks und als wir diese überprüft haben, hatten wir den Fehler zwar nicht - wir hätten aber einen ähnlichen Fehler haben können.

Dank der Detached-Architektur hat es ausgereicht, den Unterbau zu ändern und ein Upgrade der Plattform bereitzustellen. Die Kunden haben den Patch installiert, sie änderten nichts an den Anwendungen und doch waren alle Anwendungen, die sie auf unseren Systemen geschrieben hatten, plötzlich vor diesem Bug geschützt.

Es erscheint im ersten Moment wie ein Widerspruch, aber Plattformen wie unsere bieten ein enormes Maß an Sicherheit, denn vieles von dem, was man normalerweise von Hand machen muss, wird automatisch durch den Compiler erledigt. Das gilt auch für unser Wissen im Bereich Security.

Wenn wir also einen Fehler im Frontend finden und diesen mit einer neuen Regel beheben müssen, können wir einfach neu kompilieren und die neue Regel anwenden. Alle unsere Kunden erhalten dieses Upgrade dann, und für alle ihre Anwendungen. Das ist definitiv ein Vorteil und es funktioniert wirklich gut.

Wir haben auch Kunden, die viel mit so genannten White-Hat-Pentestern arbeiten. Wir verlassen uns sehr auf ihre Tests, und manchmal finden sie auch eine Sicherheitslücke. Einmal gab es einen sehr gravierenden Fall mit dem riesigen SecOps-Team. Sie testeten eine Reihe von OutSystems-Anwendungen in den Vereinigten Staaten und entdeckten 4 Sicherheitslücken. Als sie uns diese schickten, fragte ich: 'Leute, wie können wir das beheben?'

Aber es ging ganz einfach: Wir haben den Compiler geändert. Wir haben die Zielkonfiguration geändert. Wir schickten den Patch, sie spielten ihn auf und das Problem war behoben für alle darauf basierenden Anwendungen. "Dies waren die schnellsten Sicherheitskorrekturen, die wir in unserem ganzen IT-Leben je gesehen haben", sagten sie uns.