"Der Tausch von digitalen Lösungen (Services, Fähigkeiten) ist der Handel des 21. Jahrhunderts; Plattformen sind die Boote der Eroberer"; Markus Warg, CIO.de
Agile Softwareentwicklung: yes please!
Traditionelle (Legacy) Softwareentwicklung ist häufig dadurch charakterisiert, dass sämtliche Anforderungen an die zu entwickelnden Anwendungen vor Start der Softwareentwicklung erhoben und berücksichtigt werden. Diese sogenannten Big Up Front Architektur Ansätze folgen der Idee, dass erst wenn alle Anforderungen verstanden sind, die besten Designs, Architekturen und der beste Code entstehen kann.
Die letzten Dekaden haben gezeigt, dass Big Up Front Architektur Ansätze sich nicht bewähren. In der Zeit, die benötigt wird, um die Anforderungen vollumfänglich aufzunehmen und zu verstehen, ändern sich oft die Anforderungen der Kunden und des Marktes so das der ausgearbeitete Big Up Front Ansatz bzgl. Architektur und Design nicht mehr zu den Kundenerwartungen passt.
Agile Softwareentwicklung ist ein Oberbegriff für die Methoden (bspw. Scrum, Kanban), mit denen die Softwareentwicklung schneller, flexibler und nutzerorientierter erfolgen soll. Allen agilen Methoden gemeinsam ist das sie auf kleine, selbstorganisierende Teams setzen, die eng mit den Kunden interagieren und schnell Zwischenergebnisse liefern. Im "Agile Manifesto" werden die Prinzipien der agilen Softwareentwicklung beschrieben.
Warum ist "agile Softwareentwicklung" alleine nicht genug?
Agile Softwareentwicklung vertraut darauf, dass auch die besten Architekturen durch selbstorganisierte Teams entstehen ("Agile Manifesto"). Das mag bezogen auf die Lösungsarchitektur des konkreten "features" stimmen, berücksichtigt jedoch nicht übergreifende Anforderungen an die (Unternehmens-) Architektur wie bspw. bzgl. der "user experience" oder dem Zusammenspiel von Anwendungen.
Plattformbasierte Ansätze als Chance
Service Plattformen verbinden Akteure und ermöglichen die Integration und Bündelung von Ressourcen ( Daten, Wissen, Services, Produkte, Fähigkeiten...) bei deren Gebrauch (Interaktion) Nutzen entsteht.
Wenn diese Service Plattformen über eine geeignete Architektur i.S. eines Bauplanes verfügen, dann können die Vorteile der agilen Softwarentwicklung und einer ganzheitlich vorausgedachten Architektur (des Bauplans) zusammengebracht werden.
Die SDA - Service Dominierte Architektur - ist so ein Bauplan. Dieser Bauplan ist bereits in der Anlage der Lösungsbausteine (Softwarestacks) und der Plattform berücksichtigt. Damit wird sichergestellt, dass die Bausteine (wie bei einem Haus oder einem Fahrrad) zusammenspielen.
Little Up Front Plattformansätze
Jedem Use Case und jedem Lösungsbaustein wird die notwendige Architektur mitgegeben, damit die Lösung mit der Service Plattform und den anderen Lösungen zusammenspielt.
Up Front Plattformansätze
Wenn bereits fest steht, dass die Service Plattform für eine Vielzahl an Use Cases genutzt werden soll, dann ist es sinnvoll mit der Plattform zu starten und diese dann mit jedem Use Case und Lösungsbaustein weiterzuentwickeln.
SDA als Enterprise Architecture
Die Unternehmensarchitektur (Enterprise Architecture) dient als Organisationslogik für die Geschäftsprozesse und die IT. Sie bildet den Ordnungsrahmen und ermöglicht das die einzelnen Ergebnisse zusammenpassen wie beim Hausbau.
McKinsey visualisiert zwei Ansätze zur Ausrichtung von Teams (bspw. Entwicklerteams) auf die Unternehmensarchitektur (Enterprise Architecture) wie nachfolgend dargestellt.
Dabei ist entscheident, dass es erstens eine Unternehmensarchitektur (Enterprise Architecture) gibt und das zweitens alle Teams angehalten werden sich an dieser auszurichten und ihre Ergebnistypen auf diese einzahlen. Ein Beispiel für eine Unternehmensarchitektur ist die Service Dominierte Architektur.
Diesem Ansatz entsprechend unterstützt das IfSD.Hamburg das Verständnis von McKinsey (siehe Buckow et.al.) das es einer "Revolution" im Architekturmanagement bedarf, um das "Alignment" der IT zu den Geschäftsanforderungen sicherzustellen.
