Ein Paradigmenwechsel ist nötig, um den Feature-Hunger zu beenden

Unser CEO Steven ten Napel schrieb in seinem Blog über die Notwendigkeit eines Paradigmenwechsels bei der Innovation von Softwareprodukten. In diesem Blog möchte ich darlegen, dass der Paradigmenwechsel sowohl Bescheidenheit als auch Ehrgeiz erfordert.

Viele von uns sind schon seit geraumer Zeit in der IT-Branche tätig, vielleicht seit mehr als 10, 20 oder 30 Jahren. Und deshalb fühlen wir uns vielleicht wie erfahrene Profis. Aber macht uns das auch zu guten Handwerkern? In vielen Handwerksberufen gibt es einen traditionellen Lebenszyklus für das Erlernen der Tricks und Kniffe des Handwerks, der auf dem mittelalterlichen Zunftwesen basiert. Sie fangen als Lehrling an, nach ein paar Jahren harter Arbeit und guter Leistung werden Sie Geselle, und nach vielleicht 20 Jahren haben Sie die Chance, Meister zu werden.

Im Grunde genommen ist es nichts anderes als die Anerkennung Ihrer Erfahrung und Ihrer Fähigkeiten durch andere in der gleichen Branche. Erfahrung und Fähigkeiten - beides muss sich im Laufe der Jahre entwickeln, damit andere anerkennen, dass Sie gut sind in dem, was Sie tun.

Modesty

Aber es gibt noch eine weitere Sache: Tradition. Gilden bauen auf einer Tradition auf, die sich im Laufe von Hunderten von Jahren, vielleicht sogar Tausenden, herausgebildet hat. Was ist eine Tradition? Vielleicht können wir es so sehen, dass das kollektive Wissen und die Erfahrung aller in der Branche Tätigen zu bewährten Praktiken führt, damit das Rad nicht immer wieder neu erfunden werden muss.

Und hier wird es für uns IT-Profis interessant: Wie viel Tradition gibt es in unserer Branche? Vielleicht 50 Jahre? Wie ist das im Vergleich zu anderen Bereichen wie dem Bauwesen, dem Recht oder der Medizin?

Vielleicht sind Sie stolz darauf, dass Ihre Software die Arbeit im Baugewerbe oder im Rechtswesen erheblich verbessert oder Ärzten sehr hilft. Und das sollten Sie auch sein. Aber gleichzeitig würde ich argumentieren, dass Bescheidenheit eine gute Angewohnheit ist, wenn wir über unsere tägliche Arbeit nachdenken. Die IT-Branche ist noch nicht so lange im Geschäft. Wir sind alle Neulinge. Unsere Tradition ist noch im Entstehen begriffen. Der Hype von heute ist allzu oft schon morgen Schnee von gestern.

Gestern musste unsere Anwendung in Java mit Hibernate geschrieben und webfähig sein, um Client-Installationen oder die Microsoft-Variante zu reduzieren. Heute muss sie SaaS-fähig sein, mit Multi-Tenancy-Unterstützung, als offene REST-basierte API mit darauf aufbauenden nativen Apps und, ach ja, wir müssen auch das Plattformspiel spielen.

Gartner hat das Hype Cycle Model entwickelt, um diese Entwicklung der Tradition zu beschreiben. Und denken Sie nicht, dass dies nur mit Technologie und Architektur zusammenhängt: Im gleichen Tempo erleben wir Veränderungen und Innovationen bei den organisatorischen Prozessen, von Wasserfall zu Scrum und Agile durch alle Arten von Collaboration-Tools.

Und das ist nicht immer zum Besten. Wie oft verwandelt sich ein Hype tatsächlich in etwas Produktives? Und selbst wenn er sich für den Markt auszahlt, können Sie sich immer noch fragen: Wird er auch einen Mehrwert für meine Software bringen? Entscheidungen, die in der Vergangenheit getroffen wurden, können jetzt Optionen verhindern. Wie kann man also die Auswirkungen der heutigen Entscheidungen auf die Optionen von morgen verstehen? Die Falle, eine neue Technologie oder Methode nur um der Technologie willen einzuführen, ist für F&E-Abteilungen und Softwareingenieure immer nahe. Aber wie können wir den geschäftlichen Nutzen einer neuen Technologie darstellen, wenn es mehr als zwei Jahre dauert, unser Produkt umzuschreiben?

Ehrgeiz beginnt mit dem Wissen, wo man steht

Aber Bescheidenheit sollte uns nicht davon abhalten, ehrgeizig zu sein. In dieser Serie von Blogbeiträgen möchte ich Trends aus der Perspektive der Ursachenanalyse erklären. Ja, wir können bescheiden sein, was den Erfolg neuer Hypes angeht, aber in fast allen Fällen war der Ausgangspunkt des Hypes eine gute Lösung für ein bestehendes Problem, die sich herumgesprochen hat. Vielleicht interpretieren viele Menschen die Lösung anders, so dass der Hype entgleist, aber zumindest war das Problem ein echtes Problem. Nehmen Sie zum Beispiel Wasserfall und Scrum. Eine Weile, nachdem der Hype um Scrum losgetreten wurde, hat jeder Scrum gemacht - das heißt: jeder hat seine eigene Version von Scrum gemacht. Es entgleist also ein wenig. Aber das grundlegende Problem liegt in der mangelnden Agilität des Wasserfall-Prozesses. Ein echtes Problem.

Betrachten wir die aktuelle Situation, in der wir uns befinden:

• Wie sind wir hierher gekommen?
• Was sind die grundlegenden Fehler, die wir in unserer Architektur gemacht haben?
• Warum sind uns die Möglichkeiten ausgegangen?

Viele Fehler und Entscheidungen wurden damals unbewusst und mit bestem Wissen und Gewissen getroffen. Es ist leicht, über die Geschichte zu urteilen, besser ist es, bescheiden zu sein und aus ihr zu lernen.

Schauen wir uns die Fakten an und warum sie entstanden sind.

• Unsere Anwendung ist groß und komplex

• Wir leiden unter Funktionsmangel - es dauert zu lange, neue Funktionen bereitzustellen

• Wir leiden unter technologischem Rückstand - verwenden immer noch Delphi, Progress oder VB

• Es ist schwierig und zeitaufwändig, alle Nutzungsmöglichkeiten unseres Produkts zu testen

• Das Produkt hat zu viele Konfigurationsoptionen, und jeder Kunde verwendet andere Einstellungen

• Es ist schwer, über verschiedene Versionen hinweg kompatibel zu bleiben

• Unser Datenbankschema kann nicht reduziert oder geändert werden, da unsere Kunden für ihre Berichte direkt darauf zugreifen und Änderungen diese Berichte zerstören.

• Wir haben versucht, neue, webbasierte Benutzeroberflächen für bestimmte Rollen zu erstellen, und es sieht gut aus, aber jetzt haben wir auch die Logik für alle Rollen repliziert

• Wir haben einen Rückstand von vielen Tickets und Ideen, und es ist entmutigend zu sehen, wie dieser Rückstand immer größer wird.

• Wir haben nie Zeit, technische Schulden zu bereinigen

• Es gibt so viel undokumentierten Code, und der Typ, der ihn geschrieben hat, ist schon lange weg

• Wir veröffentlichen einige Male pro Jahr, aber wir sind nicht in der Lage, diese Frequenz zu erhöhen.

In gewisser Weise sagt der erste Punkt alles: Die Anwendung ist groß und komplex. Am Anfang war sie nicht so, aber jetzt ist sie so. Und wenn wir bei Null anfangen und sie nach bestem Wissen und Gewissen neu aufbauen würden, bräuchten wir wahrscheinlich weitere 3 Jahre, um die gesamte Funktionalität so umzuschreiben, dass alle aktuellen Anforderungen unserer Kunden erfüllt werden, und bis dahin ... Nun, das ist einfach keine Option.

Wie können wir sie also schrittweise modernisieren? In jedem Unternehmen und jeder Branche ist es eine gute Tradition, die Komplexität zu reduzieren, indem man die Dinge in Teile zerlegt. Aufteilen und erobern!

Es ist gut möglich, dass die Anwendung bereits aus einer Reihe von Funktionsmodulen besteht, die in unserem Katalog sogar als verschiedene Teile mit unterschiedlichen Preisen auftauchen können.

Es besteht eine gute Chance, dass unsere Codebasis entsprechend komponentisiert ist.

Und es besteht eine größere Chance, dass wir am Ende alles in einer einzigen Datenbank speichern, was das Ganze effektiv zu einem großen Monolithen dekomponiert.

Ehrgeiz

Unsere Strategie muss also darin bestehen, sie wieder in Stücke oder Komponenten zu zerlegen. Und unser Ziel muss es sein, die Bereitstellung auf Komponentenebene vorzunehmen, um mehr Agilität in unserem Softwareentwicklungsprozess zu erreichen und dem Feature-Starvation Einhalt zu gebieten.

Und das bedeutet, dass wir die Prozesse für die Entwicklung, das Testen und den Einsatz von Komponenten, die für unsere Kunden ein nahtloses Ganzes darstellen, neu erfinden müssen.

Hier kommen die modernen Technologien und Architekturmuster ins Spiel. Vielleicht sind Sie mit Begriffen wie Containerisierung, DevOps, funktionale Programmierung, Domain-Driven Design, Event Sourcing usw. vertraut. Vielleicht halten Sie sie für einen weiteren vorübergehenden Hype. Aber wir werden einige von ihnen in den folgenden Blogs näher beleuchten und uns auf das Kernproblem konzentrieren, das sie lösen, und darauf, wie sie für einen Paradigmenwechsel wirklich erforderlich sind. Sie sind für sich genommen schon wertvoll, aber in Kombination werden sie den Softwareentwicklungsprozess neu in den Griff bekommen.

DevOps sollte eigentlich OpsDev heißen

Die Bereitstellung von Komponenten, die zusammenarbeiten müssen, ist eine Herausforderung, bei der neue Technologien wie Docker und Kubernetes und Plattformen wie Amazon AWS und Microsoft Azure helfen können. Kontinuierliche Integration und kontinuierliche Bereitstellung sind zum DevOps-Hype aufgestiegen. Aber um ein Umdenken zu erreichen, müssen die Entwickler bescheidener sein. Nicht die Entwicklung treibt das Geschäft an, sondern die Kunden. Und die arbeiten mit dem, was Ops liefert. Machen Sie also lieber bei Ops mit, als sie in Ihre Entwicklungsabteilung einzuladen.

APIs müssen vom Produktmanager entworfen werden

Komponentisierung bedeutet auch, dass unsere Komponenten nicht mehr über die Datenbank miteinander verbunden werden können. Stattdessen müssen sie formale Verträge auf API-Ebene verwenden. Wenden wir hier Micro-Services an? Ja und nein. Mehr als etwas Technisches bedeutet es etwas für unser Produktmanagement. Wir müssen unsere Verträge aus der Perspektive des Informationsmanagements neu gestalten und darüber nachdenken, was Dateneigentum wirklich bedeutet. Es ist zu einfach, den internen Fremdschlüssel an die externe API weiterzugeben.

Hören Sie zu! Sie müssen die Welt informieren

Die Öffnung von Systemen kann über eine Benutzeroberfläche oder über eine Anwendungsprogrammierschnittstelle erfolgen. Die API-Perspektive ist seit den späten 90er Jahren in aller Munde. Aber eine API ist etwas, dem das System nur zuhört. Um eine kollaborative Komponentisierung zu erreichen, ist es unerlässlich, dass eine Komponente über ihre Datenänderungen informiert wird. Das ist die Essenz der Event Sourcing Technologie.

Konfiguration ist eine Programmiersprache

Viele der Kundenprodukte, die wir kennen, haben eine Art Stack, der die Produktivität der Entwickler unterstützt. Dabei kann es sich um ein 4GL-Framework oder um eine Reihe von Bibliotheken und Frameworks handeln, die die 3GL-Produktivität verringern helfen. In beiden Fällen gibt es außer auf der Ebene des Frameworks selbst nur wenig Unterstützung für die Konfiguration und Anpassung. Einstellungen werden über Eigenschaftsdateien, XML-Dateien, hier und da in Datenbanktabellen vorgenommen. Und niemand hat den Überblick über das Ganze, abgesehen von einigen wirklich erfahrenen und klugen Leuten im Implementierungsteam des Kunden.

In gewisser Weise bilden die gesamte Konfiguration und die Einstellungen, die in der Anwendung verwendet werden können, eine Programmiersprache für die Implementierungsberater. Aber ist es eine solide Sprache? Domain-Driven Design zusammen mit Domain Specific Languages kann hier wirklich helfen, den nächsten Schritt zu machen.

Und was wäre, wenn eine solche Sprache visuell wäre? Ein Bild sagt mehr als 1000 Worte.

Ehrgeiz mit Bescheidenheit sollte die Funktion des Verhungerns beenden

In dieser Reihe von Tech-Blogs möchte ich tiefer in jedes dieser Themen eintauchen. Sie decken eine Reihe von Technologien, Mustern und Ansätzen ab, die zusammengenommen einem Unternehmen helfen werden, bei der Softwareentwicklung agiler und zukunftsfähiger zu werden. Und wenn sie diszipliniert angewendet werden, verwandeln sie den Feature-Hunger in einen kontinuierlichen Feature-Strom bis hin zur agilen Budgetierung.

Woher diese Muster und Technologien kommen, welche Probleme sie zu lösen versuchen und wie wir sie in unserem eigenen Produktstapel anwenden können, sind wichtige Fragen. Begleiten Sie uns auf unserem ehrgeizigen Weg, eine Tradition der bescheidenen Handwerkskunst zu formen.