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/ 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.

Planung ist zwar für jedes Projekt wichtig, aber BPM-Projekte brauchen einen sehr viel flexibleren Planungsansatz als „normale“ Projekte, da sich Geschäftsprozesse über den Lebenszyklus hinweg häufig ändern können. Die zugrundeliegenden Technologien sollten diese Flexibilität zulassen, daher sollte man nicht versuchen, Prozesse hardkodiert in Form von Programmcode zu unterstützen. Ein guter Plan gibt dabei vor, wer was ändern darf, und welche Änderungen wann aktiviert werden sollen.

Flexibilität ist nicht nur in der Planung wichtig, sondern auch das Stichwort für die gesamte Unternehmenskultur. BPM ist anders, und es erfordert neue Denkweisen und Ansätze. Es sind Mitarbeiter gefragt, die einen kompletten Geschäftsprozess von Anfang bis Ende durchschauen und Wertschöpfungen erkennen können. Eine Kultur, in der Ideen und kreative Ansätze belohnt und gefördert werden, ist auch förderlich für BPM. Werden hingegen BPM Projekte als Rechtfertigung für Entlassungen angeführt, ist das für den Aufbau einer solchen Kultur schädlich. Ziel ist es, intelligentes, schnelleres, konsistentes Arbeiten zu erreichen. Kreative Mitarbeiter sind dabei der Schlüssel zum Erfolg.

Doch bei aller Liebe zum Prozess und den zugehörigen Planungsdetails sollte das ultimative Ziel nicht aus den Augen verloren werden: Der Nutzen für den Kunden. Letztendlich zielt BPM darauf ab, das gesamte Geschäft so zu sehen, wie der Kunde es sieht: als eine Reihe von zusammengehörigen Prozessen, die einen Kundenauftrag in eine Lieferung in Form eines Wirtschaftsguts oder einer Dienstleistung transformieren. Dem Kunden ist es dabei egal, wie es gemacht wird. Zum Schluss kommt es nur darauf an, ob Kunden einen Mehrwert erzielt haben. Das kann aber dazu führen, dass die Grenzen interner Zuständigkeiten neu definiert werden müssen. 

Zurück zu Best Practices: Das erste BPM Projekt sollte sich im überschaubaren Rahmen befinden. Es gilt zwischen Risiko und Nutzen, Learning-by-doing und dem Appetit auf Veränderungen abzuwägen. Andererseits darf ein Projekt auch nicht zu klein sein, um einen messbaren Erfolg zeigen zu können. Messbarkeit bleibt gerade im BPM-Umfeld ein wichtiges Entscheidungskriterium und schafft Transparenz darüber, ob das Projekt erfolgreich läuft oder nicht.

Da Prozesse von der Zusammenarbeit im Unternehmen leben, ist es ebenfalls sinnvoll, verschiedene Verantwortliche mit den einzelnen BPM-Projekten zu beauftragen. In einem solchen Fall versteht jeder, dass man das BPM-Projekt des Kollegen am besten richtig unterstützt. Schließlich wird man dessen Hilfe bei dem eigenen Projekt ebenfalls benötigen. Das sorgt für die nötige Kollaboration.

Bei all den Änderungen, die sich durch BPM für ein Unternehmen ergeben, ist es schließlich nicht ratsam, alles alleine lösen zu wollen. Das Rad muss nicht immer wieder neu erfunden werden. Unabhängige Berater oder der Professional Service von Anbietern sind gute Informationsquellen, die im Ernstfall jederzeit angezapft werden können.

Ungeachtet der Marketingaussagen (vieler) Hersteller ist die Welt leider doch nicht so einfach. Die Versprechen, dass man einfach ein fachliches Geschäftsprozessmodell nehmen und es direkt einer Ausführungsmaschine übergeben kann sind mittlerweile als (zumindest zurzeit) „leicht übertrieben“ entlarvt.

Was macht man aber als „geplagter“ IT-Analyst und Architekt der nun doch mit den Kollegen aus den Organisationsabteilungen zusammenarbeiten muss (Entschuldigung – natürlich will). Schließlich haben die Kollegen schon (in manchmal langer Arbeit) fachliche Beschreibungen der Unternehmensprozesse erstellt. Erklären sie mal dem C-Level warum man diese (teure) Arbeit nun genau für die Automatisierung nicht brauchen kann…

Wie also weiter? Die Lösung liegt in einer Verbindung beider Welten ohne diese semantisch zu verschmieren. D.h., sie nach fachlichen und IT technischen Inhalten streng zu trennen und dennoch zu verbinden.

Konkret bedeutet es, die Koexistenz ist möglich. Nein, es geht sogar noch viel weiter. Die Koexistenz ist zwingend. Denn ohne den Beitrag der Fachbereiche wird die IT:

• - fachliche Services nahezu nicht finden
• - Domänen nicht identifizieren
• - und den betriebswirtschaftlichen Mehrwert einer SOA nicht heben (dann ist es bloß EAI in neuem Gewand)

Aber auch die Fachbereiche kommen nicht ohne die IT Kollegen aus. Ohne deren fachkundige Unterstützung können:

• - neue SOA optimierte Prozesse gar nicht definiert werden
• - stabile Architekturen zum dauerhaften Betrieb eines BPM / SOA Modells nicht entworfen werden
• - und tatsächliche Umsetzungen in die „reale“ IT nicht erfolgen

Also lautet das Fazit: beide Welten brauchen sich! Wie man den eventuell erforderlichen kulturellen Wandel erreicht möchte ich hier jetzt nicht beschreiben. Wie man aber zumindest die fachlichen Inhalte miteinander verbindet, dass möchte ich Ihnen nicht vorenthalten.

Wenn Sie vor der Herausforderung stehen, ein integriertes fachliches und IT-technisches Prozessmodell zu erstellen, so sind Sie herzlich eingeladen die folgende Vorgehensweise und Entwurfsmuster zu benutzen.

…damit wird die Welt zumindest an einer Ecke einfacher…

PDF Geschäftsprozess- und IT-Modell

Die Vorteile liegen auf der Hand: Es entfällt eine Menge Programmieraufwand, Verständnisprobleme zwischen Fachabteilung und IT fallen weg, Anforderungen können schnell umgesetzt werden, usw. Eine Reihe von Problemen dieses Vorgehens, z. B. hinsichtlich der Detaillierung und dem Formalisierungsgrad von fachlichen Modellen wurde bereits in vorangehenden Beiträgen diskutiert.

Doch was lässt sich eigentlich mit Hilfe der Modellierungskomponenten von Business Process Management-Systemen tatsächlich modellieren? Was definiert ein BPMN-Modell oder eine BPEL-Datei? Im Wesentlichen den Kontrollfluss. Dieser umfasst die Reihenfolge der durchzuführenden Service-Aufrufe, Verzweigungen, Schleifen usw. Doch ist es das alleine, was einen Geschäftsprozess und die von ihm benötigte IT-Unterstützung ausmacht? Was ist mit Datenstrukturen, Dokumenten, Anwendungslogik, Rollen und Benutzern, Organisationsstrukturen, Benutzerdialogen, Geschäftsregeln, Kennzahlen usw.?

Erst das Zusammenspiel all dieser Aspekte mit dem Kontrollfluss ergibt die Gesamtanwendung, die benötigt wird um Prozesse komplett zu unterstützen. Und auf Basis einer SOA können solche Anwendungen wunderbar aufgebaut werden. Die Kapselung und Anbindung von Services zur Bereitstellung von Stammdaten gehört genauso zum Standardrepertoire der meisten SOA-Präsentationen wie die Einbindung von Business Rules Engines. Ausgefeilte Rollen- und Berechtigungskonzepte ermöglichen einen Single Sign-On sowie die individualisierte Bereitstellung von Inhalten und Anwendungslogik in Portalen, und eine Process Engine sorgt für die Steuerung der Prozesse über alle Services hinweg.
Process Controlling und Business Intelligence-Komponenten ermöglichen die Ermittlung von Kennzahlen und ihre Darstellung im Portal.

Die Anforderungen für all diese Elemente einer SOA-basierten Prozessunterstützung müssen zunächst auf fachlicher Ebene definiert werden. Organisationsstrukturen, benötigte Daten und Dokumente, Berechnungsvorschriften, Geschäftsregeln, Kennzahlendefinitionen, usw. - all das sind fachliche Informationen, die also auch von Fachexperten definiert werden müssen.

Es ist zwar schön, wenn man den Kontrollfluss und damit z. B. die Ausführungsreihenfolge von Services direkt ändern kann. Doch was nützt dies, wenn z. B. auch die Anwendungslogik hinter einem Service geändert werden muss? Oder wenn sich die Rollenstruktur geändert hat oder Benutzerdialoge verändert werden müssen?

Versuchen Sie einmal Folgendes zu modellieren: Ein Beschaffungsantrag muss vom Vorgesetzten des Mitarbeiters genehmigt werden, der den Antrag gestellt hat. Das müsste eigentlich ganz einfach sein. Ist es aber nicht. Mit den gängigen Modellierungsmethoden und den BPMS-Modellierungskomponenten, mit denen ich schon Erfahrungen sammeln durfte, kann man zwar eine Aktivität einer Rolle zuordnen, aber Beziehungen zwischen Rollen auszuwerten, das erfordert in reinen Modellierungstools eine textuelle Anmerkung, in BPMS zumeist Programmieraufwand. Und das ist nur ein recht triviales Mini-Beispiel.

Die Vielfalt der zu beschreibenden und zu berücksichtigenden Dimensionen wird seit langem in Rahmenwerken wie der Architektur integrierter Informationssysteme von Scheer (man denke hierbei nicht nur an das Tool, sondern lese auch die Bücher von Scheer) oder dem Zachmann Framework sehr gut beschrieben.

Eine durchgängige Methodik zur Entwicklung von SOA-basierten Systemen muss all diese Dimensionen berücksichtigen. Der Fachexperte muss also in der Lage sein, nicht nur den Kontrollfluss zu spezifizieren, sondern zugleich auch Daten, Regeln, Kennzahlen usw. - und ihr Zusammenspiel bei der Durchführung und der Steuerung von Prozessen.

Derzeit gibt es zwar viele interessante Lösungen für einzelne Teilprobleme, z. B. BPMN-Modellierung für den Kontrollfluss, modellgetriebene Software-Entwicklung für die Generierung von Anwendungslogik, modellbasiertes Customizing von Anwendungskomponenten, und vieles mehr. Ein integrierender Gesamtansatz fehlt aber bisher. Zugegeben: Das ist nicht ganz einfach, weil sich die genannten Aspekte in ganz unterschiedlicher Form an ganz verschiedenen Stellen in einer SOA-Landschaft auswirken. Dennoch wäre es ein lohnendes Ziel, um wirklich eine hohe Durchgängigkeit von fachlichen Beschreibungen bis zur Ausführung zu erreichen. Heute müssen wir noch mit zu viel Stückwerk kämpfen.

Damit SOA Anwender diese Diskussionen nicht immer neu beginnen müssen, gibt es inzwischen eine Reihe von Bemühungen das SOA Grundvokabular zu standardisieren. So hat die BITKOM vor einigen Tagen das SOA Know-How Projekt ins Leben gerufen. Auf der zugehörigen Internetseite wird eine umfangreiche Sammlung von Referenzprojekten aber auch einem SOA Leitfaden aufgebaut. Diese Informationen können Anwender nutzen, um ihre eigene SOA Initiative zu beschleunigen. Eine weitere sehr wichtige Sammlung von SOA Expertenwissen ist das OASIS SOA Referenzmodell.

Das SOA Referenzmodell definiert die wichtigsten Begriffe wie Service und Fähigkeit. Das OASIS SOA Referenzmodell wurde von namhaften Experten zusammengestellt und enthält damit das gesammelte Expertenwissen aus zahlreichen Projekten. Inzwischen gibt es auch erste Produkte die das OASIS SOA Referenzmodell umsetzen. Die Nutzung solcherSoftware beschleunigt die SOA Einführung, da auf vorhandenes Expertenwissen zurückgegriffen werden kann, anstatt von null anfangen zu müssen.

Sebastian Stein
IDS Scheer AG

Von einem rein technologischen Standpunkt aus betrachtet, birgt die Webservice-Technologie sicherlich die Möglichkeit, Services in unterschiedlichen Szenarien wiederzuverwenden. Wie jedoch stellt sich das in einem betriebswirtschaftlichen oder semantischen Zusammenhang dar?

Da Services betriebswirtschaftliche Prozesse abbilden, sind sie aus Unternehmenssicht dann wieder verwendbar, wenn sie häufig und an mehreren Stellen innerhalb des Unternehmens gebraucht werden. Die Granularität der Services ist somit ein entscheidender Faktor. Insofern gilt die Faustregel: Je feiner die Granularität und je weniger umfassend und spezifisch damit die Funktionalitäten, die der Service zur Verfügung stellt, umso höher ist die Wahrscheinlichkeit, dass er in verschiedenen Zusammenhängen verwendet werden kann. Was heißt dies nun für die Serviceentwicklung?

Bei vielen Projekten lässt sich derzeit beobachten, dass Services eher für spezifische Anwendungsfälle entwickelt werden.Wenn ein Service beispielsweise den kompletten Suchvorgang nach allen Informationen, die innerhalb eines Systems für die Ausführung eines Prozesses nötig sind, zusammenfasst, wird er sich in aller Regel nicht für andere Prozesse einsetzen lassen. Theoretisch wären somit rein technische Services wie z.B. „Lösche Datenbankeintrag“ der richtige Weg, um eine hohe Wiederverwendbarkeit zu gewährleisten. Das aber ist gleich in mehrfacher Hinsicht problematisch: Zunächst wäre bei der Komposition von neuen Applikationen eine Fülle an Services nötig. Der Aufwand, der hierbei entsteht, macht ein solches Vorgehen unwirtschaftlich und widerspricht einer der Grundideen, die hinter dem SOA Konzept stehen - der einfachen und flexiblen Erstellung und Änderung von Prozessapplikationen. Auch aus Kommunikationsgründen macht eine derartige Granularität wenig Sinn. Sind nämlich die Services quasi losgelöst vom betriebswirtschaftlichen Kontext, besteht für die Verantwortlichen auf Geschäfts- und auf IT-Seite keine gemeinsame Diskussionsgrundlage. Eine am Prozess orientierte Top-Down Entwicklung wird so erschwert.

Daher sollten die Services einer SOA betriebswirtschaftliche Funktionalitäten im Idealfall in einer Granularität bieten, die geschäftsobjektgetrieben ist. Diese Vorgehensweise hat folgenden Vorteil: Es wird eine Granularitätsebene für die Services geschaffen, die einerseits prozessunabhängig ist, sich gleichzeitig jedoch an betriebswirtschaftlichen Zusammenhängen orientiert. Dadurch fällt die Verständigung zwischen der Geschäfts- und der IT-Seite leichter und die unterschiedlichen Anforderungen können zu einem besseren Ausgleich gebracht werden. Derart gestaltete Services haben ein hohes Wiederverwendungspotenzial , weil die in einem abgeschlossenen Geschäftsobjekt gebündelten Funktionalitäten mit großer Wahrscheinlichkeit in verschiedenen Prozessen wieder auftreten. Gleichzeitig bleibt der Aufwand bei der Komposition von Applikationen überschaubar, da die Granularität eben nicht so fein ist, dass dafür unzählige Services gebraucht würden. Ein Beispiel für eine solche Serviceoperation wäre das Anlegen einer Bestellung. Die Bestellung ist als Geschäftsobjekt sowohl aus einer betriebswirtschaftlich-fachlichen als auch aus IT-Perspektive ein logischer, in sich geschlossener Vorgang. Auch wenn hinter so einem Objekt aus IT-Sicht eine Vielzahl von funktionalen Operationen steht, können die Mitarbeiter den Service der bekannten Struktur einer Bestellung nach anlegen. Dieser lässt sich in der Folge in verschiedenen Prozessen wiederverwenden.

Doch nicht nur der Serviceschnitt hat in der Praxis einen Einfluss auf die Wiederverwendung. Die Services müssen auch sinnvoll verwaltet werden. Dafür ist es neben einer betriebswirtschaftlich logischen Klassifizierung notwendig, dass die Services betriebswirtschaftlich und technisch schlüssig benannt, durch einheitliche Dokumentationsvorschriften in ihrem Verhalten beschrieben und diese Informationen zentral zur Verfügung gestellt werden. All dies ermöglicht die Suche nach benötigten Services und erleichtert einen Anforderungsabgleich. Das wiederum hilft, Doppelentwicklungen zu vermeiden und stellt letztlich die Wiederverwendung von vorhandenen Services sicher.

Ein weiterer wichtiger Aspekt, der in diesem Zusammenhang ebenfalls beachtet werden muss, ist das Datentypenmodell, auf dem die Services basieren. Im Idealfall sollten die innerhalb eines Unternehmens vorhandenen Services für die gleichen betriebswirtschaftlichen Zusammenhänge auch die gleichen Datentypen und Datenstrukturen (und Namen) verwenden. Auf diese Weise kann ein Mehraufwand durch Mappings und Konvertierungen bei der Komposition der Services verhindert und so die Wiederverwendung von vorhandenen Services attraktiver gemacht werden.

Zusammenfassend lässt sich also Folgendes sagen: Um im Rahmen einer erfolgreichen SOA Strategie Services mehrfach verwenden zu können, ist ein klar regulierter, zentral gesteuerter Governanceprozess nötig, der ein einheitliches Modell für die Serviceentwicklung, deren Verwaltung und die zu verwendenden Datentypen vorgibt.

Dem Modell zufolge findet die Preisbildung für Schweine als Wechselspiel zwischen übermäßigen Investitionen (steigendes Angebot, das zu fallenden Preisen führt) und übermäßigen Desinvestitionen (sinkende Produktionskapazitäten, die zu steigender Nachfrage führen) statt. Da sich die Angebots- und Nachfrageseite durch Versuch und Irrtum einander nähern und am Ende ein Preis zustande kommt, der keine Erwartungen mehr enttäuscht, gleicht der Zyklus einem Pendel, das immer schwächer ausschlägt und irgendwann zur Ruhe kommt.

Zwar gilt dieses Modell in den Wirtschaftswissenschaften inzwischen als teilweise überholt (siehe auch das nicht weniger unterhaltsame “Saure-Gurken-Problem”). Das Prinzip des Einpendelns lässt sich jedoch in ähnlicher Form vorrangig in solchen Märkten beobachten, die von Visionen, Erwartungen, Enttäuschungen und Skeptizismus geprägt sind.

In der letzten Zeit wurden wir mit der Vision ausgestattet, dass uns BPM in Kombination mit SOA in die Lage versetzen wird, auf der Business-Ebene Prozesse zu gestalten, und diese auf Knopfdruck in der IT abbilden (ausführen, automatisieren), überwachen und steuern zu können. Dank nicht-proprietärer Methoden wie BPMN und BPEL sollte diese Vision Vendor-unabhängig funktionieren. Es entstand die Erwartung, dass wir in Kürze mit den entsprechenden Tools versorgt werden, um diese Vision Wirklichkeit werden zu lassen. Und tatsächlich, es traten Hersteller auf den Plan, die (zumindest im Marketing-Material) glaubhaft versicherten, die entsprechende Lösung anbieten zu können. Jedoch führten die ersten Praxisprojekte zu Enttäuschungen, die sich u.a. auf Defizite in der Organisation, in der Kompetenz, aber natürlich auch in den Tools zurückführen lassen. Im Ergebnis hat das gebrannte Kind natürlich Angst vorm Feuer, und die Skepsis ist emotional verankert.

Auf den ersten Blick stellt sich jetzt eine einfache Kernfrage: Ist die Vision in der Sache verfehlt, oder existieren Defizite in der Realisierung, die abgebaut werden können? Um diese Frage dreht sich die aktuelle Diskussion, und sie ist geprägt von zwei Fraktionen, nämlich denen, die dringend etwas verkaufen wollen, und denen, die sich dazu berufen fühlen, genau dies zu verhindern (manchmal, nicht immer, weil sie etwas anderes verkaufen wollen).

Auf den zweiten Blick, und diesen möchte ich vertreten, stellt sich - völlig unabhängig davon - die Frage, ob die Vision überhaupt vollständig realisiert werden muss, um faktische Vorteile zu generieren. Im Grunde geht es doch nur darum, einige Methoden und Tools zu entwickeln, um informationszentrierte Prozesse besser (einfacher, schneller und flexibler) realisieren und betreiben zu können. Dafür ist es doch gar nicht zwingend erforderlich, einen Prozess vom Anfang bis zum Ende und von Top bis Down durch das Business so modellieren zu lassen, das eine Engine das Modell sofort verwerten kann. Es reicht völlig, für bestimmte Aspekte im Prozess neue Konfigurationsmöglichkeiten bereit zu stellen, für deren Handhabung man kein Programmierer sein muss. Das Business Rules Management geht genau in diese Richtung, und wer mir erzählen will, Business Rules hätten mit BPM nichts zu tun, hat entweder noch nie ein Prozessmodell mit Verzweigung gesehen (Business), oder eine if-then-Abfrage gebaut (IT). Für diesen Zweck (die abgestufte Automatisierung, nicht das BRM) ist die BPMN eine absolut praxistaugliche Methode, wobei auch ich den Mehrwert des Mappings auf BPEL in der derzeitigen Form sehr infrage stellen würde.

Und SOA, die heilige Kuh der IT-Architekten, kann als eigenständige Methode völlig unabhängig von BPM natürlich ganz fantastisch funktionieren. Das Problem bei SOA ist einfach nur, dass der Begriff inzwischen für alles und jeden herhalten muss (Prof. Dr. Robert Winter aus St. Gallen bemerkte, in Anspielung auf den OOP-Hype vor 20 Jahren, unlängst, dass seine Katze inzwischen ebenfalls service-orientiert sei). Es gibt eben das SOA-Paradigma auf der reinen Software-Ebene, und es gibt bestimmte Aspekte des Paradigmas, die in Kombination mit BPM in der Entwicklung und im Betrieb einer IT-Architektur bestimmte Vorteile generieren können (aber nicht müssen). Der vorgenannte Professor hat mit seiner Differenzierung des Begriffes (SOA auf Software-Ebene, auf Prozessebene, und auf der Agilitätsebene dazwischen) einen meines Erachtens extrem wichtigen Beitrag geleistet, um die diversen Meinungen ein wenig sortieren zu können. Und es ist halt so, dass wir auf der Software-Ebene inzwischen schon ziemlich weit sind in Bezug auf unser Verständnis, “wie es funktioniert”, auf der Agilitätsebene hingegen immer noch im Sandkasten spielen, und von der Prozessebene noch träumen dürfen. Das muss man bedenken, aber es ist kein Drama.

Die Essenz:

Ich kann aus dem Stand heraus eine ganze Reihe von Vorteilen aufzählen, die sich - hier und jetzt - mit Prozessautomatisierung bzw. einer BPM/SOA-Kombination realisieren lassen. Das sind keine weltbewegenden Dinge, aber sie schaffen Mehrwert, und sie sind auch heute schon mit vertretbaren finanziellen Aufwänden realisierbar - ich weiß das, weil ich es getan habe. Ich glaube, wir können uns Schritt für Schritt unserer Vision annähern, wo es aktuellen Mehrwert bietet, und solche Schritte vermeiden, die nicht praktikabel sind. Und sollte sich auf unserem Weg herauskristallisieren, dass unsere Vision in der jetzigen Form gar nicht sinnvoll ist, dann kann auch diese nachgebessert werden.

Der Begriff “Learning by Doing” stammt von Robert Baden-Powell, dem Gründer der Pfadfinderbewegung. Dort werden 15-jährige Gruppenleiter mit 3-8 Gleichaltrigen, für die sie Verantwortung tragen, auf mehrwöchige Großfahrten ins Ausland geschickt. Trotz fehlender Erwachsener gibt es weder Alkohol- noch Drogenexzesse (zumindest keine schlimmen), und der Weg durch die Wildnis wird mit Wagemut, Karte und Kompass bewältigt. Ich habe nie wieder in so kurzer Zeit so viel gelernt, wie in meiner Zeit als Pfadfinder.

Was wir meiner Ansicht nach für BPM-SOA brauchen ist die richtige Einstellung sowie die Kompetenz, mit “Karte und Kompass” umzugehen. Dann werden uns weder blinde Euphorie noch Schwarzmalerei daran hindern, fatale Fehler zu vermeiden und echte Chancen zu ergreifen.