Makrotrends in der IT- und Technologiebranche 2021 Analyse zum Thoughtworks Technology Radar, Vol. 25

Anbieter zum Thema

Thoughtworks Deutschland GmbH

DAXTEN GmbH

VON ZUR MÜHLEN'SCHE GmbH

STACKIT GmbH & Co. KG

Zweimal jährlich veröffentlicht die globale Softwareberatung Thoughtworks den Technology Radar. Der Report analysiert ausführlich Tools, Praktiken, Sprachen und Plattformen, die für die Softwareentwicklung relevant sind. Im Folgenden erläutert Mike Mason von Thoughtworks einige allgemeine Trends.

Die Software-Lieferkette absichern

Anfang des Jahres wurden Einzelheiten eines gut koordinierten Hackerangriffs bekannt, über den die Medien monatelang berichteten. Hacker waren in die Systeme des Softwareanbieters SolarWinds eingedrungen und hatten dort Schadcode in die Software Orion eingeschleust.

Warum war ausgerechnet dieses Ziel so heikel? Orion ist ein Netzwerk-Management-System, das Server überwacht und für alle sensiblen Bereiche der Firmensysteme eine hohe Berechtigungsstufe besitzt. Microsoft, Intel, Cisco, sogar Regierungen auf der ganzen Welt, waren von dem Angriff betroffen.

Das Interessante daran ist jedoch, dass sich der Angriff nicht gegen laufende Orion-Instanzen richtete, wie es bei Remote Exploits so oft der Fall ist. Vielmehr zielte der Angriff auf die Build-Umgebung von SolarWinds und die Lieferkette ab. Der Schadcode wurde direkt in die Software eingeschleust, anschließend digital signiert und an die Kunden ausgeliefert. Diese installierten die neue Version der Orion-Software wie ein reguläres Update, in dem scheinbar Fehler behoben worden waren. Tatsächlich jedoch öffnete die Installation den Hackern die Türen.

Seitdem wächst das Bewusstsein, dass nicht nur die Software selbst, sondern auch deren Lieferkette gesichert werden muss, also die gesamte Software sowie die Prozesse rund um deren Entwicklung, Erstellung, Tests, Verteilung und Ausführung. Auch in deutschen Unternehmen wächst die Angst vor solchen Angriffen auf die Software-Lieferkette.

Aktuell sehen viele Verträge mit Zulieferern keine Meldepflichten für Zulieferer an deren Vertragspartner bei IT-Vorfällen oder Vereinbarungen für IT-Sicherheit vor. Für Branchen mit kritischen Infrastrukturen wie etwa Strom- oder Kommunikationsnetze gibt es bereits klare Vorgaben des Bundesamtes für Sicherheit in der Informationstechnik (BSI) für die Sicherheit in Lieferketten. Fachleute empfehlen, diese detaillierten Regelungen auch auf andere Branchen auszuweiten, um die Sicherheit von IT-Systemen zu erhöhen.

Wenig Neuerungen bei Plattformen

Diese Radar-Ausgabe behandelt weniger Themen aus dem Plattformbereich als üblicherweise. Woran könnte das liegen? Natürlich ist das Plattformkonzept nach wie vor von großer Bedeutung. Unternehmen, die es verstehen, Plattformen effektiv zu erstellen und einzusetzen, können diese als Wettbewerbsvorteil nutzen, um ihre Software schneller in Produktion zu bringen und ihren Kunden Mehrwert zu bieten. Wieso zeigt das Tech-Radar-Spezialteam aktuell keine große Begeisterung für das Thema Plattformtechnologie?

Es liegt vermutlich daran, dass sich die meisten Unternehmen mittlerweile auf einen (oder zwei) Cloud-Anbieter verlassen und standardmäßig Kubernetes und Kafka nutzen. Die großen Cloud-Plattformen warten zwar weiterhin mit immer neuen Services auf, allerdings sind die Features nicht wirklich innovativ. Vor allem gibt es aber keine wirklich neue Plattform, die in irgendeiner Form hervorsticht. Im Wesentlichen handelt es sich um neue Funktionen und Anwendungsfälle für bestehende Plattformen.

Das ist nicht unbedingt ein schlechtes Zeichen, da das Tempo technologischer Innovationen unregelmäßig verläuft. Wahrscheinlich haben wir – zumindest, was Plattformen anbelangt – gerade einen Punkt erreicht, an dem die Innovationskraft etwas gedrosselt ist, dafür die Einführung von Plattformen aber Fahrt aufnimmt. Natürlich könnte sich dies jederzeit ändern.

Komplexität erfordert überlegte Entscheidungen

Softwaresysteme, die sich selbst überlassen bleiben, werden schnell unübersichtlich und übermäßig komplex. Angesichts dieser zunehmenden Komplexität greifen Entwicklerteams gerne auf einfache Lösungen zurück – anstatt Zeit und Sorgfalt aufzuwenden, um eine durchdachte Architektur und ein durchdachtes Design zu entwickeln und auch zu pflegen.

Denn eine bequeme, aber eher kurzsichtige Entscheidung kann langfristig große Probleme bereiten.

Die aktuelle Technology Radar-Ausgabe greift hier die folgenden Beispiele auf:

• Das Muster BFF (Backend-for-Frontend) entwickelt sich von einfachen Serviceadaptern und ‑aggregatoren zu komplexen Services für die Orchestrierung zahlreicher Backend-Services. Oft geschieht dies, weil ein kundenorientiertes Team direkteren Zugriff auf die BFF-Schicht hat und dort schnell etwas korrigieren kann, wohingegen eine Änderung an der richtigen Stelle (nämlich den eigentlichen Unternehmensservices) größere Abstimmung unter den Teams erfordern würde.

• GraphQL wird so verwendet, als ob damit eine RESTful-Schnittstelle definiert würde, und ist gespickt mit schlechten Abfragemustern, wie n+1-Selects oder mehreren wiederholten Aufrufen zum Abfragen von Details der Objekte im Graphen (worin der eigentliche Sinn von GraphQL besteht!).

• Das Projekt kong-js-pdk erweitert Kong um ein Plug-in-Entwicklungspaket und ermöglicht es Entwicklungsteams, in etwas, das ein einfacher Teil der Infrastruktur sein sollte, komplexe Logik zu verstecken.

Das „Richtige“ in jedem dieser Fälle wäre es, sich eingehend mit der Architektur des Systems auseinanderzusetzen und die Funktionalität und Logik an einen Ort zu bringen, an dem sie langfristig sinnvoll aufgehoben ist. Ein solches Vorgehen erfordert vielleicht vorübergehend etwas mehr Geduld und eine genauere Betrachtung der Architekturrichtlinien; langfristig kommt es jedoch der Qualität der Software zugute.

Clevere Developer lösen oft das falsche Problem

Häufig stellen wir fest, dass sich in der Softwareentwicklung ganze Abteilungen des falschen Problems annehmen. Ein Beispiel aus der Praxis: Ein Unternehmen hat so strikte Kontrollen in seine Testumgebungen eingebaut, dass die Entwicklerinnen und Entwickler dort keinerlei Code implementieren konnten. Andererseits legte das Unternehmen Wert auf automatisierte Tests.

Daher gab es ein System, in dem die Dev-Teams beantragen konnten, dass ihre neuesten Codeänderungen in einer speziellen Testumgebung ausgeführt wurden. Das System übernahm diese Änderungen, erstellte die Software, übertrug sie an die Testumgebung und führte darin viele Tests parallel durch. Dies löste aber nicht das eigentliche Problem, warum die Tests nicht auf den Arbeitsstationen der jeweiligen Developer oder in abgespeckten, dynamisch anpassbaren Cloud-Umgebungen ausgeführt wurden.

Es gibt einen großen Unterschied zwischen der inhärenten Komplexität der Aufgabe (den eigenen Code testen, um sich seiner Produktionsreife zu versichern) und der sich ungewollt ergebenden Komplexität des Problems, das die Entwicklerteams gelöst haben. Aktuelle Beispiele hierfür sind Airflow und Prefect, ausgesprochen smarte Tools zur Entwirrung von Spaghetticode in Datenpipelines, oder die Fülle an Tools wie Nx, mit denen sich durch Monorepos verursachte Probleme bewältigen lassen. Solche Tools werden häufig übereifrig eingesetzt und erhöhen letztendlich die Komplexität.

Immer, wenn ein Tool ein komplexes Problem zu lösen scheint, sollte man daher hinterfragen, warum es gebraucht wird. Anstatt sofort auf eine technologische Lösung zu setzen, sollte man erst überlegen, ob sich der Ansatz vielleicht so verändern lässt, dass das clevere Tool nicht erforderlich ist.

Conway’s Law ist immer noch Gesetz

Nach Conway’s Law sind die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt. In der Praxis ist die Softwarearchitektur dann tendenziell ein Abbild der sie erstellenden Teams: Große, zentralisierte Teams schreiben eher monolithischen Code, während kleinere, verteilte Teams eher Code erstellen, der modular aufgebaut und lose verknüpft ist.

Ein nicht zu vernachlässigender Aspekt ist der Schwierigkeitsgrad, mit dem sich Änderungen vornehmen und Aufgaben erledigen lassen. Die Systeme einer Organisation, in der es etliche Entscheidungsinstanzen und viel Bürokratie gibt, sind häufig schwer zu ändern; die Softwarekomponenten konkurrierender Unternehmensabteilungen vertragen sich häufig nicht miteinander.

Bei richtiger Anwendung kann Conways Gesetz hier Abhilfe schaffen. Auf ihrem Weg zur digitalen Transformation sollten Organisationen, im Einklang mit der gewünschten Weiterentwicklung ihrer Architektur- und Technologiestrategie, ihre Development-Teams neu ausrichten, inklusive Unternehmenskultur, Berichtsstruktur und Incentive-Programme.

Es ist für Unternehmen deutlich besser, wenn sie Conway’s Law als positive Kraft nutzen; dies gelingt, indem sie den Menschen, welche die Software entwickeln, Aufmerksamkeit schenken und ein Betriebsmodell sowie eine Entwicklerkultur schaffen, die produktzentriert sind.

Der Silberstreif am COVID-Horizont: Kreativität bei hybriden und flexiblen Arbeitsmodellen

Leider erweist sich die Pandemie immer noch als eine große Herausforderung. Sie hat jedoch auch bewirkt, dass das Arbeiten von verteilten oder weit entfernten Standorten aus mindestens zehn Jahre früher als erwartet zur Normalität geworden ist. Zwar war diese Veränderung letztlich absehbar, aber die Pandemie hat uns dazu gezwungen, uns viel schneller auf neue Techniken und Methoden einzulassen.

Für viele hat sich die Arbeit im Homeoffice bewährt. Die Produktivität leidet nicht, wenn die Menschen nicht mehr Vollzeit ins Büro zurückkehren. Vielmehr wäre die Rückkehr zum reinen Bürobetrieb bei einigen wohl eher kontraproduktiv. Dies spiegelt sich auch in den Forderungen der Angestellten in der Technologiebranche wider: Ein Großteil der Fachkräfte wünscht sich ausdrücklich von potenziellen Arbeitgebern, dass hybrides Arbeiten mit einer Mischung aus Büro- und Homeoffice-Tagen unterstützt wird.

Während der Arbeit am Technology Radar wurden viele kreative Ansätze für Remote Work diskutiert. Hier einige Beispiele: Asynchrone Videoanleitungen sind eine Methode zur Aufzeichnung von Showcases, Produktdemos oder sogar Architekturentscheidungen. Dadurch können Dritte diese bei Bedarf zu einem späteren Zeitpunkt ansehen.

Die Entwicklung von Tools für Remote Pair-Programming schreitet voran; die meisten integrierten Entwicklungsumgebungen verfügen über erstklassige Funktionen für die Zusammenarbeit, beispielsweise geteilte Editoren, geteilte Umgebungen oder auch Live-Debugging in einer geteilten Sitzung. Manche Unternehmen verfolgen bei der Strukturierung ihrer Teams und Systeme einen Ansatz, der explizit die Zeitzonen berücksichtigt. Dieser lässt Flexibilität bei den Mitarbeiterstandorten zu, beseitigt aber die Einschränkungen der Zusammenarbeit über unterschiedliche Zeitzonen hinweg.

* Als Global Head of Technology ist Mike Mason bei ThoughtWorks für die strategische Ausrichtung der Technologie sowie für den Erfolg der Kundenprojekte verantwortlich. Es ist seine Leidenschaft, Spitzentechnologie zur Lösung geschäftlicher Herausforderungen einzusetzen und die Kunden zu beraten, auf welche Weise Technologie ein kritischer Teil ihres Geschäfts sein kann.

(ID:47850363)