Agile Software-Architektur: Die kleinste Veränderung mit dem höchsten Geschäftswert

Veränderung ist unvermeidlich. In der Tat ist dies die einzige Konstante. Das gilt für die Evolution der Arten, der menschlichen Kultur, der Technologie und des Wetters. Offensichtlich gilt sie besonders für alles, was mit Softwareentwicklung zu tun hat. Agile Evangelisten wollen, dass wir uns dem Wandel stellen. Ich denke, sie meinen damit, dass wir Veränderungen einplanen und Änderungen in jedem Teil des Systems, das entwickelt wird, zulassen müssen. Das bedeutet, dass Zeitpläne nicht zu weit in die Zukunft reichen sollten und dass technische Entscheidungen niemals vor dem Ende des Projekts feststehen oder endgültig sein sollten. In der Tat fördert dies ein sehr konstantes Änderungsmanagement, bei dem die Änderungen kontinuierlich, aber klein sind, anstatt groß und unterbrechend.

Die meisten großen Projekte, die ich gesehen habe, folgen einem ganz anderen Muster. Zu Beginn des Prozesses wird der Wandel gefördert und sogar beworben: Ihr Kreditmanagement ist wenig verantwortungsbewusst? Lassen Sie uns Ihr Finanzmanagementsystem umgestalten! Sie haben zu viele separate Programme in Ihrem System? Schmeißen wir sie alle raus und bauen das Ganze neu auf! Ihre Website ist nicht benutzerfreundlich? Lassen Sie uns die ganze Sache mit diesem neuen coolen Framework neu gestalten! Natürlich wird viel analysiert, um herauszufinden, welche Änderungen an dem System vorgenommen werden können, aber sobald alle Möglichkeiten für Änderungen und Verbesserungen gefunden, dokumentiert, berücksichtigt und (neu) konzipiert wurden, sind Änderungen nicht mehr erlaubt. Ein Vertrag wird unterzeichnet und für den Kunden, der mit Fragen und Änderungsvorschlägen bombardiert wurde, beginnt das lange Schweigen. In dieser Zeit wird das System nach dem Entwurf entwickelt, der mit dem Vertrag konsolidiert wurde. Änderungen, die das Unternehmen möglicherweise wünscht, sind sehr kostspielig. Und dann, wenn der Kunde alles über dieses Projekt vergessen hat und sich sicher nicht mehr daran erinnern kann, was genau das Problem war, das gelöst werden sollte: BANG! Das Unternehmen wird von den Auswirkungen der neuen ^LösungTM voll getroffen. Ich denke, dass dieser Ansatz dem Softwareentwicklungsgeschäft geschadet hat. Die Softwareentwicklung wird als ein mühsamer Prozess der Implementierung von Änderungen angesehen, wo es doch eigentlich darum gehen sollte, Lösungen für Geschäftsprobleme zu finden. Die Unternehmen werden von den hohen Kosten für die Analyse ihrer "Informationsprobleme" abgeschreckt, ganz zu schweigen von den Kosten für die Implementierung all dieser Änderungen. Hier kommt das agile Geschäftskonzept voll zur Geltung: Agile Softwareentwicklung verspricht das Wertvollste zuerst und eine kurze Markteinführungszeit. Ich würde gerne einen Slogan hinzufügen: Die kleinste Änderung mit dem höchsten Geschäftswert. Anstatt nach allen möglichen Änderungen zu suchen und zu versuchen, sie alle auf einmal zu erreichen, sollten wir damit beginnen, die kleinste technische Änderung zu finden, die wir vornehmen können und die dem Kunden den größten Nutzen bringt. Das wird das Erste sein, was wir entwickeln werden. Das bedeutet, dass wir ein klares Bild von der technologischen Landschaft haben müssen, in der sich der Kunde befindet. Welche Programme werden dort eingesetzt? Wie sehen seine Prozesse aus? Wie sieht seine Infrastruktur aus? Aber sobald kleine Verbesserungen möglich sind, sollte mit der Entwicklung begonnen und die Auslieferung in Angriff genommen werden. Dies definiert die Rolle eines Architekten in der agilen Softwareentwicklung: Er ist immer auf der Suche nach Verbesserungen im Kontext des Kunden. Wie alles in einem agilen Prozess läuft auch dies parallel zu den anderen Prozessen: Design, Entwicklung, Testen. Der Architekt versucht nicht, einen abschließenden Bericht über die Anforderungen und Bedürfnisse des Kunden zu schreiben, sondern er versucht, diese in den agilen Prozess einzuspeisen, sobald sie entdeckt werden. Sein Fokus und seine Priorität sind dabei (wie immer) der geschäftliche Nutzen und die frühzeitige Bereitstellung. Ich denke, dass dies ein wichtiger Teil des agilen Geschäftskonzepts ist. Anstatt ein neues System zu bauen, bei dem alles verbessert wird, gehen wir von der bestehenden Situation aus und nehmen kleine Änderungen vor, um die gewünschte Situation zu erreichen. Auf diese Weise hat der Kunde auch die Möglichkeit, den Prozess zu steuern, wenn er das Gefühl hat, dass er in die falsche Richtung läuft. Das endgültige Ziel, wie es der Kunde zu Beginn des Prozesses sieht, wird dasselbe sein, aber da der Prozess agil ist, kann der Kunde jederzeit entscheiden, ob er die Richtung ändern möchte oder ob die aktuelle Situation zufriedenstellend ist. In gewisser Weise kann sich der Kunde zurücklehnen und entspannen: Wir werden nicht versuchen, alles auf einmal zu ändern, und der Architekt wird dafür verantwortlich sein, herauszufinden, welche Verbesserungen wann vorgenommen werden sollten. Das ist ein gutes Gegengewicht zu der stärkeren Beteiligung, die wir vom Kunden in Bezug auf Anforderungen und Tests verlangen. Fazit: Es gibt eine Rolle für Architekten in der agilen Softwareentwicklung. Der Architekt kümmert sich um die Integration des Systems in die technologische Landschaft des Kunden. Sein Hauptaugenmerk liegt darauf, festzustellen, welche Änderungen die geringsten Auswirkungen und den größten geschäftlichen Nutzen für den Kunden haben. Dies unterstreicht einen der wichtigsten Teile des agilen Geschäftskonzepts.