SOA - Service Orientierte Architektur - Neuer Wein in alten Schläuchen?

Wenn gewisse Marketing-"Groups" sich dafür entscheiden, neue Abkürzungen zu erfinden und mit Prozentzahlen als Prognosen den Klienten weiss machen wollen, dass jetzt die Technologie xy die Antwort auf jahrelanges "Leiden" ist, dann befinden wir uns am Abgrund der IT-Zukunft. Wenn das Ganze dazu noch mit dem sonst schon überladenen Wort "Architektur" verbunden ist, dann wird es fragwürdig. So geschehen kurz nach dem XML-Hype im Zusammenhang mit Service Oriented Architecture (SOA) und Web Services (WS). So wurde hier die Assoziation vermittelt, dass SOA und Web Services eng zusammengehören. Dies mag zwar aus Sicht des Internetbenutzers, vorallem für B2B (Business to Business) noch einigermassen korrekt sein. Doch wer nun die Idee bekommt, dass Web Services die "Endlösung" für die Enterprise-Architektur ist, der darf schon mal einen 5-Jahres-Budget-Antrag machen, damit er bei der Inbetriebnahme genügend CPU-Leistung und Speicher beschaffen kann.

Nun aber genug der Polemik. Um es vorweg zu nehmen, SOA ist eine seit 10 Jahren angestrebte Architektur, welche wenig mit Web Services zu tun hat aber nichts desto trotz solche beinhalten kann. SOA kann aber ge­nauso gut mit CORBA, Messaging und anderer Middleware umgesetzt werden.

Was ist Service-orientierte Architektur?

In wenigen Worten gesagt, sind Services die Grundbausteine für eine Enterprise-Architektur. Diese Services haben eine möglichst generelle (generische) Schnittstelle und kapseln eine dahinter liegende Sammlung von Business-Applikations-Funktionen oder generelle Dienste. Andere Applikationen greifen nicht direkt auf Datenbanken dieser Applikationen zu sondern nur über die propagierten Schnittstellen. Dies hat den Vorteil, dass hinter der Schnittstelle - wie hinter einer Fassade - die Implementation optimiert oder migriert werden kann, ohne dass die manchmal undefinierte Anzahl von Client-Applikationen, welche selbst wieder Services sein können, geändert werden müssen. Dies richtig zu tun erfordert Erfahrung, Weitsicht und Disziplin. Es ist keine Sache von Technology-Anwendungs-Knowhow alleine sondern vorwiegend von Design. In jeder Architektur, welche auch langfristig überdauern sollte (vgl. InfoBridge Nr.3) spielt natürlich die Technologie, speziell die Middleware und die Entwicklungswerkzeuge eine nicht unterzuordnenden Faktor. Doch sollte auch hier eine gewisse Konstanz an den Tag gelegt werden. Man wechselt nicht die Middleware, wenn die "Mode" wechselt.

Web Services

Web Services - in diesem Zusammenhang wird auch oft von SOAP, .NET gesprochen - ist gewissermassen eine Middleware und Schnittstellen-Technik mit der ebenfalls Applikationsfunktionen im Netz angeboten werden können. Sie ist vergleichbar mit CORBA (Common Object Request Broker Architecture), ist aber für ein ganz anderes Umfeld gedacht und geeignet. Während CORBA für die IT-Organisation im internen Firmennetz verwendet wird, ist die Web-Service-Technologie im Gegensatz zu CORBA besser für das Internet geeignet. Da die Uebergänge von Internet und Intranet heute fliessend sind, kann man vereinfacht sagen: Hinter der Firewall und für hohe Performance ist CORBA/IIOP oder auch Messaging zu bevorzugen, vor der Firewall und im Internet bei relative kleinen Transaktionsraten sind Web Services geeignet.

Die Vorteile von Web Services aus Architektursicht sind:

• mehrere Transport-Protokoll-Ebenen möglich (HTTP (Web/Intranet), SMTP (Mail) u.a.), wobei speziell http das beliebte Protokoll ist, da "firewalldurchlässig".
• Die Schnittstellendefinitionen (WSDL: Web Service Definition Language in XML) können typisch über das Web abgefragt werden und daraus können automatisiert Client-Anschlüsse erstellt werden.
• Die transportierten Daten werden in einer XML-Definition ausgetauscht, und sind so leicht erweiterbar, ohne dass gleich jedes Client-Programm umgeschrieben werden muss.
• Sowohl synchroner wie asynchroner Austausch sind möglich

Der grosse Vorteil von CORBA-Services aus Architektursicht sind:

• Schnittstellen in IDL (Interface Definition Language) definierbar und für verschiedene Programmier-Sprachen Anschlüsse automatisch generierbar.
• weitverbreitete, erprobte und stabile Technologie.
• Sprachenübergreifend (wie WS übrigens auch)
• Sehr gute Performance für hohe Transaktionsraten (Faktor 4-10 von Web Services besser).
• Typisch synchrone Kommunikation mit dem Service, kann aber auch asynchron gemacht werden. Für letzteres ist aber Messaging besser geeignet (vgl. InfoBridge Nr. 4).

Alter Wein...

SOA ist überhaupt nichts Neues, einzig hat es jetzt einen Namen. Den mit dem Aufkommen der Object Management Architektur (OMA von OMG, für welche CORBA als Middleware basiert) Mitte der 90er-Jahre hat man diese Architektur bereits angestrebt.Es gibt auch grössere Firmen (auch in der Schweiz) die bereits diese Architektur auf CORBA-Basis konsequent und trotz dem Aufkommen von neuen Hype-Technologien durchgezogen haben.

Enterprise Service Bus

Genauso wie die CORBA-Technologie ist auch die Messaging-Middleware heute etabliert und ebenso, von mehreren Programmiersprachen mit hoher Durchsatzleistung speziell auch im Mainframe-Umfeld sehr geeignet. Ob man im Middleware-Backbone, oft ESB (Enterprise-Service-Bus) genannt, nun CORBA oder Messaging einsetzt, ist nicht alleine entscheidend. Es kommt dabei mehr auf die Konsequenz an, mit der man diese Technologie weitertreibt und sich entscheidet, was für die Integration von Zweigstellen und Tochterfirmen geeigneter ist. Eine Lebensdauer von 5 bis 10 und mehr Jahren sollte hier nicht unüblich sein. Man bedenke dabei, was den Umfang an Investitionen an Ausbildung, Entwicklungsnormierung, Bibliotheken und Frameworks, Überwachungstools und der Migrationszeit von bestehenden Anwendungen in diese Umgebung ausmacht. Wenn die Kosteneffizienz im IT-Umfeld wichtig ist, dann sollte man auch eine stabile und langlebige Infrastruktur anpeilen.

Anderseits möchte jeder IT-Architekt nach Aussen möglichst geeignete, flexible und offene Verbindungsmöglichkeiten schaffen, damit Geschäftsprozesse z.B. im B2B-Bereich noch effizienter abgewickelt werden können. Sobald es ins Internet geht oder von dort kommt, sind Web Services mit SOAP am richtigen Platz. Hier spielt die Flexibilität und Offenheit der Schnittstelle eine wichtigere Rolle als die Dursatzleistung. Dafür bildet die Sicherheit gegen Missbrauch und Hackerangriffe ein wichtiger Faktor. Gerade weil heute noch fast problemlos jeder http-Request durch eine Firewall durchkommt, muss darauf geachtet werden, dass nicht jeder Client im Internet sich an den entsprechenden Business-Service anschliessen kann. Authentisierung und Autorisierung spielen hier eine wichtige Rolle. Für den IT-Architekten gilt es zu überlegen, ob Web Services in de DMZ (Demilitarisierte Zone) sitzen und nur dort von aussen angesprochen werden dürfen.

Weiter muss man sich dem Design der Service-Schnittstellen unabhängig von der verwendeten Middleware annehmen. Damit in einer Serviceorientierte Architektur die Schnittstellen über lange Zeit unverändert oder zumindest aufwärtskompatibel beibehalten werden können, drängt sich eine möglichst generische aber trotzdem systematische Schnittstelle resp. ein Schnittstellen-Satz pro Service auf. Auch hier steht Design vor Technologie.

Fazit

Wenn in einem Unternehmen systematisch an einer serviceorientierten Architektur gearbeitet wird, wird sich dies mehr und mehr auszahlen. Am Anfang vielleicht weniger, da es Investitionen bedeutet. Services sind aber Komponenten, woraus man ein IT-Haus baut. Komponenten in einer SOA können einfacher ausgewechselt werden oder durch neue ähnliche Komponenten ersetzt werden. Was aber noch wichtiger ist, solche Services können zur Implementation von einem Business-Prozess wesentlich einfacher von einer Workflow-Engine integriert werden, als in einer konventionell aufgebauten IT-Umgebung. Erfahrung, Systematik und Knowhow sind hier die Erfolgsfaktoren. Schaut man den Erfolgfaktor von Komponenten in Maschinen-, Flugzeug-, Auto- und Elektronik-Industrie an, dann sollte man dies auch in der IT-Industrie umsetzten können. Für Erfolg muss guter Wille und konsequentes Vorgehen an den Tag gelegt werden. Es ist nicht eine Frage wie es sich mittel- oder langfristig auszahlt, sondern ob ihre IT-Architektur in geraumer Zeit überhaupt noch den laufenden Geschäftsanforderungen gewachsen ist?

BPM: Business Process Management ist mehr als ein Thema!

Als Business Process Management bezeichnet man die Lenkung der Wertschöpfungskette eines Unternehmens durch planerische, organisatorische und steuernde Massnahmen. Das Ziel ist, Effektivität und Effizienz bei den sich ständig ändernden Markt-Anforderungen hoch zu halten.

Seit der Einführung des Qualitätsmangements wird von Prozessen gesprochen und diese sind (nicht nur) bei QM-zertifizierten Firmen mindestens in Text-Dokumenten oder in graphischen Tools festgehalten (z.b.Visio).

Kundenzufriedenheit ist das oberste Ziel und die Ausrichtung der Prozessgestaltung ist periodisch darauf auszurichten.

Fast jedes Software-System bezeichnet sich heute als prozessorientiert. Sehr oft sind solche Prozesse Teilprozesse, die zu einem Softwaresystem passen, wie etwa der Faktura-Debitoren-Prozess einer Business Software oder Kommunikationsprozesse (Mail, Aufgaben) z.B. mit Outlook.

Je nach Unternehmen passen solche Prozesselemente mehr oder weniger in die Gesamtabläufe. Das Kriterium ist: Tragen sie genügend zur Effizienzsteigerung bei, damit die Kosten gesenkt werden oder entstehen durch Medienbrüche Doppeleingaben und weitere Fehlerquellen, die Kosten verursachen?

Oder: Sind wichtige Geschäftsinformationen in verschiedenen Informatiksystemen abgelegt oder wirklich einfach verfügbar? Nach Aussagen von führenden Unternehmensberatern verbringen Mitarbeiter bis zu 20% ihrer Arbeitszeit mit dem Suchen von Informationen. Testen Sie selbst.

Sehr oft hören wir, dass "die Prozesse wohl niedergeschrieben sind, dass sie aber zu wenig gelebt (umgesetzt) werden".

Als Beispiel mag das Wissen über die Prozesse vorhanden sein aber wenn es "eilt", so werden einzelne Prozesse nicht entsprechend den Richtlinien ausgeführt. Das kann zu Qualitätseinbussen führen, zu Fehlern und nachträglich zu vermehrtem Aufwand.

Mit dieser ganzen Thematik beschäftigen sich die Fachbereiche:

 

• Business Process Modelling
• Business Process Automation
• Business Process Management
• EAI Enterprise Application Integration
• Knowledge Management.

Durch die Kooperation mit Triloga Knowledge AG sind wir nun in der Lage, ein vollumfängliches Produkt in diesem Segment anzubieten (SCODi-Amazonas).

Ausführliche Informationen darüber sind im SCODimagazin enthalten, das wir Ihnen gerne zukommen lassen: Kontaktformular

...auch für kleine Unternehmen
Als kleines Unternehmen ist es uns ein Anliegen, zu erwähnen, dass auch wir intern diese Prozesse informatikmässig umsetzen und damit auf unser Unternehmen zugeschnittene Abläufe haben, was uns weiterhin erlaubt, schlank, effizient und flexibel zu sein.

...auch für Software-Partner
Die Erfahrung zeigt, dass nur wenige Software-Häuser ERP-Lösungen einsetzen, da ihre Prozesse zu speziell sind. So bieten wir Software-Partnern diese Prozesse zu äusserst attraktiven Konditionen an (z.B. für Projekt-Offerten, Auftragsadministration, Releaseprozesse, Changemanagement, Qualitätsprüfung von Entwicklungen, Hotline, Software­download).

...und die Einfachheit
Für einen Unternehmer ist es eine Selbstverständlichkeit, die wichtigen Finanzahlen jederzeit aus der Finanzapplikation zu erhalten. Genauso können er und die anderen Mitarbeiter jederzeit die Übersicht über die verschiedenen Aktivitäten im Unternehmen haben.

BPM kann auch einfach sein, mit SCODi können Prozesse einfach modelliert werden. Diesen Beweis konnten wir anlässlich des SCODi-Amazonas-Event vom 26.8. vor dem interessierten Publikum antreten.

Es kann genügen, nur einzelne Prozesse zu automatisieren, um einen Nutzen zu erzielen. Den Möglichkeiten sind kaum Grenzen gesetzt. Beispiele finden Sie auf unserer WebSite.

 

Neuerungen: Amazonas Version 2.1

In der neuen Version 2.1.0 sind die folgenden Erweiterungen eingebaut worden:

Verwaltungsfunktionen der Prozesssteuerung:

• Erweiterung auf Personen, Rollen und neu Stellen
• Prozessverwaltung: Suspendieren, Starten, Abbrechen und Löschen von Prozessen
• Aktivitätsverwaltung: Suspendieren, Starten, Abbrechen und Löschen von Aktivitäten
• Farbliche Anzeige von zeitkritischen Aktivitäten und Prozessen (Ampelfarben)
• Übersicht der Prozess-History auf einen Klick

in den Prozessaktivitäten:

• Zurückweisen von Aktivitäten an den Vorgänger
• Zurückgeben von Aktivitäten in den Pot (u.a. für Neuzuteilung bei Kapazitätsengpässen)
• Zeit- und Kostenerfassung pro Aktivität und damit verbundene erweiterte Auswertungsmöglichkeiten
• Attachements können an der Aktivität angehängt werden.

Technisches:

• Neues flexibles Datenbankdesign; über die erweiterten Amazonas-Workflow-Schnittstellen können komplexe Abfragen für Reports erstellt werden.
• SOAP-Schnittstelle: damit kann plattformunabhängig auf Amazonas Workflow zugegriffen werden und dies ermöglicht den Einsatz von Amazonas in einer Webservice-orientierten Architektur (dies ist ab der Version 1.3 möglich, in der Version 2.1 nochmals wesentlich erweitert worden).

Rückblick:
Scodi-Amazonas Event

Am 26. August 2004 fand vor interessiertem Publikum bei unserem Partner Triloga Knowledge AG in Luzern der Scodi-Amazonas-Event statt.

Bild: Paul Schmid (Geschäftsführer Triloga AG) und Andres Koch präsentieren die Scodi/Ama­zonas am gemeinsamen Event vom 26.8.2004

Anhand eines Praxis-Beispiels konnten 40 Teilnehmer live erleben, wie ein Prozess im Programm SCODI 4P modelliert wurde, ins Workflow-Programm Amazonas übergeben und dort gleich ausgeführt wurde.

Damit konnte deutlich bewiesen werden, dass Erstellen und Umsetzen von Geschäftsprozessen - mit den entsprechenden Tools - einfach und schnell erfolgen kann.

Prozessorientiertes Arbeiten (BPM - Business Process Management) ist kein neuer Hype - es ist topaktuell, denn effizient ablaufende Geschäftsprozesse sind für jedes Unternehmen wichtige Faktors, um Zeit und Kosten zu sparen (und dies muss ein jeder von uns).

Triloga Knowledge AG ist ein Dienstleistungsunternehmen für Organisationsentwicklung.

Die Kernkompetenzen sind:

• Aufbau und Dokumentation von Prozessmanagement-Systemen
• BPM-Workflow und Prozess-Automati­sierung
• Begleitung und Umsetzung von Wis­sensmanagement-Systemen

Triloga Knowledge AG ist Problemlöser und Lösungserbringer zugleich. SCODi4P®, ein integrales Führungssystem und Wissensmanagement für:

• Produktemanagement
• Personalwesen
• Prozessmanagement
• Projektmethodik

Weiteres zu Business Process Management finden Sie im SCODimagazin, das wir Ihnen gerne zustellen. Kontaktformular

Unsere Mitarbeiter
Leiter Entwicklung Software- Komponenten: Roman Zulauf

Seit 4 Jahren ist Roman Zulauf für die Object Engineering GmbH als Software-Entwickler tätig. Seit Abschluss des Nachdiplomstudiums Software-Engineering an der Hochschule Rapperswil leitet er den Bereich Entwicklung Software-Komponenten.Er beherrscht die Sprachen C, C++, Java; Technologien wie J2EE, EJB, Java Servlets, JSP, Apache Struts, XML, XSLT, JMS, CORBA, auf den Plattformen Linux, UNIX, AIX und Windows. Sein "Kind" heisst Amazonas-Workflow und er kennt es in allen Details.

Roman Zulauf liebt Herausforderungen sowohl auf der Softwareseite als auch im Schach, das er sehr gerne mit verschiede­nen Partnern im Internet spielt.

Auflösung letzter Wettbewerb:

Brückenwettbewerb Infobridge Nr. 4 Bei der in der Infobridge Nr. 4 abgebildeten Brücke handelt es sich um die Sunnibergbrücke bei Klosters im Prättigau (GR). Sie wird nach Fertigstellung des Umfahrungstunnels den Verkehr Richtung Davos führen.

Es gab insgesamt 6 richtige Einsendungen. Der Hauptgewinner war:

Herr Ueli Merz, Ingenieurbüro Merz, Wil

Wir gratulieren dem ausgelosten Gewinner und den Trostpreisgewinner mit der richtigen Lösung. Ihnen sind Köstlichkeiten aus der Region zugestellt worden.

Neuer Brückenwettbewerb

Es gibt Brücken, welche für einen bestimmten, zeitlich begrenzten Einsatz ge­macht sind. Wo und zu welchem Anlass wurde diese Brücke gebaut?

Die Antwort senden Sie uns wie immer am per Fax 044 400 47 07 oder per Kontaktformular. Aus den richtigen Antworten wird die Gewinnerin oder der Gewinner mit dem Los ermittelt und erhält eine passende Überraschung. Einsendeschluss: 31. Januar 2005