Warum die Beherrschung der Komplexität heute die eigentliche Herausforderung in der Software ist

Der Grund, warum wir Komplexität nicht einfach wegwünschen oder „reparieren“ können, liegt darin, dass jede Lösung – sei es eine Technologie oder Methodik – die Komplexität auf irgendeine Weise neu verteilt. Lösungen ordnen Probleme neu. Als Microservices aufkamen (ein Softwarearchitekturansatz, bei dem eine Anwendung oder ein System aus vielen kleineren Teilen besteht), lösten sie scheinbar viele der Wartungs- und Entwicklungsherausforderungen, die monolithische Architekturen (bei denen die Anwendung ein einziges ineinandergreifendes System ist) mit sich bringen. Dabei stellten Microservices jedoch neue Anforderungen an die Entwicklungsteams. Sie erfordern eine größere Reife in Bezug auf Praktiken und Prozesse. Dies ist einer der Gründe, warum wir die Menschen in einer Ausgabe des Technology Radar aus dem Jahr 2018 vor dem gewarnt haben, was wir „Microservice-Neid“ nennen. CTO Rebecca Parsons schrieb, dass Microservices niemals für die Einführung auf dem Technology Radar empfohlen würden, weil „nicht alle Organisationen Microservices sind“. -bereit.” Wir haben festgestellt, dass es eine Tendenz gibt, Microservices einfach deshalb einzuführen, weil sie in Mode sind.

Dies bedeutet nicht, dass die Lösung schlecht oder fehlerhaft ist. Vielmehr müssen wir erkennen, dass die Lösung ein Kompromiss ist. Bei Thoughtworks sagen wir gerne „es kommt darauf an“, wenn Leute Fragen zum Wert einer bestimmten Technologie oder eines bestimmten Ansatzes stellen. Es kommt darauf an, wie es zu den Anforderungen Ihres Unternehmens passt und natürlich auf Ihre Fähigkeit, seine besonderen Anforderungen zu bewältigen. Dies ist ein Beispiel für die wesentliche Komplexität in der Technik – etwas, das nicht beseitigt werden kann und das bestehen bleibt, egal wie sehr Sie möchten, um ein Maß an Einfachheit zu erreichen, das Sie als angenehm empfinden.

Im Hinblick auf Microservices beobachten wir zunehmende Vorsicht gegenüber der überstürzten Umsetzung dieses besonderen Architekturansatzes. Einige unserer Kollegen haben sogar den Begriff „Monolith-Revivalisten“ vorgeschlagen, um diejenigen zu beschreiben, die sich von Microservices abwenden und sich wieder der monolithischen Softwarearchitektur zuwenden. Obwohl es unwahrscheinlich ist, dass die Softwarewelt vollständig zu Monolithen zurückkehren wird, deuten Frameworks wie Spring Modulith – ein Framework, das Entwicklern dabei hilft, Code so zu strukturieren, dass es bei Bedarf einfacher wird, einen Monolithen in kleinere Microservices aufzuteilen – darauf hin Praktiker werden sich der Kompromisse verschiedener Ansätze bei der Erstellung und Wartung von Software immer bewusster.

Da technische Lösungen die Angewohnheit haben, Komplexität neu zu organisieren, müssen wir sorgfältig darauf achten, wie diese Komplexität verwaltet wird. Geschieht dies nicht, kann dies schwerwiegende Auswirkungen auf die Produktivität und Effektivität der Entwicklungsteams haben. Bei Thoughtworks verfügen wir über eine Reihe von Konzepten und Ansätzen, mit denen wir Komplexität bewältigen können. Sinnvolle Vorgaben sind beispielsweise Ausgangspunkte für ein Projekt oder eine Arbeit. Dabei handelt es sich nicht um Dinge, die wir einfach als Regel umsetzen müssen, sondern um Praktiken und Tools, von denen wir gemeinsam anerkennen, dass sie für die meisten Projekte effektiv sind. Sie geben Einzelpersonen und Teams eine Grundlage, um zu beurteilen, was anders gemacht werden könnte.

Einer der Vorteile vernünftiger Standardeinstellungen besteht darin, dass sie Sie vor der Verlockung von Neuheiten und Hype schützen können. So interessant oder aufregend eine neue Technologie auch sein mag, sinnvolle Vorgaben können Sie bei dem verankern, was Ihnen wichtig ist. Das heißt nicht, dass neue Technologien wie generative KI nicht mit Begeisterung und Begeisterung behandelt werden sollten – einige unserer Teams haben mit diesen Tools experimentiert und beeindruckende Ergebnisse gesehen –, sondern dass die Einführung neuer Tools auf eine bestimmte Art und Weise erfolgen muss das sich gut in Ihre Arbeitsweise und Ihre Ziele einfügt. Tatsächlich gibt es eine Fülle von Ansätzen für GenAI, von hochkarätigen Tools wie ChatGPT bis hin zu selbst gehosteten LLMs. Bei der effektiven Nutzung von GenAI kommt es sowohl darauf an, die richtige Umsetzung für Sie und Ihr Team zu kennen, als auch auf technisches Fachwissen.

Interessanterweise sind die Tools, die uns bei der Bewältigung der Komplexität helfen können, nicht unbedingt neu. Eine Sache, die in der neuesten Ausgabe von Technology Radar thematisiert wurde, war die sogenannte risikobasierte Fehlermodellierung, ein Prozess, der verwendet wird, um die Auswirkungen, die Wahrscheinlichkeit und die Fähigkeit zur Erkennung verschiedener Arten von Systemausfällen zu verstehen. Dies hat seinen Ursprung in der Fehlermöglichkeits- und Einflussanalyse (FMEA), einer Praxis, die bis in die Zeit nach dem Zweiten Weltkrieg zurückreicht und in komplexen Ingenieurprojekten in Bereichen wie der Luft- und Raumfahrt eingesetzt wird. Dies signalisiert, dass es einige Herausforderungen gibt, die bestehen bleiben; Auch wenn immer wieder neue Lösungen zur Bekämpfung dieser Probleme auftauchen, sollten wir uns bei der Suche nach Werkzeugen und Techniken auch in der Vergangenheit wohlfühlen.

McKinseys Argument, dass die Produktivität von Entwicklungsteams erfolgreich gemessen werden kann, sorgte in der gesamten Softwareentwicklungslandschaft für Aufsehen. Auch wenn es sicherlich wichtig ist, die richtigen Kennzahlen zu haben, kann die Priorisierung der Produktivität in unserem Denken bei komplexen Systemen und einer sich ständig verändernden Lösungslandschaft mehr Probleme verursachen als lösen. Technology Radar hat dies mit einer Ausgabe zum Thema „Wie produktiv ist die Messung der Produktivität?“ hervorgehoben. Dabei wurde hervorgehoben, wie wichtig es ist, sich mithilfe von Tools wie DX DevEx 360 auf die Entwicklererfahrung zu konzentrieren.

Wenn wir uns auf die Produktivität konzentrieren, wie McKinsey es vorschlägt, können wir fälschlicherweise das Codieren als die „eigentliche“ Arbeit des Software-Engineerings betrachten und dabei Dinge wie Architekturentscheidungen, Tests, Sicherheitsanalysen und Leistungsüberwachung übersehen. Das ist riskant – Organisationen, die eine solche Sichtweise übernehmen, werden Schwierigkeiten haben, greifbare Vorteile aus ihren digitalen Projekten zu ziehen. Aus diesem Grund besteht die größte Herausforderung bei Software heute darin, die Komplexität zu beherrschen. Behandeln Sie es nicht als etwas, das um jeden Preis minimiert werden muss, sondern als eine Herausforderung, die Umsicht bei Prozessen, Praktiken und Governance erfordert. Die entscheidende Frage ist, ob die Branche dies erkennt.

Dieser Inhalt wurde von Thoughtworks erstellt. Es wurde nicht von der Redaktion des MIT Technology Review verfasst.