Schon seit geraumer Zeit gelten Service-orientierte Architekturen (SOA) als Top-Thema der aktuellen IT-Visionen - bei Anwendern wie auch von Seiten der Anbieter. Doch nach wie vor zeigt sich die Mehrzahl der Anwenderunternehmen unsicher in Bezug auf ihren jeweils gewählten Weg zur SOA. Obgleich derartige Architekturen mittlerweile von nahezu jedem größeren Hersteller sämtlicher Segmente der IT gepriesen und angeboten werden, gehen die Meinungen über eine tatsächliche Definition samt Standardisierung stark auseinander. Das würde sich auch in der steigenden Anzahl scheiternder IT-Projekte zeigen, wie Michael Krusche von Evolving Systems Consulting erklärt.
"Trotz aller Verheißungen sind die Segnungen von SOA in den meisten Unternehmen noch nicht angekommen. Und damit erlebt SOA das gleiche Schicksal wie all die anderen IT-Paradigmen der Vergangenheit. Tatsache ist leider, dass der Begriff Software-Krise bereits 40 Jahre alt ist und es seitdem zu keinen substanziellen Verbesserungen gekommen ist. Viele internationale Studien zeigen, dass weiterhin 30 Prozent aller Projekte scheitern. Die Frage lautet nicht nur, wie ich SOA implementiere, sondern vielmehr: Wie schaffe ich eine Organisation, in der SOA erfolgreich implementiert werden kann?"
Ein besonders hohes Risiko stelle die mangelhafte Governance dar, warnen die Auguren des Marktforschers Gartner. Aktuelle SOA-Implementierungen zeigten, dass SOA mehr Aufwand in Sachen Service Design Governance sowie Best Practices für die Integration von Applikationen benötige, als in den meisten Unternehmen geleistet werde, unterstreicht Gartner-Analyst Paolo Malinverno. "Zu Beginn eines SOA-Projektes sind die Risiken gering." Doch ein SOA-Projekt entwickle sich schnell weiter. Unternehmen sollten daher kein firmenweites SOA-Projekt beginnen, ohne vorher Governance-Prozesse für die Definition, Implementierung und Aufrechterhaltung der Services festzulegen.
Auguren fordern mehr Governance bei SOA
"Ein typischer organisatorischer Fehler ist, ein unternehmensweites SOA-Projekt wie andere Application-Development-Projekte abzuwickeln. Zudem wird unterschätzt, dass mit einer SOA viele Services dazukommen." Wie viel Governance einer SOA gut tut, sei laut dem Auguren schwer einzuschätzen. "Zu viel und zu wenig Governance tötet ein SOA-Projekt." Das Ausmaß der Governance müsse im richtigen Verhältnis zur Größe, Organisation und Kultur der Firma stehen. Pezzini zufolge gilt es, besonders auf die technischen Risiken zu achten. "Die unternehmensweite SOA-Installation erfordert Fähigkeiten, die in vielen Firmen nicht zu finden sind." Ein typischer technischer Fehler liege etwa darin, die Komplexität der SOA zu unterschätzen. "Oft werden falsche Komponenten für die Infrastruktur ausgewählt. Die SOA wird zudem ohne Proof of Concept und ohne Belastungstest implementiert."
Gartner-Analyst Malinverno empfiehlt Unternehmen, die SOA-Infrastruktur auf Basis ihrer realen funktionalen und nichtfunktionalen Anforderungen zu entwerfen - "und nicht auf der Basis eines theoretischen Modells. Etwa 25 Prozent aller technischen Bemühungen sollten darauf gerichtet sein, ein leichtes Debuggen der SOA zu sichern."
Weniger die Gefahren und scheiternden Projekte als vielmehr die Möglichkeiten Service-orientierter Landschaften sieht IDS Scheer. Mit Open BPM will das Unternehmen Kunden den Weg in eine prozessgetriebene Welt ermöglichen und erleichtern. Im Rahmen der ARIS Process World 2007 zeigte das Unternehmen unlängst Einblicke in die jüngsten Software-Versionen und gab Ausblicke auf die künftige Strategie.
Das Unternehmen hat, angesichts aktueller Trends wie SOA und BPM, seine langjährige SAP-Fokussierung in den vergangenen Monaten auf Konkurrenzanbieter wie Oracle, Microsoft und IBM ausgedehnt und sich dem Business Process Management verschrieben. Das Motto der ProcessWorld 2007 lautete dementsprechend "Accelerating Innovation & Growth with Open BPM". "Für IDS Scheer und unsere Kunden bedeutet das, dass unabhängig von den eingesetzten Unternehmenslösungen oder der verwendeten Technologie die Geschäftsprozesse stets gestaltet, implementiert, verwaltet und kontinuierlich überwacht werden müssen", erläutert Wolfram Jost, Vorstand für Produktstrategie und Produktentwicklung bei IDS Scheer. "Open BPM ist die bruchlose Verbindung dynamischer Geschäftsstrategien mit einer flexiblen IT-Architektur - und eröffnet Freiräume, um auf neue betriebswirtschaftlich motivierte Anforderungen sofort reagieren zu können."
Besonderes Augenmerk legte Jost im Rahmen der Veranstaltung auf die von IDS Scheer erstellte Studie Business Process Report 2007. Ihr zufolge steht BPM auf der Agenda mittlerer und großer Unternehmen ganz oben. "Der Einsatz von entsprechenden Werkzeugen wird dabei zunehmend zum Erfolgsfaktor." Die Analyse zeige, dass das Management der Geschäftsprozesse gerade im Umfeld von Enterprise Architecture Management (EAM) und Service-orientierten Architekturen eine unerlässliche Voraussetzung sei. "Die Befragten glauben vermehrt, dass der CIO künftig eher gestalterisch als technologieorientiert für das gesamte Geschäft wirken soll", unterstreicht Jost.
Den Geschäftsprozess im Visier halten
Das würden nahezu 80 Prozent der befragten Unternehmen bestätigen, weil sie sich auch 2007 stark oder sogar sehr stark mit dem Thema BPM beschäftigen wollen. "Der Trend der letzten Jahre hält somit unverändert stark an." Außerdem steige die Relevanz von Werkzeugen für das Geschäftsprozess-Management. Als mindestens wichtig wird deren Einsatz von nahezu 90 Prozent der Interviewten bewertet, "ein Fünftel erachtet sie sogar als unerlässlich". Rund ein Drittel der Unternehmen würde die ARIS-Plattform als alleinige BPM-Software nutzen. Wobei die Einsatzquote in Österreich bei 40 Prozent, in Deutschland und in der Schweiz bei 30 Prozent liege. "Ein Viertel der Befragten nutzen mehrere Tools."
Grund genug für IDS Scheer, das bestehende Reseller-Abkommen mit SAP für die ARIS-Plattform auszudehnen. "Angesichts steigender Kundennachfrage vertreibt SAP künftig unter dem Namen SAP Enterprise Modeling Applications by IDS Scheer zusätzliche ARIS-Software-Pakete für das Geschäftsprozess-Management", betont Jost zufrieden. Module wie SAP Process Performance Management by IDS Scheer würden Kunden dabei unterstützen, Software-Upgrades schneller zu implementieren, die Effizienz von Geschäftsprozessen zu optimieren und die Einhaltung gesetzlicher Vorgaben sicherzustellen.
"Die Vereinbarung ergänzt das Vertriebsabkommen für ARIS for SAP NetWeaver, das bereits 2003 geschlossen wurde", bemerkt IDS-Vorstandsvorsitzender Thomas Volk.
Besonders aber zwei Anbieter sind tief in die Schlacht um Service-orientierte Architekturen integriert. Mit SAP und Oracle stehen sich wettbewerbserprobte Konkurrenten gegenüber, die ihren Kunden zwar auch eine SOA ermöglichen wollen, allerdings jeweils in besonderer Ausprägung.
Besonders Oracle betont derzeit die SOA-Fähigkeiten seiner Fusion-Plattform. "Es gibt zwei Aspekte von Fusion. Einer dreht sich um Business-Services", betont Andrew Sutherland, Vice President Technology für die Region EMEA bei Oracle. "Davon stammen einige beispielsweise aus Siebel- oder Peoplesoft-Anwendungen, andere aus unserer E-Business-Suite. Manche Unternehmen werden auch Komponenten aus SAP-Anwendungen nutzen. Bei diesen Services geht es um Geschäftslogik und damit verbundene Prozesse.
Der zweite Aspekt bezieht sich auf die Infrastruktur, sprich Fusion als Middleware. Diese Infrastruktur ist kein Commodity-Produkt; sie muss sich mit den gestiegenen Anforderungen an Services und Prozesse verändern." Dass es zum Aufbau einer SOA bereits zahlreiche Infrastrukturprodukte, beispielsweise Registries, BPEL-Engines sowie diverse ESB-Angebote, gibt, stört Sutherland allerdings wenig. "Unser Ziel ist ein umfassendes Portfolio an Werkzeugen. Dazu entwickeln wir eigene Software und kaufen interessante Produkte zu. Kunden bestätigen uns, dass wir die meisten Anforderungen mit unseren Infrastrukturprodukten schon heute abdecken."
SAP forciert jedoch zunehmend sein neues Mittelstands-Produkt A1S. Dieses wird derzeit zwar noch nicht angeboten - allerdings testen ausgewählte Anwender schon das System. Mit dem Produkt steigt der Konzern massiv in das Geschäft mit Miet-Software (On-Demand) ein, in dem bereits Spezialisten wie Salesforce.com, Rightnow, Netsuite und Oracle/Siebel unterwegs sind. Vergleiche speziell mit Salesforce.com hält SAP-Chef Henning Kagermann aber für unangebracht: "Salesforce.com deckt lediglich einen Teil einer Business-Suite ab, nämlich CRM. Bei A1S hingegen handelt es sich um eine komplette Applikations-Suite, die ERP, CRM, SCM und noch mehr umfasst." Ein weiterer Unterschied sei, dass A1S nicht wie die Software des Konkurrenten nur in einer Mehrmandantenumgebung läuft, sondern isoliert von anderen Mandanten betrieben werden kann. Auf diese Weise wolle man Bedenken von Kunden in Sachen Datensicherheit zerstreuen.
A1S ist eine nach Darstellung der SAP neue Software, die mithilfe von Netweaver und des Enterprise Services Repository gebaut wird. Die SaaS-Lösung soll sich zügig implementieren lassen. Damit will SAP im Mittelstand punkten. Das Software-Angebot bietet laut Hersteller grundsätzlich einen ähnlichen Funktionsumfang wie das Produkt wie All-in-One, verfüge jedoch über voreingestellte Standardprozesse und sei nicht so weit konfigurierbar wie die beim Kunden installierten Softwareprodukte (On-Premise).
Software as a Service
Unter anderem die umfangreichen Konfigurationsmöglichkeiten haben die SAP-Software komplex und damit in der Einführung beim Kunden kostspielig werden lassen. A1S ist ein Versuch, Anwender zu erreichen, die bislang von SAP-Produkten nichts wissen wollten. Möglicherweise wird es von A1S in Zukunft eine On-Premise-Variante geben, die den On-Demand-Kunden einen Umstieg auf im eigenen Hause betriebene Software ermöglichen würde.
Zunächst konzentriert sich SAP aber darauf, das On-Demand-Geschäft mit A1S anzukurbeln. Hier will der Konzern auch neue Vertriebswege ebnen: Neben dem Direkt- und Partnergeschäft wird an Telesales gedacht. Tatsächlich bietet die von Kagermann kritisierte Firma Salesforce. com keine komplette Business-Suite im On-Demand an, allerdings unternimmt der Spezialist einige Anstrengungen, um das Image eines reinen CRM-Vermieters abzustreifen. Software-Häuser will Salesforce.com ermuntern, die eigenen Erzeugnisse so anzupassen, dass sie auf der On-Demand-Umgebung laufen.
ERP-Funktionen zur Miete werden in Zukunft immer stärker gefragt sein, meint das Marktforschungsunternehmen IDC mit Verweis auf eine eigene Studie zur Entwicklung des westeuropäischen ERP-Markts. Doch schon jetzt wachsen SOA und Business-Process-Management (BPM) zunehmend zusammen. Während aber SOA heute noch weitgehend ein IT-Thema ist, das eine bessere Handhabung von historisch gewachsenen, heterogenen Anwendungslandschaften verspricht, liegt der Schwerpunkt von BPM stärker auf der Fachseite. Diese befasst sich mit der Analyse, Planung, Steuerung und Optimierung von Geschäftsprozessen.
Unter dem Begriff BPM wird heute außerdem vermehrt die IT-basierende Automatisierung von Prozessen verstanden. Prozessorientierung verspricht verschiedene Vorteile: Neben einer höheren Flexibilität ermöglicht BPM eine bessere Nachvollziehbarkeit und Kontrolle durch die Fachseite. Darüber hinaus entsteht die Chance einer kontinuierlichen Verbesserung der Geschäftsprozesse. Aus der IT-Perspektive verspricht die Prozessorientierung, mehr Struktur auf höchster Ebene in die Anwendungslandschaften zu bringen und so das Zusammenspiel von IT und Business zu verbessern.
Zentrale Prozesssteuerung nur in wenigen Fällen vorhanden
Für die effiziente Anwendung von BPM ist ein Verständnis der Prozess-Charakteristika wichtig. BPM entfaltet insbesondere dann sein volles Potenzial, wenn es sich um hoch dynamische Prozesse oder um Prozesse mit hohem Optimierungspotenzial handelt. Eine weitere wichtige Frage ist, inwiefern die aus dem Blickwinkel von BPM betrachteten Prozesse heute eher explizit oder implizit definiert sind: Generelles Ziel des BPM-Ansatzes ist es, Prozesse explizit zu machen, beispielsweise durch Dokumentation oder Abbildung auf eine IT-Lösung. Allerdings findet sich heute nur in den wenigsten IT-Systemen eine zentrale Stelle, an der die Prozesssteuerung verwaltet wird. Vielmehr ist die Prozesslogik normalerweise implizit in der Präsentations-, Mid-Tier-, Backend- und Datenbanklogik enthalten.
Das explizite Sichtbarmachen von Prozessen findet häufig über mehrere Jahre und in mehreren Evolutionsstufen statt. BI-Tools ermöglichen Aussagen über die Performance implizierter Prozesse, weil sie ja die Daten analysieren, die das Resultat dieser Prozesse sind. Werkzeuge für das Business Activity Monitoring (BAM) ermöglichen zudem das Überwachen von Prozessen in Echtzeit. BAM ist vor allem deshalb interessant, weil es nachträglich und nichtinvasiv in implizite Prozess-Implementierungen eingebettet werden kann. Die letzte Ausbaustufe ist der Einsatz eines Business Process Management-Systems (BPMS), das eine echte Prozessdigitalisierung ermöglicht.
In den letzten Jahren bedeutete Prozess-Implementierung häufig den langen und kostspieligen Umweg von Visio-Diagrammen über UML (Unified Modeling Language) nach J2EE oder vergleichbaren Mitteln. In der BPM-Vision entwickeln sich formale Prozessbeschreibungen zur gemeinsamen Sprache von Business und IT. Das BPM-System unterstützt ein nahtloses Prozessdesign, ferner Ausführung, Monitoring, Analyse und Redesign. Eine Prozessanpassung bedarf in diesem Szenario keines IT-Projektes mehr, sondern kann sofort ausgeführt werden. Auch wenn etliche Plattformanbieter heute viel in die Realisierung dieser Vision investieren, muss das dafür nötige Zusammenspiel der unterschiedlichen Komponenten sehr genau verstanden werden, wie im Folgenden erläutert wird.
Das Zusammenspiel von BPM, SOA und verwandten Techniken wird heute häufig unter dem Begriff Enterprise SOA zusammengefasst. Im obersten Layer dieses Schichtenmodells liegen Portale zur Prozessausführung sowie zum Monitoring und der Analyse von Prozessen. Dabei werden sowohl implizite Prozesse (BI, Stand-alone BAM) als auch explizite Prozesse (BPM mit BAM) unterstützt. Der Prozess-Layer umfasst neben dem Prozess-Management auch das zentrale Erstellen und Verwalten von Geschäftsregeln, häufig auf Basis eines Business-Rules-Management-Systems (BRMS). Dieses übernimmt die Entscheidungssteuerung für das Prozess-Management und ermöglicht schnelle und direkte Änderungen der Regeln durch den Fachbereich.
Häufig ist es sinnvoll, existierende Anwendungslogik in höherwertige und stärker fachbezogene Composite Services zu aggregieren. Viele BPMS unterstützen hierzu die Service-Orchestrierung. Dabei handelt es sich häufig um eine technische Orchestrierung. Daher ist es sinnvoll, diese technischen Orchestrierungen - häufig mehrere Hundert - im BPMS von den rein fachlichen Prozessen - normalerweise weniger als hundert - zu trennen. Das lässt sich beispielsweise mit unterschiedlichen Name-Spaces regeln. Ein Geschäftsprozess ist dadurch gekennzeichnet, dass er für den Fachbereich verständlich ist, potenziell lange läuft und Benutzerinteraktion enthält. Eine Orchestrierung dagegen aggregiert elementare Operationen, läuft in der Regel sehr kurz (Millisekunden) und enthält nur Interaktionen zwischen Maschinen.
Neben dem Zusammenwachsen von SOA, BPM und BRM spielt Business Intelligence (BI) eine weitere wichtige Rolle in der Enterprise SOA: Im Kontext von BI werden SOA-Konzepte zunehmend genutzt, um historisch gewachsene, komplexe BI-Umgebungen besser in den Griff zu kriegen. So genannte Analytic SOA Services werden als Strukturierungsmittel und grundlegende Bausteine für analytische Anwendungen verwendet (semantische Integration). Innovative Hersteller erlauben zusätzlich die flexible Kombination von klassischen Data-Warehouse-Analysen mit dem Echtzeitzugriff auf operative Daten über Web Services.
Anwendungslogik herauslösen
Das Einbinden der BI in die Enterprise SOA ermöglicht außerdem die effizientere Steuerung von Prozessen im BPM über Key Performance Indikatoren (KPI). Dies ist bedeutend, weil KPI Aussagen über die Prozess-Performance machen und damit einen wichtigen Input für die Prozesssteuerung und -optimierung liefern.
Eines der wichtigsten Ziele beim Strukturieren der SOA ist die Trennung von Anwendungslogik mit verschiedener Charakteristik. Dabei sind Änderungshäufigkeit und die Person, die die Änderung vornimmt, wichtige Kriterien. Die Unterschiede lassen sich anhand der Politik für die Kostenerstattung in der privaten Krankenversicherung erläutern: Der generelle Prozessablauf, der von der Poststelle über die medizinische und gebührenrechtliche Prüfung der einzelnen Fälle bis zur Auszahlung reicht, ist durch die Aufbauorganisation und die grundsätzliche Arbeitsteilung in der Schadensabteilung relativ fest vorgegeben. Eine langfristige Prozessanalyse und -optimierung lässt sich hier am besten mittels BPM erreichen.
Im Rahmen dieses Prozesses möchte man aber auch auf Tagesbasis Steuerungskriterien beeinflussen. Tritt beispielsweise vermehrt Missbrauch im Zusammenhang einer bestimmten Diagnose auf, wird das Unternehmen zielgerichtet in diesem Bereich prüfen wollen. Dadurch wird der grundsätzliche Prozessablauf nicht verändert, aber die Verteilung verschoben, welche Fälle maschinell reguliert werden und welche vorher manuell zu prüfen sind. Eine solche taggenaue Steuerung wird durch das Anpassen entsprechender Regeln in einem BRM-System ermöglicht. Dieser Beitrag des BRM für die Enterprise SOA rückt auch für die Hersteller von BRM-Plattformen immer stärker in den Mittelpunkt der Produktentwicklung.
Ein gutes Verständnis der unterschiedlichen Artefakte einer Enterprise SOA (Prozesse, Regeln, Aktivitäten, Services) und deren Zusammenspiel ist elementar für den Erfolg. Für das Management der SOA-Artefakte nutzen Unternehmen idealerweise ein Metadaten-Repository. Damit lassen sich Informationen über die Syntax und Semantik der verschiedenen SOA-Artefakte verwalten, ferner Zusammenhänge aufzeigen, analysieren und visualisieren. Die Daten im Repository geben den Nutzern wichtige Informationen über die operationalen Abhängigkeiten und Auswirkungen im Änderungsfall.
Eine Enterprise SOA ist fast ausnahmslos in einem heterogenen Systemumfeld angesiedelt. Häufig wird auch die zugrunde liegende Plattform nicht aus einem Guss sein, sondern Produkte von mehreren Herstellern umfassen. In diesem Fall ist es wichtig, dass das Metadaten-Repository für den Einsatz in einem solchen heterogenen Umfeld geeignet ist. Marktführende Produkte zeichnen sich durch große Offenheit und Anpassbarkeit aus.
Spezielle SOA-Repositories konzentrieren sich auf die Verwaltung von grundlegenden SOA-Artefakten wie WSDL, Policy-Metadaten oder XML Schemas. Das Anwendungsfeld für Metadaten in einer Enterprise SOA ist allerdings wesentlich breiter; es umfasst beispielsweise Informationen über das Zusammenspiel von Prozessdefinitionen via BPML (Business Process Modeling Language), Business Rules und SOA-Services. Auch die SOA-basierende Komponentisierung und Entflechtung von großen Mainframe-Anwendungen lässt sich mit Hilfe eines Metadaten-Repository steuern, indem beispielsweise Informationen über die Implementierung hinter den SOA Interfaces verwaltet werden. Dabei kann es sich etwa um interne Interfaces und Call-Dependencies handeln, aber auch um Datei- und Tabellenzugriffe.
Viele Unternehmen fangen heute damit an, verschiedene Metadaten-Repositories föderiert einzusetzen, um so eine umfassende Sicht auf planungsrelevante Informationen in der IT zu erhalten. Weitere Repository-Klassen, die hier eine Rolle spielen, umfassen beispielsweise Configuration Management Databases (CMDB), EAM Repositories (Enterprise Architecture Management) und PPM Datenbanken (Projekt-Portfolio-Management). Aufgrund der vielen Abhängigkeiten ist die größte Herausforderung für ein erfolgreiches SOA-Metadaten-Management die organisatorische Disziplin. Ohne ein solches Metadaten-Management fehlt indes die Voraussetzung dafür, Geschäftsprozesse in einer Enterprise SOA auf den verschiedenen Abstraktionsebenen sichtbar zu machen, und damit die notwendige Kontrolle über sie zu gewinnen.
Schnell Etappenziele erreichen
Das erfolgreiche Einführen einer Enterprise SOA hängt von vielen Faktoren ab. Einerseits ist es hilfreich, ein Sponsoring auf der Ebene der IT Executives zu erhalten. Andererseits wird es immer nötig sein, auch dem Business schnell die Vorteile aufzuzeigen. Es gilt daher, Quick Wins zu erreichen und einzelne Erfolge zu dokumentieren und zu kommunizieren, bevor ein Durchsetzen der Enterprise SOA auf globaler Ebene möglich ist. Dazu gibt es zwei prozesszentrische Umsetzungsmodelle: den BPM-getriebenen Top-down-Ansatz und den BAM-getriebenen Bottom-up-Ansatz.
Ein Top-down-Vorgehen lässt sich umsetzen, wenn eindeutige Ziele existieren, einhergehend mit einer klaren Vorstellung der umzusetzenden Prozesse. In diesem Falle wäre das vereinfachte Vorgehen wie folgt: Zunächst werden Prozesse identifiziert, das heißt Namen und Kurzbeschreibungen festgelegt, allerdings keine Detaildiagramme. Im zweiten Schritt definiert das Projektteam für jeden Prozess Aktivitäten, das heißt Namen und Kurzbeschreibungen. Auch hier sind noch keine Details gefragt, die Reihenfolge der Aktivitäten im Prozess ist noch irrelevant.
Im nächsten Schritt werden die Aktivitäten auf die SOA-Domänen-Architektur abgebildet: Welche Prozessaktivität benötigt Services aus welcher Domäne? Es folgt ein globaler Abgleich über alle zur Implementierung anstehenden Prozesse (Synergien identifizieren). Danach können die Mitarbeiter Services unter Berücksichtigung von Wiederverwendung im Detail entwerfen, ferner Prozesse und Aktivitäten ebenfalls detailliert modellieren. Was bleibt, ist die technische Implementierung. Last, but not least sollten BPM-Fähigkeiten ausgenutzt werden, um Prozesse zu optimieren.
Ein Bottom-up-Vorgehen ist sinnvoll, wenn es bereits viele implizite Prozesse gibt, die Transparenz aber unzureichend und der Business Case oder der Prozessfokus nicht ganz klar ist. In diesem Falle würden Unternehmen mit den Mitteln des Business Activity Monitoring (BAM) anfangen, Transparenz zu schaffen, indem die impliziten Prozesse sichtbar gemacht werden. Unabhängige BAM-Hersteller erlauben das nichtinvasive Umsetzen von Echtzeit-Prozess-Dashboards durch den Einsatz so genannter Probes, die sich einfach in die existierende Systemlandschaft integrieren lassen. Insbesondere wenn dieser Ansatz mit dem Erstellen eines Bebauungsplanes kombiniert wird, der den Zusammenhang zwischen Prozessen und Anwendungen aufzeigt, kann schnell ein gutes Verständnis für die Ist-Umsetzung der Geschäftsprozesse in der Systemlandschaft erzielt werden.
Wiederverwendung von Services - Vorteil für Nutzer
Auf Basis der so gewonnenen Informationen lässt sich eine aussagekräftige Analyse des Potenzials für die Prozessoptimierung erstellen und dadurch letztendlich ein besserer Business Case. Anhand des Ist-Bebauungsplanes entwickeln Projektverantwortliche schließlich einen Soll-Bebauungsplan, der den fachlichen Schnitt möglicher SOA Services beinhaltet.
Eine Kombination aus SOA und BPM (Enterprise SOA) bietet viele Vorteile. Aus technischer Sicht ermöglicht sie die Wiederverwendung von Services. Dadurch lassen sich etwa Redundanzen und die Komplexität verringern. Aus fachlicher Perspektive liegt der größte Mehrwert der Enterprise SOA mit BPM und BRM darin, dass fachliche Prozesse und Regeln explizit, das heißt sichtbar, gemacht werden und dadurch besser analysiert und optimiert werden können.