Chief Retirement Officer – eine unbeliebte aber sinnvolle Rolle

Viele Landschaften von Geschäftsapplikationen, die man als Analyst so zu sehen bekommt, scheinen von einer ähnlichen Einstellung geprägt zu sein. Auch wenn die Lage hier natürlich etwas komplizierter ist, ist ein Grundproblem doch ähnlich: welchen Nutzen soll eine langwierige Aufräumaktion schon haben, wenn sich die Gesamtaufgabenstellung nicht ändert und hinterher die selben Sachen im Regal liegen wie vorher?

In beiden Fällen ist der Nutzen eher versteckt und nur langfristig zu erkennen. Im Zimmer geht es zum Beispiel darum, Dinge wieder zu finden, was wesentlich aufwendiger ist, wenn alles durcheinander liegt. Bei Applikationen geht es eher um die Ressourcen, die sie unweigerlich konsumieren; und beim Schreckensthema “Anpassungen” (oder neudeutsch “Customizations”) auch darum, dass die angepassten Applikationen nur weit schwieriger und aufwändiger zu betreiben und weiterzuentwickeln sind, etwa durch sogenannte “Feature Packs” oder gar einen Upgrade auf eine neuere Version.

Dummerweise wird das Wegräumen von Anwendungen oder Anpassungen nicht als attraktiver Job angesehen. (Eine weitere Parallele!) Wie viel mehr kann man sich mit der Einführung einer neuen Anwendung brüsten, und wie gut schmeckt das Lob der Anwender für eine gelungene Anpassung!

Also muss jemand her, dessen Rolle das Aufräumen ist und der vor allem an dem Grad an Aufgeräumtheit der gesamten Landschaft gemessen wird. (Schwierig auch das: wie zählt man Bauklötze, die nicht mehr auf dem Boden rumliegen; wie misst man die Abwesenheit von sogenanntem Chaos? Stoff für endlose Diskussionen…) Ich schlage daher den CRO (“Chief Retirement Officer”) vor, der sich zuerst um das Aufspüren von nicht mehr dringend benötigten Applikationen oder Anpassungen und dann um ihre ordnungsgemäße Entsorgung kümmert. Schon das Aufspüren kann spannend sein, denn meist fehlen ausreichende Dokumentationen, die darüber Auskunft geben, vor welchem Hintergrund und mit welchen Begründungen eine bestimmte Anwendung eingeführt oder eine Anpassung gebaut wurde.

Als Hilfsmittel für das Aufräumen gibt es von Gartner die TIME-Methode. Sie sortiert Anwendungen, Anpassungen, aber etwa auch Geschäftsaktivitäten in vier Körbe, nach zwei Kriterien (ja, mal wieder ein Gartner-Quadrant): technische Qualität und geschäftsseitiger Nutzen. “Bauklötze” mit geringer technischer Qualität und ohne größeren Nutzen werden entsorgt (“eliminate”). Solche ohne Nutzen, aber mit hoher technischer Qualität werden toleriert (“tolerate”; höchstens kann man denjenigen zur Rechenschaft ziehen, der dem nutzlosen Klotz eine gute technische Qualität beschert hat). Bausteine mit hohem Nutzen, aber geringer technischer Qualität bergen das größte Risiko; sie müssen auf eine bessere Grundlage migriert (“migrate”) werden. Hoffentlich bleiben dann nur noch solche mit hohem Nutzen und bester technischer Qualität übrig; in sie wird weiter investiert (“invest”). Voilà: Tolerieren, Investieren, Migrieren, und Eliminieren, fertig ist der Besen zum Durchfegen (vgl. Application Portfolio Triage: TIME for APM).

Jetzt muss man nur noch anfangen, und auch das fällt manchmal schwer: “Komm schon, je schneller wir anfangen, um so eher sind wir fertig und haben Zeit zum Spielen!” Ja ja…