In 2009 waren deutlich weniger Teilnehmer als in den vorhergehenden Jahren auf der OOW „spürbar“. Durch die Akquisition von SUN und die jetzt parallel abgehaltene Java One Konferenz wurde zumindest dieser Trend (gefühlt) gestoppt.

Oracle Open World 2010

Aber was gibt es wirklich Neues?

Die kurze Antwort vorweg: „bis jetzt eigentlich nichts“.

Ann Livermore hielt eine sehr schwache (fast lustlose) Key Note zusammen mit Dave Donatelli. HP adressiert nun die Transformation und Optimierung von IT. Tolle Nachricht – endlich macht das mal jemand…

Während ich der Key Note zuhörte kam mir immer wieder die Frage in den Sinn: Was HP macht HP eigentlich? Ich kann keine klare Strategie dieses Unternehmens erkennen, bis auf einen Gedanken der sich während der Präsentation irgendwo in meinem Gehirn entwickelte: Wird HP die zweite CA? Ein ziemlicher Gemischtwarenladen bei dem nur rudimentär erkennbar ist wie die Puzzelteile zusammenpassen könnten.

Nach HP war Larry Ellison an der Reihe. Irgendwie war das gestern keine Sternstunde des Oracle Gründers. Er wirkte müde und gehetzt bei dem Vergleich der Cloud Ansätze von Amazon und Sales Force. Wirkliche Neuigkeiten gab es keine. Es gibt die Exalogic Maschine, man greift Red Hat „ein wenig“ an indem man einen eigenen Linux Kernel entwickelt und das neue Fusion Apps kommt Anfang des nächsten Jahres.

Interessant war die Aussage von Larry Ellison, dass für ihn „Business Intelligence“  das Zentrum zukünftiger Business Applikationen sein wird. Er bewertetet (BPM) Prozesse deutlich als „commodity“ die man einfach beherrschen müsse und die deshalb gegenüber Systemen die ihren Nutzern aktiv die benötigten Informationen auf Basis von BI Analysen bereitstellen in den Hintergrund treten. Zufällig ist die neue Fusion Apps genau nach dieser Lesart entwickelt…

Hoffentlich überfordern sie sich und die Anwender damit nicht. Denn wenn man seine Prozesse nicht beherrsch hilft auch eine darauf aufbauende Analyseintelligenz nur bedingt. Mal sehen was wir als Nutzer daraus machen. Ich bin nur beschränkt zuversichtlich…

In diesem Sinne, gute Nacht Deutschland

Gestern hatte ich erwähnt, dass die IDS Scheer AG das Meta Modell von ARIS öffnen und ein Open Repository anbieten möchte. Konkret handelt es sich bei Ersterem nach Aussage von Britta Hild (Senior Manager ARIS Product Management) um „die freie Erweiterbarkeit um selbstdefinierte Diagramm-, Objekt- und Beziehungstypen“.

Dies wird die Flexibilität auf der Anwenderseite (wünschenswert) erhöhen. Gleichzeitig ergeben sich dadurch aber neue Anforderungen an das Meta-Modell-Management und damit an die verantwortlichen Administratoren. Ich hoffe die Betroffenen sind sich bewusst, was da auf sie zukommt.

Das angesprochene „Open Repository“ zielt zunächst auf verbesserte Reporting Funktionalitäten ab. Den Anwendern soll die Möglichkeit gegeben werden eigene Auswertungswerkzeuge mit den Daten aus einem ARIS Repository zu versorgen. Wie genau die technische Umsetzung aussehen wird konnte oder wollte man noch nicht verraten. Es wäre möglich, dass eine API für die ARIS Suite zurückkommt. Lassen wir uns einmal überraschen. Beides wird erst mit dem Release 8 von ARIS verfügbar sein.

Abschließend noch ein Lob zu einer sehr guten Präsentation die ich heute gesehen habe (für mich die Beste der Veranstaltung – ich motze nicht nur…). Erik Brabänder (Senior Manager ARIS Product Marketing… so steht es auf der Web Site aber der Titel ist glaube ich nicht mehr ganz aktuell) stellte detaillierter die zukünftigen Funktionen der Verbindung zwischen ARIS, CentraSite und WebMethods vor. Dabei setzt die IDS Scheer AG auf ein Konzept mit zwischengeschaltetem „Logischen Business Modell“ zwischen der Fach- und IT Modellierung. Dieser Ansatz geht grundsätzlich in die auch von mir bevorzugte Richtung, da eine direkte Überführung fachlicher Modelle in ausführbare Modelle methodisch nicht möglich ist. Ich bin mir aber nicht sicher, ob der hier gewählte Ansatz mit einem weiteren Layer wirklich praktikabel ist. Insbesondere die hohe Modellierungskomplexität und die dadurch entstehenden Anforderungen an den Modell-Lebenszyklus werfen bei mir noch einige Fragen auf. In der Theorie mag die vorgestellte Lösung funktionieren in der Praxis habe ich Zweifel.

Abschließend ein Satz zu der von mir gestern erwähnten „Marketinglastigkeit“ der Präsentationen. Angesprochen auf meinen Beitrag erklärte mir jemand, dass dies auf den stärkeren US amerikanischen Einfluss in der externen Darstellung der Software AG zurückzuführen sein könnte.

Ob das stimmt? Ich bin mir nicht sicher, eine Erklärung wäre es.

Ist das gut? Ich glaube nicht.

Wir sollten doch in der guten kontinentaleuropäischen Tradition fortfahren. Nicht zuviel Wind und Lärm machen sondern Lösungen liefern die funktionieren. Finde ich persönlich sympathischer und vertrauenserweckender.

Grüße aus Berlin

Dirk Stähler

Seit heute Vormittag findet in Berlin die IDS Scheer AG / Software AG Process World 2010 mit Vorträgen der bekannten IDS Scheer Größen statt.

Bevor ich auf die aus meiner Sicht interessanten Inhalte eingehe, die bis jetzt auf der Veranstaltung bekannt gegeben wurden möchte ich kurz etwas zum Gesamteindruck sagen (auch wenn das vielleicht als Fazit unten stehen sollte). Wer also danach nicht weiterlesen möchte…

Die IDS Scheer Process World wird von Jahr zu Jahr kleiner. Waren im vergangenen Jahr noch die großen Hersteller (IBM, Microsoft, Oracle und SAP) alle als Sponsoren vertreten, so findet man in diesem Jahr nur noch SAP. Und auch diese nur als „kleiner“ Platin und nicht als Diamond Sponsor (vielleicht war deshalb der SAP Stand in der meisten Zeit in der ich an ihm vorbei ging unbesetzt…). Es scheint, als würde die stärkere Einbindung der IDS Scheer AG in die Software AG erste Opfer kosten.

Auch auf der Teilnehmerseite muss ich sagen, dass gefühlt deutlich weniger anwesend sind als letztes Jahr. Diese Aussage beruht zwar auf einer subjektiven Einschätzung, aber abgehängte Bereiche im großen Raum der Keynote um diesem „die Größe“ zu nehmen sprechen für sich.

Soweit also recht bescheiden (was aber ja nicht zwangsläufig ein Nachteil sein muss… aber bisher leider war).

Gab es denn wenigstens spannende Inhalte?

Als erstes die personelle Nachricht aus der Einleitung von Peter Gerard. Er wird im Sommer sein Mandat als CEO bei der IDS Scheer AG niederlegen. Das als Eröffnung vor der Keynote macht Mut. Aber es sollte die Anleger beruhigen. Im letzten Frühjahr sagte er noch „ich bleibe bis die Marge wieder zweistellig ist“. Das wird sie dann ja wohl sein… (http://www.computerwoche.de/software/soa-bpm/1891491/)

Die fachliche  Nachricht über allem ist, dass mit der Verbindung zwischen der IDS Scheer AG und der Software AG endlich die Verbindung zwischen fachlichem BPM und der IT Ausführung geschlossen werden wird (Konjunktiv). Na da bin ich aber platt!

Wolfram Jost stellte in der Key Note den neuen Business Process Excellence Life-Cycle vor, der auf der Abstimmung der Produkte beider Unternehmen beruht. Dieser setzt sich zusammen aus:

• Strategize
• Design
• Implement
• Compose
• Execute
• Monitor

Als Schnittstellen zwischen beiden Unternehmen wurden die Domänen Implement und Monitor gesehen. Dort arbeitet man an der Integration der Produkte. Ziel ist es, eine Übergabe der Modellinhalte zwischen Fachbereichen und IT zu erzielen. An dieser Stelle hatte ich ein Deja-vu. Diese Absicht höre ich jetzt von diversen Herstellern schon seit Jahren. Besonders amüsiert war ich, weil in der Präsentation von Georg Simon fast genau die Folien auftauchten, welche von der IDS Scheer AG schon im Jahr 2004 verwendet wurden. Ein kurzer Blick auf den Kalender hat mich dann aber wieder beruhigt was meine Präsenz in der Gegenwart betraf und beunruhigt was den Fortschritt der Werkzeughersteller auf diesem Gebiet angeht. Nichts Neues und keine wirklich Innovation. Sie haben es immer noch nicht begriffen, dass bis auf weiteres diese Integration nicht an Werkzeugen sondern an grundsätzlichen methodischen Fragestellungen scheitert die bisher niemand ernsthaft angeht. Auch wenn die Hersteller behaupten sie würden eine Methodik anbieten. Dies sind Bedienungsanleitungen. Genau das ist es aber nicht was wirklich fehlt. Mein Fazit an dieser Stelle ist, dass die IDS Scheer AG / Software AG gegenüber anderen großen Herstellern hinten liegt. Aus diesem Grund beeilte sich Wolfram Jost auch in seiner Präsentation die bestehenden Partnerschaften mit SAP, IBM, Oracle und Microsoft als besonders wichtig zu betonen.

Also inhaltliches Fazit: wenig Neues und an der Integrationsfront beider Hersteller viel Marketing

Eine spannende Information gab es aber dann doch, obwohl ich den Eindruck habe das eben diese im Marketingrauschen unter gegangen ist. Die IDS Scheer plant im nächsten Jahr das Meta-Modell von ARIS freizugeben. Das wird erheblichen Einfluss auf die Flexibilität haben mit der ARIS eingesetzt werden kann. Was dass allerdings für die Unternehmen (und letzten Endes dann auch für den Hersteller IDS Scheer) bedeutet stellen sich sicher viele noch nicht vor. Die Möglichkeit „frei“ am Metamodell „drehen“ zu können weckt bekanntlich Begehrlichkeiten bei den Benutzern. Als Beispiel möchte ich hier nur auf die Probleme verweisen die Hersteller von Modellierungswerkzeugen mit offenem Meta-Modell bereits heute haben. Die Reihe reicht da von IBM, über Casewise bis zu MID. Ich bin gespannt was dort kommt und wie die ARIS Gemeinde damit fertig wird.

Eine weitere interessante Neuigkeit ist der Ansatz des „Open Repositories“. Soweit wie ich verstanden habe, ist damit der freie Zugang zu den Inhalten im ARIS Repository für Analysezwecke auf Basis von Werkzeugen anderer Hersteller gemeint. Kommt damit endlich die ersehnte JAVA API? Mal sehen, vielleicht kann ich das noch herausfinden. Ich halte Sie auf dem Laufenden.

Grüße aus Berlin

PS: ich habe auch noch einen Bericht über die Gartner EA Konferenz in London vom Mai 2010. Diesen habe ich aber mit Rücksicht auf Gartner noch nicht veröffentlicht. Man kann ja nicht immer auf den armen Kollegen herum… nein…

Aber ich schreibe ihn noch, versprochen!

http://www.pressebox.de/pressemeldungen/gartner-uk-ltd/boxid/315655

Nachdem Anfang März die Pressemitteilung zu der Londoner Konferenz verfügbar war musste ich das Gesagte erst einmal etwas sacken lassen. Aber jetzt ist die Zeit bei mir reif. …glaube ich jedenfalls.

Folgen Sie mir auf eine kleine Zeitreise gemeinsam mit den Propheten von Gartner:

„By 2012, 20 per cent of customerfacing processes will be knowledgeadaptable and assembled just in time to meet the demands and preferences of each customer, assisted by BPM technologies. Today’s capability to proactively change processes is merely an interim step for process improvement. The next evolution will be processes that selfadjust based on the sensing of patterns in user preferences, consumer demand, predictive capabilities, trending, competitive analysis and social connections.“

Diese Aussage klingt zunächst einmal nicht so spektakulär. 20% der direkten Kundenprozesse werden 2012 automatisiert sein. Dem kann man erst mal zustimmen, auch wenn dabei natürlich sofort die Fragen aufkommen warum die Restlichen 80% nicht automatisiert sind und weshalb nicht? Bemerkenswerter ist aber der Zusatz „zusammengestellt zur Laufzeit“. Was bitte soll denn das? Basierend auf den Wünschen von Kunden sollen sich Automaten an individuellen, bisher nicht bekannten Bedürfnissen ausrichten und flexibel reagieren?

Vor 2 Wochen war ich gemeinsam mit zwei Kollegen auf einen Flug von Frankfurt nach Berlin gebucht. Da wir alle bereits separat und getrennt voneinander online eingecheckt hatten, saßen wir natürlich zunächst nicht zusammen in der Maschine. Der Versuch dies zu ändern war am Automaten unmöglich, am Schalter mit „Human Interaction“ durch das (wirklich bemühte) Personal der Fluggesellschaft leider auch nicht. Erst im Flieger ging das unter Einsatz einer netten Frage an die betroffenen Mitreisenden und Nutzung des Moduls Empathie und Freundlichkeit.

Unser „Customer demand“ war „wir möchten gerne zusammen sitzen“. Ergebnis: das Check In BPM der Fluggesellschaft konnte es nicht lösen. Glauben Sie, das dass 2012 geht? Aber schauen wir mal weiter, vielleicht war das nur zufällig ein Prozess aus den 80%.

„By 2013, dynamic BPM will be an imperative for companies seeking process efficiencies in increasingly chaotic environments. … Adopting a more dynamic form of BPM, which focuses on enabling process changes to occur when and as needed will enable organisations to better respond to unanticipated change requirements in business processes, and to handle process changes more effectively.“

Das wird ja immer besser. BPM wird uns also helfen in chaotischen Umgebungen auf extern indizierte, vorher nicht bekannte,  Ansprüche zu reagieren. Lassen Sie uns kurz die Definition von Chaos aus dem New Oxford American Dictionary betrachten:

Physics behavior so unpredictable as to appear random, owing to great sensitivity to small changes in conditions.

Liebe Kollegen von Gartner, das Verhalten und die Ergebnisse innerhalb eines chaotischen Systems sind nicht zu 100% vorhersagbar. Bestenfalls statistisch beschreibbar. In Zukunft werden dann Automaten mit Hilfe von Algorithmen planvoll und vorherbestimmt genau darauf reagieren? Natürlich nur wenn bis dahin die künstliche Intelligenz einen durchschlagenden Erfolg erzielt hat, wonach es im Moment aber nicht aussieht. Auf besagtem Flug nach Berlin hatte ich eine interessante Diskussion mit Clemens Utschig-Utschig (Sr. Principal Product Manager im SOA Suite Product Management Team der Oracle Corporation in Redwood Shores verantwortlich für die interne Architektur der SOA/BPM- Plattform). Er sagte, eigentlich benötige er gar keine Prozessmodelle mehr. Schon gar keine graphisch dargestellten Diagramme. Ihm genüge ein Algorithmus den er über die Informationen legt um sich zu jeder Zeit ergebende Schlussfolgerungen aus der Verknüpfung zugrundeliegender Informationen zu errechnen. Ich kenne Clemens nun schon eine Weile und glaube ihm das sogar. Er wird das hin bekommen. Aber wir anderen in der breiten Masse? Glauben wir wirklich, dass wir mit dieser chaotischen Komplexität arbeiten wollen (und können)?

„Through 2014, the act of composition will be a stronger opportunity to deliver value from software than the act of development. … Gartner recommends enduser organisations recognise that the movement from applications to compositions will require a shift in how they think about projects, organisations, and collaboration across business and technical roles to achieve business goals. Traditional development approaches don’t fit well with new service oriented architecture (SOA) and BPM compositions.“

Das stimmt. Ich würde sogar noch einen Schritt weiter gehen. Nicht nur die klassischen Formen der Software Entwicklung, sondern die Organisation eines Unternehmen (oder darüber hinausgehender Beziehungen) passen heute in den meisten Unternehmen nicht in den SOA Ansatz.

Und damit sind wir bei dem Kern der Sache. Es gibt heute eine Grenze für BPM und SOA Projekte. Diese wird im Wesentlichen bestimmt durch die folgenden Faktoren:

• Intellektuelle Fähigkeiten
• Gesellschaftliches Umfeld
• Sicherheitsanforderungen

Die intellektuellen Fähigkeiten

Sind wir zu dumm für BPM? Nein, sicher nicht. Aber jeder von uns hat seine Grenzen (auch ich schließe mich da nicht aus). Je umfassender wir BPM denken, sei es in der Breite über Unternehmensgrenzen hinweg oder in der Tiefe bis in sehr detaillierte komplexe individuelle Abläufe, desto schwieriger wird es einen Prozess wirklich zu verstehen. Ich schreibe diesen Beitrag gerade in einer Höhe von 32.000 Fuß mit einer Geschwindigkeit von rund 900 km/h irgendwo über Grönland. Ich weis, diese 747 fliegt und ich bin mit den wesentlichen physikalischen Grundlagen vertraut. Dennoch könnte ich sicher nicht nach vorne gehen und sagen: „Ab jetzt mache ich hier weiter“. Das würde meine Fähigkeiten bei weitem übersteigen. Es gibt aber einen Autopiloten. Die Software hat im Fall der 747-400 mehr als 5 Millionen Zeilen Code. Diese Software ist in der Lage in begrenztem Umfang auf externe Einflüsse zu reagieren. Jetzt überlegen Sie einmal, wir würden eine ähnliche Intelligenz für diverse andere chaotische ad hoc Prozesse nachbauen. Auf jeden Fall wirtschaftlich ein Desaster. Von den nicht monetären Auswirkungen ganz zu schweigen. Und bis 2014 schaffen wir das mit Maschinen? Liebe Kollegen von Gartner, geht es auch eine Nummer kleiner?

Das gesellschaftliche Umfeld

In unserer Wirtschaft versuchen wir gerade Prozesse über Unternehmensgrenzen hinweg zu verbinden, zu optimieren und in vielen Fällen gänzlich neu zu gestalten. Ist den Protagonisten dabei vielleicht schon mal in den Sinn gekommen, dass bei diesem Prozess der größte Widerstand von den Menschen selber kommt? Die Optimierung in einem Unternehmen alleine kann bei den Betroffenen schon erhebliche Ressentiments auslösen. Wenn aber ganze Beziehungszusammenhänge, Arbeitsmuster und Denkweisen in dem eigenen Unternehmen vorhergehenden und nachfolgenden Einheiten verändert werden löst das Widerstände aus die mit keiner ad hoc selbstorganisierenden Technologie der Welt beseitigt werden können.

Die Sicherheitsanforderungen

Sandro Gaycken, Technikphilosoph und Sicherheitsforscher, schreibt in der ZEIT vom 18. März 2010: „Unternehmen und Behörden müssen sich entscheiden. Entweder sie speichern ihre Daten auf vernetzten Computern, organisieren Prozesse über das Firmennetzwerk und das Internet hinweg – diese Lösung erlaubt Geschwindigkeit, Zentralisierung, bessere Verwaltung und weniger Personal. Dann gilt aber für alle Prozesse: Sie sind anfällig. … Wer das nicht will muss konsequent entnetzen.“

Dieser Aussage schließe ich mich voll und ganz an. Ich glaube, wir werden nach dem Hype den Analysten verbreiten eine Phase der Rückbesinnung erleben, in dem wir einige der automatisierten Prozesse wieder manualisieren. Alleine um der Sicherheit willen.

Ich muss es immer wieder betonen, ich bin nicht gegen BPM und SOA. Ja ich glaube an diese Technologien und bin sicher wir können mit ihnen bei richtigem und wohlüberlegtem Einsatz einiges erreichen. Wichtig ist aber eine gesunde Portion Realismus in der Anwendung und vor allem in der Vermarktung. Mit nicht realisierbaren Prognosen erweisen die Analystenprofis der Sache keinen guten Dienst.

In diesem Sinne – viele Grüße aus San Francisco

PS 1: liebe Kollegen von Gartner, es ist keine Absicht, dass ich Euch immer wieder zitiere aber Ihr schreibt halt so witzige Dinge…

PS 2: ist Ihnen etwas aufgefallen? In London dauerte die Konferenz 2 Tage. In Las Vegas 3 Tage. Das werte ich als Beweis, dass wir in Europa das Thema BPM schon besser verstanden haben…

Die Oracle Open World geht in ihre zweite Hälfte. Heute war der Tag der großen Keynotes. Kris Gopalakrishnan (Infosys) stellte uns das Konzept des Value Webs vor. Kurz zusammengefasst geht er davon aus, dass sich die Wertschöpfung in Unternehmen immer weiter vernetzten wird. Die Kernaussage war: „Die besten Menschen auf diesem Planeten arbeiten nicht in unserer Firma. Wir müssen diese besten Menschen zukünftig stärker einbinden um als Unternehmen weiterhin erfolgreich zu sein“. Als Voraussetzung für diese „neue“ Welt wird eine noch bessere Nutzung von Technologie gesehen. Natürlich die der anwesenden Anbieter…selbstverständlich.

Es verwundert nicht, dass die aktuellen ökonomischen Entwicklungen auch nicht spurlos an dieser Veranstaltung vorbei gehen. Beachtenswert ist die Tatsache, dass auch in den Vorträgen (zumindest in denen dich ich gesehen habe) etwas Neues mitschwingt. Es scheint, als hätten die Referenten einen neuen Pragmatismus ausgerufen. „Best Practice“ und „Things that really work“ scheinen zum Mantra der kommenden Monate zu werden. Besonders herausheben möchte ich dabei die Präsentation „The Global Recession – IT’s Role, Impact and Future von Lem Lasher, Chief Innovation Officer und President des CSC Office of Innovation.

Laut Lasher hat IT in den letzten Jahren erst viele Produkte und Dienstleistungen, man denke nur an komplexe Mortgage backed securities, erst möglich gemacht. Damit hat IT eine „Mitschuld“ an der Krise. Seine Kernaussage ist, dass wir nicht mehr Herr der Komplexität sind. Dagegen seien in der IT Herdeneffekte von Anbietern und Anwendern spürbar. Geschäftsrisiken würden dadurch maskiert und erhöht.

Bei der Analyse fehlte als einer der Gründe für den oben genannten Zustand natürlich auch der altbekannte Punkt des fehlenden Abgleich zwischen Business und IT nicht. Klingt dies beim ersten hinhören noch sehr banal, so sind die daraus abgeleiteten Ratschläge von Lasher dennoch bedenkenswert.

Um den Risiken zu begegnen sollten wir folgende Punkte berücksichtigen:

- aufhören Vorhersagen über die Entwicklung der Wirtschaft und der IT machen zu wollen (z.B. von Analysten)

- besser auf Ratschläge hören was wir nicht tun sollten (verglichen mit Ratschlägen was wir tun sollten) und

- nicht mehr ein so starkes Vertrauen in Risikomodelle basierend auf Logik und Daten setzten.

Lasher merkt an, dass wir in Zukunft den Einsatz der IT umdrehen sollten. Seine Analyse kurz zusammengefasst: Heute haben wir die Ausführung von Arbeitsschritten an Menschen gegeben und die IT liefert uns die Informationen welche Richtung die Prozesse nehmen – als Beispiel seien hier nur Human Interaction gesteuerte Prozesse genannt. Seiner Meinung nach müssen wir dieses Muster in Zukunft umkehren. Die Ausführung von Prozessen überlassen wir den Maschinen und die Entscheidung in welche Richtung wir gehen übernehmen wieder Menschen (mehr oder weniger ohne IT-Unterstützung). Erst nachdem ich etwas über diese Schlussfolgerung nachgedacht hatte erschloss sich mir deren ganze Konsequenz. Zu Ende gedacht geht dieses Szenario weit über das reine BPM Versprechen hinaus. Demnach wäre (aktuell) kein IT System der Welt in der Lage unsere zunehmend komplexere Welt in ein Modell zu fassen, ohne das menschliche Intuition eine valide Entscheidungsbasis liefert. Vielmehr ist die menschliche Fähigkeit zum intuitiven und vernetzten Denken bisher unerreicht wird aber aktuell unzureichend genutzt. Auch wenn diese Feststellung sicher auf angloamerikanische Verhältnisse besser zutrifft als auf Europa, so ist die Schlussfolgerung doch interessant.

Die Analyse ist gelungen, aber bringen uns diese Ratschläge weiter? IT ist und bleibt ein essentieller Teil des Geschäftslebens. An diesem Umstand wird sich sicherlich nichts ändern. Etwas weniger blindes Vertrauen und ein wenig mehr menschliche Intuition und „Bauchgefühl“ wären aber sicher nicht schlecht. Das bedeutet dann auch, dass wir immer noch Menschen für unsere Arbeit benötigen und deren individuelle Fähigkeiten bis auf weiteres nicht durch Technologie ersetzt werden können – eine für mich beruhigende Schlussfolgerung. Ich hoffe sie trifft zu.

Hoffen wir also, dass das Mantra „Things that really work“ nicht nur ein vergängliches Bekenntnis ist.

Neben den ernsteren, schon fast BPM – philosophischen, Themen bot der erste Tag der Open World auch ein paar heitere Episoden. Ich werde versuchen jeden Tag eine festzuhalten. Heute eine Geschichte über Demonstranten vor dem San Francisco Moscone Center. Mit dem Slogan „Better dead than red“ machten sie auf eine ihrer Meinung zu stark marktbeherrschende Stellung von Oracle aufmerksam. Mir wurde nicht klar wofür genau sie aber demonstrierten. Mein Fazit: Outfit gelungen – Nachricht nicht transportiert.

In diesem Sinne – gute Nacht Deutschland

]]> http://www.computerwoche.de/soa-expertenrat/2009/10/13/oracle-open-world-2009-%e2%80%93-leerer-%e2%80%93-leiser-und-vielleicht-auch-etwas-reflektierter/feed/ 2 http://www.computerwoche.de/soa-expertenrat/2009/09/18/das-ende-des-%e2%80%9ebullshit-bingos%e2%80%9c-werden-wir-wirklich-endlich-wach/ http://www.computerwoche.de/soa-expertenrat/2009/09/18/das-ende-des-%e2%80%9ebullshit-bingos%e2%80%9c-werden-wir-wirklich-endlich-wach/#comments Fri, 18 Sep 2009 08:56:54 +0000 Dirk Stähler http://www.computerwoche.de/soa-expertenrat/?p=333 Danke Gulp! Endlich haben wir die Chance wieder etwas Normalität und Wahrhaftigkeit in unseren Arbeitsalltag einziehen zu lassen… hoffentlich

Lesen Sie selbst. Bei GULP  werden die Ergebnisse einer Befragung von IT Experten zu den aktuellen „Trend-Themen“ der IT vorgestellt und mit dem „IT Hype Cycle“ von Gartner verglichen. Wirklich ernst zu nehmen sind nach der Umfrage nur zwei der propagierten „IT-Trends“.

Ich möchte die Ergebnisse nicht im Detail kommentieren, da es dazu bereits viele gute Beiträge im Netz gibt. Den Versuch einer Erklärung dieser wiederholt auftretenden Missverständnisse möchte ich aber einmal zur Diskussion stellen.

Auch hier gilt wieder mein bereits in vorhergehenden Beiträgen erläutertes Modell einer grundsätzlich unterschiedlichen Sichtweise angelsächsischer und kontinentaleuropäischer „IT-Kulturen“. Was für BPM im Kleinen gilt (s. Die Gartner Glaskugel – Rosige BPM Zukunft oder nicht?) kann auch auf die IT Welt als Ganzes übertragen werden. Die angelsächsische Kultur springt viel schneller auf neue Trends und Themen auf, probiert sie aus und spielt ein wenig damit herum. Wenn sich nach einer (häufig kurzen) Zeit kein wirtschaftlicher Erfolg einstellt wird das „Trendthema“ ohne viel Jammern beerdigt und man beginnt etwas Neues. Wir Kontinentaleuropäer sind da eher zurückhaltend. Wir beobachten, prüfen und diskutieren erst mal genau einzelne Details. Wenn wir dann irgendwann zu dem Schluss kommen das die Idee gut ist, dann wenden wir sie (mitunter immer noch zaghaft) in einzelnen Bereichen an. Viele Trends erleben deshalb die breite Anwendung erst spät (s. SOA) oder gar nicht. Leider scheint sich bei uns aber eine Situation etabliert zu haben, in der wir versuchen beide Vorgehensweisen irgendwie zu kombinieren. Das kann nur scheitern!

Damit Sie mich richtig verstehen, ich möchte keine der beiden Vorgehensweisen als besser oder schlechter kennzeichnen. Jede hat ihre Stärken und Schwächen (hierzu könnte man noch viel mehr aus empirischer Sicht anführen, was ich aber an dieser Stelle nicht mache).

Weil wir kontinentaleuropäisch Arbeiten, neue IT-Visionen aber meistens mit der angelsächsischen Brille verkauft bekommen, entsteht (bei mir) regelmäßig ein ungutes Gefühl wenn jemand die nächste IT-Sau durch das Dorf treibt.

Bitte liebe Analysten – und das schreibe ich jetzt aus der Sicht eines regelmäßig mit neuen Schlagwörtern und Trends konfrontierten Beraters – für uns Europäer wäre ein wenig Mäßigung gut. Aus meiner Erfahrung heraus betrachtet, glaubt ohnehin so gut wie kein IT Verantwortlicher in den Unternehmen in Deutschland mehr die Heilsversprechungen. Weder von Euch, noch von den Herstellern. Viel besser wäre es doch wenn wir realistisch und mit ausgewogenem Urteil auf die IT-Welt schauen. Das zahlt sich sogar aus. Nämlich in weniger Fehlschlägen, besseren Projektergebnissen und zufriedeneren Mitarbeitern die nicht permanent etwas Neues machen sollen / müssen. Dann schaffen wir es auch das von Betty Zucker so passend formulierte „Chronic Change Fatigue Syndrom“ zu vermeiden.

Ich jedenfalls habe meine Entscheidung getroffen. Hype-Begriffe verwende ich nur noch in homöopathischen Dosen.

Liebe Kollegen von Gartner, auch wenn ich schon wieder auf eine Eurer Analysen Bezug nehmen muss, so soll das doch nicht zu einem Dauerzustand werden. Ein wenig mehr Realitätssinn und Verständnis für die europäische und deutsche Sichtweise wären wünschenswert. Und dann lobe ich Euch beim nächsten Mal auch – versprochen!

In diesem Sinne – allen ein schönes Wochenende

Aktuell führe ich eine interessante Diskussion. Kann man EA, BPM und SOA Inhalte in einem Modell einfach und in wenigen Schritten zusammenzubringen? Grundsätzlich weiß ich, dass dies erreichbar ist. Knackpunkt in meinen Gesprächen sind aber die Worte „einfach“ und „in wenigen Schritten“.

Zum Aufbau des EA Teils benötigt man Experten die sich mit der strukturierten Beschreibung von Infrastrukturen und Anwendungssystem auskennen. Die Ergebnisse dieser Gruppe sind meistens sehr geordnet und stringent. Auf der Seite des „fachlichen“ BPM sieht die Lage anders aus. Die Erfassung betrieblicher Abläufe ist schwieriger, handelt es sich bei diesen doch um mitunter umfangreiche und durch Ausnahmen und Sonderfälle geprägte Inhalte. Neben diesem Fakt kommt noch das unterschiedliche Verständnis der Semantik von Prozessinhalten hinzu.

Zuletzt tauchen dann noch die SOA Kollegen auf, die in der Regel eine tief technische (Integrations-)Sicht hinzufügen möchten.

Bei jeder dieser Gruppen weicht die Sichtweise mehr oder weniger stark voneinander ab. Vielleicht kennen Sie die Situation: Sie sitzen in einem Meeting mit Teilnehmern aus dem Management, den Fachbereichen und der Informatik. Jede Seite trägt ihre Position vor, aber irgendwie haben Sie latent das Gefühl, dass die anderen den Sachverhalt doch noch nicht so ganz verstanden haben. Jedenfalls nicht so wie Sie.

Irgendwo zwischen Management, Fachbereichen und den Niederungen der Informatik bestehen erhebliche Kommunikationslücken, deren Schließung vom Business Analyst erwartet wird. Dabei muss es der „arme“ Mensch allen Interessengruppen recht machen. Das führt natürlich zwangsläufig zu zwei möglichen Konsequenzen:

Man spricht entweder offen über Probleme (Neudeutsch… Herausforderungen) und Einschränkungen oder versucht jeder Gruppe nur einen Ausschnitt darzustellen, der sie nach Möglichkeit in ihrem Umfeld zufrieden stellt. Beide Herangehensweisen haben ihre Gefahren, wie wir gestern Abend sehr schön im Wahlduell sehen konnten.

Als „Zuschauer“ oder „Kunde“ hat man ein ziemlich gutes Gefühl welche „Wahl“ am besten wäre und welche Lösung den Konsequenzen klar ins Gesicht schaut. Andererseits möchte man natürlich auch gerne in der “heilen Welt“ leben und von Problemen, Schwierigkeiten und Einschränkungen nichts hören. Im Ergebnis bleibt das „unscharfe“ Empfinden, dass man vielleicht etwas anderes “wählen” sollte weil es im Ganzen zu besseren Ergebnissen führt, man sich aber so recht dazu nicht durchringen kann. Dann bleibt man bei seiner Entscheidung und hofft insgeheim, dass es doch anders kommt. Für das persönliche (schlechte) Gewissen bleibt der Trost, an dieser Entscheidung ja nicht beteiligt gewesen zu sein.

Lassen Sie uns gemeinsam bei dem Entwurf von EA, BPM und SOA Lösungen diese Falle umgehen. Transparenz und ein offenes Wort sind hier das Erfolgskriterium und erleichtert im Übrigen dem Business Analysten das Leben.

In diesem Sinne eine gute Woche

Gartner: „More than half of respondents plan to increase spending on BPM by more than 5 per cent in next 12 months”

Um diese Aussage in Deutschland einordnen zu können, müssen wir ergänzen wer die Befragten überhaupt sind und was sie unter BPM verstehen. Zum ersten Punkt macht Gartner leider nur rudimentäre Aussagen. Die betrachteten „IT Professionals“ wurden auf zwei Gartner Konferenzen mit Teilnehmern aus 34 Nationen in London und in San Diego befragt. Wer das genau war, aus welchen Ländern sie kamen und wo ihr BPM Arbeitsschwerpunkt liegt erkennt man nicht. In Anbetracht der aktuellen Sparsamkeit bei Geschäftsreisen gehe ich in London aber von zumeist britischen und in San Diego von US Teilnehmern aus.

Weiterhin behaupte ich dann, dass die befragten IT Professionals bei dem Begriff BPM hauptsächlich die angelsächsische Sicht vertreten, welche im Wesentlichen die Automatisierung von Prozessen mit Hilfe der Informationstechnologie betrachtet (Anmerkung: im kontinentalen Europa verstehen wir unter BPM die fachlich organisatorische und technisch ausführende Sicht gleichgewichtet nebeneinander).

Schlussfolgerung: Gartner verspricht uns ein BPM Wachstum im IT Bereich – nicht in fachlichen BPM Projekten.

In der Pressemitteilung heißt es weiter: „Only 23 per cent anticipated any degree of revenue decline, while 42 per cent anticipated some growth,…”.

Das bedeutet doch, dass immerhin 35% gar keine Veränderung erwarten. Zusammen mit den 23% die von einem Erlösrückgang sprechen, komme ich auf 58% die entweder keinen Effekt oder sogar einen Rückgang erwarten.

Übersetzung von mir: Die Mehrheit der IT Fachleute die bei Gartner in London und San Diego anwesend waren meinen, dass sich die Ertragssituation ihrer Unternehmen in den kommenden 12 Monaten nicht gravierend verändert oder die Erträge sinken.

Wie das direkt mit BPM zusammenhängt verschweigt Gartner. Allenfalls könnte man mutmaßen, dass Unternehmen mit sinkenden Erträgen nach Einsparmöglichkeiten suchen. Ich glaube in diese Richtung will Gartner das auch verstanden wissen. Wachstum sieht aber anders aus!

Sehen Sie sich weiterhin die nächste Aussage an.

Gartner verspricht folgendes: „Gartner predicts that BPM may be a way for companies to do more with less, and to free up more funding for growth and transformation initiatives”.

Das ist schon ziemlich nah am Perpetuum Mobile. Aber mal ernsthaft, glauben wir wirklich das man mit BPM kurz- oder mittelfristig in der Lage ist die Flexibilität der IT ohne signifikanten Aufwand im Vorfeld zu steigern? Wohl kaum.

Übersetzung von mir: BPM kann mittel bis langfristig helfen fachliche Prozesse und deren IT Unterstützung in Unternehmen zu verbessern. Kurzfristige Mittel für Wachstums- oder Transformationsprojekte kann BPM nicht freisetzen. Im Gegenteil, die BPM Einführung wird erst mal selber mehr Mittel benötigen.

Erwarten Sie keine Wunder – mehr mit weniger geht nicht! Ich bin BPM Anhänger und weit davon entfern die Möglichkeiten von BPM zu leugnen, aber die Gartner Schlussfolgerung geht zu weit.

Dann stellt uns Gartner einem weiteren Nutzen von BPM Projekten vor.

„She (Ms. Michele Cantara, Research Vice President bei Gartner, Anmerkung des Verfassers) recommended that organisations use BPM to help prioritise which existing projects, suspended projects and new projects will be prioritised, sequenced, funded and staffed when business growth returns”.

Das ist ja interessant. Wir sollen also BPM verwenden, um zu priorisieren welche bestehende, gestoppte oder zukünftige Projekt in einem Unternehmen priorisiert werden sollen wenn die Wirtschaftkriese vorbei ist. Damit wäre BPM ein Planungsinstrument und “bootet sich selbst”.

Übersetzung von mir: Vergessen Sie Ihre Erkenntnisse aus technischen BPM Aktivitäten zur Bewertung welche Projekte Sie durchführen sollten. Auch ein fachlich orientiertes BPM kann Ihnen an dieser Stelle nur begrenzt helfen. Zum Projekt-Portfolio-Management (PPM)und zur strategischen Planung taugt BPM nicht. Es ist dabei bestenfalls eine von vielen Informationsquellen.

Mein Fazit: Die vorliegende Gartner Untersuchung versucht Zusammenhänge herzustellen wo keine sind. Wie sich der BPM Markt in den kommenden 12 Monaten verändert kann man aus dieser Untersuchung nicht ablesen.

Siehe dazu auch: http://www.computerwoche.de/software/soa-bpm/1902426/

Statt eines Heilsbringers habe sich SOA in den meisten Organisationen zu einem “großen gescheiterten Projekt” entwickelt, konstatiert Manes. Angesichts der geballten öffentlichen Kritik sollten Unternehmen auf das Akronym verzichten und stattdessen eher über Begriffe wie Enterprise Service Bus (ESB) reden. Manes: “SOA ist zu einem Unwort geworden. Wir müssen es aus unserem Vokabular streichen.”

Wer beschäftigt sich mit BPMN und warum?

Die Teilnehmer der Seminare lassen sich grob in drei Gruppen einteilen. Bei der ersten Gruppe handelt es sich um Prozessmanager, die eine geeignete Notation suchen, die als unternehmensweiter Standard eingesetzt werden kann. Zumeist gibt es bereits Erfahrungen mit verschiedenen anderen Notationen, die aber nur an einzelnen Stellen eingesetzt worden sind. Im Sinne einer durchgängigen Modellierung soll nun eine einheitliche Notation gefunden werden, die möglichst von Business und IT gemeinsam verwendet werden soll. Oftmals leiden bislang eingesetzte Notationen auch unter Akzeptanzproblemen bei den Mitarbeitern, die in der Vergangenheit von riesigen, nicht immer realitätsnahen “Prozesstapeten” abgeschreckt wurden. Zwar liegt es häufig nicht an der Notation, sondern an den Modellierern, wenn derart unübersichtliche und eigentlich nicht verwendbare Modelle entstehen, doch ermöglicht es eine neue Notation, die nocht nicht mit schlechten Erfahrungen der Mitarbeiter belastet ist, eine bessere Akzeptanz für neue Initiativen zu gewinnen. Unabhängig von der neu ausgewählten Notation ist es natürlich wichtig, die bisherigen Fehler nun zu vermeiden. Die Verwendung der BPMN schützt noch nicht vor schlechter Modellierung.

Die zweite Gruppe von Teilnehmern stammt aus internen Beratungsabteilungen großer Konzerne. Hier werden bisher oftmals unterschiedliche Notationen eingesetzt. Oft gibt der interne Kunde Tools und Methoden vor, oder die aus Anwendern und Beratern gebildeten Projektteams entscheiden selbst, wie sie Prozesse und Anforderungen dokumentieren. Die Berater möchten ihre Methodenkompetenz verbessern und ihre Kunden beim Aufbau eines durchgängigen Prozessmanagements unterstützen. Hierzu benötigen sie geeignete Vorgehensweisen und einheitliche Notationen, die nicht nur im Rahmen von Einzelprojekten einsetzen lassen.

Die dritte Gruppe von BPMN-Interessenten kommt aus den IT-Abteilungen. Angesichts zunehmender Anforderungen an die IT, Business-Anforderungen schnell umzusetzen und konkret nachweisbaren Nutzen für das Business zu schaffen, sind sie daran interessiert, die Anforderungsermittlung durch eine gemeinsame Sprache mit dem Business zu verbessern. Außerdem beschäftigen sie sich zunehmend mit SOA-Projekten und setzten hierbei auch Process Engines ein. Da in diesem Bereich die BPMN eine große Rolle spielt, fragen sich die IT-Abteilungen, wie fachliche Prozessmodelle in ausführbare Prozessbeschreibungen umgesetzt werden können.

Wie wird die Eignung der BPMN eingeschätzt?

Praktisch alle Teilnehmer äußerten sich positiv über die BPMN. Die Art der Prozessdartstellung durch die BPMN-Grundkonstrukte wird als angenehm und gut verständlich empfunden. Dies gilt für Business-orientierte Teilnehmer ebenso wie für Mitarbeiter aus der IT. Auch die Besonderheiten der BPMN, wie die Verwendung verschiedener Typen von Ereignissen und die Modellierung des Nachrichtenaustauschs zwischen verschiedenen Prozessbeteiligten wird als interessant und nützlich angesehen. Interessanterweise äußerten sich IT-Vertreter skeptisch über das Verständnis dieser erweiterten Konstrukte seitens der Fachmodellierer, wohingegen diese in den Seminaren zumeist keine großen Probleme hatten, diese Konzepte zu verstehen und anzuwenden.

Kaum ein Teilnehmer konnte sich vorstellen, die noch spezielleren BPMN-Konstrukte wie z. B. Exceptions oder Transaktionen einzusetzen – es sei denn im Rahmen der Modellierung ausführbarer Prozesse für eine konkrete Process Engine.

Meist wurde die Erwartung geäußert, zunächst mit den grundlegenden Elementen zu beginnen, wie Aktivitäten, Sequenzfluss, Gateways, Pools und Bahnen. Auch oder gerade weil sich diese Elemente kaum von herkömmlichen, einfachen Flussdiagrammen unterscheiden, wird hierfür eine hohe Akzeptanz erwartet. Der Vorteil der BPMN ist in diesem Fall einfach die Tatsache, dass es sich um einen Standard handelt. Dadurch ist einerseits die Bedeutung der jeweiligen Elemente recht klar definiert, andererseits wird Wildwuchs in der Modellierung verhindert.

Für den Einsatz der BPMN zur fachlichen Prozessmodellierung wird insbesondere noche eine gute Integration mit anderen Modellierungssichten (z. B. Organigramme, Daten- oder Fachbegriffsmodelle, Anwendungssystemlandschaften) vermisst. Hier weisen aktuelle BPMN-Tools ebenfalls Defizite auf: Tools zur Unternehmensmodellierung mit unterschiedlichen, miteinander integrierten Sichten bieten bislang oft keine komplette Umsetzung der BPMN. Auf der anderen Seite gibt es hervorragende Tools zur spezifikationskonformen BPMN-Modellierung, die aber meist keine Integration anderer Sichten ermöglichen.

Prinzipiell bestätigen die Erfahrungen aus den Seminaren, dass sich die BPMN als gemeinsame Prozess-Sprache für Business und IT eignet. Allerdings beseitigt alleine die Nutzung einer gemeinsamen Sprache noch nicht die Möglichkeit, sich misszuverstehen. Das ist nicht anders als mit natürlichen Sprachen: Auch wenn zwei Menschen Deutsch sprechen, ist noch nicht sichergestellt, dass der eine versteht, was der andere sagen will.

Auf Grundlage des beschriebenen Seminars ist mittlerweile ein kleines Büchlein entstanden, bislang die einzige BPMN-Einführung in deutscher Sprache (Infos zum Buch).

Was genau meint denn dieses Wörtchen Unabhängigkeit? Unabhängigkeit bedeutet nicht primär, dass ein neutraler SOA-Hersteller seine Kunden unabhängig von ihrer eigenen Infrastruktur macht – obwohl das natürlich gewisse nicht zu verleugnende Vorteile hätte. Doch was gegeben ist, muss in die Kalkulation mit einbezogen werden. Niemand hat genug Budget, Energie und Nerven, um die komplette IT-Struktur von heute auf morgen abzureißen und rundum neu aufzusetzen. Unabhängigkeit bedeutet also vor allem, unabhängig von dem zu werden, was in einer SOA verbunden werden soll – also von den herstellerspezifischen ERPs, CRMs, Core Systems, usw. Der Kernpunkt ist, Anwendungs-Silos zusammenzubringen, sie miteinander kommunizieren zu lassen und den Produktivitätseffekt zu nutzen. Das Stichwort heißt Integration. Und das geht nur über neutrale, herstellerunabhängige Mechanismen.  

Wer könnte sich mit diesen Mechanismen besser auskennen als ein Anbieter, der keine eigene Anwendung vertreibt und daher auch keine Präferenz für den einen oder anderen Hersteller hat? Die Antwort ist einfach: Niemand. Integration ist gefragt zwischen Standardanwendungen verschiedener Hersteller. Ein Hersteller einer (Silo-)Standardapplikation ist verständlicherweise bemüht, ein möglichst frühes „Lock in“ bei seinem Kunden zu erreichen – also ist eine wirkliche Unabhängigkeit für ihn gar nicht wünschenswert. Eine proprietäre SOA-Lösung desselben Herstellers erschafft einen weiteren Sog hin zu den Anwendungen dieses Herstellers.

Und hiermit können wir den unabhängigen SOA-Hersteller klar definieren: Ein Hersteller, der keine Präferenz für einen einzelnen Hersteller von Standardapplikationen erzeugt. Bei Herstellern, die Standardapplikationen gar nicht erst anbieten, ist die Gefahr für den Kunden, in eine bestimmte Richtung gedrängt zu werden, gleich null. SOA ist kein Marketing-Gag, sondern Realität. Und mit einem unabhängigen SOA/BPM-Hersteller sorgt sie – selbst bei nicht unerheblichen Kosten- und Arbeitsaufwänden – für einen raschen ROI. Der neueste „SOA Check 2008“ zeigt es: SOA etabliert sich. Nicht zuletzt dank der seltenen Spezies der unabhängigen SOA-Hersteller.

Im Gegenteil. Zwar müssen Unternehmen insbesondere in der aktuellen wirtschaftlichen Situation Investitionen noch sorgfältiger planen. Daher ist es auch nicht verwunderlich, dass neue Initiativen zunächst zurückgestellt werden.

Allerdings stellt Sholler zugleich fest, dass 53 % aller Befragten in Teilen ihrer Organisation eine SOA nutzen! Das beweist, dass SOA heute schon aus den Unternehmen nicht mehr wegzudenken ist und die Vorteile von SOA in großem Rahmen genutzt werden. Dass sich das Wachstum bei SOA-Einstiegsprojekten angesichts dieser doch beachtlichen Verbreitung abschwächt, ist kaum verwunderlich.

Zudem deckt sich der durch die Gartner-Studie postulierte Trend nicht mit unseren Beobachtungen, die wir bei SAP gemacht haben und machen. Wir haben im Laufe des Jahres sehr viele interessante SOA Projekte verfolgen können. In den Unternehmen werden diese aber nicht als SOA Projekte betrachtet, sondern über den Geschäftsnutzen und die Anforderungen definiert und schließlich auch angestoßen. Jedes Projekt muss einen klaren Nutzen bringen. Ob solche Projekte dann unter dem SOA-Banner laufen oder nicht, ist sekundär.

Unsere SOA Referenzen und die Anzahl installierter Enhancement Packages (>1000 im Oktober), die Enterprise Services bereitstellen lassen erhebliche Zuwachsraten in 2008 erkennen.

- “Ich habe es versäumt, unsere SOA-Initiativen mit unseren geschäftlichen Anforderungen in Einklang zu bringen”, steht in dem Brief. “Deshalb kann ich den vielen hundert Services, die wir entwickelt haben, keinerlei Wert zumessen.”

Weitere Kosproben:

- “Ich habe es versäumt, (…) ein SOA Center of Excellence, Steering Commitee oder Competence Center einzurichten.”

- “Ich habe es versäumt, das Topmanagement als Unterstützer und Evangelist für unsere SOA-Vorhaben ins Boot zu holen.”

- “Ich habe einen ESB gekauft, ohne unsere Anforderungen an eine SOA-Infrastruktur wirklich zu verstehen. (In Wahrheit war es nicht mein Fehler: Der Softwarehersteller sagte, das sei super duper wichtig)”

- “Ich habe es versäumt, meinen Entwicklern Anreize für eine Wiederverwendung von Softwareartefakten zu geben.”

- “Ich war nicht dafür zuständig, die Aktivitäten des BPM-Teams von nebenan mitzuverfolgen (…) Das sind doch zwei verschiedene Initiativen.”

- “Ich glaube fest daran, dass SOA nichts anderes als Corba oder COM ist.”

Die gute Nachricht, so lässt Kenney den imaginären Briefeschreiber formulieren, sei, dass ohnehin 70 Prozent der IT-Vorhaben scheiterten. Schuld an den Problemen sei nicht er, sondern das SOA-Konzept als solches. Das Schreiben endet mit der Bemerkung: “Im voraus möchte ich erklären, dass Cloud Computing, Virtualisierung und SaaS unter meiner Führung ebenfalls scheitern werden.”

Das Heft Nr. 40 der COMPUTERWOCHE vom 3. Oktober 2008 war übertitelt mit „Brandherd SOA – Anwender unterschätzen die Komplexität“. Als Mitglied des SOA-Expertenrats der Computerwoche ist mir natürlich sofort die Einseitigkeit dieser, als Teilaspekt sicherlich korrekten Feststellung aufgefallen.

Wir können „Brandherd SOA“ mit derselben Aktualität und Relevanz ebenso gut um den Ausspruch „Hersteller haben die Gesamtaufgabe methodisch nicht unter Kontrolle“ ergänzen. Die entscheidenden Gründe für die Probleme bei der Umsetzung Serivce-orientiertrer Architekturen in Kundenunternehmen liegen jedoch sehr viel tiefer.

Im Sommer 2004 veranstaltete ich zusammen mit Thomas Kühne und Hartmut Wedekind an der Technischen Universität Darmstadt sowohl für Informatiker(innen) als auch für Wirtschaftsinformatiker(innen) ein Seminar über die sprachlogischen Grundlagen der UML. Wedekind hielt dann im Wintersemester 2006/2007 – vom meinem Lehrstuhl Entwicklung von Anwendungssystemen aus – für denselben Adressatenkreis die Vorlesung „Critical Analysis of UML“. Dieser lag das umfassende Buch über den, alle Ebenen behandelnden Sprachumfang der UML von Hitz et al. in der 3., aktualisierten und überarbeiteten Auflage von 2005 zugrunde. Wer interessiert ist und Grundkenntnisse in formaler sowie klassischer Logik besitzt, kann sich das sehr klar und verständlich abgefasste Manuskript der Vorlesung noch heute von meiner Homepage (http://www.metainformationen.de) herunterladen.

Das Ergebnis der kritischen Analyse der UML kann man, wie schon zwei Jahre zuvor in dem Seminar mit Kühne und Wedekind, mit den Worten Wedekinds wie folgt zusammenfassen:

„The very question remains: Is UML 2 repairable to achieve a logic consistent UML 3 or do we have to take UML 2 as a heap of rubbel, on which we have to build a new UML? Qui vivra, verra! Take this for granted: In any case, UML 2 is not stable.“

Seither haben meine Mitarbeiter und ich in verschiedenen Arbeiten demonstriert, wie Logik-basierte Modellierung vor allem auf dem Gebiet der Ablauf- und Aufbauorganisation von Unternehmen aussehen und zu welchen Resultaten sie uns führen kann. Wir greifen dabei auf semantisch schwergewichtige Teil-Logiken wie Temporale Logik, Modallogik, Deontische Logik, Praktische Logik und Topologische Logik zurück und wählen für den zu modellierenden Gegenstand einen Ereignis-orientierten Ansatz. Auch hierüber können dem interessierten Leser dieses Blogs – wo Bedarf besteht – Unterlagen zur Verfügung gestellt werden.

Gerade bei BAM herrscht in meinen Augen einiges an Verwirrung.  Dies ist aus meiner Sicht umso kritischer, als das Monitoring sicherlich eine wichtiger Bestandteil einer SOA und einer BPM Lösung darstellt.  Wobei hier das Monitoring eben nicht als reiner Selbstzweck zu betrachten ist, sondern eine wichtige Voraussetzung für eine effektive und Zeitnahe Entscheidungsfindung und Verbesserung von Geschäftsaktivitäten.

Abhängig davon, mit wem ich mich hierbei bei Kunden und auch mit Kollegen unterhalte besteht ein unterschiedliches Verständnis über BAM.  Oft wird in BAM vieles hineingepackt, was zwar auch Monitoring ist, aber eben nicht im Sinne von Business Activity Monitoring.

Sind also BAM, BSM und O-BI (Operational BI) Synonyme?

Ohne jetzt hier in weitreichende Definitionen zu verfallen oder auch Diskussionen um Definition auszulösen, ist es doch wichtig kurz darzustellen, was sich aus meiner Sicht hinter den Begriffen verbirgt.

Business Activity Monitoring (BAM) - Echtzeit Zugriff auf geschäftsrelevante Kennzahlen (KPI) aus den laufenden Prozessen und weiteren verschiedensten Quellsystemen für schnellere und efizientere Geschäftsabläufe durch ganzheitliche Sicht auf die Geschäftsaktivitäten.  Es geht also grundsätzlich um Prozesse, Geschäftsereignisse und KPIs.

Business Services Management (BSM) -aus Richtung der IT (Betrieb, Infrastruktur) kommende Echtzeit Betrachtung von Ereignissen und Zuständen im bezug auf z.B. Service Level Agreements (SLA) und im weiteren Schritt auch im Bezug auf Einfluss auf Geschäftsprozesse. Manchmal auch als Business of IT Dashboard bezeichnet.

Operational BI - mit Ursprung aus der Datenhaltung ud die Ausdehnung der ‘klassischen’ Business Intelligence Lösungen auf eine echtzeitnahe Analyse von Daten.

Sicherlich gibt es auch gewisse Überschneidungen.  Und zumeist beginnen an dieser Stelle auch die Diskussionen:

• Bei BAM kann ich als Quellen natürlich auch entsprechende Ereignisse aus der IT oder auch Datawarehouse einbeziehen und entsprechend verknüpfen – sprich in meinem BAM Monitoring Modell entsprechend abbilden.
• Bei BSM benötige ich auch Informationen über die Geschäftsprozesse um eine entsprechende Verbindung herstellen zu können zwsichen IT und Auswirkung auf die Geschäftsaktivitäten.
• Und wenn ich es dem typischen Operational BI ermögliche ausser den Datenquellen auch weitere Quellen zur Informationsanalyse mit einzubeziehen kann ich natürlich auch entsprechende Darstellungen von IT/Betriebsdaten oder auch Prozessdaten umsetzen.

Doch dies reicht nicht aus um zu sagen, dass BAM, BSM und Operational BI Synonyme sind.

Neben der reinen Darstellung von echtzeitnahen Business Ereignissen in Kombination mit und der Analyse von historischen Daten grenzt sich BAM maßgeblich noch durch die folgenden Aspekte gegenüber BSM oder Operational BI ab:

• Prozesseinsicht bis auf einzelne Prozessinstanzen und Tasks herunter sind möglich.  Dies beinhaltet auch den aktiven Eingriff in Business Workflows zur Steuerung der Zuordnung von Aktionen
• Auslösen und Aufsetzen von ad-hoc Aktionen innerhalb der BAM (und der darunter liegenden Prozess Laufzeitumgebung) um Erfasste Problemsituation in einen Bearbeitungsflow zu bringen.
• BAM ermöglicht eine klare Resourcenüberwachung im Sinne der Optimierung der Bearbeitung einzelner Geschäftsvorfälle
• Übernahme der KPIs aus der Definition der Prozessmodellierung, sowie einfache Rückgabe entsprechender Echtdaten aus dem Monitoring zurück zur Modellierung (SOA bzw. BPM Lifecycle).
• Klare Fokussierung auf Business Events (Geschäftsereignisse)

Meine Erfahrung zeigt mir hierbei aber auch, dass eine strikte Trennung nicht immer wirklich machbar ist.  Jeder Ansatz öffnet sich aus seinem Ursprungsbereich (Geschäftsereignis/KPI, IT und Daten) heraus auch für die anderen Bereiche, da häufig nur so ein umfassendes Bild des Ganzen gegeben werden kann.

Aber auch wenn eine solche Universallösung häufig nicht gewünscht oder erforderlich ist, so kann es dennoch von großem Interesse sein, informationsanteile auch in anderen Ausprägungen in der für den Fall dann nötigen Detailtiefe einfach mit einbeziehen zu können.

Wie sehen Sie den Bedarf an Business Activity Monitoring und die zukünftige Ausrichtung?  ich freue mich auf Ihre Reaktionen, Anmerkungen und Ideen.

“The purpose of measuring is not to know how a business is performing but to enable it to perform better.” Source: Michael Hammer

Bei genauerem Hinsehen erweisen sich diese Argumente als Augenwischerei. Natürlich sind auch die selbsternannten neutralen Anbieter daran interessiert, möglichst viele ihrer Produkte zu verkaufen und damit Anwenderunternehmen stärker an sich zu binden. Die Mär von der beliebigen Austauschbarkeit von Infrastrukturkomponenten macht die Sache nicht besser. Es mag theoretisch möglich sein, einen Enterprise Service Bus (ESB) oder andere zentrale SOA-Komponenten gegen besser geeignete Produkte auszutauschen. In der Praxis aber rechnet sich der damit verbundene Aufwand in den allerwenigsten Fällen.

Und schließlich singen auch die großen SOA-Player vom Schlage IBM oder Oracle schon seit Jahren das hohe Lied der Offenheit und Interoperabilität. Offene Standards würden schon dafür sorgen, dass Systeme unterschiedlicher Anbieter “nahtlos” zusammenarbeiten. Unternehmen könnten, wenn sie es nur wollten, jederzeit eine Best-Practice-Strategie verfolgen und sich die für ihre Anforderungen passenden Produkte herauspicken. Leider zeigt die Praxis, dass Standards immer wieder durch proprietäre Erweiterungen “verbessert” und damit ad absurdum geführt werden. Fazit: Es gibt keine neutralen Anbieter im SOA-Markt. Wer sich eine Architektur vom (Software-)Hersteller zimmern lässt statt selbst Hand anzulegen, begibt sich in eine Abhängigkeit, die irgendwann teuer wird.

Dieser Eindruck trügt. IT-Verantwortliche sollten sich von den Abgesängen auf den SOA-Hype ebenso wenig blenden lassen wie von den Hochglanzbroschüren der Softwarehersteller. Denn es gibt sie, die erfolgreichen SOA-Initiativen, auch in Deutschland. Nicht nur Pionieranwender wie die Deutsche Post haben bewiesen, dass SOA mehr ist als ein technikgetriebenes Modethema. Als strategische Option steht das Konzept bei einer Vielzahl großer Unternehmen und Behörden weit oben auf der Agenda. Dazu gehören die Daimler AG ebenso wie die Deutsche Bank, der Volkswagen-Konzern, die Telekom, die Hypovereinsbank oder auch die Bundesagentur für Arbeit. Die Bewerbungen zum computerwoche-Wettbewerb “CIO des Jahres 2008″ belegen zudem, dass SOA nicht nur in Großunternehmen ein Thema ist.

Eine gewisse Ernüchterung, manche Analysten sprechen von Abkühlung oder gar Desillusionierung, ist dennoch unverkennbar. Die zum Teil schlechten Erfahrungen in der Anfangsphase der SOA-Euphorie, aber auch überzogene Versprechen der IT-Hersteller, haben ihren Teil dazu beigetragen. CIOs, Projekt- und Prozessverantwortliche sollten diese Erkenntnisse als Chance begreifen, um ihre SOA-Pläne kritisch zu hinterfragen.

Die wichtigste Lektion: SOA ist, entgegen vielen Argumenten der Softwaregurus, kein reines IT-Thema. Wer SOA nur als Architekturparadigma für die Softwareentwicklung begreift, wird die erhofften Vorteile wie Flexibilität, Agilität und Effizienz kaum ernten können. Das volle Potenzial entwickelt eine SOA erst über die damit zu erzielenden Prozessverbesserungen. Dazu müssen die Fachabteilungen ins Boot, was direkt zur zweiten Lektion führt: Die Protagonisten müssen den wirtschaftlichen Nutzen einer SOA besser erklären. Das altbekannte Kommunikationsproblem der Techies wirkt sich in SOA-Vorhaben fatal aus.

Dazulernen müssen aber auch die Mitarbeiter in den Fachabteilungen, beispielsweise wenn es um den Umgang mit modernen Tools für die Prozessmodellierung- und -analyse geht. Eng damit zusammen hängt eine dritte Erkenntnis: Die mit SOA einhergehenden organisatorischen Veränderungen wirken nicht nur in den IT-Abteilungen, sondern potenziell in allen Unternehmensteilen und Führungsebenen. Ohne deren Unterstützung und Mitwirken bleibt SOA am Ende doch nur ein IT-Konzept.

Ja, die gibt es. Einige der Leser werden sagen: „Jetzt ist er total durchgedreht“, aber sehen wir uns die Fakten doch einfach einmal an. Der aktuelle Ifo-Geschäftsklimaindex ist gerade erstmals seit zweieinhalb Jahren unter die Marke von 100 Punkten gesunken. Der Ifo-Erwartungsindex, ein Maß für die erwartete Geschäftsentwicklung, ist sogar um ganze 4,6 auf 90 Punkte eingeknickt. Diesen Stand hatten wir zuletzt im Jahr 2002. Lange Rede, harte Aussage: es kommen stürmischere Zeiten auf uns zu. Dieser Feststellung werden wohl nur wenige Permanentoptimisten wiedersprechen.

Was sind die Gründe für diesen Rückgang? Zu nennen sind 3 wesentliche Ursachen:

1. Die US Immobilienkriese hat die Finanzsysteme destabilisiert und rast mit Schockwellen  um den Globus
2. Die permanente Steigerung der Energiekosten drückt auf den industriellen Sektor
3. Die Lebensmittelpreise steigen permanent und zusammen mit 2) werden zusätzlich die privaten Haushalte getroffen

Welche strategischen Entscheidungen werden Unternehmen im Angesicht der oben geschilderten Realitäten im Jahr 2009 wohl treffen?  Es wird in nicht zu unterschätzendem Maße zu einem sicherheitsorientierten Verhalten der Unternehmen führen. Investitionen werden zurückgefahren, Einstellungen werden reduziert und innovative Weiterentwicklungen der Geschäftsmodelle werden abnehmen. Als Beispiele denke man nur an Siemens, T-Systems und andere.

Mit der oben erläuterten, an Sicherheiten ausgeprägten Unternehmensstrategie werden 2 wesentlichen Faktoren an Bedeutung gewinnen:

• Das Subsidiaritätsprinzip wird in der Einbindung externer Partnern massiv zunehmen. Leistungen werden wieder verstärkt lokal erbracht. Ursachen dafür sind die Probleme im internationalen Finanzsystem, welches in lokalen Strukturen ein höheres Vertrauen, und damit Sicherheit findet. Sowie in verbesserten lokalen Kostenstrukturen ausgelöst durch hohe Energiepreise.
• Unternehmen werden verstärkt am Weiterbetrieb und der „Renovierung“ bestehender Infrastrukturen arbeiten im die Investitionskosten niedrig zu halten um dem wirtschaftlichen Trend entgegenzusteuern.

Aber was hat das mit SOA zu tun? SOA ist ein innovativer neuer IT Trend. Zugegeben, jetzt werden sich bei einigen technischen Lesern die Haare sträuben, aber lassen Sie uns SOA einmal für ein paar Sätze in dieser Form definieren.

Aufgrund der oben genannten betriebswirtschaftlichen Erläuterungen gehe ich davon aus, dass auch die IT sich diesem Szenario nicht entziehen kann. Die Unternehmen werden in naher Zukunft einen sehr pragmatischen Ansatz in der Weiterentwicklung ihrer IT Infrastruktur verfolgen, und im Wesentlichen auf Stabilität setzte.

Ich bin kein Untergangsprophet und sage es wird auch wieder besser. Genau darin liegt meine Sicht wie IT Verantwortliche die kommende „schwerere“ Zeit heute angehen sollten.

Mein zentrales Argument ist: räumt die IT auf und nutzt die Phase der Konsolidierung (hoffen wir das es nur so weit geht) um die IT richtig aufzustellen. Konkret bedeutet dies:

• Verschafft Euch einen Überblick was in den letzte fetten Jahren so alles angefallen ist und für die zunächst kommenden mageren Zeiten nicht geeignet ist
• Bringt die IT für Subsidiaritätsstrukturen auf Vordermann
• Reduziert die Verflechtungen mit Dritten und implementiert einfache Strukturen

Dann kann das echte SOA irgendwann wiederkommen. Die oben genannten Arbeiten haben bis dahin vielleicht mehr Wert für SOA geschaffen als man heute vermutet. Dann ist die Finanzkriese indirekt vielleicht einer der Helfer um SOA in Zukunft wirklich zu etablieren.

SOA ist ein Bauprinzip für die Entwicklung neuer Anwendungen und die Erweiterung vorhandener Systeme. Ein ganz einfacher Vergleich hilft, SOA in der Praxis in die richtigen Bahnen zu lenken: Das Lego-Prinzip. Die Idee ist, dass neue Systeme aus Komponenten aufgebaut werden, die bereits vorhanden sind. Die Steckverbindungen heißen Schnittstellen (WSDL). Alle Komponenten werden durch diese einheitlichen Schnittstellen miteinander verbunden – das sind dann die Web Services. Systeme, die aus unterschiedlichen Komponenten aufgebaut sind, können leicht Daten mit anderen Systemen austauschen, und sie sind einfach zu erweitern und zu verändern – genauso wie die unterschiedlichsten Legosteine immer zueinander passen und in vielen verschiedenen Formen und Bauteilen verwendet werden können. Ältere Systeme können mit Hilfe von Adaptern für eine SOA nutzbar gemacht werden. In dieser Hinsicht geht SOA sogar über das Lego-Prinzip hinaus.

Erfahrungen aus Kundenprojekten haben gezeigt, dass eine schrittweise Modernisierung der operativen Anwendungen besser als eine komplette Ablösung ist. Das Risiko wird minimiert, wenn ein Gesamtprojekt in Teilprojekte untergliedert werden kann. Wie bei einem komplizierten Lego-Bauplan ist es sinnvoll, Schritt für Schritt vorzugehen und dabei das Ganze nicht aus den Augen zu verlieren. Die ersten Schritte finden auf dem Business-Level statt: Benutzer-Anforderungen verstehen und Geschäftsprozesse analysieren, Verbesserungspotenziale identifizieren. Dann folgt die IT-Ebene: Notwendige Services identifizieren, Neuentwicklungen planen, Services für Geschäftsprozesse programmieren. Die letzte Ebene ist die übergeordnete Governance-Ebene: Policies definieren, Lifecycle Management implementieren, definierte Geschäftsprozesse fokussieren.

Vielleicht haben Sie auf dem Dachboden noch eine alte Legokiste aus Ihrer Kindheit? Probieren Sie es aus: die Bausteine funktionieren auch heute noch, auch in Kombination mit den High-Tech-Lösungen moderner Lego-Baukästen. Dank der konsequenten Einführung und Einhaltung von Standards galt und gilt das auch für Software. SOA ist dabei der Bauplan, oder auch der Wegweiser durch die Komplexität der vor uns liegenden Aufgaben, vorhandene und neue Systeme zu einem neuen, sinnvoll genutzten und effizient arbeitendem Gesamtwerk zu machen.

Was CIOs vom Thema halten, sehen Sie im Video der COMPUTERWOCHE.

Teil 1: Beim Anwender findet top-down (Enterprise Modeling) die Arbeitsprozessanalyse und -optimierung statt.

Teil 2: In einem nachfolgenden Schritt wird dann seitens der Nachfrager bei den Anbietern der bottom-up rekonstruierten Anwendungssoftware, die wir in Zukunft auch Application Service Provider nennen könnten, nach dem passenden Service gesucht. Hierzu werden eine Service-Anbieter-Analyse sowie eine Service-Rekonfiguration und -Evaluation durchgeführt.

Wie das mit Interviews heutzutage so ist, wurden natürlich vor dem Druck Meinungen anderer Experten eingeholt. Und eine dieser Kommentare möchte ich nun als Grundlage für den heutigen Blog-Beitrag nehmen.

Rolf Schumann (Europa-CTO Netweaver, SAP) antwortete auf meine Ausführungen: „Unsere Transformationsmethodik zur Enterprise SOA enthält ein Vorgehen, um betriebswirtschaftliche Prozesse auf der Business-Prozess-Plattform zu implementieren. Hinzu kommt eine Methodik zur semantischen Modellierung von Enterprise Services.“

Sie werden mir sicherlich zustimmen, dass es dieses Statement verdient, hier diskutiert zu werden. Ich mache gerne den Anfang und zwar mit der Frage, was Herr Schumann im Kontext von Enterprise Services mit „semantisch“ meint. Semantik, was übersetzt bekanntermaßen „Bedeutung“ heißt, ist eines der schwierigsten Konzepte in der Computer Science überhaupt. Aber ich denke, Herr Schumann meint mit „semantisch“ das, wofür wir hier in diesem Zusammenhang genauer die Bezeichnung „fach-semantisch“ verwenden sollten.

Wie also ist beispielsweise der Prozess-Abschnitt „konstruiertes Produkt zur FertigstellungFREIGEBEN“, „MitarbeiterEINSTELLEN“ oder aber „SteuerbilanzERSTELLEN“ genauer auszumodellieren, damit entschieden werden kann, welchen Teil des Prozesses ein Enterprise Service und welchen Teil weiterhin ein Mitarbeiter ausführen müsste?

Die Betriebssystem-Leute – wobei es bei uns natürlich um Arbeitsprozesse geht – werden sagen: „I need requirements to provide runnability“. Requirements (Erfordernisse) könnten wir mit „Betriebsmitteln“ im weitesten Sinne übersetzen, zu denen dann organisationstheoretisch auch Mitarbeiter gehören. Und diese Betriebsmittel gilt es auszumodellieren, um den Prozessen ihre Runnability zu verschaffen. Dazu müssen dann Methoden zur Aufgabenmodellierung wie beispielsweise Use Case Diagramme sowie Methoden zur Arbeitsprozessmodellierung wie beispielsweise BPMN-Diagramme zum Einsatz kommen. Mein Eindruck ist hier der, dass noch zahlreiche weitere Gegenstände einer Ablauf- und Aufbauorganisation wie z.B. Arbeitspläne oder Stellenbeschreibungen als „Betriebsmittel“ auszumodellieren wären, um zu einer „tatsächlichen“ Runnability zu gelangen.

Auf den ersten Teil der Aussage von Herrn Schumann würde ich übrigens – zugegeben ein wenig polemisch und mit Augenzwinkern – folgende Frage erwidern: Wenn die SAP über prozess-zentrische Vorgehensmodelle zur Einführung von SOA verfügt, wozu brauchen wir dann noch Firmen, wie beispielsweise die IDS Scheer?

Ihre Meinung ist gefragt: Wie sehen hier Sie die Situation auf der Seite der passenden Methodologien und welche Antwort haben Sie auf die Frage, was in fachsemantischer Hinsicht bei unserem Umgang mit den Arbeitsprozessen des Anwenders zur Erreichung ihrer hohen „Runnability“ modellierungsseitig getan werden müsste?

Warum sind die Daten das ungeliebte Kind und was bedeutet dies für den Nutzen, den man sich von BPM und SOA erhofft?

Viele der Dinge, die heute in den Fachbereichen und auch der IT gemacht werden und dazu zähle ich BPM und SOA zielen doch darauf ab, schneller, bessere Daten zu erhalten. Diese Daten werden dann genutzt um ebenfalls schnellere, bessere Entscheidungen zu treffen und somit ggf. einen wirtschaftlichen Vorteil zu schaffen.

Was sind bessere Daten

Bessere Daten sind Daten, die zur richtigen Zeit, an den richtigen Ort in der richtigen Qualität geliefert werden und damit dann auch zu besseren Entscheidungen führen können. Das können hierbei sowohl strukturierte als auch und in steigendem Maße semi-strukturierte oder unstrukturierte Daten sein, welche aus den unterschiedlichen Quellen stammen. Das bedeutet an dieser Stelle aber auch, bislang nicht erschlossene Datenquellen – neue Quellen, Quellen, die bislang keinen Zugang ermöglichten oder die unbekannt waren mit einbeziehen zu können.

Was bedeutet dies für meine SOA und BPM Überlegungen

Für die SOA und BPM Überlegungen bedeutet dies in erster Linie diesen Aspekt nicht aus den Augen zu lassen und gesamtheitlich mit zu betrachten. Datenservices oder auch Information on Demand sollte so einbezogen sein, dass auch hier die notwendige Dynamik und Agilität abgebildet werden kann. Es sollte zudem klar werden, welches die ‘single version of truth’ meiner Daten darstellt.

Eine Betrachtzung und unter Umständen auch Bereinigung der Daten ist ein wichtiger Schritt hin zu einer effektiven Umsetung einer SOA. Manschmal ist dies sicherlich sogar auch eine notwendige Voraussetzung für eine SOA.

Ein Wort hier zum Schluss zu den Thema Daten und Informationen. Das Entscheidende an den Daten sind nicht nur die Daten selber sondern vielmehr, was man aus diesen Daten macht sprich auch welche Informationen man aus der steigenden Flut an Daten herausziehen kann und somit einen Mehrwert in die Daten auch hineinlegen kann.

Neben Daten und Informationen nehmen auch Ereignisse eine gesteigerte Bedeutung in dieser Betrachtung, aber auch insgesamt bei BPM und SOA ein. Dazu aber mehr in einem späteren Artikel.

Gerade dieses Interagieren der in vielen Unternehmen organisatorisch oft getrennt aufgestellten Domänen ist es jedoch, das nicht wenigen Konzernen in der Umsetzung Service orientierter Architekturkonzepte so seine Schwierigkeiten bereitet.

Dass das sogenannte „Business-IT-Alignment“ einen wesentlichen Erfolgsfaktor auf dem Weg hin zu einer effizienten Kommunikations-infrastrukturimplementierung darstellt, wird in Fachartikeln und Podiumsdiskussionen sowie Fachforen so häufig propagiert, wie es an Umsetzungspfaden zu dessen Erreichung mangelt. Überraschen kann dies indes nicht, ist doch die Verschaltung zwischen Geschäftsprozess und der als dessen Umsetzungswerkzeug agierenden IT einer der sensibelsten weil „menschlichsten“ Entwicklungsvorgänge, der zudem von Unternehmen zu Unternehmen individuell divergiert.

Inwieweit vor diesem Hintergrund „Studien“, wie jener des Unternehmens Amberpoint, nach der rund 60% der in einer Erhebung befragten CIOs im Rahmen der Einführung Service orientierter Architekturen bereits heute „die meisten ihrer Projekt-Ziele erreicht“ haben, Glauben geschenkt werden darf, bleibt der individuellen Interpretation der hier zugrunde gelegten (Projekt-)Zieldefinition durch jeden Einzelnen überlassen. So lassen nicht zuletzt die fortwährend intensiv geführte Diskussion des Themas sowie die stetig wachsenden IT-Budgets der Unternehmen für Beratung, Konzeption und Implementierung Service-orientierter Architekturen Zweifel aufkommen, ob die erhoffte Weiterentwicklung hin zum „agilen, den Anforderungen der Zukunft gewachsenen Konzern“ tatsächlich erreicht werden konnte.

Sollen auf ganzer Linie die heutzutage das Konzept nahezu ausnahmslos positiv besetzenden Potenziale einer SOA, wie Wiederverwendbarkeit von Diensten, agile, an wandelnde Umweltgegebenheiten sich flexibel anpassende Geschäftsprozesse oder, dadurch bedingt, durchschlagende Kosteneinsparungspotenziale gehoben werden, müssen Unternehmen eine ganze Reihe technischer wie auch organisatorischer und politischer Hürden nehmen. SOA wird zur Change-Management- und Organisationsaufgabe.

Und so lautet die Frage in Zukunft nicht mehr nur, wie eine Service orientierte Architektur zu implementieren ist, sondern auch bzw. vielmehr, wie eine Organisation geschaffen werden kann, welche die effektive Implementierung einer SOA überhaupt zulässt. Bleibt die Beantwortung letzterer Fragestellung jedoch weiterhin unbeantwortet weil unbeachtet, sind suboptimale Projektergebnisse, die am Ende jenen inzwischen gerade deshalb vermehrt laut werdenden Stimmen Nahrung geben, welche SOA als „anbieterorientierte Marketing-Strategie“  oder gar „Geldverschwendung“ verschreien, unvermeidliche Konsequenz.

IT- und Organisationsorchestrierung

Wirft man einen Blick in die Literatur, stellen Serviceorchestrierung und -choreographie zentrale Begrifflichkeiten im Hinblick auf die Philosophie der Prozesssteuerungswahl innerhalb des Themenfeldes Service orientierter Architekturen dar. Dass diese „(Neu)-Orchestrierung“ – oder allgemeiner, dieses neue Zusammenspiel – aller IT-bezogenen Instrumente eines Unternehmens auch ein neues Zusammenspiel der Organisationseinheiten eines Unternehmens, mit all den in ihnen verankerten Kompetenzen und somit nicht zuletzt eine neue Definition der Unternehmenspolitik notwendig macht, wird bislang oft außer Acht gelassen. Wird der konzeptionelle Ansatz einer SOA in Projekten, welche maßgeblich in die vitalen Geschäftsprozesse eines Konzerns eingreifen (und eben nicht irgendwelchen Mickey Mouse Projekten) zur Anwendung gebracht, kommt es zwangsläufig zu weit reichenden, durch eben jenen Verantwortungstransfer induzierten Machtverschiebungen innerhalb des Unternehmens, gegen die sich die vermeintlich unterlegene Partei, bei Wahrnehmung des Machtverlustes, mit den bekannten Mitteln zur Wehr setzen wird.

Dass auch bei zur Zusammenarbeit (zunächst) gewilltem Personal indes im operativen „Doing“ der mit der SOA-Konzeptumsetzung notwendigerweise einhergehenden Geschäftsprozessimplementierung in manchen Fällen Frustration aufkommt, liegt neben unklaren Projektzieldefinitionen oder auch in Einzelfällen nicht optimal ausgebildetem Personal, an in der Persönlichkeit begründeten Charakteristika von Denk- und Handlungsstrukturen der sich bewusst für unterschiedliche Berufsbilder entschieden habenden Charaktere, wie auch nicht selten orthogonal zueinander stehenden Ziel- und Anreizsystemen der betroffenen Fachbereiche.

So ist einerseits zu konstatieren, dass Menschen, die sich für unterschiedliche Berufsbilder entschieden haben – und kaufmännische und technische Stellenprofile divergieren inhaltlich doch deutlich voneinander – unterschiedlich sozialisiert und ausgebildet sind, andere Wertesysteme haben, gar in verschiedenen Wahrnehmungs- und Sprachwelten leben. Und so nähern sich „Process Engineer“ und Systemarchitekt – um nur zwei Stellenprofile prototypisch für beide Lager herauszustellen – Problemen ebenso unterschiedlich wie sie Begrifflichkeiten und Sprache divergent verwenden. Missverständnisse und die aufgrund divergierender Zielsysteme logischerweise entstehende Verfolgung individueller (lokaler) Optima sind die Folge. Gesamtoptima aus Unternehmenssicht können oder sollen nicht verfolgt werden.

Einen sinnvollen, wenn auch – vielleicht durchaus bewusst – inhaltlich sehr eng gefassten Lösungsansatz zu Annäherung beider Welten liefern Vollmar et al.  in ihrem Beitrag zur Governance-Umsetzung, welcher auf der herstellerübergreifenden Informationsplattform der Bitkom soa-know-how.de publiziert wurde. Sie propagieren mit der Etablierung eines „SOA Centers of Excellence“ die Schaffung eines bereichsübergreifenden Gremiums, „welches aus Mitgliedern der Fachbereiche und der IT auf unterschiedlichen Hierarchiestufen zusammengesetzt ist“ und dessen Aufgabe in der Unterstützung von Projekten, dem Durchführen von Architektur-Reviews oder dem Sammeln und Verwalten von Services und deren Metadaten liegt.

Im Gegensatz zu der von vorgenannten Autoren vertretenen Lösung zur Überwindung des „IT-Business Gaps“ sollte die Zusammensetzung dieses Gremiums indes nicht temporärer Natur sein, da sich Zielsystem und kulturell-soziologischer Hintergrund der in diesem vereinigten Individuen nicht innerhalb von Tagen – quasi per Dekret – nachhaltig im Sinne eines für (zumindest größere) SOA-Projekte erforderlichen ganzheitlichen Denkens und Handelns ändern lässt. Mehr noch: Das geschaffene Gremium benötigt einen Moderator zwischen IT und (i.d.R. kaufmännischen) Fachbereichen, der über weit reichende Entscheidungs- und Fachkompetenzen verfügt. Gerade letzteres ist in aller Regel sehr branchenbezogen, da Prozess Know-how, und über dies muss die Instanz zwingend verfügen, nicht nur in methodologischen Aspekten, sondern, zwecks Sicherstellung der Akzeptanz im Unternehmen und Projektzielführungskompetenz, vor allem auch in fachlichen Fragen unabdingbar ist. Letztlich sind die Aufgaben der Moderatorenfunktion vielfältig und reichen so von der zentralen Kommunikationssteuerung über das Prozess-Effizienzmonitoring bis hin zu Übersetzerfunktionen zwischen den unterschiedlichen Sprach- und Begriffswelten und dem hiermit oft verbundenen Konfliktmanagement.

Nur als eigenständige Instanz mit Weisungsbefugnis gegenüber Drittparteien ausgestattet, durch ein starkes Management etabliert und mit außergewöhnlichen kommunikativen Fähigkeiten ausgestattet, lässt sich die zweifelsfrei ebenso außergewöhnliche Herausforderung bewältigen. Vor allem aber bedarf es, wie bereits zuvor angedeutet, eines konsequenten und gut strukturierten Entwicklungsprozesses, Mitarbeiter in jene Position zu entwickeln. Diese Voraussetzung indes zu schaffen, ist Aufgabe des Top-Managements, welches wiederum professionell diesen organisatorisch sehr weit reichenden Wandel zu managen in der Lage sein muss.

SOA heißt daher weniger Tooldenken, weniger Top-Down oder Bottom-Up und ganz sicher zwecks Erzielung gesamtunternehmerischer Optima und Prozess- wie Systemkomplexitätsbeherrschung ein Aufeinanderzubewegen von Business und IT, das jedoch weiter greift, als manchem heute bewusst sein mag. SOA findet nicht per Erlass statt, es ist vielmehr „orchestrierter Entwicklungsprozess“ denn Projekt. Dann und nur dann wird unser Ansicht nach SOA sich auch rechnen.

Bernhard Balkenhol
Oliver Simon
Axel Wiemann
Infinity³

Flexibilität und Transparenz sind ausschlaggebende Faktoren für den Geschäftserfolg. Firmen brauchen Einblick in ihre Geschäftsabläufe, um zu verstehen, welche Änderungen in ihren Geschäftsprozessen erforderlich sind, und sie müssen flexibel sein, um schnell entscheiden und reagieren zu können.

Viele Unternehmen sind überzeugt, dass SOA wichtig für BI ist und planen, BI-Services in der nächsten Zeit in allen Geschäftsbereichen zu implementieren. Tatsächlich glauben viele, dass SOA zu einem gewissen Grad für BI von Bedeutung sei und die meisten gehen davon aus, dass alle Geschäftsbereiche von BI-Services profitieren können.

Es ist an der Zeit, den geschäftlichen Nutzen von BI und SOA nicht nur zu erkennen, sondern auch den Synergieeffekt zwischen den beiden Ansätzen zu verstehen und sie als Schlüsselkomponenten moderner IT-Architekturen zu begreifen. Daher ist es für Unternehmen von wesentlicher Bedeutung, sowohl eine BI- als auch eine SOA-Strategie zu entwickeln und dafür zu sorgen, dass jede Strategie eine zentrale Komponente der anderen ist. Dies ermöglicht die schnelle Anpassung von Geschäftsprozessen an plötzliche Veränderungen des Marktes und stellt gleichzeitig sicher, dass die Kundenanforderungen erfüllt werden.

Wie kommen BI und SOA in die Chefetagen?

Was also erwarten Geschäftsführer und Vorstände von der IT und was sind ihre Prioritäten? Zentrale Ziele sind dabei, Einblick in Geschäftsprozesse zu vermitteln, Wachstum und Wandel zu unterstützen, die Einhaltung gesetzlicher Bestimmungen und interner Vorgaben zu gewährleisten sowie Risiken zu minimieren. Dazu benötigen die Entscheidungsträger schnellen Zugang zu hochwertigen und verlässlichen Informationen über die operative und finanzielle Leistungsfähigkeit ihrer Unternehmen.

Unternehmen müssen in der Lage sein, sich auf Veränderungen einzustellen – zum Beispiel nach einer Übernahme oder bei schnellem Wachstum – und dazu brauchen sie die richtigen IT-Systeme. Geschäftsprozesse müssen sich schnell und effizient integrieren und ändern lassen, wobei die IT-Architektur flexibel bleiben muss. Wie schnell sich Geschäftsprozesse anpassen lassen, hat einen direkten Einfluss darauf, wie effizient neue Produkte und Dienstleistungen auf den Markt gebracht werden können.

Der Einsatz der richtigen BI-Infrastruktur spielt zudem eine wichtige Rolle bei der Einhaltung interner Richtlinien und gesetzlicher Bestimmungen. Dieses Anliegen haben sowohl Führungskräfte, die Risiken besser verwalten möchten, als auch Finanzmanager, die für die Konformität mit gesetzlichen Vorgaben verantwortlich sind, und IT-Leiter, die gleichzeitig Projektanforderungen aus den Bereichen Governance, Risikokontrolle und Compliance managen müssen.

Um all diesen Zielen gerecht zu werden, brauchen Unternehmen eine Technologie, die Geschäftsdaten allen Unternehmensbereichen umfassend zugänglich macht. BI liefert die Erkenntnisse, die man braucht, um zu entscheiden, welche Veränderungen an den Geschäftsprozessen vorgenommen werden müssen. SOA versetzt die Firmen dann in die Lage, ihre Abläufe anzupassen, den Wert der bestehenden Systeme und IT-Infrastruktur zu maximieren sowie die Komplexität und die Kosten zu reduzieren. Für eine “Best-of-Breed”-Lösung beider Welten muss man jedoch BI und SOA miteinander kombinieren.

Die Vorteile erkennen

BI ist nicht mehr nur ein Analysewerkzeug für Spezialisten oder eine Möglichkeit, um Berichte aus historischen Informationen zu generieren, sondern entwickelt sich immer mehr zu einem nahtlos integrierten Bestandteil von Geschäftsprozessen. Durch diese tiefere Integration ermöglicht BI schließlich die effizientere Nutzung von Prozessen über alle Abteilungen hinweg. Eine integrierte BI- und SOA-Strategie hilft Unternehmen, den Geschäftswert ihrer Technologien zu optimieren.

SOA ermöglicht Unternehmen zwar flexible Geschäftsprozesse und die schnelle Anpassung an veränderte Marktbedingungen. Voraussetzung dafür ist jedoch die Kenntnis der Auswirkungen, die diese Prozesse auf die geschäftliche Leistungsfähigkeit haben. Deshalb brauchen Unternehmen ein BI-System, das einen vollständigen, einheitlichen und funktionsübergreifenden Überblick über alle Geschäftsdaten liefert. Die Kenntnis dieser Daten ist immer Grundlage guter Entscheidungen, egal ob sie Kunden, Lieferanten oder interne Abläufe betreffen.

Fokus Integration

Für Unternehmen, die ihre Geschäftsprozesse optimieren möchten, ist die Integration von BI in die Geschäftsabläufe eines der Hauptziele. Dazu muss BPM-Software (Business Process Management) in die bestehenden Anwendungen und Systeme integriert werden. Diese Herausforderung hat zusammen mit den Anforderungen an die Verwaltung komplexer heterogener Softwareumgebungen zu einer deutlichen Steigerung des Einsatzes von SOA geführt.
Bei der Integration von BI und SOA muss mit großer Sorgfalt vorgegangen werden, um sicher zu stellen, dass bei geschäftskritischen Prozessen eine angemessene Servicequalität gewährleistet wird und die Daten den entsprechenden Zuverlässigkeitsgrad aufweisen. Zudem muss die Geschäftsprozessarchitektur leicht anzupassen und zu pflegen sein.

Überblick und Transparenz

Was können integrierte BI- und SOA-Lösungen in Unternehmen bewirken? Zum Einen können Firmen damit Geschäftsaktivitäten in Echtzeit verfolgen, die Bedeutung dieser Prozesse für die Unternehmens-Performance verstehen sowie erkennen, welche Änderungen innerhalb der Geschäftsabläufe erforderlich sind. Zum Anderen haben die Anwender auf Grund der Informationen, die sie über Dashboards, Berichte und Warnmeldungen erhalten, die Möglichkeit, entsprechend zu reagieren. Wenn zum Beispiel die Warnung eingeht, dass ein Produkt nicht fristgerecht geliefert wird, können die bestehenden Abläufe geändert werden, um dieses Problem zu beheben.

Fazit

Genaue Kenntnis der Geschäftsabläufe in allen Bereichen ist überlebenswichtig für jedes Unternehmen. Nur so können die Verantwortlichen erkennen, welche Änderungen in Geschäftsabläufen vorgenommen werden müssen. SOA versetzt sie dann in die Lage, auf solche Veränderungen zu reagieren. Wenn in der SOA erst einmal die relevanten Daten hinterlegt sind, können sich Unternehmen schneller als je zuvor auf Veränderungen einstellen. Der Synergieeffekt zwischen BI und SOA ist nicht zu verleugnen. Es liegt in der Hand der Unternehmen, sich diese Vorteile zunutze zu machen.

Fachwissen zum Auftakt

Eröffnet wurde das Programm vom gfo-Vorstand Prof. Dr.-Ing. Hartmut F. Binner, der in seiner Keynote das Publikum für den notwendigen Paradigmenwechsel von der Funktions- zur Prozessorientierung sensibilisierte, und auf die besondere Bedeutung von Prozessmanagement-Tools für den entsprechenden Change Management – Prozess hinwies. Im darauffolgenden Vortrag stellte ich selbst als Beirat der gfo die wesentlichen Risiken und Erfolgsfaktoren bei der Auswahl von BPM-Tools vor. Die im Vortrag dargestellte Herausforderung der Software-Auswahl geht auf die besondere Intransparenz des Marktes für derartige Lösungen zurück. Diese Intransparenz ist auch der Anlass für das Projekt „Tool-Cert“ der International Association for BPM (IABPM), das anschließend vom IABPM-Chairman Prof. Dr. Götz Schmidt gemeinsamt mit mir vorgestellt wurde. Zielsetzung dieses Projekts ist die Zertifizierung von BPM-Tools durch die IABPM, um ihre Tauglichkeit für definierte Einsatzszenarien zu prüfen und öffentlich zu bewerten. Solche Szenarien können sich sowohl im organisatorischen Prozessmanagement, wie zum Beispiel der fachlichen Prozessdokumentation, als auch in der Prozessautomatisierung, wie dem Human Workflow Management oder der Service Orchestrierung, abspielen. Anspruch der IABPM ist also, das ganzheitliche, übergreifende Business Process Management auch in Bezug auf die unterstützenden Werkzeuge thematisch aufzugreifen und zu entwickeln.

Präsentation der Lösungen

Nach dieser ersten Aufwärmphase ging es nach einer kurzen Kaffeepause zur Sache: In den drei parallel stattfindenden Tracks

• A: Modellierung, Dokumentation, Analyse, Simulation
• B: Serviceorientierte Architekturen (SOA)
• C: Prozessportale, Human Workflow Management

mussten die Tool-Anbieter zeigen, was sie können. Hier bewiesen erfreulich viele Hersteller den Mut, ihre Lösungen nicht nur auf Powerpoint-Folien konzeptionell zu erklären, sondern öffneten ihre Tools auch live vor den Augen des Publikums und beantworteten somit durch direkte Beispiele die Fragen, die ihnen seitens der gfo im Vorfeld gestellt worden waren. Diese Fragen bezogen sich beispielsweise auf die Sicherstellung der Prozessmodellqualität, die Wege zur Publikation von Prozessmodellen, den praktischen Lösungsansatz zur Einrichtung von Web Services, oder auch die Möglichkeiten zur Konfiguration automatisierter Eskalationsprozesse.

Die verschiedenen Stärken und Schwächen aller gezeigten Tools an dieser Stelle aufzuzählen, würde den Rahmen dieser Nachlese sprengen. Erwähnt werden sollen aber zumindest auszugsweise die höchst interessanten und zum Teil auch sehr unterschiedlichen konzeptionellen Ansätze, die den verschiedenen Lösungen zugrunde liegen. So hat beispielsweise die Firma jCOM1 mit der subjektorientierten Prozessmodellierung schon vor Jahren eine visionäre Methode entwickelt, deren Prinzipien teilweise an die jüngsten akademischen Überlegungen zur Prozess- und Service-Choreographie erinnern. Die Firma imatics konnte ein sehr schlankes und im unteren Preissegment befindliches Tool für Human Workflow Management präsentieren, während die Firmen SunGard und Oracle (letztere mit vertreten durch Opitz Consulting) äußerst mächtige und im internationalen Umfeld erprobte Werkzeuge zum Aufbau serviceorientierter Architekturen (SOA) vorstellten. Das hierzulande noch wenig bekannte, im Ausland dafür weit verbreitete Tool intalio des gleichnamigen Herstellers ist auch Open Source verfügbar und repräsentiert BPEL Code in BPMN. Mit AENEIS von intellior lassen sich in kurzer Zeit grafisch ansprechende, BPMN-konforme und konsistente Prozessmodelle erstellen, während ADONIS von der Firma BOC dank eines ausgefeilten Metamodellierungskonzepts durch besondere Flexibilität bei der Abbildung betriebli-cher Abläufe glänzte. Die Firma inubit war gleich in allen drei Tracks vertreten und unterstrich damit ihren Anspruch, BPM über alle Phasen des Lebenszyklus durchgängig zu unterstützen. Ibo Prometheus beeindruckte durch umfangreiche Möglichkeiten zur Analyse und Simulation von Prozessen, während die Firma Arcway besonders das prozessorientierte IT – Requirements Engineering unterstützte. Die Firma Cordys begeisterte im SOA Track dank einer gelungenen, plastischen Live Demonstration zur Einrichtung von Web Services und Human Tasks das Publikum, und die Firma Soreco punktete mit einem konsequenten „Bottom-Up“-Ansatz zur Erzielung handfester Vorteile durch Human Workflow Management. Das BPM-Werkzeug COVUM Processor konnte eine im Bereich der Prozessautomatisierung selten anzutreffende Benutzerfreundlichkeit unter Beweis stellen, und die Firma binner IMS zeigte mit ihrer integrierten Lösung sycat in Track A und Track C, wie Prozesse sowohl organisatorisch erfolgreich dokumentiert und optimiert, als auch mittels Human Workflow Management effizient umgesetzt werden.

Die insgesamt 18 parallel stattfindenden Vorträge wurden nur von einem reichhaltigen Mittagsbuffet unterbrochen, das die Teilnehmer ausführlich zum Austausch über die erhaltenen Informationen und für das Networking nutzten. Die Kaffeepause am Nachmittag war dann vor allem von weiterführenden Gesprächen der Teilnehmer mit den ausstellenden Tool-Anbietern geprägt, denn die informativen Präsentationen hatten bei den Zuhörern natürlich viel Interesse und weitere Fragen erzeugt.

Verleihung des Process Solution Award

Den Höhepunkt der Veranstaltung bildete die Verleihung des Process Solution Award, den die gfo in diesem Jahr erstmalig zu vergeben hatte. Diese Auszeichnung würdigt besonders innovative und mustergültige BPM-Projekte. Die Kandidaten mussten zu diesem Zweck bereits Monate vor der Veranstaltung die entsprechenden Projektberichte einreichen, die dann von einer qualifizierten, neutralen Jury bewertet wurden. Diese bestand aus Prof. Dr. Thomas Pietsch (Vorsitzender), Dr. Rudolf Hoyer, Dr. Kai Krings und Ullrich Nawrath. Prof. Dr. Pietsch spannte das Publikum nicht lange auf die Folter, sondern verkündete nach einer kurzen Erklärung des Bewertungsverfahrens die drei bestplatzierten Projekte. Der erste Platz ging an die Firmen AUDI und jCOM1 für das Projekt „AUDI Prozessportal“, den zweiten Platz erhielten Degussa und SunGard für das Projekt „OpenServe“, und den dritten Platz belegten die Firmen Blechwarenfabrik Limburg und binner IMS für das Projekt „Einführung sycat DokWeb“. Alle drei Gewinner stellten ihre Projekte dem interessierten Publikum vor und nahmen anschließend die Urkunden und Gratulationen entgegen.

Im nachfolgenden Fazit bedankte sich Prof. Dr.-Ing. Binner bei all jenen, die zum Erfolg des 3. Process Solutions Day beigetragen hatten, insbesondere bei den Track-Moderatoren Bernd Rücker, Thomas C. Grempe und Dr. Kai Krings, und stellte abschließend heraus, dass auch ein BPM-Tool immer nur Mittel zum Zweck sein kann, während die Organisation die alles umschließende Klammer einer jeden Prozessverbesserung ist.

Sind jedoch auch die Prozesse selbst das Ziel, dann müssen erheblich weiterführende Überlegungen angestellt werden. Oft kommt so die gesamte Anwendungslandschaft auf den Prüfstein, ebenso das Datenmodell. Also Kernelemente der IT Unternehmensarchitektur, womit wir über BPM beim Thema Enterprise Architecture Management angekommen sind. Die SOA wird Mittel zum Zweck, nur eine – zwar wichtige – Methode unter anderen. Sind bei einer technisch orientierten SOA die Varianten zur Gestaltung noch prinzipiell einfach, geraten BPM Lösungen selten ähnlich. Sicher gibt es auch für einen BPM Ansatz grundlegende Muster und “best practices”. Die hohen Freiheitsgrade, die ja in der Regel auch das Ziel der Nutzung von BPM Werkzeugen sind, erlauben sehr unterschiedliche Lösungen für nach außen hin ähnliche Aufgabenstellungen. Das Optimum zwischen Aufwand und Nutzen zu finden ist von erheblich mehr Faktoren abhängig, deren Ursprung auch nicht mehr primär in der IT Technik begründet ist. Kritischer Erfolgsfaktor für eine SOA basierte BPM Einführung ist also – deutlich stärker als bei einer technischen SOA – die enge, partnerschaftliche Zusammenarbeit zwischen IT und Fachseiten. Um dies erfolgreich zu etablieren muss vor allem in den Nahtstellen zwischen Fachseiten und IT umgedacht werden. Denn die Flexibilität einer SOA basierten BPM ist das Ergebnis einer durchdachten und diszipliniert umgesetzten Gesamtarchitektur und entsteht nicht durch Hau-Ruck Aktionismus. Das bedeutet, das IT Projekte nicht länger isoliert durchgeführt und allein durch den kurzfristigen Nutzen getrieben werden dürfen, sondern sich deutlich mehr auf die Bereitstellung von Infrastruktur und wieder verwendbare Funktionalität konzentrieren müssen. Schritt für Schritt entsteht so eine IT, die kurzfristige Anforderungen primär durch Konfiguration wieder verwendbarer Services bereitstellt und gleichzeitig in Zusammenarbeit mit den Fachseiten die strategische Ausrichtung des Unternehmens mitgestaltet und vorausschauend in klar geschnittene Funktionsblöcke der Anwendungslandschaft übersetzt. Eine starke und konsistente Governance der IT in den Dimensionen Budget, Portfolio, Standards und Ressourcen ist hierzu ebenso unverzichtbar wie ein konsequent ausgerichtetes Management der gesamten Architektur. Daraus darf aber kein schwerfälliger Wasserkopf entstehen, sondern ein pragmatischer und nutzenorientierter Partner der Fachseiten und der umsetzenden Kollegen der IT. Dies, liebe Leserinnen und Leser, ist die eigentliche Königsdisziplin.

]]> http://www.computerwoche.de/soa-expertenrat/2008/06/01/bpm-die-konigsdisziplin-der-serviceorientierung/feed/ 0 http://www.computerwoche.de/soa-expertenrat/2008/05/30/soa-bpm-und-brm-der-dreibeinige-barhocker/ http://www.computerwoche.de/soa-expertenrat/2008/05/30/soa-bpm-und-brm-der-dreibeinige-barhocker/#comments Fri, 30 May 2008 11:37:14 +0000 Peter Kürpick http://www.computerwoche.de/soa-expertenrat/?p=300 Business Process Management (BPM), serviceorientierte Architekturen (SOA) und Business Rules Management (BRM) wachsen immer mehr zusammen. Ein guter Zeitpunkt, in Gedanken einen Schritt zurückzutreten und einen prüfenden Blick auf diese Technologien zu werfen. Was passiert hier gerade? Und warum?

Viele Jahre lang haben Berater und Hersteller den Mythos aufrechterhalten, dass sich Unternehmen zwischen BPM und BRM entscheiden müssen, um flexible und agile Geschäftslösungen zu erstellen. Dieser Mythos war eine Übertreibung. Es stimmt zwar, dass fast jeder BPM-Prozess Regeln verwendet, wenn es um Entscheidungsfindung geht, und dass sich in jedem BRM das Konzept eines Prozesses wiederfindet. Es ist aber nicht wahr, dass diese beiden Technologien austauschbar sind. Vielmehr handelt es sich um zwei Seiten derselben Münze, und die wahre Stärke besteht darin, die Vorteile von beiden Ansätzen zusammenzubringen. Wie also werden die unterschiedlichen Technologien verwendet?

Mit SOA werden vorhandene Geschäftsvorfälle in definierte, wiederverwendbare Services transformiert. Diese definierten Services sind die Bausteine, aus denen BPM-Prozesse erstellt werden. Es ist also ganz einfach: SOA liefert Services, aus denen wiederum BPM-Prozesse hervorgehen. Werden diese Services richtig implementiert, ergibt sich dadurch eine erhebliche Kostensenkung und Reduzierung von Komplexität, denn richtiges Implementieren bedeutet auch, dass Prozesse wiederverwendbar sind. Dieser Ansatz ist flexible und ersetzt das alte Paradigma des Schreibens von statischem Programmcode. Erst BPM und SOA-basierte Infrastrukturen ermöglichen diese Wende hin zu mehr Agilität und führen zu der Notwendigkeit, BRM-Technologien einzusetzen.

Wenn Unternehmen mehr Agilität für ihre Prozesse fordern, müssen sie versuchen, jedes „volatile“ – also verfügbare und passende – Prozessteil zu externalisieren. Im BPM/SOA-Kontext manifestiert sich diese Externalisierung in Form von Services. Kandidaten für diese Externalisierung ist Geschäftslogik, die ebenfalls  „volatil“ ist. Diese Geschäftslogik kann in Form von Geschäftsregelen festgelegt und damit in einer BRM-Suite dargestellt werden. In traditionellen Anwendungsstrukturen sind diese Geschäftsregeln in der Anwendungslogik vergraben und werden dadurch statisch. Damit ist es sehr schwer, sie zu ändern. Die meisten BPM-Suites erlauben heute dagegen benutzerfreundliche Möglichkeiten, direkt mit den Geschäftsregeln zu interagieren und sie ohne Programmieraufwand zu verändern. Das trägt natürlich enorm zur Flexibilisierung und damit zum Nutzen von Prozessen bei.

Mit SOA lassen sich also wiederverwendbare Geschäfts-Services erstellen, die dann von BPM in einen Prozess verwandelt werden, wobei BRM die Flexibilität für den Prozess beisteuert. Zusammen genommen liefern diese drei Technologien also einen erheblichen Mehrwert: der taktische Kosten/Zeit-Nutzen wird unterstützt durch die Tatsache, dass es sich gleichzeitig um die drei Pfeiler einer wettbewerbsfähigen Wachstumsstrategie handelt. Es ist wie mit einem dreibeinigen Barhocker: Man kann zwar auf einem ein- oder zweibeinigen Barhocker sitzen (indem man sich an der Theke festhält), aber das ist ganz und gar nicht gemütlich. Erst das dritte Bein liefert das gewünschte Ergebnis.  

Die Standardisierung durch die OMG hat dem Thema Prozessmodellierung einen wichtigen Schub gegeben. Eine ähnliche Entwicklung hat vor einigen Jahren im Bereich der objektorientierten Entwicklung stattgefunden. Zwar hatte es bereits zuvor zahlreiche Modellierungstools gegeben, doch erst als mit der Unified Modeling Language (UML) ein Standard für die objektorientierte Modellierung zur Verfügung stand, gewann die Modellierung im Rahmen der Software-Entwicklung einen bedeutenden Platz. Heute unterstützen praktisch alle Software-Modellierungstools die UML, weltweit wird die UML in der Informatiker-Ausbildung gelehrt. Einen ähnliche Entwicklung könnte sich nun im Bereich der Prozessmodellierung abzeichnen, wo bislang viele Unterschiede zwischen den Notationen der diversen Modellierungstools herrschten. Bislang gibt es schon weit über 40 Tools, die die BPMN unterstützen.

Im Moment gibt es noch viele Baustellen im Bereich der BPMN, unter anderem das Fehlen eines standardisierten Austauschformats sowie die mangelnde Integration mit anderen im Rahmen eines Prozesses zu berücksichtigenden Aspekten, wie z. B. Datenstrukturen sowie Rollen- und Organisationsmodellen. Auch fehlen anerkannte Anwendungs- und Strukturierungshinweise für eine sinnvolle BPMN-Modellierung auf fachlicher Ebene, so dass jedes Unternehmen seine eigenen Konventionen entwickeln muss. Dies erschwert natürlich den Übergang von fachlichen zu ausführbaren BPMN-Modellen. Doch ist zumindest eine Grundlage geschaffen, so dass diese Fragestellungen auf der Basis einer gemeinsamen Notation gelöst und somit leichter weiter verbreitet werden können.

Im Blog “Kurze Prozesse” wurden jüngst einige BPMN-Modellierer zu der noch recht jungen Notation befragt. Eingesetzt wurde die BPMN vor allem für die Kommunikation zwischen Fachabteilung und IT im Vorfeld oder während der Entwicklung von ausführbaren Workflows, z. T. auch für die rein fachliche Modellierung. Über die Eignung für die rein fachliche Modellierung gehen die Meinungen allerdings auseinander. Als wesentlicher Vorteil wurde vor allem die leichte Verständlichkeit genannt, wobei die Bedeutung der Konstrukte zugleich präzise definiert ist. Auf der anderen Seite gibt es eine Reihe von Konstrukten, die eher selten genutzt werden und vor allem den Anfänger eher verwirren.

Als Nachteile wurden neben der fehlenden Integration mit anderen Modellierungsmethoden und dem fehlenden Austauschformat die z. T. schwierige Überführung in andere, ausführbare Prozessbeschreibungen (z. B. BPEL oder XPDL) genannt. Vermisst werden außerdem ein Metamodell sowie gute Beispielmodelle. Das Erlernen der BPMN gestaltet sich momentan noch etwas schwierig. Es gibt einige nützliche Webseiten. Das Kursangebot ist bislang noch recht übersichtlich, gute Literatur fehlt noch gänzlich. Immerhin: An der FHS St. Gallen wird die BPMN bereits in einer Vorlesung gelehrt.

Mit Business Process Analysis (BPA) wird die Lücke zwischen ausführbaren technischen und allgemeinen fachlichen Geschäftsprozessen geschlossen. BPA verbindet BPM und SOA zu einem funktionierend Ganzen und erlaubt eine durchgängige Spezifikation, Bereitstellung, Analyse und Kontrolle von Geschäftsprozessen.

Business Process Management

“Das Geld steckt in den Prozessen”. Diese von Dr. Wolfgang Martin an der Cebit im letzten Jahr formulierte Aussage bringt auf den Punkt, was viele Unternehmen versuchen; durch die Verbesserung der Geschäftsabläufe soll die Effizienz der Unternehmenstätigkeit gesteigert werden. Gemäss einer Studie von IBM hängt die Performance eines Unternehmens stark von seiner Innovationsfähigkeit in den Betriebsabläufen ab. In den letzten Jahren hat sich BPM als wichtigstes Instrument zur Verbesserung dieser Betriebsabläufe entwickelt. “BPM erlaubt die Spezifikation, Bereitstellung, Analyse und Kontrolle der operativen Geschäftsprozesse durch Methoden, Werkzeuge und Technologien.” Diese Definition stammt aus der sehr empfehlenswerten Broschüre “BPM Basics for Dummies”. Das wichtigste Element von BPM ist der Prozess als “Bündel von Aktivitäten die einem Wertbeitrag für den Kunden leisten” (Hammer und Champy 1995). Das wichtigste Werkzeug ist die Modellierung dieser Geschäftsprozesse. Seit vielen Jahren sind verschiedene Techniken zur Modellierung von Prozessen bekannt und im Einsatz. Prozesse werden mit geeigneten graphischen Werkzeugen modelliert und eventuell simuliert.

Fachliche Prozessmodellierung

BPM kann als unternehmensweite und integrierte Managementaufgabe zur ergebnis-orientierten Steuerung von Prozessen verstanden werden. Getreu dem Grundsatz, dass nichts gesteuert werden kann, was nicht gemessen werden kann, setzt BPM eine Erfassung aller Leistungs-, Unterstützungs- und Führungsprozesse voraus. Gemäss dem Kompetenzzentrum für Prozessmanagement Deutschland können 80% aller Unternehmenstätigkeiten als standardisierte und wiederholbare Abläufe in einem Modell beschrieben werden. Diese Beschreibung bestehender oder neuer Geschäftsabläufe wird auch fachliche Prozessmodellierung genannt. In grösseren Unternehmen wird diese Tätigkeit sehr oft Business Engineering genannt und ist neben der Informationsarchitektur ein Bestandteil der Enterprise Architecture Management Tätigkeit. Die Darstellung der Geschäftsprozesse umfasst eine Beschreibung allgemeiner betrieblicher Leistungen, die durch verschiedene Unternehmensressourcen erbracht werden.

SOA

“Das Geld wird in der IT sinnlos ausgegeben”. Die Antwort auf die Aussage von Nicholas Carr in seinem Artikel “IT doesn’t matter” ist SOA, da diese Architektur durch Standardisierung, Kostenersparnis und verbesserte Flexibilität den Nutzer der IT für ein Unternehmen nachhaltig verbessert. SOA ist die erste Standardarchitektur überhaupt, welche bestehende Systeme als integralen Bestandteil eines neuen Systems betrachtet. Die Grundidee hinter “Dienste statt Applikationen” ist die Weiterverwendung ganzer Systeme und die Kombination bestehender Systeme zu einem funktional erweiterten, neuen Gesamtsystem. Erreicht wird dies durch die Kapselung ganzer Systeme durch definierte Service-Schnittstellen. Diese Weiterverwendung hat einen grossen Einfluss auf die Kosten eines Systems. Werden bestehende Anwendungen teilweise oder ganz weiterverwendet, statt Systeme als Ganzes neu zu bauen, sind erhebliche Einsparungen realisierbar. Die Flexibilisierung einer Anwendung durch die Trennung der Business-Logik in statische und dynamische Bereiche ist eine weitere Stärke von SOA. Der statische Bereich der Business-Logik wird als Service realisiert, der dynamische Bereich wird getrennt davon als Prozess oder als Regel modelliert, generiert und ausgeführt. Eine Anwendung wird zur Sequenz von einzelnen Prozessschritten. Jeder Schritt stellt einen Service dar. Die Sequenz selbst wird als ausführbarer Prozess oder auch Workflow graphisch modelliert und zur Laufzeit ausgeführt. Ändert sich nun ein Ablauf, so muss lediglich der entsprechend modellierte Prozess nachgeführt werden. Die neuen Prozessinformationen werden geladen und die Änderung ist durchgeführt. Auf SOA basierende Systeme sind änderungsfreundlicher und damit wesentlich flexibler als mit Andwendungen, die mit konventionellen Mitteln umgesetzt werden.

Technische Prozessmodellierung

SOA stellt Standards und Technologien zur Verfügung, die eine direkte Umsetzung von graphisch modellierten Prozessen in ausführbaren Code erlauben. Die Definition der ausführbaren Prozesse wird auch technische Prozessmodellierung genannt. BPEL (Business Process Execution Language) oder auch WSBPEL für Web Services ist der wichtigste Standard für die technische Prozessmodellierung im Rahmen einer SOA. Mit BPEL lässt sich ein Prozess beschreiben und abbilden. Diese Beschreibung erfolgt graphisch mittels eines BPEL Editors. Im Unterschied zu den anderen Techniken kann aus dem modellierten Geschäftsprozess direkt die Steuerung der Workflow Engine (BPEL Engine) erzeugt werden. Mittels BPEL lassen sich verschiedene Dienste zu einer Gesamtanwendung verknüpfen. Ein BPEL-Prozess besteht aus einem Prozess-Interface und einem Prozess-Schema. Das Prozess-Interface ist in WSDL formuliert, da jeder BPEL-Prozess selbst einen Web Service darstellt. Das Prozess-Schema definiert den eigentlichen Prozessablauf (Actions), die Art und Weise der Instanziierung (Correlation Sets), die involvierten Partner (Partner Link) und die Mechanismen der Fehlerbehandlung (Fault Manager).

Die Grenzen von BPM

Ohne BPM ergibt SOA keinen Sinn, behauptete Sven Schnägelberger vom Kompetenzzentrum für Prozessmanagement an der letzten Cebit Podiumsdiskussion. Und viele Hersteller betrachten SOA als das Instrument zur Umsetzung von BPM in einem Unternehmen. Nur leider ist die Betrachtungsweise des Prozesses durch BPM und SOA nicht ganz dieselbe. Während BPM von einer allgemeinen betrieblichen Tätigkeit ausgeht, versteht eine SOA den Prozess als ausführbaren Prozess oder auch als Workflow. Die Granularität ist nicht dieselbe. BPM kann mit einer Prozessdokumentation leben, die nicht alle Details eines Geschäftsablaufes erfasst. Eine SOA kann das nicht, da die Prozessbeschreibung gleichzeitig die Instruktionen zur Steuerung eines oder mehrerer Informationssysteme umfasst. Die technischen Details sind für einen Business Engineer, die fachliche Prozesse betreut, nicht relevant. Die fachlichen Aspekte sind für den Process Designer, der die technischen Prozesse betreut, nur ein allgemeiner Rahmen. Die Konsequenz ist ein Nebeneinander von fachlich und technisch spezifizierten Prozessen.

BPA als verbindendes Element

Der ausführbare Prozess ist jedoch immer ein integraler Bestandteil eines fachlichen Prozesses. Er kann in gewissem Sinne als Verfeinerung einer fachlichen Spezifikation angesehen werden. Genau da setzt Business Process Analysis (BPA) an. BPA verbindet BPM und SOA durch die Kombination fachlicher und technischer Prozessmodelle. Unter dem Begriff “Round Trip Engineering” wird die Integration von fachlichen Prozessmodellen (BPM) und ausführbaren Prozessen (SOA – BPEL) zusammengefasst. Dies bedeutet, dass ein fachliches Prozessmodell mit relativ grober Granularität in ein verfeinertes IT Prozessmodell überführt werden kann. Konkret heisst das, dass die Fachseite ihre Prozesse modelliert und dokumentiert. Sind diese Prozesse aus fachlicher Sicht vollständig, so werden sie durch die IT verfeinert, um die Steuerung betrieblicher Informationssysteme zu erlauben. Diese Verfeinerung bringt in vielen Fällen eine Änderung der fachlichen Prozesse mit sich. Aus diesem Grund müssen die durch die IT verfeinerten und damit ausführbaren Prozesse wieder in ein fachliches Prozessmodell zurückgeführt werden, damit die Fachseite den Prozess nachführen oder prüfen kann. Änderungen oder Optimierungen von Prozessen können nun auf Initiative der Fachabteilungen oder auf Initiative der Entwicklung erfolgen.

Zwei BPA Ansätze

BPA wird heute entweder über die Transformation von standardisierten Modellierungstechniken oder über ein integriertes gemeinsames Prozess-Repository gelöst. Die Transformation von standardisierten Modellierungstechniken wird von vielen BPM Tool Herstellern angeboten. In diesem Fall werden die Prozesse mit verschiedenen Techniken wie beispielsweise EPK, BPMN oder einem proprietären Ansatz modelliert. Anschliessend wird das Modell in ein Format transformiert, welches sich zur Ausführung von Workflows eignet (BPEL, XPDL, andere). Die transformierten Informationen werden dann von einer Process Engine geladen. Der zweite Ansatz – Integrierte gemeinsame Prozess-Repositories – werden erst von wenigen Herstellern angeboten. In diesem Fall erfolgt die Prozessmodellierung in zwei Schritten, die oft auch von Unterschiedlichen Personen ausgeführt werden. Die fachliche Prozessmodellierung erfolgt beispielsweise in EPK, die technische Modellierung in BPEL. Die Prozessinformationen werden jedoch in einem gemeinsamen Repository gespeichert, so dass jede Änderung – ob auf fachlicher oder auf technischer Seite – sofort für das Gegenüber sichtbar wird.

BPA Zukunft

BPA als verbindendes Element zwischen BPM und SOA verspricht vieles; Einerseits die Bereitstellung integrierter Werkzeuge zur Spezifikation operativer Geschäftsprozesse durch fachliche und technische Modellierung, andererseits die Instrumente zur automatisierten Analyse und Kontrolle der ausführbaren Prozesse durch SOA Komponenten. Damit bietet BPA die optimale Unterstützung von BPM für ein Unternehmen. Voraussetzung ist allerdings eine auf den Prinzipien von SOA basierende Anwendungslandschaft und eine konsequente Nutzung der standardisierten Techniken. Es geht natürlich auch eine Nummer kleiner. Bereits heute haben viele Unternehmen Aktenschränke voller Prozessbeschreibungen. Könnten diese durch BPA verfeinert und als Grundlage zur Steuerung der betrieblichen Informationssysteme verwendet werden, würde sich der Einsatz von BPA allemal lohnen.