Die Einstiegshürden

Service-orientierte Architekturen, kurz: SOA, ermöglichen flexible IT-Landschaften für ERP, PLM, CAD und MES. Soweit die Theorie. In der Praxis bereiten SOA-Technologien noch viele Probleme – vor allem, wenn die falsche Technologie gewählt wird.

Service-orientierte Architekturen, kurz: SOA, ermöglichen flexible IT-Landschaften für ERP, PLM, CAD und MES. Soweit die Theorie. In der Praxis bereiten SOA-Technologien noch viele Probleme – vor allem, wenn die falsche Technologie gewählt wird.

SOA soll die Komplexität von Unternehmenssoftware reduzieren und die heute notwendige Verknüpfung unterschiedlichster Anwendungen ermöglichen. Ziel ist, die verschiedenen Systeme eines Fertigungsprozesses von der Entwicklung und dem Design (CAD, PLM) sowie die Bestellung (ERP) bis hin zur Produktion (ERP/MES) und Auslieferung zu vernetzen. Die mit SOA realisierbaren Vorteile zeigt der Ablauf bei einem Engineering-Change-Prozess: Aufgrund eines qualitativen Mangels ändert der Entwickler die Konfiguration eines Artikels im CAD und damit auch im PLM-System. Mit einer SOA lassen sich die Serviceabteilung und die Logistik sehr früh in diesen Change-Prozess einbinden. Die Änderung im CAD/ PLM-System stößt in der ERP-Umgebung die Überprüfung des Lagerbestands aus. Gleichzeitig wird der Auslieferungs-Status des Bauteils im ERP oder CRM-System angefragt: Wie oft und wann wurde das fehlerhafte Bauteil in welchen Maschinen verbaut? Daraus lassen sich präventive Service-Einsätze zum Austausch der Bauteile organisieren.

Auch Änderungen der Fertigungsprozeduren, etwa weil der Gesetzgeber neue Sicherheitsbestimmungen erlassen hat, müssen in allen beteiligten Systemen entsprechend geändert und abgebildet werden. Bei einem SOA-Konzept bedarf es lediglich der Implementierung eines zusätzlichen Kontrollschrittes in Form eines entsprechenden Service (Genehmigungs-Service). Dazu beschreiben die Fachabteilung gemeinsam mit der IT den neuen Prozessablauf mithilfe eines grafischen Werkzeugs, beispielsweise einem BPEL-konformen Editor (BPEL: Business-Process-Execution-Language).

Im Prozessmodell wird der Genehmigungsschritt eingefügt und auf den Genehmigungs-Service abgebildet. Die aktualisierte Prozessbeschreibung wird anschließend einer BPEL-Engine, welche die Prozessausführung kontrolliert, als aktuelle Prozessversion bekanntgegeben. Danach enthält der Prozessablauf den zusätzlichen Genehmigungsschritt. Großen monolithischen Softwarepaketen und gewachsenen Infrastrukturen fehlt es dazu an Flexibilität, um die Geschäftsabläufe solchen Veränderungen zügig anzupassen.

Die Flexibilität basiert auf der Modellierung und Konfiguration von Software-Systemen: Funktionen, die als Services zur Verfügung stehen, lassen sich zu neuen oder abgewandelten Prozessen zusammenfügen, ohne eine komplett neue Applikation zu erstellen. Zudem sind die einzelnen Komponenten unabhängig voneinander und dadurch einfacher zu warten.

Die Implementierungsvarianten

Grundsätzlich gibt es zwei Ansätze, um mit einer SOA-Implementierung zu starten – mit einer individuellen, firmenspezifischen Lösung oder auf Basis der SOA-Plattform eines ERP-Lieferanten. Beim individuellen SOA-Projekt werden die vorhandenen Unternehmensanwendungen in spezifische Services gegliedert. Anschließend werden die Prozesse über Orchestrierungslösungen wie WebSphere Process Server oder web Methods BPMS, Ablaufsteuerung und Service-Integration modelliert und neu implementiert.

Der zweite Ansatz setzt auf herstellerspezifischen SOA-Plattformen auf. Diese enthalten bereits Service- und Prozessdefinitionen für Standardabläufe, so dass in der Regel nur noch die Anpassung der Services und Prozesse an die spezifischen Unternehmensabläufe notwendig ist.

In der Praxis kommen beide Ansätze parallel zum Einsatz, da fast immer unternehmensspezifische Anwendungen oder spezielle Software-Komponenten anderer Hersteller in die SOA-Plattform eines Lieferanten zu integrieren sind. Insbesondere die Projektteile mit individuellem Charakter verlangen viel Prozess-Know-how. Um die Komplexität zu reduzieren, werden zunächst nur einzelne Anwendungen gezielt ausgewählt und in Services zerlegt. Ziel ist es, existierende Ressourcen möglichst weiter zu verwenden. Nach diesen grundlegenden Festlegungen steht die Definition der Semantik jedes einzelnen Services an, wobei auf die Wiederverwendbarkeit zu achten ist. Im nächsten Schritt müssen die Schnittstellen zu den verschiedenen IT-Systemen, beispielsweise zum CAD-Programm, erweitert werden, damit die Systeme die SOA-Services „verstehen“.