IT-Mitarbeiter verabschieden sich nur ungern von einer funktionalen auf eine Software-Produkt bezogenen Denkweise. Kommt eine neue Anforderung von einer Fachabteilung, müssen sie sich nun Gedanken darüber machen, ob eine vorhandene Software diese Aufgabe nicht schon abdeckt. "Wir prüfen auch, wie wir neue Prozesse abbilden, ohne dass wir die vorhandene Software erweitern oder verbiegen", berichtet Vice President IT Dirk Klöckner vom Heiztechnikhersteller Viessmann. Diese für Service-orientierte Architekturen (SOA) notwendige Arbeitsweise gestaltet sich in der Praxis allerdings nicht so einfach. "Da tun sich Kulturgräben auf", sagt Klöckner. "Für die IT bedeutet diese neue Denkweise eine große Umstellung."
Um den Kulturwechsel hinzubekommen, müssen IT-Mitarbeiter viel miteinander reden. Doch SOA verlangt zudem intensive Kommunikation zwischen IT und Fachabteilungen. Denn der Erfolg von SOA hängt entscheidend davon ab, wie beide miteinander sprechen und zusammenarbeiten.
Nur Business-Potenziale überzeugen
Für eine SOA-Strategie müssen nach Ansicht von Martin Eldracher, Mitglied der Geschäftsleitung und Leiter IT-Beratung beim Münchener Software- und Beratungsunternehmen sd&m, zunächst die Potenziale einer SOA für das Unternehmen erkannt werden. Nur so steigt die Attraktivität des Konzepts für das Unternehmen. Potenziale finden sich zuerst auf der Fachseite, etwa kürzere Time-to-Market. Allein mit Effekten in der IT lassen sich SOA-Projekte nicht rechtfertigen.
Dann ist eine Governance-Struktur zu schaffen, an deren Spitze der CIO mit wesentlichen Fachbereichsleitern steht. Dieses Gremium versorgt wiederum Architekten, Serviceverantwortliche aus den Fachbereichen und Domänenverantwortliche mit Informationen über Ressourcen, Aufwand und Struktur von Projekten. Das oberste Gremium legt nicht nur Projektstarts fest, sondern behält auch den Gesamtzusammenhang im Blick und kontrolliert die Anwendung und Wiederverwendbarkeit der Services. "Zuvor müssen Unternehmen zwingend die Basisfrage klären, wie zentral oder dezentral die IT-Organisation laufen soll", sagt Eldracher.
Letztlich muss das Management die Vision vorgeben, einzelne Rollen festlegen und Druck auf eine stringente Verfolgung der SOA-Ziele machen. "Unternehmen sollten die Rolle des CIOs zu einem Chief Process Officer oder einem Chief Innovation Officer für SOA weiterentwicklen", rät Eldracher. Denn nur sie hätten einen Überblick über Geschäftsprozesse im Unternehmen sowie Services in der IT.
Klöckner von Viessmann hat dafür die Position des Requirement-Managers geschaffen. "Die Aufgaben eines Requirement-Managers sind vergleichbar mit denen eines Chief Process Officers", erläutert er. "Zurzeit haben wir vier, bis Ende des Jahres sollen es acht sein." Doch keiner von ihnen kann einen Gesamtüberblick in der erforderlichen Tiefe haben. "Die Aufgaben sind zu komplex, deswegen sind unsere Requirement-Manager auf Fachbereichsprozesse wie Vertrieb oder Fertigung spezialisiert", erklärt Klöckner.
Ihre Aufgabe liegt darin, Anforderungen vom Fachbereich aufzunehmen, sie in einem für alle verständlichen Fachkonzept festzuhalten und daraus einen Plan für die IT-Entwicklungsteams abzuleiten. "Requirement Manager haben eine hohe Verantwortung, weil sie abschätzen müssen, wie sich die Änderungen auf die Abläufe im Fachbereich auswirken", sagt Klöckner.
Um den Umsetzungsaufwand besser abzuschätzen, greift der Requirement-Manager auf ein Service-Repository zu. "Außerdem muss er ein Gefühl dafür haben, welche Anforderungen des Fachbereichs sich mit welchem Aufwand umsetzen lassen. Damit soll er frühzeitig eine Vorstellung von der Wirtschaftlichkeit der Lösung bekommen", sagt Klöckner. Oft sei es sinnvoll, mit einer 80-Prozent-Lösung zu starten, dabei Erfahrungen zu sammeln und in iterativen Schritten weiterzugehen.
Requirement-Manager statt Hey-Joe
Mit der Einführung der Requirement-Manager organisierte Klöckner zugleich die IT-Abteilung neu. Mit den alten funktionalen Zuschnitten und dem Hey-Joe-Prinzip ließen sich SOA-Prinzipien nicht umsetzen. Denn SOA braucht abteilungs- und fachbereichsübergreifendes Denken, was die alte Organisation behinderte. Während sich Fachbereiche früher bei Fragen direkt an das spezialisierte Team wendeten, sprechen sie nun mit den Requirement-Managern.
Die bisherige Arbeitsweise besaß noch einen weiteren Nachteil. So sprach beispielsweise die Logistikabteilung eine andere Sprache als die für MySAP Logistics zuständigen IT-Mitarbeiter. "Sie benutzten die gleichen Vokabeln, meinten aber unterschiedliche Dinge", beschreibt Klöckner. Derartige Reibungsverluste sollen nun künftig die Requirement-Manager als Übersetzer zwischen IT und Fachbereichen minimieren.
Ganz ohne Missverständnisse wird es allerdings nie ablaufen, ist sich Head of IT Architecture Stephan Murer von Crédit Suisse sicher. Die Züricher Bank arbeitet schon seit mehr als neun Jahren nach SOA-Pinzipien. Die Kommunikationsprobleme sind bis heute geblieben. "Die gemeinsame Sprache ist eine große Herausforderung und der schwierigste Teil bei SOA. Das bleibt eine ewige Arbeit", sagt Murer.
Um das Verständnis ständig zu verbessern, arbeitet die Bank mit Glossaren. Damit sollen alle Beteiligten unter Begriffen wie "Kunde und Konto“ dasselbe verstehen. Glossare allein reichen aber nicht, sodass die Schweizer zusätzlich mit „Business Analysten“ als Übersetzer zwischen IT und Fachbereichen arbeiten. Allerdings ist „Business Analyst“ keine feste Position, sondern eine Rolle, die Mitarbeiter einnehmen. Auf rund fünf bis zehn Prozent schätzt er den Anteil der rund 9000 IT-Mitarbeiter, die gelegentlich in die Rolle eines Business-Analysten schlüpfen.
Als Business-Analyst nehmen die Mitarbeiter die Wünsche der Fachbereiche auf und diskutieren mit ihnen. Dabei machen sie Vorschläge in Form von Prototypen. „Sie dürfen vom Fachbereich nicht einfach fertige Anforderungen in umsetzbarer Form verlangen. Das überfordert den Fachbereich total“, sagt Murer.
Auch die Frankfurter Direktbank ING Diba arbeitet mit Business-Analysten. Nur dass hier die neu geschaffenen Positionen Vollzeitstellen sind: Sie begleiten Projekte vom Plan bis zu Tests und Abnahme. "Business- Analysten sitzen zwar in der Entwicklungsabteilung, sind aber vom Typ her keine Entwickler", erläutert CTO Martin Rauch. Mit den Fachbereichen diskutieren sie auf der Ebene von Fachlichkeiten, nicht aber über die technische Umsetzung in der IT. "Sie verfügen über ein tiefes Wissen darüber, wie eine Bank funktioniert."
Leute mit Übersetzerqualitäten sind allerdings nicht leicht zu finden, auf dem freien Markt sind sie fast nicht zu bekommen. "Deswegen sind wir parallel dazu übergegangen, eigene Mitarbeiter zu Business-Analysten weiterzuentwickeln. Man erkennt mit der Zeit, welche Mitarbeiter das Potenzial dazu mitbringen", sagt Rauch. Zurzeit gibt es sechs bis acht Business-Analysten, wobei die Bank teilweise auch externe Berater holt, um Spitzen abzufangen. "Wir werden in Zukunft noch mehr in Business-Analysten investieren und die Zahl weiter erhöhen", berichtet der CTO. "Dann können wir mehr Projekte parallel durchführen. Denn ein Business-Analyst ist mit einem Projekt fast komplett ausgefüllt."
Weiterhin entsteht künftig auch Bedarf an Facharchitekten. "Facharchitekten besitzen sehr tiefe Kenntnisse über bereits vorhandene Services und Möglichkeiten der IT und können dieses Wissen zur Wiederverwendung der fachlichen Services in neuen Geschäftsprozessen nutzen", sagt Rauch. "Wir prüfen zurzeit die Erweiterung unseres Teams durch hauptamtliche Facharchitekten."
Für einen wesentlichen Erfolgsfaktor zur besseren Kommunikation hält Eldracher von sd&m das Domänenmodell. Er empfiehlt, immer zwei Verantwortliche pro Domäne zu benennen: einen "Eigentümer" aus der IT und einen "Auftraggeber" aus dem Fachbereich. Dabei verantwortet die IT die Prozesse, der Fachbereich die Anforderungen. "Der Fachbereich muss sich aber rausziehen, wenn es um die Umsetzung auf der IT-Seite geht", sagt Eldracher.
Domänenmodell hilft wenig
Kommunikation stand bei ING Diba allerdings nicht im Hauptfokus des Domänenmodells. In erster Linie setzt es die Direktbank für die parallele und unabhängige Entwicklung von Projekten ein. „Der Hintergrund des Domänenmodells ist weniger die effizientere Kommunikation mit dem Fachbereich als vielmehr, fachliche Services parallel weiterzuentwickeln“, sagt Rauch. Jede technische Änderung an einer Domäne muss zwar erst durch einen Fachbereich und einen Architekten genehmigt werden. Aber das ist mehr ein Thema der Governance und der Verantwortlichkeit, weniger der Kommunikation.
Um die Kommunikation zu stärken, setzt ING Diba dagegen auf das Iterationsmodell. Damit wird ab Projektstart der Austausch bei jedem Release-Schritt in ständigen Feedback-Schleifen mit den Fachbereichen gewährleistet. Dazu hat sie gleichzeitig Standards entwickelt, wie Fachlichkeiten beschrieben werden müssen und wie ein IT-Konzept auszusehen hat. Nach drei Jahren SOA-Erfahrung haben sich so mittlerweile Vorgehensweisen entwickelt, damit Fachbereich und IT ihre Konzepte gegenseitig verstehen. Einen Blueprint gab es anfangs nicht. "Wir sind mit zwei Projekten gestartet und haben die Best Practices nach jedem Release immer weiter ausgebaut und verfeinert", erläutert CTO Rauch. Dabei sei wichtig, dass die IT die Fachlichkeit verstehe. Wenn das gelingt, dann vermeide man auch viel Ärger.
Durch die Wiederverwendbarkeit von Services bei SOA kommt dem gegenseitigem Verständnis und der gemeinsamen Sichtweise eine noch größere Bedeutung zu. Wenn ein Service auf Wunsch einer Fachabteilung geändert wird, kann das auch andere Abteilungen treffen. Denn sie verwenden möglicherweise denselben Service, sind mit ihm zufrieden und wollen ihn nicht ändern. Trotzdem müssen sie die Folgen der Änderungen mittragen. "Erfolge bei Projekten sind die beste Motivation", hofft Klöckner von Viessmann. Doch Ärger wird sich vermutlich nie ganz vermeiden lassen.