Serviceorientierte Architektur lebt - sagt der SOA Check 2009

Gut , dass es den SOA Check gibt: Die Ergebnisse des SOA-Checks kommen nicht überraschend. Sie bestätigen eigentlich die deutsche Tugend, gute Dinge erst nach einer gründlichen Prüfung im Stillen walten zu lassen. Der Ausbau einer SOA innerhalb von Unternehmen ist eine Notwendigkeit geworden. Das Missverständnis liegt darin, dass SOA gerne wie eine Revolution wahrgenommen wird, als etwas komplett neues, das wie ein Panaceum die Probleme der IT lösen soll. SOA ist aber Evolution: weder schafft man SOA aus dem Nichts, noch verzichtet man auf SOA, indem man den Begriff ignoriert oder keine Middleware einsetzt. Tatsächlich hat aber jedes Unternehmen schon lange SOA in der einen oder anderen Form. Spätestens wenn Server miteinander Daten in Echtzeit austauschen, man EDI-Server einsetzt, Daten zwischen Maschinen und SAP per File austauscht oder über einen Druckerserver druckt, hat das Unternehmen Services. Die Architektur, die die Kommunikation möglich macht, ist SOA. Das zeigt schon deutlich, dass alleine schon ein Netzwerk, das es erlaubt ohne großen Aufwand zwischen Applikationen auszutauschen SOA ist. Die Herausforderung besteht nun darin, die Architektur so auszubauen, dass immer mehr Anwender die eigenen Daten und Leistungen zur Verfügung stellen und man diese ohne Aufwand nutzen kann. Stellen Sie sich das ruhig bildlich vor: Der Cognos-User schiebt seine Daten auf die SAPGUI und voila: schon sind diese in der Buchhaltung; der Buchhalter schiebt die Steuererklärung auf die ELSTER-Anwendung zur Übertragung an das Finanzamt ohne viel Download, Upload und komplexe Konvertierungen. Bestehende SOA-Strukturen sind IT-lastig, denn sie haben sich bisher darauf beschränkt, die technische Kompatibilität zwischen den Anwendungen herzustellen. Das ist durchaus gelungen, still und leise eine erfolgreiche EAI aufzubauen. Auch hier kann vieles verbessert werden. : in unserem jährlichen Logosworld Blue Elefant Award for SOA Excellence stellen wir immer noch fest, dass die kommerziellen Tools und Middleware-Applikation noch weit hinter den realen Anforderungen hinterherhinken, besonders im Bereich Bedienbarkeit und Kompatibilität. Das bestätigt auch die Erkenntnis eines anderen CW-Artikels von vor einiger Zeit, dass es von Übel ist, Middleware aus der Hand seines zentralen ERP-Betreibers zu nehmen (http://www.computerwoche.de/soa-expertenrat/2008/12/09/und-es-gibt-sie-doch-die-wahrheit-uber-neutrale-soa-hersteller/). Aber jetzt geht es erst mal darum, auch die nicht-technischen Bereiche für SOA zu begeistern, indem man einen Mehrwert schafft. Das Problem steckt in der "multiple-Domain-Ownership", dem Faktum dass in SOA Services vielen verschiedene Eigentümer haben. Es ist die Aufgabe der SOA-Governance die Kleinstaaterei bei den Applikation durch das Bereitstellen von Infrastruktur-Services zu überwinden; in wenigen Jahren werden SAP, Oracle und Dynamics etc. genau so einfach und selbstverständlich miteinander sprechen, wie wir heute mit einem beliebigen Drucker kommunizieren, ohne dass mühselig über Wochen hinweg Drucker-Codes gepflegt werden müssen. Es ist gut, dass es den SOA-Check gibt: denn daran sieht man, dass es nicht um SOA an sich geht, sondern nur um die richtige Systematik und Methodologie geht und darum, möglichst viele Anwendungsbereiche wie etwa die sich aufdrängenden Thema Compliance, Safety und Security mit einzubeziehen. Damit geht es zu wie in allen Gesellschaftssystemen und Städten: man muss Anwender überzeugen und begeistern, einfache und klare regeln aufbauen, öffentliche Dienstleistungen anbieten und vor allem Mehrwert offen demonstrieren. Letztlich bleibt die Erkenntnis: wer SOA macht, braucht auch ein gutes SOA-Marketing und eine harmonisierte Ausbildung über Abteilungsgrenzen. Tue Gutes und rede darüber. Und schaffe Services, die auch leicht genutzt werden können. Da gerade die Bereiche Ausbildung und Service-Marketing noch im Pionierstadium sind und von IT-Abteilungen nicht geliebt sind, liegt da die Ursache, warum SOA immer wieder für tot erklärt wird. Herzliche Grüße Axel Angeli: "Building SOA City" zum Beitrag

Was die Bereiche Risk Management, Due Diligence usw. betrifft, sind extrem viele interne und externe Rahmenbedingungen zu berücksichtigen, welche eine ganzheitliche Analysearbeit benötigen. Ich weiss es, weil ich selber als Praktikant bei Proquest Riskmanagement GmbH tätig war und bei vielen Analysen der IST Situation von Unternehmen mitgeholfen habe. zum Beitrag