Unternehmen, die über keine eigene Applikationslandschaft verfügen gehören definitiv zur Ausnahme. Die Zeit der grünen Wiesen ist also auch in der IT vorbei. Die heute vorliegenden Applikationslandschaften sind meistens vor mehreren Jahren entstanden und in verschiedenen Iterationszyklen konstant weiterentwickelt worden.
Gründe, warum Software verändert wird existieren viele. Zum Beispiel:
- Fehler die auf Grund von neuen Konstellationen auftreten müssen behoben werden
- Neue Anforderungen erfordern Adaptionen im System
- Das Betriebssystem, auf welchem die Software läuft verändert sich
- Sicherheitslücken werden identifiziert und müssen behoben werden
- usw.
Eine praktische Kategorisierung über die verschiedenen Gründe bietet der ISO-14764 Standard: https://en.wikipedia.org/wiki/Software_maintenance
Der Zahn der Zeit und seine unangenehme Folgen
Über den Lebenszyklus einer Software lässt sich immer wieder den gleiche Effekt feststellen: Die Aufwände für das Umsetzen von Änderungen und Fehlerkorrekturen nehmen von Iteration zu Iteration zu. Das Verhältnis zwischen geleistetem Aufwand und erhaltener Funktionalität driftet somit immer weiter - zuungunsten der Funktionalität - auseinander.
Die Kundenanforderungen an die digitalen Services eines Unternehmens wachsen stetig. Darum ist es essenziell, dass die graduelle Weiterentwicklung des bestehenden Geschäfts durch Digitalisierung möglichst effizient vorwärtsgehen kann. Die Fähigkeit bestehende Software und Applikationslandschaften schnell adaptieren zu können wird in Zukunft noch geschäftskritischer.
Der Lösungsansatz aim42
Wie kann man nun diesem negativen Effekt entgegenwirken und das vorhandene Innovationspotenzial der bestehenden Software entfalten?
Genau gleich wie Software heute in agiler Entwicklung über Iterationen (Sprints) entsteht, lässt sich auch die Qualität einer bestehenden Software durch mehrere Änderungszyklen systematisch verbessern. Ein interessanter Ansatz, der diese Philosophie aufgreift und als super Leitfaden dient, entsteht unter dem Namen aim42: Architecture Improvement Method (http://aim42.org). Bei aim42 handelt es sich um eine Systematik Software in Zyklen bewusst weiter zu entwickeln und mit jedem Schritt zu verbessern.
Nebst der Identifikation von technischen Problemen und adäquaten Lösungsmassnahmen werden auch die Kosten und die Risiken für deren Umsetzung systematisch miteinbezogen. Gerade diese Betrachtungsweise finde ich besonders zentral, um am Ende die Probleme zu adressieren, welche auch aus Geschäftssicht entsprechende Relevanz geniessen.
Aim42 gliedert sich dabei in drei Phasen, die jeweils in einem Zyklus durchlaufen werden:
1. Analyze
In der ersten Phase geht es um das Identifizieren und Sammeln von Problemen. Dabei wird einerseits die Software als technisches System betrachtet, andererseits werden Aspekte wie die Organisation, Struktur und Lösungskonzepte beleuchtet. Primär dient diese Phase zum Schaffen eines Verständnis für die vorliegende Software.
2. Evaluate
In dieser Phase geht es um das Quantifizieren und Bewerten der identifizierten Probleme. Zentral sind dabei, die Gegenüberstellung von Kosten, die Probleme verursachen (einmalig oder wiederholt) und Kosten, die für die Behebung des Problems entstehen würden. Diese Gegenüberstellung ermöglicht letztendlich eine betriebswirtschaftliche Priorisierung und Planung der Problembehebung.
3. Improve
In dieser Phase gilt es nun die als relevant definierten Problem zu lösen. Aim42 bedient sich da gängiger Patterns und Methoden.
4. Crosscutting
Aim42 sieht vor, dass jederzeit - egal in welcher Phase man sich gerade befindet - identifizierte Massnahmen gesammelt werden können. Dies geschieht mittels dem sogenannten "Improvement Backlog".
Bessere Resultate dank Open Source
Interessanter Aspekt: Aim42 ist Open Source. Das bedeutet, dass die Systematik durch eine Community - bestehend aus erfahrenen Software Architekten - entstanden ist und konstant weiter ausgebaut wird. Dadurch ist sichergestellt, dass die Methoden und Ansätze nicht von einzelnen Personen ausgehen, sondern durch eine Gruppe erfahrener Architekten geprägt und verifiziert werden. Unter dem GitHub-Repository: https://github.com/aim42/aim42 kann mitgearbeitet und die Aktivitäten nachvollzogen werden.