Im Gespräch mit Detlev Klage

Das Verständnis für Architektur zählt

Mirko Schrempp

„Im Fokus steht die Wertschöpfung für unsere Kunden und die Wettbewerbsfähigkeit.“


Business Technology: Wie zeigt sich in Ihrem Alltag, der kein reiner Architektenalltag ist, dass die IT grundlegender Bestandteil des Unternehmenserfolgs ist? Und wie drückt sich das in Ihrer Arbeitsweise aus, dass Architektur, Technologie und die Businessseite zusammenarbeiten müssen?

Detlev Klage: Wir sind der IT-Dienstleister der Sparkassenfinanzgruppe. Das heißt unser Erfolg wirkt sich auch auf den Erfolg unserer Kunden aus. Der Business Value muss beim Kunden ankommen. Im Fokus steht daher die Wertschöpfung für unsere Kunden und die Wettbewerbsfähigkeit. In diesem Sinne haben wir ein ganzheitliches Bild entwickelt, um Architektur durchgängig von einem Leitbild, über die Führungskultur hin zu strategischen Zielen in die operative Umsetzung ableiten zu können. In diesem Leitbild steht die Kundenorientierung weit vorne. Denn der Value Add, den wir der IT entsprechend anbieten, wird dann zum Mehrwert, wenn er beim Kunden ankommt. Sowohl auf der Kostenseite als auch auf Seiten – und die folgende Reihenfolge ist aus meiner Sicht wichtig – der Sicherheit, Verfügbarkeit und Wirtschaftlichkeit der IT-Anwendung.

Wer ist Ihr Kunde genau?

Klage: Unsere Kunden sind unter anderem 428 Sparkassen, neun Landesbanken wie die Landesbank Berlin oder die Norddeutsche Landesbank, die wir gerade erst erfolgreich auf unsere Systeme migriert beziehungsweise unsere Systeme auch in die Systeme der Landesbank integriert haben.


Wie kommunizieren Sie mit Ihren Mitarbeitern, was Architektur für den Erfolg bedeutet?

Klage: Die Architektur selbst, aber auch eine Architekturaffinität bei den Führungskräften und Mitarbeitern ist aus meiner Sicht ein entscheidender Eckpfeiler für den Erfolg unseres Systems OSPlus. Das haben wir jetzt nachhaltig sowohl von der wirtschaftlichen Seite mit den Einsparungen von 124 Millionen Euro in 2010 im Vergleich zu den ursprünglichen Planungen hinterlegt als auch hinsichtlich der Verfügbarkeit und des Mehrwerts für den Kunden gezeigt, die wir letztendlich auf eine IT-Plattform migriert haben. Um zu verstehen, was dabei zu beachten ist, muss man sich vergegenwärtigen, was in den letzten Jahren passiert ist: Mit dem Einsatz der Serviceorientierung, beginnend auf der Anwendungsseite, sind Plattformgrenzen aufgebrochen worden. Damit ist die Bedeutung eines unternehmensweiten Supportservice wie EAM überproportional gestiegen. Dieses Aufbrechen der Plattformgrenzen sieht man aber nicht nur in der Anwendungsarchitektur, sondern auch in der Systemarchitektur. Wo also vor einigen Jahren einzelne Anwendungen und Funktionalitäten bei unseren Kunden bankfachlich funktioniert haben, brauchen diese heute fast alle Plattformen, um ihre Geschäftsprozesse zu unterstützen. Die verschiedenen Plattformen und Prozessortypen, angefangen bei einer Mainframe über powerbasierte Systeme bis hin zu Intel-basierten Systemen, müssen zusammen funktionieren, damit wir diese bankfachliche Prozessunterstützung bei unseren Kunden durchgängig sicher, verfügbar und wirtschaftlich bereitstellen können. Und diese plattformgreifende Integration ist ebenfalls ein Erfolgsfaktor. Denn damit kann man den Kunden bezüglich Geschwindigkeit und Wirtschaftlichkeit mit der Systemarchitektur unterstützen, was wir auch durch eine serviceorientierte Architektur in der Anwendungsentwicklung erreichen wollen. Das heißt, dass die Bedeutung von EAM auch hier überproportional wächst. Ein Schlüssel zum Erfolg ist dann nicht nur die Anwendungsarchitektur, sondern auch eine gut funktionierende Systemarchitektur.

Das bedeutet gleichzeitig, dass wir Führungskräfte benötigen, die die Architektur aus dem Elfenbeinturm oder aus den PowerPoints herunter in das reale Leben holen, also in die operative Umsetzung übersetzen. Das Thema Führung ist für mich allgemein von großer Bedeutung. Denn meine Erfahrung hat gezeigt, dass Bereichsleiter architekturaffin und auch ein wenig Chefarchitekt sein müssen, um zum Beispiel Nachhaltigkeit in die Architektur zu bringen und die IT-Strategie in die operationale Umsetzung zu übersetzen. Dafür haben wir einen bankfachlichen Bebauungsplan, den wir mit unseren Kunden vereinbaren. Darin steckt das „WAS wir machen“. Daraus leiten wir auch ab, WIE und WOMIT wir entwickeln. Das Wie und das Womit sind dabei sozusagen unser Hoheitsgebiet, unser Kernthema, in dem wir die Spezialisten sind. Dafür ist es wichtig, dass die Führungskräfte die Verantwortung tragen und die bereits genannte Ableitung hinbekommen: konkret also vom bankfachlichen Bebauungsplan in Kombination mit der IT-Strategie hin zu wirklich realen Projekten, zu Schnittstellenarchitektur, zu einer Serviceorientierung, zu einer bankfachlichen Geschäftsprozessunterstützung, die modelliert wird statt programmiert.

Zum anderen ist es ebenso wichtig zu beachten, dass Architektur oft sehr querschnittlich gesehen wird. Da zeigt unsere Erfahrung: Nur so viel Querschnitt wie nötig. Das heißt also klare Verantwortungen. Die Verantwortung liegt in der Linie und wird vom Bereichsleiter getragen, und das über verschiedene Hierarchieebenen hinweg. Umgesetzt wird das, was unserem Kunden nutzt. Aus der IT-Strategie wird über die Führungskräfte hin zur operativen Umsetzung beim Mitarbeiter eine Nachhaltigkeit für das Unternehmen erzielt. Das ist ebenso ein Schlüssel zum Erfolg, weil so die Architektur aufblüht und zu leben beginnt.

„Im Fokus steht daher die Wertschöpfung für unsere Kunden und die Wettbewerbsfähigkeit.“

Wie erreichen Sie die Architekturaffinität bei ihren Mitarbeiten und wie erzeugen Sie das Verständnis für das enge Verhältnis von Architektur und Fachanforderung? Das ist ja eine der größten Herausforderungen der Industrie.

Klage: Wir haben uns ganz pragmatisch durch unsere Erfolge weiterentwickelt. Ein wichtiges Thema ist hier, dass Projekte, die Umsetzung der Produkte, die Architektur, Anwendungssysteme und Entwicklungsarchitektur der Linienverantwortung unterliegen beziehungsweise in ihr verankert sein sollten. Das Spannungsfeld zwischen dem Querschnitt und der Linienverantwortung kann man dann dadurch lösen, indem man eindeutig Verantwortung zuteilt. Bei uns gibt es genau eine Person, die zum Beispiel festlegt, wie die Entwicklung vom Web Service im Backend geschieht, und alle anderen halten sich daran. Und es gibt genau eine Person, die beschreibt und festlegt, mit welchem Style Guide und mit welchem Framework Oberflächenkomponenten entwickelt werden. Die Verantwortung ist in der Linie also klar einer Person zugeordnet. Jeder Verantwortungstyp kommt genau einmal vor.
Dabei stellt sich aber auch die Frage, welche Menschen einen Überblick darüber behalten, dass zum Beispiel die Fronend-Themen zu den Backend-Themen passen und die Systemarchitektur zu den Mechaniken der Ausfallmengenreduzierung, um Sicherheit und Verfügbarkeit zu garantieren. Wir haben das folgendermaßen gelöst: Zum einen haben wir ein Architektur-Board, in dem die Ableitung von der bankfachlichen Architektur zur Anwendungsarchitektur verantwortet wird. Zum anderen haben wir ein Steuerungs-Board Systemarchitektur, in dem die Systemarchitektur verankert wird. Beide Boards stehen auf einer Ebene. Dazu gibt es einen kleinen Querschnittsteil, in meinem Team sind das etwa sieben Leute, die quasi eine Klammer um die Facharchitekten bilden, die wiederum in den Linien verankert sind. Diese Leute sind bekannt und in einem Organigramm markiert, sodass man auf Geschäftsbereichsleiterebene sieht, wer Pate oder Architekt des Projekts ist. Dieses Team kommt regelmäßig nach der Geschäftsordnung für diese Boards zusammen, findet Beschlüsse und hat auch direkten Einfluss auf das Projektgeschehen. Wer in einem Projekt nach Standard arbeitet und sich daran hält, kann einfach durchlaufen. Wenn aber ein Thema als architekturrelevant gekennzeichnet wird, also vom Standard abweicht oder diesen Zukünftig fortschreibt, bekommt es einen Paten aus dem Steuerungs-Board zugewiesen, der dann bei der Fortschreibung der Architektur hilft, sodass alle etwas von der Entwicklung haben. Ohne Freigabe durch den Paten geht das Projektergebnis nicht in Produktion. Die Paten gestalten jedoch nur die Kernprojekte mit, werden also nicht überall eingesetzt, damit das Verfahren pragmatisch bleibt.

Sie sagten eingangs, der Business Value muss beim Kunden ankommen. Wie stellen Sie die Wertschöpfung und die Wettbewerbsfähigkeit fest? Was sind für Sie Kriterien, um Architekturentscheidungen zu treffen, Budgets freizugeben und Dinge umzusetzen?

Klage: Management by Excel funktioniert hier natürlich nicht. Das hat viel mit Erfahrung und den Führungskräften zu tun, die wissen, wann es sinnvoll ist, in eine bestimmte Richtung zu gehen. Man kann auch einen Proof of Concept machen, um etwas auszuprobieren. Wenn es zum Beispiel darum geht, Intel-basierte Systeme einzusetzen, um mit Open-Source-Komponenten hochkritische Anwendungen zu produzieren, kann man die Daten verifizieren oder einen Business Case aufstellen und entsprechend planen. Für mich ist es wichtig, dass die Führungskräfte, die dann Entscheidungen treffen, einen entsprechenden Durchblick haben und wirklich entscheiden können, ob etwas tragfähig ist oder nicht.

Letztendlich kommt man über den Weg der Serviceorientierung dahin, dass wir einen hohen Grad der Wiederverwendung erreichen. Dabei achten wir dann besonders darauf, wie groß der Grad der Wiederverwendung ist und ob wir es erreichen können, Geschäftsprozesse schneller zu unterstützen, weil wir die Komponenten wiederverwenden können. Wohlwissend, dass wir Zeit und Geld, die wir einsparen, in die Entwicklung oder Bereitstellung von Systemkomponenten reinvestieren müssen – das ist mit dem Management entsprechend vereinbart. Denn durch den hohen Grad der Wiederverwendung werden IT-Systeme komplexer. Und das ist nicht nur ein Segen, das kann auch ein Fluch sein. Was etwa in der Cloud-Technologie und in der dynamischen Provisionierung an Mehrwerten herausgeholt wird, durch eine höhere Auslastung von Systemkomponenten, durch mehr Flexibilität, durch eine schnellere Bereitstellung, das müssen wir auch zum Teil wieder reinvestieren, weil wir ganz andere Informationen in einer anderen Granularität benötigen, wenn wir von der systemtechnischen Seite aus zum Beispiel einen neuen Releaseeinsatz durchführen wollen. Früher hat der I/O nicht so interessiert, aber wenn man heute genau provisionieren will, die Teile besser aufeinander abstimmen muss, dann ist es wichtig, die Details zu kennen und die freigewordenen Mittel teilweise in neuer Form qualitätsfördernd ins System zu bringen.

Geschrieben von
Mirko Schrempp
Kommentare

Schreibe einen Kommentar

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