IT-Architektur zwischen Elfenbeinturm und Drecksarbeit

Zuordnung der IT-Architekturkosten

Die Kosten für die IT-Architektur entstehen in allen fünf oben gezeigten Bausteinen. Wie auch die jüngsten Ereignisse aus dem Finanzbereich zeigen, ist nicht nur die Ausgestaltung der Systeme maßgebend, sondern auch die Art und Weise, wie diese gelebt werden.

Als erste und offensichtliche Kostenkomponente sind die direkten Kosten für die Erstellung und Wartung der Konzepte und Standards zu erfassen. Hierzu zählen als größter Kostenblock die personellen Ressourcen. Dann folgen die Kosten für die technische Ausrüstung, Lizenzen etc. Damit wird der Baustein 1 (Struktur der Architektur) vollständig erfasst, auch Teile der Bausteine 2 bis 4 sind darin enthalten.

Zu den Kosten für die IT-Architektur sind auch die Aufwände zu zählen, die erbracht werden, um die Architekturvorgaben umzusetzen. Vor allem sind dies Supportaufwände für die korrekte Anwendung im Entwicklungsprozess und die gesamte Prozessgestaltung mit den notwendigen periodischen Reviews.

Nicht zu vergessen sind die Prozesse im Zusammenhang mit der Einhaltung der Governance (Baustein 5). So tritt immer wieder die Situation ein, dass „Quick Wins“ in einzelnen Projekten nur erzielt werden können, wenn Architekturvorgaben außer Acht gelassen werden. Hier gilt es nun, zwischen kurzfristigen Erfolgen und den Aufwänden für eine nachhaltige Lösung abzuwägen. Nicht immer ist die Einhaltung der Architekturvorgaben die bessere Lösung.

Der Aufwand für die Einhaltung der Compliance der Architekturvorgaben hält sich insbesondere bei größeren Projekten ab einem Aufwand von mehr als 1000 Personentagen in Grenzen, denn um eine geordnete Entwicklung zu ermöglichen, müssen die notwendigen Dokumente erstellt und auch innerhalb des Projektteams kommuniziert werden. Der zusätzliche Aufwand für spezifische Architektur-Reviews kann mit unter 50 Personentagen veranschlagt werden. Diese Aufwände können als Versicherungsprämie betrachtet werden, denn sie schützen vor unliebsamen Überraschungen im weiteren Projektverlauf oder später in der Produktion.

Zwei Beispiele

In einem größeren Entwicklungsprogramm wurde sehr großer Wert auf ein konsistentes Design und eine einheitliche Methodik gelegt. Das Programm war auf mehrere Jahre angelegt und umfasste eine Projektmannschaft von ungefähr hundertzwanzig Personen. Die Entwicklung erfolgte an verschiedenen Standorten. Im Verlauf der Zeit geriet ein Projekt in einen Engpass und ein anderes Projekt an einem anderen Standort wurde deshalb behindert. Kurzfristig wurde beschlossen, die brachliegenden Ressourcen des zweiten Projekts zur Behebung des Engpasses einzusetzen. Durch die stark standardisierte Umgebung waren die zusätzlichen Mitarbeiter nach drei Tagen Einarbeitung voll produktiv. Konsequenz: Die vorbereitende Standardisierung und Schulung zahlte sich aus.

In einer gewachsenen IT-Landschaft bestanden Schwierigkeiten mit redundanten Datenbeständen. Kundendaten waren über mehrere Orte verstreut und mehrfach gespeichert, zum Teil handelte es sich um die gleichen Informationen mit verschiedenen Attributbezeichnungen und Formaten. Das Ergebnis der Analyse zeigte, dass sich eine Bereinigung nicht auszahlt, da mehrere Applikationen massiv umgestaltet werden müssten ohne einen Mehrwert zu bringen und durchgehende Prozesse fraktioniert würden. Die Lösung bestand darin, dass unter dem Titel „Managed Redundancy“ die wichtigsten Datenbestände durch Brücken verbunden wurden. Es zeigte sich jedoch auch, dass bei einem etwaigen Totalersatz einzelner Applikationen der Architekturaufwand zur Behebung der Redundanzen sich auszahlen wird. Konsequenz: Eine nachträgliche punktuelle Bereinigung lohnt sich nicht, wohl aber konzeptionelle Vermeidung bei neuen Applikationen, wobei der Grundsatz gilt: Alt passt sich neu an.

Zusammenfassung

Eine gute IT-Architektur verlagert Aktivitäten aus den eigentlichen Projekten in eine Vorbereitungsphase und ermöglicht so eine mehrfache Nutzung. Typisches Beispiel dafür ist die SOA (Service-oriented Architecture). Wobei die Erstellung und Verwaltung eines Services aufwändiger ist als wenn eine Funktion nur zum Einsatz an einer Stelle realisiert wird.

IT-Architektur erfolgreich zu betreiben bedingt ein auf Ordnung bedachtes Verhalten und erfordert sehr viel Ausdauer. Eine erfolgreiche IT-Architektur bedarf der stetigen Pflege und wird nie einen endgültigen Zustand erreichen, sondern sie muss immer weiterentwickelt werden. Der Business Value der IT-Architektur liegt primär in der Kostenvermeidung und Kosteneinsparung, wobei die Vermeidung unnötiger Kosten wesentlich einfacher, erfolgreicher und mit weniger Aufwand zu erreichen ist. IT-Architektur als Enabler ist dann eher die Ausnahme.

Die IT-Architektur steht einem opportunistischen auf kurzfristigen Erfolg bedachten Verhalten im Weg. In einer geordneten Umgebung können unter Missachtung sämtlicher Regeln kurzfristig Erfolge erzielt werden, auf die IT-Architektur bezogen heißt das unter Umgehung von Standards und Konzepten. Innerhalb kurzer Zeit können so durch Zulassung von Redundanzen oder unkontrollierter Einführung zusätzlicher Technologien im Einzelfall eine kurze Time-to-Market- und auch eine Kostenreduktion durch die nicht vorgenommenen Architektur-Reviews erreicht werden, denen dann später eine Kostenexplosion folgt.

Dr. Heinrich Krause ist unabhängiger Berater für IT und Enterprise Architecture Management. Er ist Betriebswirtschaft und verfügt über eine langjährige Erfahrung in der Applikationsentwicklung in vielen Branchen. Bei einer Schweizer Großbank hat er als Leiter der Applikationsarchitektur die IT-Architektur und die Einführung der SOA maßgebend geprägt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.