Mit dieser strategischen Initiative gilt es, IDS Scheer ARIS Software von der reinen Geschäftsablaufmodellierung zur Ablaufausführung, Überwachung, Simulation und Optimierung heranzuziehen. Die Bedeutungen für die (hohe) Erwartungshaltung innerhalb des Markts sind enorm:
1. eine große Erleichterung für Architekten und Entwickler
2. schnellere Verfügbarkeit von Lösungen für Anwender
Die geplante Integration und den Weg zu einem geschlossenen Lebenszyklus entnehmen Sie folgender Abbildung.
1. Unterstützung für „publish-subscribe communication routing“ (Nachrichtenverteilung auf Basis von Metadaten).
2. Kommunikations-Adapter um Anbindungen zu bedeutenden Geschäftsanwendungen (zum Beispiel mySAP ERP, Siebel CRM) zu gewährleisten.
3. Unterstützung für die Bereitstellung von (Geschäfts)Abläufen auf Serverfarmen
Ein weiterer Teil von Oslo ist eine gemeinsam genutzte Repository Komponente, die Abläufe, „Web Service Contracts“ und andere Komponenten von „composite applications“ speichert und zentralisierte Entwicklung und Verwaltung unterstützt. Dieses Repository wird dann sowohl von BizTalk Server Version 6 als auch von Visual Studio (sehr wahrscheinlich mit dem Codename „Rosario“ bezeichnet und ca. 2009 verfügbar) genutzt; ebenfalls von zukünftigen Versionen der Systems Center Software wie Operations Manager, Überwachungssoftware und dem „configuration manager“ für Software UpDates und Softwarebestandsverwaltung. Die Art und Weise der Auslieferung des Repository muss noch geklärt werden – neben anderen Möglichkeiten könnte es Bestandteil vom .NET Framework „4“ sein, eine einzelne Software oder sogar ein (weiteres) Merkmal des Microsoft SQL Server Management Systems werden. Visual Studio wird weiterhin BizTalk Server die Entwicklungsumgebung und deren Mittel bereitstellen, um Kommunikations- und Geschäftsabläufe zu erschaffen.
Jedoch wird Version 6, ähnlich wie Vorgängerversionen, sehr wahrscheinlich Prozessmodellierungs- und Überwachungssoftware enthalten, die eben nicht Visual Studio benötigen, um Analysten zu unterstützen, die Geschäftsabläufe definieren und überprüfen (müssen).
Stand heute
Das bereits heute verfügbare SOA- und Geschäftsprozesssoftware-Portfolio von Microsoft spannt sich über einen breiten Bereich, der Geschäfts- und EDV-Strategie als auch Lösungsbereitstellung umfasst. Die Ansammlung gibt Verantwortlichen für Geschäftsführung, EDV-Fachleuten, Architekten und (Software)Entwicklern Handreichungen, Technologien und eine Reihe von (unterstützender) Software, um die Gesamtheit der Anwendungen und Tragweite ihrer Arbeitsweise, Entwürfe zukünftiger Anwendungen, deren Design, den Aufbau und die (weitere) Pflege, Aufrechterhaltung von SOA- und Geschäftsprozessstrategien und deren entsprechende Lösungsansätze zu gewährleisten, genauso Software im Umfeld eines Mitarbeiters in seinen Rollen zu berücksichtigen. Die Voraussetzung der Ergebnisse dieser Implementierung fach- und zeitgerechter Anwendungen und Optimierung von Geschäftsabläufen, welche tatsächlich die Produktivität anheben, die Kosten nachhaltig senken und vor allem aber organisatorische Flexibilität und rechtzeitige Anpassungsfähigkeit bedeuten, sind:
1. die (Rück)Besinnung auf bereits vorhandene (Lösungs-)Teile und Anwendungen
sowie
2. die Durchsetzung eines sich an Modellen orientierenden Vorgehens, um die Verquickung von tatsächlichen Geschäftsabläufen und Microsoft Technologien darzustellen
Weiter Information finden Sie auf der neu eingerichteten Oslo Homepage
a. „Intermediaries”, beispielsweise Ablauflogik („Orchestrations”).
b. „Off-Ramps“, beispielweise ein beliebiger Zustelldienst („Delivery Agent“), der mit einer Guidance ausgestattet ist oder ein eigens aus gewählter Zustelldienst („Custom Delivery Agent“).
Als Alternative zu den „On-Ramps“ können Dokumente von BizTalk Anwendungen entstanden sein und in die MessageBox durch folgenden Prozess gelangen:
Die erzeugten Dokumente in die MessageBox einzulegen und dass Abonnenten („Subscriber“) sie gemäß den Verarbeitungsregeln („Processing Instruction“) aufnehmen, ist genau genommen ein „StateMachine“ Muster. Diese locker verbundene Vorgehensweise, um die Architektur von BizTalk Lösungen zu errichten, ergibt hochskalierbare Lösungen und gilt als von der Industrie angenommener Weg im Sinne einer beispielhaften Mustervorgehensweise.
Einige der Schlüsselmerkmale dieser Vorgehensweise lauten:
Alles innerhalb der Microsoft ESB Guidance Anwendungen ist, in dem die BizTalk „MessageBox-Datenbank“ als Annahme und Ablieferpunkt dient, lose miteinander verknüpft. Die ESB Anleitung wurde mit dieser Architektur im Hintergrund entwickelt und benutzt sie ausführlich in ihrer Implementation.
Die Dienste und Komponenten fallen in sechs Kategorien:
Microsoft ESB Guidance (Anleitung) enthält einen Architekturleitfaden, Muster- und Erfahrungsbeispiele aus der Praxis, sowie BizTalk Server und .NET Komponenten, die es Microsoft Partnern erlauben, große und kleine ESB Lösungen auf der Microsoft Plattform aufzubauen. Ebenso besteht die Anleitung aus einer Anzahl von BizTalk Server Anwendungen. Die Anleitung liefert Softwarearchitekten und – entwicklern eine Menge häufig anzutreffender ESB Anwendungsfälle und Beispielszenarien. Diese sind innerhalb einer ESB Client Beispielanwendung zugänglich und durch eine Vielzahl veränderbarer Parameter auszuführen, um die Funktionalität der „ESB Core Engine“, der „Core Services“, des „ESB Management Portal“ und den dazugehörigen „Pipeline Komponenten“ (Nachrichtennach/-vorverarbeitung) aufzuzeigen. Aufgebaut auf einer modularen Architektur, finden viele der Microsoft ESB Guidance Komponenten als einzeln stehende Bausteine Verwendung. Somit erhalten ESB Softwarearchitekten und ‑entwickler die Flexibilität, Anpassungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen.
Wikipedia
Wikipedia beschreibt den ESB als „…eine Softwarearchitekturkonstruktion, implementiert durch Technologien, die sich in der Kategorie der „Middleware“ Infrastrukturprodukte befinden. Sie gründen sich gewöhnlich auf Standards, die grundlegende Services oder Dienste für komplexere Architekturen durch eine ereignisgesteuerte oder auf Standards basierende „Message Engine“ (der Bus) bereitstellen
IBM
IBM definiert ESB als ein System das „… einemUnternehmen erlaubt, einen umfassenden, flexiblen und konsistenten Zugang zur Integration bei gleichzeitiger Verringerung der Komplexität der zu integrierenden Anwendungen zu besitzen. Wegen der komplexen und unterschiedlichen Natur der Geschäftsbedürfnisse stellt der Enterprise Service Bus eine evolutionäre Vorgehensweise dar, die Nachrichtenorientierung, Ereignissteuerung und Serviceorientierung als Vorgehensweise vereint, um Anwendungen und Dienste zu integrieren“. Das Unternehmen beschreibt die Vorteile folgendermaßen: „… höhere Wiederverwendung von IT-Lösungsbausteinen durch Trennung von Anwendungslogik und Integrationsaufgaben, um die Anzahl, Größe und Komplexität von Integrationsschnittstellen zu verringern“ und die daraus entstehende Möglichkeit „… Dienste hinzuzufügen oder zu ändern, bei einer minimalen Unterbrechung der existierenden im Betrieb befindlichen Softwarelösung; dabei anfallende Kosten zu verringern und eingeschlossenes Risiko zu mindern, wenn sich das Geschäftsmodell ändert und neue Möglichkeiten sich ergeben.“
Sonic Solutions
Sonic Solutions geben eine umfassende Untersuchung des ESB, indem sie die hauptsächlichen Gesichtspunkte, sowohl den IT- als auch geschäftsbezogenen Nutzen diskutieren. Die Beschreibung der Voraussetzung für den Enterprise Service Bus lautet: „Um Altes und Neues zu integrieren, benötigt eine Service Orientierte Architektur (SOA) eine Infrastruktur, die sich an jede IT-Ressource anbindet, unerheblich ob deren Technologie(-herkunft) und wo immer sie sich befindet“.
TIBCO
TIBCO Software definiert ESB als „… eine standardbasierte Kommunikationsschicht in einer Service Orientierten Architektur (SOA), die es ermöglicht, Dienste über mehrere Kommunikationsprotokolle zu benutzen, um die Verbreitung und das Verwalten von Diensten zu vereinfachen und die Wiederverwendung dieser in heterogenen (EDV-) Umgebungen zu fördern“. Der Hersteller schlägt vor „… um diese Fähigkeiten bereitzustellen, sollten ESBs beides unterstützen, zum einen offene Standards und zum anderen proprietäre Technologien: Dazu gehören Web Dienste und UDDI-basierteVerzeichnisse, um Dienste zu erkennen und zu veröffentlichen, Java Message Service (JMS) und andere, weit verbreitete Nachrichtenprotokolle, standardbasierte (XML) Transformationen und einfache Dokumentenweiterleitung“.
David Chappel
In den Ausführungen seines Buchs „Enterprise Service Bus” (ISBN: 0596006756), hält der Autor David Chappel fest, dass, „statt mit den traditionellen Nabe und Speiche („Hub and Spoke”; siehe auch Abbildung unten) Architekturen von unternehmensweiten Anwendungsintegrationsprodukten konform zu gehen, liefert der Enterprise Service Bus einen sehr breit verteilten Ansatz für Integration“. Er fügt hinzu, dass, „… [er] ausgestattet [ist] mit einzigartigen Fähigkeiten, die es einzelnen (Arbeits-) Bereichen oder Geschäftseinheiten erlauben, ihre Integrationsprojekte schrittweise, in kleinen Häppchen, auszubauen. Dabei erhalten die Abteilungen ihre Kontrolle vor Ort und Unabhängigkeit. Trotzdem sind sie in der Lage, jedes (Integrations-) Projekt in ein größeres, umfassenderes Integrationsgefüge oder Netz(werk) einzubinden.“
Der Softwarehersteller Microsoft hat den Anschluss an die bisherigen Enterprise Service Bus (ESB) Marktführer hergestellt, schickt sich nun aber selbst an, eine führende Rolle zu übernehmen.
Die Vorstellung des Microsoft ESB auf Basis des „BizTalk Servers 2006“ erfolgte bereits vor Jahresfrist auf der Microsoft SOA und BPM Konferenz in Redmond im Oktober 2006. Zurzeit ist die CTP3 (Community Technical Preview 3) allgemein verfügbar, dazu gab es eine eingeschränkt verfügbare Betaversion für ausgewählte BizTalk Server Partner. Die Veröffentlichung des ESB erfolgt laut Hersteller lizenzkostenfrei im erweiterten Lieferumfang von BizTalk Server 2006 R2.
In folgenden Posts lesen Sie relevante Aspekte zum geplanten Microsoft ESB: ausgehend von allgemeinen Grundlagen zu ESB, über den geplanten Funktionsumfang, bis zum Anwendungsszenarien.
Die Kostendynamik offenbart sich in einer Vielzahl von bekannten und manchmal durchaus Unstimmigkeit verbreitenden Art und Weise. Ändern sich beispielsweise die Geschäftsbedingungen, dann verändern sich ebenso die Anforderungen an das gesamte Gefüge der Geschäftsabläufe:
Eine neue (Code-basierende und – abhängige) Auslegung der Geschäftslogik war anzufordern, die unweigerlich weitere, andere typisch IT-getriebene Zyklen von Softwareentwicklungen nach sich zieht. Hersteller bieten daher oft gern eine „Formularsoftware“ an, die HTML-basierende Lösungen erstellt. Leider sind sie oft proprietär, die dann wiederum zu höheren Kosten in der Anpassung, Wartung und Pflege führen. Entwicklerbezogene Werkzeuge bestätigen und wahren weiterhin, dass die IT (Abteilung) allgemein der Flaschenhals bleibt. Mit der Zeit behindert die Bürde der IT (allgemein) die Beweglichkeit des (täglichen) Geschäftsablaufs und die Ermächtigung und Befähigung des Anwenders. Gleichermassen verschlimmert diese Situation die gefühlte „Trennung durch die IT (Konstellation)“ im Unternehmen oder sogar bei angeschlossenen Partnern und gibt stetig zunehmender Verärgerung der Benutzer und einer manchmal bereits um sich greifenden Ohnmacht (über die scheinbar festzementierten Zustände) zusätzliche Nahrung.
Ein Blick nach vorn
Auf der anderen Seite liefern wahre BPM Systeme das Rüstzeug für Entwicklung und Verteilung, aber noch wichtiger das System liefert ein vollständiges Gerüst. Ein Gerüst, das sowohl die zugrunde liegende Infrastruktur bereithält, welche die reibungslose Ablieferung von Geschäftsablauf und deren Prozessbausteinen gewährleistet, die untereinander durchaus verknüpft sein dürfen und die darum sich befindende technologische Umgebung. Das gleiche besagte Gerüst, gewährleistet eine Umgebung in der die IT (allgmein) und das (abstrahierte) Geschäftsleben zusammenarbeiten. Eine Umgebung, in der die darin Beteiligten fortlaufend ihre Arbeitsumgebung (kritisch) überwachen und (konstruktiv) verbessern, ohne dabei selbst für sogar kleinste Änderungen die Dienste der IT (Abteilung) nachzufragen. Genau genommen und wirkungsvoll fördert das Gerüst, die Abstraktion von genau angepassten Programmiercode in (immer weiter) wiederverwendbare Komponenten von Geschäftsabläufen (oder SOA Serviceleistungen). Teile oder Services, die Verantwortliche (für Prozesse), Beteiligte oder sogar Anwender direkt mit grafisch unterstützter Software in wiederholt ausführbare XML-basierende Business Process-Modelleselbständig oder sogar eigenständig zusammenstellen.
Diese Art von Funktionalität stellt sich wesentlich breiter auf als was bisher mit rein „ablauftechnisch orientierten Modellen“ möglich schien. Die nun erhältliche Funktionalität gestattet endlich die Anwendung(smöglichkeit), diskrete Elemente bestehender Vor,- und Altsysteme zu integrieren (dabei die bereits getätigten Investitionen erfolgreich zu bestätigen), aber auch die Fähigkeiten allgemeiner Softwareprodukte wie beispielsweise Microsoft BizTalk Server oder SharePoint Portal Server zu erweitern. Anstatt eingebettete, elektronische „Formularsoftware“ bereitzustellen, benutzt und sichert das BPM-System bereits vorhandene „Formularsoftware“ (als Technologien) innerhalb von ASP.NET, Microsoft Office System 2003 InfoPath, JSP, Windows Forms unter anderem, um (deren) „Formulare“ als wieder benutzbare, wertvolle IT-Bestandteile durch das vorher erwähnte Gerüst zugänglich zumachen. Das regelt das zugrunde liegende Gerüst auf eine verblüffend einfache Weise, in dem es die Benutzerschnittstelle (Interface) als Formular von der Logik des (anpassbaren) Geschäftsprozesses und allen anderen IT-Anwendungsbezügen (inhaltlich) trennt. Damit zeigt das nun bekannte Gerüstmodell zum ersten Mal dieses beispielhafte Merkmal für eine beliebige (n-fache) Ebenenstruktur auf, da sich ebenso Prozessmodelle von beliebigen darunter liegenden Prozessen oder-modellen bilden lassen.
Ja sogar darüber hinaus besteht das Prozessmodell nicht nur als reine visuelle (Ablauf-) Beschreibung, sondern es ist identisch mit der ausführbaren Geschäftslogik. Abgespeichert jetzt in XML als bisher in eigens geschriebenem Code, wird sie während der Laufzeit korrekt interpretiert. Deshalb ist es möglich, sollte es der Anwendungsfall notwendig machen, dass der dafür verantwortliche Mitarbeiter flexibel das Modell (der Geschäftlogik) beliebig anpasst. Die Fähigkeiten moderner BPM- Systeme wertvolle IT-Bestandteile (von Geschäftsprozessen) auf der Ebene des Prozessablaufs zusammenzustellen ist eigens durch die auf XML-basierende Architektur möglich, was etwa 2001 heranreifte. Viele andere Arbeitsfluss darstellende Softwareprodukte verkleiden sich als „wahrhaftige BPM Systeme“ und entstanden bereits in den 90ziger Jahren, also lange bevor XML und Web Services heranwuchsen.
Die bisherige Ablauflogik durch weitverbreitete Technologien seit den 90er Jahren, als auch das Zentralstück vieler etablierter Hersteller, lässt dynamische oder sich laufend anpassbare Verbesserungen im Lebenszyklus nicht zu. In der Regel gilt dies auch für systemzentralistische EAI Plattformen. Tatsächlich bedeutet BPM aber die gemeinsame Instrumentation aller Gesichtspunkte des Verhaltens von Geschäftsabläufen:
1.) Mensch-zu- Mensch (Zusammenarbeit)
2.) Mensch-zu-System (Integration des (PC-)Systems)
3.) System-zu-System (EAI- und B2B-Integration)
Während viele der Hersteller von geschäftsablaufspezifischer Software darüber sprechen, Mensch-zu-System oder Systemzu-System Bedürfnisse zu adressieren, tun sie dies in der Regel auf der Aufgabenebene alleinig durch dafür geschriebenen oder erzeugten Code: Jegliche Veränderung im Arbeitsprozess oder den Vor-, Serversystemen verlangt nach einer Anpassung – oder wenigstens einer Bestätigung – an jedem Punkt, an dem ein Austausch stattfindet.
Darüber hinaus zielen diese Arten von Software darauf ab, Punkt (zu Punkt) Lösungen zu erstellen, die ein einziges System- oder Geschäftsproblem lösen; möglicherweise dabei eine jeweils verschiedene Prozessarchitektur oder Vorgehensweise anwenden. Damit sind sie nicht Teil eines gültigen Gerüsts, das eine allgemein benutzte Infrastruktur und gemeinsame Vorgehensweise liefert.
Auf der jeweiligen Technologieebene bedeutet diese Vorgehensweise, dass die Modelle der Geschäftsabläufe in einer entwicklertypischen Umgebung mit seinen Werkzeugen entstehen. Die erkannte Geschäftslogik schlussendlich in festen Code umgesetzt wird, dann entsprechend mit speziellen Anpassungen erweitert an Vor-, Alt- und wichtige Serversysteme angeschlossen. Das Ergebnis präsentiert sich als ein monolithisches, starres Gebilde, deren Anwender (und Architekten) sich völlig auf die IT-Abteilung verlassen, um auch nur geringste Änderungen vorzunehmen.
Die Architektur führt mehrere Abstraktionsstufen für die RFID Laufzeitumgebung ein. Ein zentrales Element ist die abstrakte Schnittstelle „Device Service Provider Interface“ (DSPI). Deren Aufgaben heissen die vereinheitlichte Kommunikation und Handhabung von RFID Endgeräten (Reader und Printer) und die Normalisierung unterschiedlichster Protokolle (auch Legacy/Altprotokolle). DSPI ordnet sich in die Schicht „RFID Vorverarbeitung und Dienste Schicht“ (siehe Abbildung unten) ein. In dieser Schicht findet auch eine ereignisorientierte Vorverarbeitung statt. Hierzu kann der Entwickler mitgelieferte Komponenten verwenden – Anwendungsbeispiele hierfür sind die Verwendung des Microsoft BizTalk Server 2006 R2 Geschäftsregelsystems und die Integration der RFID Ereignisse in eine Microsoft SQL Server Datenbank (2000/2005). Auch kann der Entwickler eigene Softwarekomponenten schreiben und diese bei der Vorverarbeitung verwenden. Die Geschäftsprozessintegration in einer RFID Lösung übernimmt Microsoft BizTalk Server 2006 R2 selbst in der Schicht „Geschäftsprozessintegration und Business Intelligence“. Hierzu sind verschiedenste am Anwendungsfall orientierte Integrationen von Microsoft BizTalk Server 2006 R2 und BizTalk RFID möglich. Sinnvoll erscheint auch die Auswertung der ereignisgesteuerten Vorverarbeitung und den darauf basierenden Geschäftsprozessen mit Business Intelligence, um aktuelle Stati und Trends in die Entscheidungsfindung mit aufzunehmen.
Zur Verfügung stehen X12 (Standards 2040 bis 5030), EDIFACT (Standards D93A bis D05B) und HIPAA (EDI Standard im amerikanischen Gesundheitsbereich). Die Vielzahl der Schemata und die nahtlose Integration der EDI Funktionalität in BizTalk Server, verbunden mit umfassenden Überwachungsfunktionen und ausgeklügelter Fehlerbehandlung, ermöglichen eine effizientere Lösungserstellung und schnellere Integration von Handelspartnern, um den Anforderungen des Marktes genüge zu tragen und auch sich und dem Anwender Wettbewerbsvorteile zu schaffen. Die im Lieferumfang enthaltene Migrationssoftware für bestehende Lösungen auf Basis des BizTalk 2004/2006 “Base EDI Adapter” und BizTalk HIPAA Accelerator (Version 3.0 und 3.3) ermöglicht die Migration von Artefakten zur Softwareentwicklung und zum Betrieb der resultierenden Lösung.
Die Abbildung unten zeigt ein Laufzeitbeispiel zum Versand von EDI Dokumenten. BizTalk Server 2006R2 empfängt Dokumente eines bestimmten Formates über einen beliebigen Adapter (bspw. „Line of Business“ Anwendung/System wie ERP, CRM), bereitet diese nach dem erfolgreichen Empfang auf (bspw. dekomprimieren des Austauschs, Prüfung der Signatur, Entschlüsselung des Dokumentes, Transformation des Dokumentes nach EDI, Senderbestimmung (Party resolution). Über den Mechanismus „Batching“ fasst BizTalk Server optional Dokumente auf Basis konfigurierbarer Bedingungen zusammen (bspw. Dokumente an einen bestimmten Handelspartner, welche dann beispielsweise alle 8 Stunden auf einmal übertragen werden) und versendet diese abschließend.
Ein durch die “Drummond Group” zertifizierter AS2 (Applicability Statement 2) Adapter komplettiert die EDI Funktionalität und befähigt den BizTalk Server zur anerkannt sicheren EDI Datenübertragung im Internet (EDIINT).
1. Zum einen kommuniziert ein WCF Client mit einem BizTalk Server 2006 R2 WCF Dienst oder
2. BizTalk Server 2006 R2 ist WCF Client eines anderen WCF Services/Dienstes.
Die Funktionalität und Konfiguration ähnelt jenen der SOAP-Adapter in den Produktversionen 2004 und 2006, umfasst jetzt jedoch nativ WS-* Standards und eine Vielzahl an neuen Protokollen (TCP, NamedPipe, MSMQ, …) – die vollständige Liste und Ausprägungen entnehmen Sie bitte Abbildung 2.
Die WCF Adapter Wizzards ermöglichen eine effizient gesteuerte Veröffentlichung von Ablauflogik und Schemata zu WCF Diensten im Internet Information Server (IIS), dem WebServer der Microsoft Plattform (Version 6 bei Windows Server 2003 und R2 oder XP, Version 7 bei Longhorn/Vista). Dies ist zum einem möglich für Dienste als „WCF HTTP Service“ als auch für WCF Dienst Metadaten (alle „in-process“ und „isolated“ Adapter, siehe Spalte Host Typ in der Abbildung unten) . Unterstützt durch Wizzards gestaltet ein BizTalk Softwareentwickler die Konsumierung von externen WCF Diensten innerhalb eines Geschäftsablaufs. Ein Durchlaufen des Wizzards erzeugt notwendige Implementierungs- und Laufzeitartefakte wie bspw. Schemata, PortTypen.
Durch den Einsatz „WCF-WsHttp“ erreichen Sie Interoperabilität zu Diensten die folgenden Standards entsprechen oder einer gewünschten Untermenge derer: SOAP 1.2 Messaging, WS-Addressing 2005/08, WSS SOAP Message Security 1.0/1.1, WS Secure Conversation / WS Trust, WS Atomic Transactions / WS Coordination und WS Metadata Exchange.
Microsofts eigene Einordnung
Microsoft ordnet diese Produktversion, BTS2006, als die zentrale Microsoft Software ein. Dies gelang durch eine durchgängige strategische Plattform und Produktplanung:
1. BizTalk Server selbst als Produkt treibt andrere Produkte und weitere Frameworks,
2. BizTalks Server nimmt auch Einfluss auf die Strategie der gesamten Microsoft Plattform.
Die Produktversion 2006 wirkte auf maßgeblich große Teile des .NET Frameworks 3.0. für Kommunikation (Windows Communication Foundation, Kurzform WCF) und Ablauflogik (Windows Workflow Foundation, Kurzform WF) ein und prägte sie entsprechend - Mitglieder des Microsoft BizTalk Produktteams beteiligten sich aktiv an der .NET 3.0 Entwicklung, um dann die somit entstandenen, verallgemeinerten Bausteine für Kommunikation und Ablauflogik wieder in die Produkte als eigene Lösungsbausteine aufzunehmen. Bei der Entwicklung der Produktversion 2006 Release 2 (BTS2006R2) entschied sich Microsoft die Adapterentwicklung für .NET Entwickler zu vereinfachen und zu verallgemeinern, ebenso die Adapterbenutzung für .NET Programme und Anwendungen zu öffnen. .NET Entwickler erstellen nun auf Basis des von BizTalk Server 2006 stark geprägten „NET 3.0 Line of Business Adapter Frameworks“ einen Adapter der Systeme und/oder Anwendungen (bspw. ERP-, CRM Systeme) konfigurierbar integriert; welcher dann vorzugsweise in Anwendungen von Microsoft BizTalk Server 2006 R2 verwendet werden wird oder aber direkt in .NET 3.0 fähigen Anwendungen ! Der Hersteller selbst implementiert alle zukünftigen BizTalk Adapter mit dem neuen „.NET 3.0 Line of Business Adapter Framework“. Die BizTalk Produktversion 2006 R2 und Nachfolgerversionen adaptierten sukzessive die Teile Kommunikation (WCF) und Workflow (WF) von .NET 3.0.
In folgenden Post erfahren Sie mehr über: den erweiterten Funktionsumfang, die Überarbeiteten Bausteine und die angestrebte Zeitplanung.
Die Microsoft „Connected Systems Division“ arbeitet innerhalb der „Software as a Service“ Initiative an den sogenannten BizTalk Services – Hauptbestandteil ist der Internet Service Bus (ISB). Er befriedigt die Anforderungen der Integration interner Services (bspw. für interne Systeme), Services bei Geschäftspartnern und Services im Internet. BizTalk Services sind im Stadium einer experimentellen, frühen CTP.
Anwendungsintegration:
Anwendungsintegration verbindet und fasst bestehende Anwendungen/Systeme zusammen (bspw. ERP, CRM, PDM, Datenbanken, Altsysteme). Dies können auch Anwendungen sein, die prinzipiell in Teilen dem Wesen der BTS06 Software entsprechen und neben dieser bestehen bleiben oder Anwendungen, die bei nächster Gelegenheit durch den Server ersetzt werden. Redundante Datenhaltung entfällt und kostspielige, fehleranfällige Mehrfacheingabe werden minimiert. Somit können Unternehmen Entscheidungen fällen auf Basis konsistenter Daten.
Ein Beispiel für Anwendungsintegration ist die Integration von SAP. Die dazu benötigte Funktionalität stellt Microsoft im erweiterten Lieferumfang als BTS06 SAP-Adapter zur Verfügung. Der SAP-Adapter greift dabei auf SAP-Schnittstellen zu (bspw. BAPI, Business API) mit dem Ziel, Informationsübermittlung und Informationserhalt zwischen BTS06 und SAP zu automatisieren. BTS06 Entwickler bewerkstelligen eine SAP Integration mit BTS06 Bordmitteln (Schemata, Mapping, Adapterkonfiguration) ohne weiteren Code zu schreiben. Die notwendigen Artefakte zur Lösungserstellung erzeugt BTS06 durch Analyse und Auswertung des SAP-Systems selbst bzw. SAP stellt sie bereit. Das Umsetzen einer Dokumentenstruktur (Mapping) von der SAP-Software auf die BTS06 interne Dokumentenstruktur geschieht in der Entwicklungsphase durch ein komfortables, grafisch unterstütztes Bordmittel (BTS06 Mapper, siehe Abbildung unten.
Partnerintegration
Partnerkommunikation ermöglicht die Kommunikation mit Partnern mit beliebigen Protokollen und Formaten. Austausch, Versendung, Empfang, Weiterleitung, Transformation beliebiger Dokumente mit Partnern gestaltet sich einfach.
Beispiel 1: Ein Partner übermittelt eine Bestellung in einem standardisierten Format (bspw. RosettaNet) über FTP. Die Bestellung wurde durch den Partner komprimiert, verschlüsselt und signiert. BTS06 empfängt, protokolliert, dekomprimiert und entschlüsselt das Dokument. Anschließend prüft BTS06 die Signatur und leitet das Dokument an ein Ziel (Prozess, Partner, Anwendung) weiter.
Beispiel 2: Filialen eines Einkaufsverbundes übermitteln (nicht zwingend aus BTS06) Geschäftsdokumente an einen zentralen BTS06. BTS06 leitet die Geschäftsdokumente auf Basis von Geschäftsregeln und Verarbeitungsregeln weiter oder verarbeitet diese in einem definierten Prozess.
BTS06 unterstützt in der Industrie verbreitete Protokolle und Kommunikationsmechanismen wie:
Eine Vorverarbeitung und Aufbereitung von Dokumenten nach dem Empfang beziehungsweise vor dem Versenden ist gewährleistet.
Beispiel 3: Ein Partner hat einen WebService veröffentlicht für das Reklamationsmanagement. Ein Prozess in BTS06 ruft den WebService auf und arbeitet die Ablauflogik in Abhängigkeit des Antwortdokumentes ab.
BTS06 konfiguriert Protokolle und Endpunkte, Programmierkenntnisse sind nicht erforderlich. Analog zur Anwendungsintegration erwarten bzw. erzeugen Partner Dokumente in einem bestimmten Format. BTS06 unterstützt verbreitete Formate wie XML, Flatfile und EDI (Basisfunktionaltät).
Beispiel 4: XML
XML ist Standard für maschinell- und manuell lesbare Dokumente in Form einer Baumstruktur. XML löst alte Standards beim Datenaustausch sukzessive ab. Alle relevanten Standardisierungsgremien (bspw. RosettaNet.org) etablieren XML.
Beispiel 5: Flatfile
Datenaustauschformat für Dokumente mit fest vorgegebenem Aufbau. Dokumente der Standards erinnern an Datenbankexporte älterer Datenbanksystem. Ein vereinbartes Trennzeichen separiert Datensätze. Elemente einzelner Datensätze stehen bspw. an einer absoluten Position im Datensatz oder werden auch durch ein vereinbartes Trennzeichen separiert. BTS06 hat Bordmittel, um ein Flatfile „lesen“ zu können, d.h. nach XML zu bringen. Viele Anwender setzen noch Austauschformate auf Flatfile-Basis ein (bspw. VDA Standards zum Datenaustausch in der Automobilindustrie). Spezialisierte Drittanbieter für BTS06 decken Formate wie PDF ab und bieten Erweiterungsbausteine für BTS06 an.
Beispiel 6: EDI
Electronic Data Interchange umfasst etablierte Formatstandards von Geschäftsnachrichten und deren Übermittlung. Alle EDI Standards werden in neuen Versionen in XML angebotenen, doch viele Anwender (somit auch Kommunikationspartner) besitzen funktionierende EDI Systeme und BTS06 unterstützt deswegen EDI.
BTS06 ermöglicht Ihrem Unternehmen den Zugang zu Wertschöpfungsnetzwerken, virtuellen Unternehmen. Grundlage hierfür ist die E-Business Standardisierung. E-Business Standardisierungsvorhaben verfolgen primär das Ziel der Standardisierung von Dokumentenaustauschformaten. Einige Standardisierungsvorhaben definieren auch Prozessbausteine. BTS06 kann vorgefertigte Lösungsbausteine nutzen, um den Aufbau von Handels-/Kommunikationsbeziehungen beschleunigen (reine Konfiguration, keine Programmierung). Ein Beispiel hierfür ist der BizTalk Accelerator for RosettaNet im Supply Chain Management.
Mit der Prozessintegration erreichen Sie die durchgängige digitale Abbildung, Ausführung und Überwachung dokumentgetriebener Geschäftsprozesse. Es handelt sich um beliebige Prozesse, und zwar organisatorische und/oder IT-seitige, denn der BTS06 macht in seiner Verarbeitung dieser Prozesse keinen Unterschied. BTS06 verbindet unternehmensinterne und -übergreifende Geschäftsprozesse mit verschiedensten Partnern und wichtigen IT-Standards (Kommunikationsprotokolle, Datenformate, Softwaresysteme, Dienstleistungen, etc.). Ablauflogik und korrespondierende Geschäftsregeln beschreiben die Geschäftsprozesse. Ebenso erfolgt eine Abbildung der Interaktion der Geschäftsprozesse durch Mitarbeiter und angeschlossener IT-Systeme beziehungsweise Dienstleistungen. Prozesse sind mit gewünschter Komplexität, Flexibilität und variablen Detaillierungsgrad IT-technisch aufzeig- und nachvollziehbar.
Beispiel 7: Abbildung eines Beschwerdemanagementprozess.
unternehmensübergreifender Beschwerdemanagementprozess, der einem Bestellprozess/Lieferprozess mit fehlerhafter Leistung folgt (falsche Produkte, Überlieferung/Unterlieferung, beschädigte Ware) und Prozessschritte bis zur Ersatzlieferung oder Gutschrift durchläuft.
Grafische Führungs-/Entwicklungshilfen, die im Lieferumfang eingeschlossen sind, erleichtern die Modellierung auf einem abstrakten, logisch konsistenten, transparenten Niveau – gegensätzlich zur oft verborgenen Programmlogik in einzelnen Codezeilen.
Für unternehmensinterne Prozesse gilt, dass sie sich mit (anderen) internen, externen und unternehmensübergreifenden Prozessen teilweise oder ganz synchronisieren lassen. Die einfache Vorgehensweise zur Lösungserstellung erlaubt, Prozesse mit der Implementierung zu verbinden, anschließend auszuführen. Auch erfolgt die Prozessintegration oft kombiniert mit der Anwendungsintegration.
Beispiel 8: Partnerintegration
Ihr Unternehmen veröffentlicht strukturierte Öffentliche Prozesse (siehe Abbildung oben) „Öffentlicher Prozess A“ für Partner A; „Öffentlicher Prozess B“ für Partner B zur strukturierten Partnerinteraktion/-kommunikation mit Geschäftsdokumenten. Öffentliche Prozesse mit Partnern werden mit einem oder mehreren internen Prozessen synchronisiert/verzahnt. BTS06 bezieht involvierte Systeme und Services sowie involvierte Rollen und Personen dabei mit ein.
Um allen Entscheidern, Entwicklern, Integratoren, Beratern und Projektleitern zu helfen, Entscheidungen zu beschleunigen und zu vereinfachen, befinden sich im „erweiterten“ Lieferumfang von BTS06 eine Reihe von vorgefertigten Prozessbausteinen. Die Funktionen (bspw. Ablauflogik, Interaktionsmuster, Kommunikationsendpunkte) dieser Bausteine sind unterschiedlich. Sie umfassen in sich abgeschlossene Bausteine, Teilprozesse wie etwa die Abbildung einer Rolle in einem strukturierten Kommunikationsprozess mit einer Behörde oder einem bekannte Partner. Die daraus resultierenden Verbindungsmöglichkeiten finden sich als „Packet“ zur allgemeinen Verfügung und sind logischerweise für alle gleich.
Somit können Unternehmen, beliebiger Größe, besonders auch der Mittelstand, diese „zertifizierten“ Prozessbausteine sofort und schnell einsetzen, wobei die unternehmensrelevanten Zusammenhänge und -spezifischen Gegebenheiten vorrangig gegenüber einem detaillierten IT Wissen sind.
Beispiel 9: „RosettaNet“ Prozessbausteine
RosettaNet ist eine sich selbst finanzierende, non-profit Organisation, die aus einem Konsortium größerer Computer- und elektronischer Verbrauchsgüterhersteller, elektronischer Bauteilelieferanten, Halbleiterindustrie, Telekommunikations- und Logistikunternehmen besteht. Diese Unternehmen arbeiten zusammen, um offene e-Business Prozessstandards zu implementieren. Sie begründen allgemeine Prozessbausteine, die Beschaffungsprozesse zwischen Lieferanten weltweit angleichen und beschreiben. Microsoft bietet einen BizTalk Accelerator for RosettaNet für verschiedene BizTalk Server Produktversionen an.
Online Services Computer Interface (OCSI) ermöglicht die Teilnahme an einem rechtssicheren elektronischen Datenaustausch basierend auf nationalen Normen und ist als Prozessbaustein verfügbar. So lassen sich beispielsweise Wartezeiten bei der Kfz-Zulassungsstelle vermeiden, indem alle notwendigen „Papiere“ bereits vorher elektronisch übermittelt und aufbereitet sind. OSCI gibt den Kommunikationsprozess vor. Entwickler koppeln den Kommunikationsprozess mit der Ablauflogik von internen und/oder unternehmensübergreifenden Prozessen. Interne Anwendungen wie Mitarbeiterportale oder Datenbanken werden durch Anwendungsintegration in die Prozesse integriert.
Geschäftslogikkomponente
Ein weiteres Mal zeigt BTS06 interessante Gesichtspunkte auf, wenn es sich um die Implementierung eines Workflowsystems und/oder die Migration von Anwendungen in die Microsoft-Welt dreht, wo er BTS06 als Geschäftslogikkomponente Anwendungen und Systeme zentral steuert.
Beispiel 11: Ein Benutzer will einen Workflow anstoßen (z.B. Genehmigungsverfahren), lädt dazu ein neu erzeugtes InfoPath Formular (siehe Abbildung unten, Punkte 1). Der Benutzer füllt das Formular aus (siehe unten, Punkt 2) und speichert es zurück auf SPS (siehe unten, Punkt 3). Formulardaten werden durch BTS06 abgeholt (siehe unten, Punkt 4) und weiterverarbeitet (z.B. Dokumententransformation, anstoßen eines internen Workflows, Anwendungsintegration mit SAP oder einer Datenbank).
Die genannten Einsatzgebiete zeigen die sehr vielfältigen Möglichkeiten der Software auf. Beliebige Kombinationen der Einsatzgebiete (gleichzeitig, nacheinander) sind möglich. Eine BTS Lösung wächst mit den Anforderungen und Prozessen („start small - think big“).
Hinweis: Eine weitere Detaillierung der Einsatzgebiete von Microsoft BizTalk Server 2006 in einer BPM Anwendung finden die auf im Blogeintrag Entwickler.
Hinweis: Eine entscheiderorientierte Darstellung für Microsoft BizTalk Server 2006 (BTS06) und BPM finden Sie auf der Seite Blogeintrag Entscheider.
Ansatz:
Verbinden Sie mit BTS06 verschiedene Softwarewelten und setzen Prozesse und Kommunikationsflüsse sicher, einmalig und daher arbeitssparend um. Darüber hinaus verbindet BTS06 interne und externe, in sehr unterschiedlichen IT-Welten gelagerte Geschäftsprozesse.
Folgen:
1.) Erlangen Sie Prozesstransparenz:
Prozesse werden für Beteiligte transparent. Entscheider und/oder Sachbearbeiter ermitteln Prozessstati mit bereitgestellter Analysesoftware für Prozesse (z.B. auf Basis von Microsoft Excel, befüllt mit aktuellen BTS06 Daten) und ergreifen Maßnahmen auf Basis einer aktuellen, vertrauenswürdigen Datenbasis. Steigern Sie Ihre Kommunikationstransparenz mit transparenter, nachweisbarer Kommunikation mit Partnern. Senken Sie Kostens bei täglichen Aufgabenstellungen. Um den Server herum angesiedelte, unterstützende und weiterführende Dienstleistungen vervollständigen seine und Ihre Leistungsfähigkeit.
2.) Automatisieren Sie Routineaufgaben:
Die Unterstützung namhafter Gremien und die stetig sich vergrößernde Anzahl von Adaptern (bspw. Protokoll POP3, System SAP) und Acceleratoren (bspw. RosettaNet) durch unterschiedliche Hersteller verleihen BTS06 Gewicht. Das erleichtert es Unternehmen, besonders auch dem Mittelstand, den Einsatz von BTS06 schneller zu befürworten und tägliche Routineaufgaben zu automatisieren. Das geht einher mit deutlichen Einsparpotenzialen und dem optimalen Einsatz der eigenen Mitarbeiter, die an verzahnten Prozessen von unternehmensweiter und -übergreifender Bedeutung beteiligt sind.
3.) Gewinnen Sie von der Vielseitigkeit im Einsatz:
BTS06 glänzt durch seine Vielseitigkeit. Anwendungsintegration, Partnerintegration, Prozessintegration, Nutzung vorgefertigte Prozessbausteine, Geschäftslogikkomponente bieten sich ergänzende Einsatzgebiete. Durch seine zahlreichen, leicht anzuwendenden und schnell zu erlernenden Bordmittel erleichtert der Server es, die unternehmensspezifischen Belange in den Vordergrund zu rücken und dabei die IT-relevanten Themen auf ein Minimum zu begrenzen.
Partner Ihres Unternehmens (bspw. Logistik, Dienstleister, Behörden) haben:
stellen diese für Sie zu Teilen bereit. Diese gemeinsame Prozesskette erfordert eine Ablaufsteuerung (bspw. Vorgänger- und Nachfolgerbeziehungen). Angemessene Reaktionen auf veränderliche Prozesse intern wie extern (der Partner) gewährleisten zunehmend Ihren Unternehmenserfolg. Eine weitere Herausforderung im Unternehmensalltag ist die Aufrechterhaltung verlässlichen Datenaustauschs mit unterschiedlichen Geschäftspartnern entlang gemeinsamer zielgerichteter Prozessketten.
Microsoft BizTalk Server 2006 (BTS06) organisiert und koordiniert in seinem Wirkungsbereich reale Prozesse und deren Beziehungsgeflecht von:
BTS06 bündelt und strukturiert Prozesse, wählt für Vorgänge die richtige Reihenfolge aus. Dies ermöglicht Prozessmanagement, schafft Prozesstransparenz und ein Unternehmen kann sich auf die laufende Überprüfung von Einsparungsmöglichkeiten und Prozessoptimierung konzentrieren. BTS06 passt sich einer bereits vorhandenen System- und Prozesslandschaft (bspw. CRM, ERP, Altsysteme) an, ermöglicht eine Koexistenz und Integration von Systemen und fasst Teilprozesse zu einem ganzen Prozess zusammen. Gestalten, verzahnen und synchronisieren Sie ihre unternehmensübergreifenden Prozesse mit internen Prozessen. Dies ermöglicht granulare Gestaltungsmöglichkeiten der Aufteilung intern/externe Prozesse und ihr Unternehmen führt Anpassungen (bspw. Einbindung neue Partner) schnell durch.
Fazit:
Eine auf Microsoft BizTalk Server 2006 (BTS06) basierende Business Process management (BPM) Lösung bietet Flexibilität (bspw. schnelle Etablierung einer Geschäftsbeziehung), Anpassungsfähigkeit (bspw. Änderung der Prozessablauflogik) und Wandlungsfähigkeit (bspw. Entwicklung neuer Dienste) und ermöglicht Ihnen erfolgreiche BPM Vorhaben.
Gartner publizierte schon im Feb-06 in englisch seine Position zu Business Process Management (BPM): BPM bringt grundlegende Änderungen für Ihr Unternehmen, wie Sie Ihre Prozesse planen, implementieren, bereitstellen und betreiben.
Kernaussagen sind:
Überblick
Overview (engl.):
