SOA den Weg zum Mainframe ebnen
Der nächste Schritt für Unternehmen
Mainframes waren die erste Rechenplattform der Unternehmens-IT. Mit dem Industriewachstum wurden Mainframes kontinuierlich weiter entwickelt und in die vielfältigen Formen der Unternehmensarchitektur integriert. In der Tat kommt den Mainframes als erstes Rechnersystem eine Sonderrolle im Hinblick auf die Unternehmensarchitektur zu, da Mainframes praktisch an allen Architekturrichtungen beteiligt waren. Anfänglich war der Mainframe sogar der Inbegriff von IT, indem er die Architektur verkörperte. Mainframes wurden zu Beginn als monolithische Standalone-Systeme eingesetzt. Die vorherrschende Einstellung jener Tage war, dass alle Applikationen sich auf einer einzigen, umfangreichen Rechenplattform, nämlich dem Mainframe, befinden könnten und sollten. Die Applikationsintegration wurde ganz unkompliziert über die auf dem Großrechner vorhandenen Datenbestände und abrufbare Transaktionen abgewickelt. Mit der IT-Entwicklung zu Client/-Server- und anderen Nicht-Mainframe-Architekturen veränderte sich jedoch auch die Integration.
Enterprise Application Integration (EAI) entstand aus der Notwendigkeit verschiedene Systeme zu integrieren, ohne jeweils projektspezifisch maßgeschneiderte Punkt-zu-Punkt-Schnittstellen zu verwenden. EAI lieferte das Versprechen, das verwickelte Knäuel von Schnittstellen zu entwirren. Dieses war in der Folge entstanden, um jedes Datenzentrum des Unternehmens mit einzubinden. Mainframes bildeten noch immer die Grundlage der Unternehmens-IT, allerdings gab es nun Tausende von Schnittstellen, die andere Systeme über eine Vielzahl von Punkt-zu-Punkt-Lösungen und applikationsspezifischen Standards und Semantiken versorgten. Für den Mainframe war MQ die Antwort zur Standardisierung von EAI.
Jedoch zeigte die Erfahrung rasch, dass EAI das verwirrte Knäuel der Integrationspunkte nicht auflöste. EAI erleichterte die Integration. Jedoch verhinderte ein Mangel an Standards bezüglich der EAI-Werkzeuge verschiedener Anbieter, dass diese gut miteinander harmonierten. Zudem waren die Integrationssemantiken nach wie vor gezielt dafür entwickelt, die Anforderungen der spezifischen Punkt-zu-Punkt-Applikationsintegration eines Projekts zu erfüllen.
Die Serviceorientierte Architektur (SOA) wird derzeit als Retter der Unternehmensintegration gepriesen, da endlich wiederverwendbare Schnittstellen erzeugt werden, um die komplexe Punkt-zu-Punkt-Integration zu lösen. SOA bietet in der Tat eine saubere Lösung für den Standardprozess an, und da SOA keine Technik erfordert oder vorschreibt, liefern die meisten SOA-Initiativen leicht verwendbare Services wie etwa Webservices. Was jedoch den zweiten Punkt, die Erzeugung wiederverwendbarer Services betrifft, ist es nützlich, auf die Erfahrungen mit der Erzeugung wiederverwendbarer Integrationspunkte zurückzublicken.
Mainframe-Applikationen stellen einen Großteil der Geschäftsprozesslogik dar. Als Beispiel lässt sich eine Mainframe-Anwendung betrachten, die ausschließlich zur Auftragsbearbeitung verwendet wird. Mit der monolithischen Mainframe-Anwendung würde man eine Anzahl von Subprozessen abwickeln, die an der Auftragsbearbeitung beteiligt sind wie zum Beispiel Auftragseingang, Debitoren-, Kredit- und Kundenverwaltung. Das Mainframe-System und der damit verbundene Applikationsablauf repräsentieren und unterstützen die Geschäftsprozesse des Unternehmens. Da sich jedoch die Geschäftsprozesse des Unternehmens weiter entwickeln, entwickelt sich auch die Applikationslogik des Mainframes weiter oder wird schließlich ersetzt.
Sobald sich die Rechnerumgebung hin zu einer heterogenen Umgebung aus Mainframe, Client/-Server und anderen Techniken entwickelt hat, wird die Integration die Makro-Geschäftsprozesse mit den jeweiligen Fähigkeiten der Anwendungspakete auf jeder einzelnen Plattform widerspiegeln.
Betrachtet man nun, was mit dem Mainframe-Betrieb geschieht, wenn das Unternehmen entscheidet, die Funktionen "Kundenpflege" und "Kreditverwaltung" mit einem Programmpaket zu ersetzen, um eine Konsolidierung der Geschäftsprozesse für Kunden- und Kreditpflege über mehrere Abteilungen hinweg zu ermöglichen.
Folgendes Szenario für diesen Makro-Geschäftsprozess ist vorstellbar: Die Verantwortlichen für Kundentransaktionen wäre anfänglich dafür zuständig, die Kundenbasis zu erstellen. Keine Aufträge einzelner Abteilungseinheiten könnten erteilt werden, bis jener Kunde im System angelegt ist, und die Kreditabteilung könnte über einen angemessenen Kreditrahmen entscheiden, basierend auf den Konditionen und der Kreditwürdigkeit des jeweiligen Kunden. Die IT-Abteilung bestimmt ferner, dass die neue Client-Server-CRM-Suite der Master der Kundendaten ist und eine Batch-Schnittstelle zum Auftragseingangssystem auf dem Mainframe erstellt wird, um im System die neuesten Informationen einzuspielen beziehungsweise zu aktualisieren.
Die IT-Schnittstelle würde dem Makrogeschäftsprozess mit einem formalen Dokument entsprechen, das heißt der Schnittstelle zwischen den Kundendatensystemen, die die Informationen zwischen der Kreditabteilung und der Auftragsbearbeitungsabteilung nachts synchronisiert.
Selbstverständlich wird dann eine weitere Schnittstelle zu einem Reporting-System geschrieben, um Management-Reports bereit zu stellen und eine andere, um die Debitoren abzugleichen oder, um ein SFA-Produkt auf den neuesten Stand zu bringen, sowie beispielsweise eine weitere, um den webbasierten Auftragsstatus zu aktualisieren.
Doch gibt es abgesehen von der Schnittstellenvermehrung noch einen anderen Punkt, der im Zusammenhang mit der Granularität des Geschäftsprozesses steht, den diese Schnittstelle unterstützt. Die Schnittstelle ist ein Spiegelbild des Geschäftsprozesses. Jedoch spiegelt sie eine sehr lange und umfangreiche Differenzierung des Geschäftsprozesses (Auftragsverarbeitung versus Kundenmanagement) wider. Betrachten lassen sich nun die Auswirkungen auf die Pläne unserer Abteilung, spezielle Preisangebote auf Basis des Gesamtumsatzes über mehrere Abteilungen hinweg anzubieten.
Das CRM-System dokumentiert den Gesamtumsatz der Abteilung. Jedoch wurde diese Information über die Schnittstelle nicht zum Mainframe zurückgeleitet. Und anstatt auf die IT zu warten, um die Schnittstelle zu aktualisieren, wird das Verkaufsteam das Standard-Desktop-Integration-Tool seiner Wahl verwenden, seit es PCs gibt. Mit dem Spreadsheet wird die Information aus dem CRM-System geholt, der Auftrag aus dem Auftragsmanagementsystem bearbeitet und der entsprechende Preisnachlass festgesetzt.
Der Mangel an Agilität und Flexibilität in IT-Systemen und die damit verbundene Integrationsproblematik hat einen ganzen Sekundärmarkt mit PC-basiertem Integrationsbedarf und -verfahren entstehen lassen. Terminal-Emulatoren verfügen über Scripting-Sprachen, um Informationen vom Mainframe zum Client herunterzuladen. Client/-Server-Systeme haben die Fähigkeit, Reports lokal zu exportieren. Auch sind Desktop-Tools, die diese Dateien verwalten, bearbeiten und analysieren sehr leistungsfähig geworden. Die Anwender im Unternehmen haben gelernt, wie sie deren untergeordnete Geschäftsprozesse integrieren können, ohne die IT in Anspruch zu nehmen, um die für das Geschäft notwendige Flexibilität und Agilität zu erzielen. Keine ideale Lösung, jedoch praktikabel.
Dann kam jedoch das Internet hinzu, und ganz plötzlich erwarteten Kunden nicht mehr, es direkt mit einer Person zu tun zu haben. Die Systeme mussten so intelligent, flexibel und agil wie deren Nutzer sein.
Mit SOA wird daher nicht nur die Erwartung verknüpft, dass es standardbasiert und daher wieder verwendbar ist. Es handelt sich vor allem auch darum, dass die Integrationspunkte in das System die Details des Geschäftsprozesses widerspiegeln müssen.
Ist die Service-Definition zu grobkörnig, wird man wiederum dieselben Probleme haben, nämlich einen Mangel an Flexibilität und Agilität. Definiert man andererseits den Service zu feinkörnig, wird man den Großteil der Geschäftsprozesslogik, die in den Legacy-Assets eingebettet ist, neu in den Workflow zur Steuerung dieser Services kodieren müssen. Daher besteht die eigentliche Erwartung an SOA, um dem Unternehmen Agilität und Flexibilität zu bringen darin, dass die Service-Definition den Geschäftsprozess mit der richtigen Granularität widerspiegelt und somit eine leichte Wiederverwendbarkeit ermöglicht, um schnell unterstützende, neue Geschäftsprozesse zu erstellen.
Die Standardvorgehensweise bei der Definition und Dokumentation von Geschäftsprozessen besteht in einer Top-down-Analyse, die mit einer umfangreichen Definition der Makroprozesse beginnt. Iterativ und schrittweise werden dann die Prozesse heruntergebrochen. Zum Beispiel besteht Auftragsverwaltung aus Eingang, Änderung, Nachforschung etc. Geschäftsprozessanalyse ist keine neue Disziplin: Allerdings ist sie eine langwierige und kostspielige Methode. Häufig hat sich bis zum Zeitpunkt der vollständigen Identifizierung und Dokumentation der Geschäftsprozesse der Geschäftsbetrieb selbst bereits verändert. Und all zu häufig, wenn der Prozess detaillierter wird, hört die Analyse auf - und in der Welt von SOA, wo das Verständnis der Einzelheiten des Mikroprozesses unerlässlich ist, stellt die Detaillierung der Geschäftsprozessanalyse eine absolute Notwendigkeit dar.
Business Process Discovery (BPD) ist ein neu entstehendes Feld und umfasst Tools und Methoden, die einen Bottom-up-Ansatz zur Analyse der Geschäftsprozesse ermöglichen. Anstatt mit einem Top-down-Ansatz anzufangen, der von grobkörnig zu feinkörnig führt, untersucht BPD die aktuellen Arbeitsprozesse, startet mit den Einzelheiten und modelliert ein Bild des Geschäftsprozesses, das auf der tatsächlichen Dokumentation der erfolgten Arbeitsabläufe beruht.
Die Stärke von BPD liegt darin, sehr schnell lokalisierte Geschäftsprozesse zu entdecken, ausführlich zu beschreiben und zu dokumentieren, um die Definition und Erstellung von SOA-Services zu ermöglichen. Anstatt auf eine langwierige und kostspielige Top-down-Analyse zu warten, kann BPD sehr schnell die erforderlichen Hinweise erbringen, um intelligente Entscheidungen über die Granularität eines Services im Rahmen des ihn unterstützenden Geschäftsprozesses zu treffen.
BPD ist nicht nur schneller, sondern liefert auch eine Geschäftsprozessbeschreibung höherer Qualität. Der herkömmliche Top-down-Ansatz geht von Prozessannahmen aus, die auf Gesprächen mit Geschäftsprozessexperten beruhen. Jedoch unabhängig davon, wie qualifiziert der Experte ist und wie gut die BPA-Methodik (Geschäftsprozess-Analyse) erscheint, gibt es häufig viele Fehler in Bezug auf den Prozess. Sei es, dass sowohl Prozesseinzelheiten und -ausnahmen nicht berücksichtigt werden als auch die Tatsache, dass verschiedenen Anwender die Prozesse unterschiedlich ausführen.
Im Rahmen der Schaffung eines Services, der den detaillierten Geschäftsprozess widerspiegelt, wirken sich Schwachstellen bei der Detaillierung der Geschäftsprozesse kritisch aus. Interessanterweise besteht die Standardmethode, diese unvorhergesehenen Situationen in den Griff zu bekommen, in einer Variante von BPD, die man bei standardmäßiger Softwareentwicklung ?Testen? nennen würde. Langwierige und mühsame Testabläufe bilden die übliche Voraussetzung für jedes größere Systemprojekt und erfüllen nach dem Entwurf und Erstellen des Systems die Rolle von BPD, um alle beim Designprozess vergessenen Einzelheiten herauszufinden. Diese langsame Methode der Nachbereitung ist zwar effizient, scheint aber das Versprechen zu begrenzen, der Unternehmens-IT schließlich die erforderliche Agilität und Flexibilität zu bescheren.
SOA erfüllt das Versprechen der IT-Agilität durch die Wiederverwendbarkeit bestehender Systeme und Schnittstellen, falls die Services sachgerecht definiert sind. Die Definition und Auswahl von Geschäftsprozessen, die für einen Service in Frage kommen, sind der Schlüssel für einen Erfolg von SOA. Weder eine zu feinkörnige noch eine zu grobkörnige Definition wird zu einer kontinuierlichen Investition in den Service führen, bestenfalls zu einer Neugestaltung des Services und schlimmstenfalls zu einer Anhäufung nicht wiederverwendbarer Services.
Tools und Methoden zur Geschäftsprozessanalyse bieten eine ausgezeichnete Top-down-Analyse an, um Geschäftsprozesse in einen Zusammenhang zu stellen. Jedoch sind sie schwach beim Ableiten der Details eines Geschäftsprozesses. BPD-Tools zeichnen sich durch die Aufdeckung und Dokumentation der Geschäftsprozessdetails unter Beobachtung der realen Anwendung aus. Der gemeinsame Einsatz dieser beiden Tools kann auf schnelle Weise eine Geschäftsprozessabbildung liefern. Vollständig und detailliert ermöglicht dies den Services eines Unternehmens, den Geschäftsanforderungen schließlich gerecht zu werden und bietet eine schnelle und agile IT-Architektur, um die ständig sich wandelnden Erfordernisse aller Unternehmen zu erfüllen.
Lesen Sie mehr zum Thema
