»manage it« als

E-Paper  5-6 2011
E-Paper  3-4 2011
E-Paper  1-2 2011
E-Paper  11-12 2010
E-Paper  9-10 2010
E-Paper  7-8 2010
E-Paper  5-6 2010
 

BPM und Masterdatenmanagement sollen SOA-Schwachstellen beseitigen

Services zum Selbstbedienen

Die technologische Reifeprüfung haben serviceorientierte Architekturen (SOA) sicherlich schon bestanden. Die meisten Ansätze zeigen, wie man Dienste flexibel austauschen oder verbinden kann. Und dennoch haben SOA einen Haken: Sie lassen immer noch eine verhältnismäßig große Kluft zum eigentlichen Business. Mit anderen Worten: Die Brücke zwischen Fachabteilungen und IT kann man damit in aller Regel nicht bauen. Ein möglicher Ausweg besteht darin, die SOA-Idee um Business Process Management (BPM) und ein übergeordnetes Masterdatenmanagement zu erweitern, um so auf Basis eines gemeinsamen Metadatenmodells Prozesse, Daten, Regeln und agierende Parteien zu integrieren.

igentlich ist es nichts weiter als ein Architekturkonzept, eine schnöde Managementidee, wenn man so will. Und diese Erkenntnis ist deshalb beinahe bitter, weil man angesichts der vielfach geschürten SOA-Euphorie fast versucht war, zu glauben, dass man damit endlich den so oft angestrebten Brückenschlag zwischen Fachabteilungen und IT hinbekommen könne. Schließlich läuft ihre Logik darauf hinaus, dass man funktionale Erfordernisse mit wiederverwendbaren Diensten erfüllen kann.

Das eigentliche Problem besteht dabei nicht etwa darin, Dienste bereitzustellen. Denn das ist sowohl über ein lokales Repository, ein Service Bus oder auch externe Web Services mit einer normierten Schnittstelle wie WSDL machbar.

Um die Schwachpunkten des SOA-Ansatzes zu verdeutlichen, muss man etwas ausholen: SOA sollen Freiräume schaffen und damit natürlich auch für Entlastung sorgen, wenn es darum geht, IT-Services für die Fachabteilungen bereitzustellen. Denn die sind ja letzten Endes die Speerspitze im Wettbewerb. Sie sprechen mit den Kunden, kennen deren Anforderungen und wissen, mit welchen Produkten man darauf reagieren muss.

Damit sich diese Faktoren jedoch ohne überproportional hohen Aufwand nutzbar machen lassen, benötigen sie Anwendungen, die ihre Prozesse durchgängig unterstützen.

Die Rahmenbedingungen des Marktes, Kundenanforderungen oder auch gesetzliche Vorgaben können sich jedoch rapide ändern. Eben das verlangt nach Flexibilität, und zwar auch beim Bereitstellen von Applikationen. Schon allein deshalb bedarf es hier eines Ansatzes, bei dem die zugrunde liegenden Prozesse die Applikationen treiben und zu Veränderungen führen.

Das aber ist mit traditionellen Applikationen nahezu unmöglich, denn sie sind zu rigide: Die Geschäftsprozesse sind zu fest verankert, sodass die Probleme beim Auflösen oder Konsolidieren von Daten schlichtweg zu groß sind, gerade dann, wenn das über Anwendungsgrenzen hinweg passieren soll. Das hat seine Ursache in aller Regel darin, dass die Applikationen als Monolithen eben nur die ganz bestimmten Anwendungen des Fachbereiches unterstützen.

Vielfach müssen Spreadsheets und E-Mails herhalten, wenn man Daten austauschen oder kollaborieren will. Die eigentlich angestrebte Flexibilität lässt sich so aber nicht erzielen.

Denn sollen Prozesse geändert werden, muss man hier zwangsläufig Programmieraufwand betreiben. Und dafür kann auch die allseits gefeierte und hofierte SOA-Idee noch keine Lösung an die Hand geben.

SOA-Gedanken offenbart Schwachstellen

Gefragt ist deshalb vor allem ein gemeinsames Datenmodell, das die verteilt liegenden Daten zusammenführen und semantisch validieren kann.

SOA offenbaren bei genauerer Betrachtung aber noch weitere Schwachpunkte, zum Beispiel bei der Frage der flexiblen Korrelation von Prozessen und Daten. Eben die jedoch sind unabdingbare Voraussetzung für Governance und Risikomanagement.

All das ändert jedoch nichts an der Tatsache, dass SOA eben doch einen entscheidenden Umschwung eingeleitet haben und damit zumindest eine Zwischenetappe zur umfassenden Lösung der angerissenen Probleme sind. Denn auf Basis von SOA lassen sich Stammdaten, Business-Regeln und Prozesse durchaus zu einem Framework zusammenfügen, sodass sich die Integration von Prozessen, Regeln und Services bewerkstelligen lässt. Gartner nennt diese Idee »Serviceoriented Business Applications« oder kurz SOBA.

Vier Säulen tragen SOBA-Architektur

Die architektonische Grundlage eines solchen Frameworks bildet das gemeinsame Metadatenmodell, unter dem die vier gleichberechtigten Pfeiler Prozesse, Daten, Regeln und handelnde Personen integriert sind.

Der Antrieb und auch die Governance gehen in diesem Gebilde von den Geschäftsprozessen aus, die in der Prozessebene abgelegt sind. Durch den Zugriff auf diese Ebene kann man Geschäftsprozesse übergreifend steuern sowie die Lebenszyklen der dazugehörenden Daten verwalten und Aufgaben gemäß der passenden Zuständigkeit verteilen.

Damit sich Regeln auf einfache Weise bilden lassen, stellt die Regelebene dazu ein Repository bereit, in dem die Regeln als ablauffähiger Code vorgehalten werden. Dabei muss jedoch gewährleistet sein, dass sich Regeln zum einen ohne großen Aufwand aus bestehenden Regelen ableiten lassen. Zum anderen gehört dazu auch, dass das Repository modifizierbar sein muss, um jederzeit die relevante Geschäftslogik vorzuhalten. Andernfalls wäre bei jeder Änderung ein kaum zu rechtfertigender Releasewechsel des Frameworks notwendig.

Wenn also eine Regel zu verändern ist, betrifft das nur den Regelalgorithmus im Repository; das übrige Framework der Anwendung bleibt von Veränderungen unberührt.

Eine ebenfalls überaus wichtige Rolle kommt dem Faktor Datenmanagement zu, denn erst darüber erschließen sich die Relevanz und die Zusammenhänge von Daten und Informationen. Mithilfe von Metadaten wie Elementtypen und deren Attributen lassen sich dabei Relationen zwischen Elementtypen, Element-Lifecycles, Datenerzeugungsregeln und Element-Semantiken herstellen. Element-Lifecylces sind dabei dem Datenelement fest zugeordnete Prozesse, die den Zugriff zum Element steuern. Damit kann jede Geschäftsonthologie abgebildet werden.

Die Fachabteilungen greifen über eine Service Delivery Plattform auf das Framework zu und können von dort aus Geschäftsprozesse ohne Programmierung modellieren und managen. Dabei haben sie natürlich nicht vollkommen freie Hand, sondern müssen sich an die »Bauvorschriften« aus der Regelebene halten, die durch die entsprechenden Metadaten vorgegeben sind. Innerhalb dieses Rahmens jedoch lassen sich Dienste flexibel konfigurieren und kombinieren.

Externe Applikationssystem kann man, sofern die geeignete Konnektivität gegeben ist, an das SOBA-Framework anbinden. Letztere lässt sich zum Beispiel mithilfe von generischen Adaptern auf Basis von simplen Mapping-Verfahren oder dedizierten Adaptern zu speziellen Systemen herstellen. Als Mastersystem sichern die SOBA dabei in jeder Variante die notwendige Datenkonsistenz.

Industrielle Softwarefertigung hält Einzug

SOBA können – vor allen Dingen aus der geschäftlichen Warte heraus betrachtet – eine, wenn nicht die entscheidende Weichenstellung für die Zukunft sein. Denn sie bringen ein neues Entwicklungsparadigma mit sich, bei dem das finale Produkt aus den Zwischenprodukten der Zulieferer gefertigt wird.

Wie bisher auch bleibt die Technologie im Ressort IT, wo man sie in ausführbare Services umsetzt. Auf diese haben die Fachabteilungen über das Service Delivery Framework freien Zugriff, um sich quasi selbst zu bedienen und ihre Prozesse zu orchestrieren.

Software dient dazu, Daten zu verwalten und Prozesse zu unterstützen. Im Gegensatz zur klassischen Programmierung kann man mithilfe der Metadaten eines einheitlichen vollständigen Datenmodells die Datenelemente, ihre Beziehung sowie die Abläufe abbilden und mit dem SOBA-Framework zur Laufzeit interpretieren. Änderungen in den Anforderungen müssen nur in den Metadaten beziehungsweise verwendeten Services oder Regeln vorgenommen werden.

Damit schafft man Grundstrukturen für die flexible Informationsintegration von Unternehmen und unterstützt ferner eine effektive Datenkonsolidierung.

Das ergibt sich schon aus der Architektur selbst: Denn nur der Lifecycle-Prozess bestimmt ein Datenelement und ermöglicht den Zugriff auf seine Attribute. Das hat den »schicken« Nebeneffekt, dass man so für eine revisionssichere Datenhistorie sorgt, weil immer deutlich wird, wer in welchem Zusammenhang welche Änderungen vorgenommen hat.

Best Practices müssen verwirklicht werden

SOBA sind prozessgetriebene Gebilde mit der Möglichkeit, Aufgaben aus den jeweiligen Prozessschritten den entsprechenden Sachbearbeitern zuzustellen. Damit eine umfassende Governance möglich wird, bedarf es an dieser Stelle aber natürlich auch der Möglichkeit, Service Levels zu bestimmen und zu überwachen.

Zudem muss auch gewährleistet sein, dass das Referenzmodell (Service Delivery Framework) generisch arbeiten kann, damit es sich für die Anforderungen der unterschiedlichen Fachabteilungen (Geschäftsonthologien) konfigurieren lässt. Denn will man die oben beschriebene industrielle Herangehensweise umsetzen, braucht man die Option, Dienstkomponenten wie in einem Lego-Prinzip in jeder Aggregationsstufe als Vorlagen und Schablonen bereitstellen und managen zu können. Das trifft besonders auf diejenigen Geschäftsprozesse zu, die interpretativ zu deduzieren sind. Auf diese Weise kann jedwede Modifikation unmittelbar in Betrieb gehen, ohne dass es zu einem Medienbruch aufgrund von generativen Software-Entwicklungsverfahren kommt. Darüber hinaus benötigt die Plattform eine intuitive Visualisierung sowie einfach nachzuvollziehende Basis-Modelle, die sich zur Modellierung durch die Fachabteilungen eignen.

Außerdem sollte der Faktor Informationssicherheit bedacht sein, und zwar nach Möglichkeit auch für zukünftige Anforderungen. Dabei ist nicht nur die Integration des Information Security Managements zu sehen, sondern insbesondere auch die Anforderungen rechtlicher Art, die sich aus »Basel II« ergeben. Das betrifft zum Beispiel Aspekte wie die flexible Verschlüsselung von Daten in verschiedenen Verwaltungsdomänen.

Und last but not least will auch der Faktor Skalierbarkeit berücksichtigt sein. Denn der holistische Ansatz eines solchen »System»-Modells darf nicht zu Engpässen bezüglich Kapazitäten beziehungsweise Performanz führen. Die Architektur des Frameworks selbst sollte eine Verteilung auf eine SOA-Architektur mit zum Beispiel verschiedenen Datenbankdiensten problemlos ermöglichen.

OPM sorgt für konsistente Darstellung

Wie aber lassen sich Systeme einheitlich mit einem Modell darstellen? Eine Möglichkeit dazu bietet die Object Process Methodologie (OPM) des Massachusetts Institute of Technology (MIT). Sie beschreibt Struktur, Verhalten und Zustand eines Systems in einem holistischen Modell. Damit lässt sich der Brückenschlag zwischen dem statischen SOA- und dem dynamischen BPM-Systemmodell vollziehen. Gleichzeitig gelingt so die Integration von Regeln als Services, die von statischen und dynamischen Objekten verwendet werden.

Zur System-Modellierung nutzt die OPM folgende Elemente:

·         Objekte

·         Prozesse

·         Zustände (Objekt-Status)

·         Links (prozedurale, strukturelle)

·         Relationen (Spezialisierung, Aggregation)

Während Objekte in diesem Szenario statische Gegebenheiten bezeichnen, stel­len Prozesse dynamische Vorgänge dar. Beide, Objekte und Prozesse, verfügen jedoch über Gemeinsamkeiten bezüglich ihrer Aggregation (»besteht aus») und Spezialisierung (»ist ein»). Das heißt, man behandelt strukturelle Merkmale nach der gleichen Methode. Ein »Prozess« ist ein Objekt und besteht aus (ist eine Aggregation von) anderen Objekten, zum Beispiel »Zustand« oder »Aktivität«. Jedes dieser Objekte enthält zudem weitere Attribute.

Auf den Punkt gebracht bedeutet das:

·         Objekte können nicht ohne Prozesse transformiert werden und Pro­zesse haben keine Bedeutung und Ursache ohne Objekte.

·         Objekte und Prozesse sind zwei Typen von fest gekoppelten komplementären Dingen. Der Prozess bestimmt dabei den »Lifecycle« des Objektes.

Diese Methodik ist reflexiv, das heißt, man kann sie mit ihren eigenen Mitteln erweitern, und damit vollständig, sodass man keine weiteren fremden Hilfsmittel benötigt, um das Metamodell auszudehnen.

Betrachtet man etwa ein Attribut als Objekt und ordnet ihm einen Link zu einem Editor zu, mit dem es sich bearbeiten lässt, ist das Metamodell mithilfe seiner eigenen Mittel erweitert.

Auf der Ebene der Metamodellierung werden die oben definierten »OPM-Objekte« genau wie die Business-Elemente auf der Ebene der (System-)Modellierung verwendet. Möglich wird dies durch den Rückgriff auf die SOA-Prinzipien.

Drei Etappen führen zum Ziel

Der Aufbau eines derartigen Frameworks lässt sich also in drei wesentliche Schritte untergliedern.

1. Definitionen des Datenmodells:

·         Welche (Daten-)Objekte sind für das Business nötig?

·         Welche Parameter (Attribute) benötigen die Objekte?

·         Welche strukturellen Beziehungen bestehen zwischen den Objek­ten?

·         Wie sind die Gültigkeitsbereiche der Objekte?

·         Welche (Geschäfts-)Regeln sind anzuwenden?

·         Wie sollen Daten abgelegt werden (Taxonomien)?

2. Definition der Prozesse zur Verwaltung der Daten:

·         Wie werden Datenobjekte erzeugt?

·         Wie werden Objekte verändert?

·         Wie werden Objekte gelöscht?

·         Jeweils:

o    In welchen Schritten wird dies durchgeführt (Pflichteinträge, Genehmigungen etc.)?

o    Wer ist zuständig?

·         Welche (Entscheidungs-)Regeln liegen zugrunde?

3. Prozesse zum Betrieb der Business-Applikation:

• Welche Datenobjekte werden benötigt?
• Welche Aggregationen sind notwendig?
• In welcher Form ist ihr Lifecycle betroffen?
• In welchen (Prozess-)Schritten wird vorgegangen?
• Wie wird der Gesamtvorgang dokumentiert?
• Wer ist zuständig?
• Welche (Entscheidungs-)Regeln liegen zugrunde?
• Welche Service Levels sind einzuhalten für einen gesamten Geschäftsvorgang beziehungsweise die Einzelschritte (Aufwände, Termine, Dringlichkeiten)
• Welche Aktionen sind zur Vermeidung von SLA-Verletzungen notwendig (Eskalationen, Notfallpläne etc.)?

Resümee

Die Entscheidung pro SOBA ist mit weitreichenden Auswirkungen verbunden und kann bei einer falschen Herangehensweise leicht zum Desaster werden. Denn sowohl der pekuniäre als auch der temporäre Aufwand sind nicht unerheblich.

Eben deshalb gilt es, das Risiko von vornherein gering zu halten. Das heißt zunächst, dass man die Umsetzung getreu der Devise »Think big, start small« nur in einem überschaubaren Rahmen betreiben sollte. Und das gilt umso mehr, weil man eine graduelle Expansion über bestehende Anwendungen mit kalkulierbarem Aufwand betreiben kann.

Wer das aber beherzigt, darf auch auf den Return on Investment hoffen, und der ist in jeder Hinsicht vielversprechend: mehr Anschaulichkeit, eine weitaus einfachere Bereitstellung von IT-Services und natürlich auch eine effektive Daten- und Prozesskonsolidierung, um nur einige Aspekte zu nennen.

Das wirklich Entscheidende ist jedoch, dass SOBA eine Möglichkeit zum Brückenschlag zwischen IT und Fachabteilungen bieten und damit eine reelle Chance, das Business mithilfe der IT zu leben.

Knut Lünse

____________________________________

Knut Lünse ist CTO der SAPHIR GmbH, München

Ein SOBA-Framework besteht aus vier paritätischen Säulen.

Ein integriertes semantisches Datenmodell mit Bezeichnern aus dem Geschäftsvokabular bildet eine wesentliche Voraussetzung für ein SOBA-Framework.

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012  ap Verlag GmbH