Innovation beschleunigen: Softwareentwicklung automatisieren für Wettbewerbsvorteile

Traditionelle Softwareentwicklung ist langsam. Es ist Zeit für ein Umdenken.

Vor fast drei Jahren prägte Microsofts Satya Nadella den berühmten Satz: „Jedes Unternehmen wird ein Softwareunternehmen sein“. Heute ist der 500 Milliarden Dollar globale Softwaremarkt auf Kurs, sich bis 2030 auf 1 Billion Dollar zu verdoppeln.

J.P. Morgan gibt an, 40.000 Softwareingenieure zu beschäftigen (mehr als Alphabet) in ihrem jüngsten Bericht. Jedes große Unternehmen rennt, um Ingenieure einzustellen, um die Konkurrenz zu übertrumpfen. Das große Problem: Traditionelle Softwareentwicklung ist langsam, fragmentiert und verschwenderisch.

Beispielsweise verbringt der durchschnittliche Softwareingenieur jede Woche 4 Stunden mit Warten auf Tests, 3,5 Stunden mit Warten auf Builds und 3 Stunden mit Environment Management – mehr als ein Viertel ihrer Arbeitswoche, ohne etwas Wertschaffendes zu erschaffen. Wenn man bedenkt, dass Ingenieure oft die bestbezahlten Mitarbeiter in Organisationen sind, ist das eindeutig ein großes Problem. Doch die Dinge ändern sich.

Eine der führenden Entwicklungsplattformen, CircleCI, setzte darauf, dass KI und Automatisierung der Schlüssel sind, um Softwareinnovation zu beschleunigen und Ingenieure für wichtige Arbeit freizusetzen. Im letzten Jahr führte das Unternehmen eine Reihe von Automatisierungs- und Machine-Learning-Verbesserungen ein, die die Wartezeiten der Ingenieure um 50 % reduzierten. Das ist einer der Gründe, warum mehr als 300.000 Entwickler – einschließlich jener bei Facebook, Spotify, GoPro, InstaCart und vielen anderen – zu CircleCI gewechselt sind, um schneller zu werden.

An der Spitze steht Jim Rose – ein sechsmaliger Gründer mit früheren Investments von Google Ventures, Foundation Capital und Marc Andreessen. Seit er vor etwas mehr als vier Jahren zu CircleCI kam, hat Rose den Umsatz um mehr als 450 % gesteigert und das Unternehmen zu einer wirklich spannenden Entität ausgebaut.

Information Age sprach mit Rose über die Automatisierung der Softwareentwicklung und die Beschleunigung von Innovation.

Wie ist der aktuelle Stand des Softwaremarktes?

Derzeit führen noch viele Unternehmen und Einzelpersonen Prozesse manuell durch. Wenn man über digitale Transformation nachdenkt, geht es wirklich darum, ein Softwareentwicklungsteam zu fördern.

Erstens: Software aus On-Premise-Rechenzentren in cloud-native Umgebungen zu bringen, wo man sofortigen Zugriff auf Rechenleistung hat.

Zweitens: Software war traditionell oft nur ein Leitfaden oder Adjunkt zum Kerngeschäft. Jetzt erkennen alle möglichen Unternehmen – von Banken über Autohersteller bis zu Einzelhändlern –, dass Software zum Kern dessen gehört, was sie tun. Sie müssen herausfinden, was sie besitzen, ihre Assets konsolidieren und als Standard integrieren.

Sobald Unternehmen diesen sofortigen Zugriff auf Rechenleistung haben und Strukturen vorhanden sind, in denen Entwickler arbeiten können, sitzt dazwischen heute meist ein Mischmasch aus verschiedenen Plattformen und Prozessen.

In den meisten Fällen gibt es sehr lange Waterfall-Software-Release-Prozesse mit vielen manuellen Schritten und Skripten. In fortgeschritteneren Shops gibt es vielleicht die erste Generation von Automatisierungslösungen, aber da Teams schneller werden, beginnen diese zu brechen.

Und genau da kommen wir ins Spiel und helfen Unternehmen, das zu navigieren. Da ihre Softwareteams schneller werden, mehr Software bauen und versuchen, dies schneller zu tun – um sowohl auf Marktchancen als auch auf potenzielle negative Veränderungen reagieren zu können –, müssen Unternehmen komplett überdenken, wie all diese Teile zusammenpassen.

Ist diese Geschwindigkeit das Haupthindernis in der Softwareentwicklung?

Unternehmen und Entwicklungsteams versuchen, schneller zu werden, weil der Markt schneller wird. Sie versuchen herauszufinden, wie sie schnell arbeiten können, um Chancen anzugehen.

Der einzige Weg dorthin ist, wirklich alle Schritte zu automatisieren, die nicht zwingend menschlichen Eingriff erfordern, weil man sie statt in Minuten, Stunden und Tagen in Sekunden erledigen kann.

Wenn Teams schneller werden und Software Ihr primärer Schaufenster zum Kunden ist, müssen Sie sicherstellen, dass Qualitätsniveaus hoch sind; dass es nicht abstürzt oder Sicherheitslücken hat.

Wenn man über agil nachdenkt, geht es darum, sowohl aus Qualitäts- als auch aus Geschwindigkeitsperspektive beweglicher zu werden.

In den USA dreht sich alles um Geschwindigkeit, aber indem man schneller wird, kleinere Stücke integriert und Software auf konsistenterer Basis releast, wird die Software inhärent besser. All diese Ängste vor Deployments verschwinden, wenn man es fünf, acht, 15 Mal pro Woche tut, und in manchen Fällen haben wir Kunden, die es 100 Mal am Tag tun.

Deployment wird zum Non-Issue.

Auf der Qualitätsseite: Ein großes Problem der Softwareentwicklung in der Vergangenheit war, dass wenn man nur einmal pro Quartal released, man große Schwierigkeiten hat, sicherzustellen, dass alle eingeführten Änderungen tatsächlich zusammenarbeiten. Oft sieht man Unternehmen ein Big-Bang-Release machen und dann die nächsten 60, 90 Tage damit verbringen, all die Dinge zu fixen, die regressed und gebrochen sind. Bei dieser Methode verlangsamt sich der Softwarezyklus, aber auch die Qualität der Applikation leidet.

Aus agiler Perspektive ist das, was Menschen anzugehen versuchen.

Wie kann eine Organisation sich ändern, um Softwareentwicklungsteams aufzunehmen, zu unterstützen und zu fördern?

Es gibt ein paar verschiedene Wege.

Einer: Entwickler sind schwer einzustellen, also wollen Sie sicherstellen, dass die gesamte Zeit aus Entwicklungsperspektive darauf verwendet wird, Ihre spezielle Software zu bauen – wenn Sie eine Bank sind, eine großartige Banking-App, wenn Sie eine E-Commerce-App sind, eine wirklich großartige E-Commerce-App. Ich denke, einer der großen Bereiche, in denen Menschen unterinvestiert haben, ist, dass Softwareentwickler historisch Dinge gebaut haben. Das ist, was sie tun. Der Entwicklungszyklus wurde aus Third-Party-App-Perspektive unterinvestiert.

Es gibt Dinge wie Testautomatisierung und Continuous-Delivery-Infrastruktur, die Teams nicht selbst bauen sollten. Sie sind viel besser beraten, sie von jemandem zu beziehen, der sich darauf spezialisiert hat, damit Sie sich auf das konzentrieren können, was Sie gut können. Es wäre, als würde man jemandem sagen, er müsse eine Kaffeemaschine bauen, und ihm ein paar Kupferrohre, Lot und Ventile geben. Das würde man nie tun. Historisch wurde Entwicklung aber so behandelt. Also definitiv die richtigen Tools und Plattformen an der richtigen Stelle zu haben, ist kritisch – den ganzen Stack hoch und runter, vom Rechenzentrum bis zu den Planungstools.

Der zweite Teil: Im traditionellen Waterfall-Modell spielt Softwareentwicklung meist die Rolle des Catchers – die Applikation wird viel früher im Prozess definiert und wenn das Entwicklungsteam sie bekommt, wurden bereits Entscheidungen getroffen, die vielleicht nicht funktionieren oder nicht machbar oder einfach umzusetzen sind.

Es gibt diesen Begriff „Shift Left“, der versucht, Entwicklung immer weiter in den Planungszyklus zu schieben, damit die Bedenken oder Bedürfnisse des Entwicklungsteams sowohl in der Konstruktion der Applikation als auch in ihrer Auslieferung berücksichtigt werden. Und aus operativer Perspektive bedeutet das, man muss wirklich durchdenken, wie eine Applikation betrieben wird, viel früher im Lebenszyklus. Wenn Sie beispielsweise cloud-native Apps bauen wollen, müssen Sie sie auf eine sehr spezifische Weise architekturell gestalten, was bedeutet, dass Sie diese Entscheidung treffen und Teil dieses Prozesses viel früher sein müssen.

Wenn Teams mehr software-first, agile Prozesse adoptieren, entsteht eine Triangulation von Bedenken. Sie haben die Leute, Business Owner und Product Manager, die das „Warum“ besitzen. Sie haben technische Architekten und Softwareentwickler, die über das „Wie“ sprechen. Und Sie haben die Operatoren, die für den Betrieb verantwortlich sind und herausfinden, was am Ende des gesamten Prozesses tatsächlich läuft. Jeder muss involviert sein. Und das kann für manche Unternehmen ein harter Übergang sein.

Wie können KI und Automatisierung Softwareinnovation anregen und verbessern?

Mit Automatisierung können Sie Aufgaben automatisieren, die sowohl vorgegeben als auch selbstlernend sind. Ein Beispiel: Wenn Sie jedes Mal, wenn Sie ein Stück Software releasen, einen Third-Party-Test gegen ein anderes Third-Party-Zahlungssystem durchführen müssen. Früher hätte man dafür ein QA-Team einstellen müssen, das Transaktionen manuell verarbeitet – unglaublich langsam und fehleranfällig.

Das sind perfekte Beispiele für Aufgaben, die in Ihrer Testsuite vollständig automatisiert werden sollten – all diese Dinge, die Sie wissen, dass Sie immer wieder tun werden, sollten Sie automatisieren, um sie deterministisch und vorhersagbar zu machen. Und letztlich schnell.

Es gibt Gelegenheiten, diese repetitiven Aufgaben zu nehmen, bei denen jede Minute, die ein Entwickler damit verbringt, sie immer wieder zu tun, Zeit- und Geldverschwendung ist.

Wenn man sich KI und Software ansieht, die gebaut wird: Statt deterministische, vorhersagbare Software zu pushen, pusht man ein Modell. Und das Modell ist ein Sandbox aus vorgefassten Vorstellungen, wie etwas funktionieren könnte, und während Menschen hindurchgehen und Tests laufen, ändert und entwickelt sich das Modell, während es mehr darüber lernt, wie Dinge funktionieren oder nicht funktionieren. Das setzt die Testsysteme enorm unter Druck.

Wenn man an einige KI-Fehltritte denkt – Situationen, in denen unbewusster Bias in die KI eingebaut ist, wo die KI Amok läuft und Leute aus bestimmten Anwendungen aussperrt oder Dinge herunterfährt – das sind alles Situationen, die aus Testperspektive herausfordernd sind.

Es wird immer komplizierter, aber auch viel, viel schneller und reaktionsfähiger. Sie werden also nur sehen, dass die Einbeziehung von KI und Machine Learning in die Softwareentwicklung weiter zunimmt. Aber jetzt brauchen Sie all die notwendigen Frameworks, um all diese Änderungen testen zu können.