SOA wurde zu früh ein Hype - mit fatalen Folgen

KAGERMANN: Eigentlich haben wir diese Herausforderung schon vor zehn Jahren aufgegriffen. Damals haben wir mit der Hochschule St. Gallen das Thema Business-Networking lanciert. Aber wir waren zu früh dran. Außerdem war SAP R/3 nicht die richtige Plattform dafür. Jetzt wissen wir, dass wir dafür andere Mechanismen benötigen. Immerhin war dies der Anstoß dafür, dass wir über den Manufacturing-Bereich hinaus in andere Branchen gegangen sind. Wir haben intern erbittert darüber diskutiert. Und mein Hauptargument war, dass sich Geschäftsmodelle verändern können. Die Unternehmen wollen plötzlich vielleicht Teilprozesse aus einer artfremden Branche verwenden. Zudem gibt es in den unterschiedlichen Branchen eine Menge gleicher Bestandteile. Wir hatten anfangs 15 getrennte SAP-R/3-Brachenlösungen. Um wieder eine übergreifende Lösung zu bekommen, mussten wir diese 15 Lösungen in einem ziemlichen Kraftakt zusammenbringen. Das gelang uns mit Hilfe von SOA. Allerdings muss diese Struktur jetzt auch mit ausreichend Services bestückt werden, damit das kein Schweizer Käse wird, sondern die Kunden irgendwann auch in einem heterogenen Umfeld nahtlose Verbindungen knüpfen können. Selbstverständlich stehen wir hier erst am Anfang, aber die Kunden nehmen uns diese Vision zumindest schon einmal ab - auch wenn bei den Referenzen immer noch der eine oder andere Service fehlt. Ich sehe für uns einen Vorteil darin, auf beiden Feldern zu spielen: zum einen eine Architektur anzubieten und zum anderen die Services zu erstellen. Wir sind nämlich noch nicht so weit, dass wir wirklich entkoppelte Services verbinden können. Aber - ohne jetzt falsche Versprechungen machen zu wollen - in einigen Jahren werden Kunden wie die Münchener Rück Many-to-many-Beziehungen zu anderen Unternehmen aufbauen können, deren Teilnehmer sich quasi im Flug wechseln oder ergänzen lassen.

JANSSEN: Ich sage bei unseren Outtasking-Beziehungen auch immer: Momentan sind die Scheidungskosten einfach zu hoch.

KAGERMANN: Ja, Scheidung und Hochzeit müssen einfacher und billiger werden.

JANSSEN(lacht): Gut, es darf schon etwas kosten, aber es müssen ja nicht gerade alle Verwandten zu Besuch kommen … (wieder ernst) … Was die unternehmensübergreifenden Ketten angeht, so erwarte ich, dass wir die Fähigkeit dazu in den kommenden fünf Jahren entwickeln werden. Aber wissen Sie, und da sind wir wieder beim Thema Marketing-Kommunikation, SOA ist auch so ein Fall, wo eine Idee zu früh gehypt wurde, nämlich schon, als sie noch nicht mehr als eine Marketechture war. Und heute ist das Thema beinahe schon veraltet. Die Anbieter sollten sich fragen: Wie früh dürfen wir eine Idee kommunizieren, wenn wir sichergehen wollen, dass es keine Totgeburt wird?

KAGERMANN: Sie können solche Ideen leider nicht im Labor einsperren. Wir haben SOA nicht erfunden, sondern das ist ein Trend, wie beispielsweise Client-Server einer war. Und wer hier zu spät kommt, den bestraft das Leben. Ein Thema, das wir selbst in der Hand hatten, ist SAP Business ByDesign. Da mussten wir uns tatsächlich fragen, wann wir damit an den Markt herantreten sollten. Ich denke, man muss in den Markt gehen, wenn man ihn braucht. Irgendwann müssen die Entwickler aus dem Labor herauskommen und sich die Hände beim Kunden schmutzig machen. Die eigentlichen Probleme entdecken sie nur blutig vor Ort. Wenn die Produktentwicklung abgeschlossen ist, muss man herausfinden, ob das Konzept bei der Kundschaft ankommt und wo die Software noch löchrig ist. In diesem Prozess ändern sich mitunter die Prioritäten. Im Labor hätten wir niemals herausgefunden, dass beim Betrieb über das Netz die Performance nachlässt oder dass die Leute nicht offenbaren wollen, welche Software sie auf ihren Laptops haben, oder wie viele unterschiedliche Drucker es im Mittelstand gibt. In dieses schmutzige tägliche Leben müssen wir die Research-Abteilung irgendwann hineinjagen. Deshalb können wir neue Konzepte nicht so lange einschließen, bis sie fix und fertig sind.

JANSSEN: Die Formulierung blutig beim Kunden schmeckt mir überhaupt nicht.

KAGERMANN (lacht): Es sind unsere Leute, die bluten, nicht die der Kunden.

Niemand kennt die Pflichten von Softwarearchitekten

JANSSEN: Da bin ich aber beruhigt. Außerdem sind wir gern bereit, uns ab und zu als Partner für einen Forschungsprototypen zur Verfügung zu stellen. Doch Software-Engineering ist schon eine seltsame Disziplin. Obwohl der Begriff schon vor gut 40 Jahren geprägt wurde, gibt es in unserer Profession bis heute kein echtes Bemühen um Qualitätssicherung. In der Lebensversicherung darf beispielsweise kein Produkt verkauft werden, für das es keinen zertifizierten Aktuar gibt. Dieser Aktuar prüft alle rechtlichen und wirtschaftlichen Bedingungen des Produkts und berichtet direkt an den Vorstand. Im Software-Engineering - ob bei der SAP, bei einem Dienstleister oder bei uns - gibt es viele Architekten, aber niemand weiß, welche Rechte und Pflichten sie haben. Ein Statiker darf sagen: So wird das nicht gebaut! In unserer Branche erkenne ich nicht einmal die Bereitschaft, sich ernsthaft mit diesen Gedanken auseinanderzusetzen. (Zum Thema siehe auch: "Software-Blutbild zur Qualitätssteuerung".)

KAGERMANN: Jetzt muss ich aber doch mal zur Ehrenrettung unseres Berufsstandes schreiten. Ich sehe immer wieder, dass ein großer Softwarehersteller ungleich mehr Aufwand treiben muss als ein kleiner. Das liegt vor allem an den Produktstandards. Wir haben etwa zwei Dutzend solcher Standards, die eingehalten werden müssen. Das macht uns schon das Leben schwer - auch unter betriebswirtschaftlichen Gesichtpunkten. Aber in einem haben Sie Recht: Wir haben eigentlich alle für die Qualitätssicherung notwendigen Prozesse definiert und etabliert, aber am Ende ist das immer eine Frage der Menschen. Wenn man diese Prozesse nicht top-down vorlebt und laufend hinterher ist, fangen die Künstler wieder an, sich selbst zu verwirklichen.