Daniel Liebhart

Endlich - In die Tonne mit dem Chaos Report der Standish Group

Daniel Liebhart — Wed, 28 Jan 2009 11:53:00 GMT

IT- Projekte scheitern im Normalfall. Es existiert eine Software Krise, da wir nicht wissen, wie IT-Projekte zu realisieren sind. Dies wird eindrücklich durch die seit 1994 von der Standish Group veröffentlichten Chaos Reports belegt. Diese Zahlen werden ohne Unterlass in vielen Verkaufspräsentationen, an vielen Konferenzen und sogar in Software Engineering Vorlesungen herumgereicht. Da werden Zahlen, wie beispielsweise ein Scheitern von 70% aller IT-Projekte oder eine durchschnittliche Kostenüberschreitung von 189% oder eine Projektabruchrate von 30% genannt. Diese Zahlen wurden uns seit Jahren um die Ohren geschlagen und wir sind reumütig in uns gekehrt und haben nach vorbeugenden Massnahmen gesucht.

Berechtigte Zweifel

Bereits im Jahr 2005 hat der renommierte Herausgeber der Journal of Systems and Software Robert L. Glass die Zahlen des Standish Chaos Reports angezweifelt. In seinem Artikel "IT Failure Rates - 70% or 10-15%" kritisiert er die Zahlen der Standish Group und stellt dem gegenüber die praktische Erfahrung der Branchengrössen. Und er fordert die Standish Group auf, die Grundlage der Zahlen zu veröffentlichen. Die Antwort der Standish Group ist wahrlich unglaublich. "Nur weil jemand eine Frage stellt, bedeutet das nicht, dass wir antworten. Tatsächlich antworten wir eher nicht". Naja, was soll man da sagen? Details sind im Blog von Jorge Aranda (University of Toronto) zu finden. Das Fatale an den zweifelhaften Zahlen ist ja nicht, dass sie unseriös sind und das ein Zitieren dieser Zahlen oder das Präsentieren der entsprechend Grafiken einfach von mangelnder Kenntnis der Sachlache zeugt. Nein das Fatale daran ist, dass mit unsinnigen vorbeugenden Massnahmen, die nicht zu erfüllende Erwartungen wecken, Projektgelder verschleudert werden. Projektgelder, die anserswo sehr viel sinnvoller eingesetzt werden könnten. Zum Beispiel für die Entwicklung oder für das Testing.

Glücklicherweise gibt es seriöse Leute, die genau untersuchen aus welchen Gründen Projekte scheitern oder abgebrochen werden. Und dass sind auch Zahlen, die als Handlungsgrundlage genommen werden können. So haben beispielsweise K.E. Eman und A.G. Koru (Universität Ottawa und Maryland) erst vor kurzem in der Septemer/Oktober Ausgabe des IEEE Software Magazins den Artikel "A Replicated Survey of IT Software Project Failures" veröffentlicht. Darin kommen sie beispielsweise auf eine IT-Projekt Abbruchrate von 11.5-15.5%. Ihre Zahlen sind sorgfältig recherchiert und belegt. Und bilden damit eine wesentlich bessere Grundlage, um IT-Projekte so zu steuern, dass ein Erfolg wahrscheinlicher ist.

Weg mit dem Chaos Report

Die Zahlen des Chaos Reports werden von der Software Gemeinde zunehmend bezweifelt. Seriösere Untersuchungen zeigen starke Abweichungen vom Chaos. IT-Projekte sind damit noch nicht besser als andere Projekte. Aber es scheint wahrscheinlich zu sein, dass die Erfolgsraten sich nicht von denjenigen anderer Projekte unterscheiden. Es ist und bleibt nach wie vor Richtig in IT-Projekten auf die sorgfältige Durchführung zu achten und den richtigen Mix zwischen vorbeugenden Massnahmen und speditiver Durchführung zu finden. Bestimmte Massnahmen müssen gegenüber den Projektsponsoren gerechtfertigt werden. Den Chaos Report als Grundlage für eine solche Rechtfertigung zu nutzen ist kontraproduktiv und unseriös. Hören wir also auf damit. Es gibt bessere und belegte Zahlen.

IT Governance mit SOA?

Daniel Liebhart — Mon, 05 May 2008 11:40:00 GMT

Viele Firmen formulieren heute Information Governance oder auch IT-Governance Richtlinien als Rahmen für die Bereitstellung und den Betrieb ihrer betriebsunterstützenden Informationssysteme. SOA bietet sich als Umsetzungsinstrument für diese Governance Richtlinien an. Eine Reihe von Prinzipien, die SOA ausmachen, begünstigen die Umsetzung von Governance Richtlinien. Es sind jedoch die Rahmenbedingungen zu beachten; Ein pragmatisches SOA Modell und eine vernünftige Governance. IT-Governance Governance ist eine Sammlung von Grundsätzen der Geschäftsführung, die durch den Einsatz geeigneter Instrumente Transparenz und ein ausgewogenes Verhältnis von Führung und Kontrolle anstreben, wie der Swiss Code of Best Practice for Corporate Governance formuliert. IT-Governance wird heute in vielen Unternehmen mit dem Ziel formuliert, den Wildwuchs und die Heterogenität der betrieblichen Informationssysteme in den Griff zu bekommen. Grössere Unternehmen und Verwaltungen formulieren Richtlinien, etablieren IT-Governance Boards und etablieren KPI’s zur Steuerung, Messung, Kontrolle und Überwachung der IT-Prozesse. So gibt es beispielsweise kaum mehr ein grösseres Unternehmen, dass keine IT-Security Richtlinien formuliert hat. Einzelne Unternehmen formulieren Lebenszyklen für Anwendungen, Daten oder Services, während andere wiederum komplexe Indikatoren zur Messung der Qualität ihrer IT formulieren. Die Schwierigkeiten der Umsetzung der IT-Governance IT-Governance Initiativen werden oft von der Unternehmensleitung im Rahmen der Einführung einer allgemeinen Corporate Governance gestartet. Dem gegenüber stehen die bestehenden Informationssysteme die teilweise seit langem in Betrieb sind und ständig erweitert werden. Dem gegenüber steht auch das Bedürfnis der Fachabteilungen, ihre Anforderungen möglichst schnell in Funktionalität umsetzen zu lassen. Dieser Widerspruch droht IT-Governance zum Bremser werden zu lassen. Ein IT-Projekt empfindet die Einhaltung der Governance Richtlinien als Verzögerung oder gar als Stolperstein für die Einführung einer Anwendung oder eines bestimmten Services. SOA als Umsetzungsinstrument einer IT-Governance Heterogene und nach und nach gewachsene betriebliche Informationssysteme können durch SOA schrittweise strukturiert und geordnet werden. Sämtliche Funktionen und alle Daten werden als standardisierte Services betrachtet, sämtliche Prozesse werden als ausführbare Prozesse mit standardisierten Schnittstellen betrachtet. Das strukturierende Grundelement einer IT ist der Dienst. Seine Funktionalität wird als Service Contract formuliert, seine Schnittstelle wird als Web Service ausgeführt. Der Service ist also das ordnende Grundelement der IT. An dieses Grundelement lassen sich die Anforderungen einer IT-Governance knüpfen. So können Lebenszyklen, Qualitätskriterien, Sicherheitsregeln, gesetzliche Rahmenbedingungen, organisatorische Verantwortlichkeiten und andere KPI’s den Service zugeordnet werden. Da eine auf SOA basierende Anwendung eine Sammlung von Services und ausführbaren Prozessen, die wiederum Services sind, darstellt und sich der Betrieb einer IT-Infrastuktur ebenfalls auf die Bereitstellung dieser Services bezieht, können damit sämtliche Bereiche einer unternehmensweiten IT abgedeckt werden. Zudem hat SOA den Vorteil, dass standardisierte Services mit standardisierten Infrastrukturen verwaltet und überwacht werden können, die heute jeder grosse Anbieter im Portfolio hat. Die Messung der KPI’s oder der Nachweis der Einhaltung regulatorischer Richtlinien ist damit flächendeckend möglich. Pragmatismus und Vernunft ist gefragt

Die Umsetzung einer IT-Governance in einer gewachsenen und heterogenen unternehmensweiten Informatik ist alles andere als einfach. Sie muss auf jeden Fall schrittweise erfolgen. Voraussetzung für die Einführung einer IT-Governance ist die ganzheitliche Betrachtung der Anwendungslandschaft. Genau dies ist durch SOA möglich. Allerdings nur dann, wenn ein pragmatisches Vorgehen gewählt wird, welches die Weiterverwendung bestehender Anwendungen und Datenbestände ermöglicht. SOA erlaubt eine Standardisierung durch die konsequente Anwendung weniger aber wirkungsvoller Standards. Der Web Service (WSDL und SOAP) und der ausführbare Prozess (BPEL) sind die zentralen Standards einer SOA. Der Service wird so zum zentralen ordnenden Element der IT. An ihn sollten auch die IT-Governance Richtlinien geknüpft werden. So kann vermieden werden, dass die Governance als Stolperstein für die Bereitstellung und den Betrieb der betrieblichen Unterstützungsfunktion IT empfunden wird.

Lang lebe das Jahr der Informatik

Daniel Liebhart — Tue, 29 Jan 2008 12:05:00 GMT

Fast unbemerkt von der Oeffentlichkeit feiern wir hier in der Schweiz das Jahr der Informatik.

Hier die Website: http://www.informatica08.ch/de/index.html. Interessant ist die Geschichte der Informatik-Innovationen in der Schweiz, die auf der Website der Ideesuisse zu finden ist: http://www.ideesuisse.ch/240.0.html?&changeLang=set&L=0 und der Beitrag von Dominik Landwehr zum Thema auf http://www.peshawar.ch/tech/madeinswitzerland.htm und von Emil Zofi auf http://www.zopfi.ch/0e/Gunzinger2.html. Details zum GigaBooster findet Ihr hier: http://www.svifsi.ch/revue/pages/issues/n983/a983Gunz.pdf und hier: http://www.scs.ch/~frey/booster.html.

Leider ist dieser Erfindung der kommerzielle Erfolgt verwehrt geblieben. Vielleicht haette ein gutes Betriebssystem oder die Umsetzung des Windows HAL geholfen. Ich denke, dieses Schicksal hat noch manche Innovation in der schweizerischen Informatik Branche getroffen.

Die Erklärung zum Jahr der Informatik 2008 zielt darau ab, die Informatik als Wirtschaftsmotor einer breiteren Oeffentlichkeit zugänglich zu machen und die Informatik-Grundausbildung zu fördern. Leider sagt sie wenig dazu, wie denn die Branche als Ganzes zu fördern ist.

SOA Blogs, die einfach Spass machen

Daniel Liebhart — Sat, 08 Dec 2007 15:00:00 GMT

Heute bin ich auf Frank Bremers Blog gestossen. Kann ich nur empfehlen. Der Blog macht Spass und ist sehr interessant. Und bietet ausserdem Einblicke in die IBM SOA Welt (http://quovadis-bremer.de/wp/category/allgemein/)

Guerilla SOA

Daniel Liebhart — Mon, 29 Oct 2007 12:20:00 GMT

Der Analyst Dana Gardner fasst in einem Blog Eintrag "SOA Insights analysts view IBM’s information umbrella, explore SAP’s Business Objects grab and define ‘Guerilla SOA" (http://blogs.zdnet.com/Gardner/?p=2565) die Diskussionen verschiedener IT Experten und Analysten zusammen. Besonders interessant ist dabei der Abschnitt "On WOA and Guerilla SOA"

Umbrella SOA

Der Begriff "Umbrella SOA" beschreibt den Ansatz der grossen Hersteller SOA als Gesamtarchitektur der IT eines Unternehmens anzusehen. Diese Gesamtarchitektur beschreibt nicht nur die technischen Systeme, sondern auch die Art und Weise, wie Software entwickelt werden soll und wie der Gesamtbetrieb realisiert und kontrolliert werden soll. Also von SOA Governance bis hin zum Bau von Software Factories. Und der Hersteller hat sämtliche Werkzeuge dazu. Und tatsächlich; Die SOA-Modelle vieler Hersteller, Analysten und Berater wirken umfangreich und kompliziert. Hinter vielen dieser Modelle steckt die Vorstellung, mit SOA sämtliche Schwierigkeiten, die nun mal mit dem Bau, dem Betrieb und dem Unterhalt von Informationssystemen verbunden sind, lösen zu können. Hinzukommt der unübersichtliche Wald von Standards, die in Zusammenhang mit der Basistechnologie von SOA - Web Services - entwickelt werden. Beides neigt dazu, die zentralen Vorteile von SOA zu verdecken und SOA als ein Modell erscheinen zu lassen, das komplex und mit sehr grossen Investitionen verbunden ist und nur durch essenzielle Veränderungen der bestehenden IT-Systeme umgesetzt werden kann.

Web Oriented Architecture

Unter Web Oriented Architecture (WOA - auch Enterprise Web 2.0 oder Enterprise 3.0 genannt) wird ein etwas anderer Ansatz verstanden. Es sollen kleinere Anwendungen basierend auf Web Services realisiert werden können. Dabei soll die Realisierung sehr nahe an den konventionellen Web Anwendungen umgesetzt werden. Dies bedeutet vor allem, dass Web Service Schnittstellen so gestaltet werden, dass sie im "REST Stil", also mit ressourcen-orientierten Interfaces arbeiten. Resource-Centric Interfaces nennt man auch Content-Centric Interfaces. Als Operationen lassen sie lediglich die Standard-HTTP-Methoden GET, POST, PUT und DELETE zu. Die Funktionalität eines Web Service wird mit Resource-Centric Interfaces als implizite Funktion einer Resource umgesetzt, die im Falle eines Aufrufes der entsprechenden HTTP-Methode ausgeführt wird. Eine Ressource kann als Dokument angesehen werden. Der Serviceaufruf ist dann lediglich eine Anforderung dieses Dokuments über das Web. Das Dokument selbst ist eine logische Komponente, die Daten hierarchisch strukturiert und die Operationen auf diesen Daten als Operationen auf einzelnen Dokumentteilen ausführt. Sie ist aber alleine durch die Tatsache, dass ausschließlich HTTP-Methoden als Operationen verwendet werden, sehr mächtig in Bezug auf die Flexibilität und die Möglichkeiten der universellen Ausbreitung eines Dienstes über die gebräuchlichen Internet-Mechanismen.

Guerilla SOA

Wenn mit SOA nur sehr grosse Systeme oder gar ganze Systemlandschaften basierend zu realisieren sind, so ist das für kleine und mittlere Unternehmen oder für Abteilungen, die ein bestimmtes Problem mit Software lösen möchten, kein vernünftiger Weg. Unter Guerilla SOA werden Realisierungen verstanden, die oft an den Vorgaben der zentralen IT Standardisierung vorbeigehen und sich durch einen sehr grossen Pragmatismus auszeichnen. Es wird also die praktische und schnell realisierbare Lösung gesucht. Ob jedoch Guerilla SOA mit WOA tatsächlich immer der wirklich pragmatische Weg ist, bleibt abzuwarten. Denn es ist nicht einfach, Resource-Centric Interfaces einzusetzen. Sie unterscheiden sich substantiell von den üblichen Schnittstellen (Methoden-Orientiert oder Meldungs-Orientiert) und sind gewöhnungsbedürftig.

Pragmatische Umsetzung von SOA

Guerilla SOA kann jedoch auch etwas anders verstanden werden. Als pragmatische Umsetzung von Lösungen basierend auf einer SOA, bedeutet es die Reduktion der einzusetzenden Werkzeuge auf das notwendigste. Dies bedeutet aus meiner Sicht die einfache Erweiterung der üblichen Schichtung von Anwendungen und Architekturen um eine Service- und eine Orchestrierungs-Ebene und damit die Möglichkeit, mit Hilfe von SOA Ordnung in eine bestehende heterogene Systemlandschaft zu bringen und bestehende Systeme weiterzuverwenden. Und es bedeutet ganz sicher eine Beschränkung auf die drei wichtigsten Standards SOAP, WSDL und BPEL. Und es kann bedeuten, dass die Schnittstellen so nahe wie möglich an den bestehenden Systemen realisiert werden, also methoden-orientierte Schnittstellen eingesetzt werden.

Service Systems

Daniel Liebhart — Mon, 29 Oct 2007 11:40:00 GMT

Im Zentrum einer SOA steht der Service. Selbstverständlich steht im Rahmen einer Software-Architektur der technische Service, der mit einer Web Service Schnittstelle versehen ist, im vordergrund. Der Service kann jedoch auch etwas genereller betrachtet werden; im weiteren Sinn als Dienstleistung. Was für den technischen Service eine SOA darstellt ist für den nicht-technischen Service ein Service System.

Was sind Service Systeme?

Service Systeme versehe ich als Netzwerke bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen. Die Schaffung solcher Netzwerke wird in naher Zukunft einen neuen Berufzweig beschäftigen - den Service Engineer. Unter dem Begriff Service-Sciences Management and Engineering (SSME) entstehen zurzeit auf internationaler Ebene eine Reihe von Initiativen.

Ein Service ist mehr als ein Web Service

Aus technischer Sicht ist ein Service eine sich selbst beschreibende, offene Komponente, die eine schnelle und kostengünstige Zusammenstellung von verteilten Anwendungen ermöglicht. In einer SOA stellt der Service einen Schritt in einem ausführbaren Geschäftsprozess dar. Der ausführbare Geschäftsprozess wird in BPEL (Business Process Execution Language) modelliert, der Service selbst wird als standardisierter Web Service realisiert. Ein technischer Service ist in jedem Fall eine Unterstützungsfunktion für eine betriebliche Tätigkeit. Aus betrieblicher Sicht ist ein Service "eine Veränderung des Zustandes einer wirtschaftliche Entität - einer Person oder einer Ware -, die durch die Aktivität einer anderen wirtschaftlichen Entität im Einverständnis mit der zu verändernden Entität durchgeführt wird." So definiert das neue Produktklassifikationssystem der USA den Service. Der Begriff "Service" stammt aus den 30er Jahren des letzten Jahrhunderts. Diejenigen Branchen, die nicht in die Bereiche Produktionsgewinnung (Landwirtschaft) und Produktionsverarbeitung (Herstellung) passten, wurden unter "Service" zusammengefasst, der auch als "Tertiärer Sektor" definiert wird. Die Aktivität in diesem Sektor sind sehr breit, sie umfassen Bereiche wie die öffentliche Verwaltung, das Gesundheitswesen, die Finanzen, den Verkehr, die Bildung, die Kommunikation und das Business. Eines ist jedoch jedem Service gemeinsam, es ist in jedem Fall ein Netzwerk bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen.

Die Konsequenzen der ökonomischen Bedeutung des Service

Der tertiäre Sektor oder auch der Dienstleistungssektor ist die dominante Form ökonomischer Tätigkeit, die in hoch entwickelten Ländern bis zu 80% eines BIP ausmacht. Die enormen Produktivitätssteigerungen in der Landwirtschaft und in der Güterherstellung sind nicht zuletzt dadurch bedingt, dass Menschen, die beispielsweise in der Landwirtschaft gearbeitet haben, neu in wissensintensiven Berufen tätig sind, die die landwirtschaftliche Produktion unterstützten. So sind spezialisierter Branchen, wie die Herstellung von hochwertigem Saatgut, der Produktion von Landwirtschaftsmaschinen, der Organisation von Warenterminbörsen, Logistikbetriebe und Verwaltungen, entstanden. Dieselbe Entwicklung hat die industrielle Produktion durchlaufen. Die dominante Form ökonomischer Tätigkeit ist der Service. Diese Tätigkeit unterscheidet sich grundlegend von der Warenproduktion. Der zentrale Gegenstand eines wirtschaftlichen Austausches ist nicht mehr eine Ware, sondern ein immaterieller Gegenstand, die Dienstleistung. Im Gegensatz zum Warenaustausch bedingt die Bereitstellung von Services einen möglichst detaillierten Austausch von Kontextinformationen. Eine gute Dienstleistung ist optimal auf das Geschäft des Kunden abgestimmt. Dies bedeutet, dass der Leistungserbringer das Geschäft des Kunden möglichst gut verstehen muss. Ein weiterer wichtiger Unterschied ist der Charakter der Service-Transaktion. Der Austausch wird durch beide Parteien gleichzeitig initiiert und die Leistungserbringung und der Leistungsbezug erfolgt parallel. Die Tiefe der Beziehung zwischen dem Leistungserbringer und dem Kunden hängt von der Art des Kunden ab. Ein B2B Service bedingt eine langfristige und umfassende Beziehung, während B2C Services auf episodische Bedürfnisse ausgerichtet sind. Zentrales Element einer Servicebeziehung ist der Austausch von explizitem und implizitem Wissen zwischen allen Beteiligten. Der Austausch des expliziten Wissens ist durch den Datenaustausch bereits heute möglich, wenn auch die entsprechenden formalen Standards und die notwendige Transparenz der Unternehmen erst in Zukunft - beispielsweise mit SOA - realisiert werden wird. Der Austausch des impliziten Wissens gestaltet sich jedoch wesentlich schwieriger. Das klassische Beispiel für implizites Wissen ist die Fähigkeit Fahrrad zu fahren. Es ist sehr einfach, zu zeigen, wie man ein Fahrrad fährt, es ist jedoch sehr aufwändig, diese Fähigkeit explizit zu beschreiben. Das implizite Wissen eines Unternehmens macht jedoch in vielen Fällen den strategischen Marktvorteil der Firma aus. Der Austausch dieses Wissen wird neue Arten der Interaktion zwischen Leistungserbringer und Kunden erfordern.

Der Service Engineer der Zukunft und seine Hilfsmittel

In Zukunft werden Services mehr und mehr als zentraler Bestandteil der unternehmerischen Tätigkeit anerkannt und organisiert werden, so werden neben bestehendenn F&E Abteilungen und Produktfactories neue Service Creation Groups Entstehen. Service Systems werden zu einer wichtigen Grundlage der Unternehmensstrategie und es wird ein neuer Berufsstand entstehen; der Service Engineer. Er ist für die Innovation von Services und für die Überwachung der Leistungserbringung zuständig. Ausserdem ist er der Impulsgeber für die Transformation von Unternehmen von der traditionellen Produktionsstätte in Richtung Service System Provider. Sein wichtigstes Hilfsmittel sind Informationssysteme, die den Austausch von expliziten und impliziten Informationen während der Serviceleistung erlauben. Diese Informationssysteme unterstützen die Innovation von Services durch die Bereitstellung von Instrumenten, die eine dynamische Modellierung Sozio-Technologischer Systeme beispielsweise durch "Agent-Based Modelling" erlauben. Solche Modelle werden dann in Geschäftsprozesse abgebildet und als ausführbare Prozesse in die entsprechenden IT-Systeme umgesetzt. Während der Austausch von expliziten Informationen durch "Service based Computing" bereits absehbar ist, wird der Austausch impliziter Informationen den Einsatz neuer Technologien in Unternehmen und Organisationen mit sich bringen. So ist ein Service System als Netzwerk nur dann vollständig, wenn alle Beteiligten in Echtzeit implizite Informationen austauschen, sich also bei der Arbeit gegenseitig über die Schultern schauen können, unabhängig davon, wo sie sich gerade aufhalten. Dies wird durch den Einsatz von Technologien, wie beispielsweise einer Weiterentwicklung der Second Life Plattform für Unternehmen oder der Anpassung von Online Game Engines für Service Value Chains, möglich.

Oracle möchte BEA kaufen - Gute Idee!

Daniel Liebhart — Tue, 16 Oct 2007 14:24:00 GMT

Der Hersteller von Application Server und Middleware-Komponenten, BEA Systems, hat von Oracle ein Übernahmeangebot bekommen. BEA war einst einer der Marktführer im Application Server Bereich, hat jedoch in letzter Zeit sehr an Schwung verloren. Vielleicht auch desshalb, weil mit SOA und den Ansprüchen der Kunden an Integrationskomponenten hohe Investitionen in AquaLogik und WebLogik notwendig gewesen wären, um mit IBM WebSphere und Oracle Fusion Middleware mitzuhalten. BEA hat aufgrund ihrer langen Präsenz auf dem Markt eine sehr grosse Kundenbasis. Diese Kunden würden eine Integration von BEA in die Oracle Produktfamilie profitieren. Es ist davon auszugehen, dass die Standardprodukte PeopleSoft, JDEdwards, Siebel und auch die E-Business Suite als Servicekomponenten mit vorgefertigten Geschäftsprozessen in BPEL auf den Markt kommen werden. Hat nun ein Kunde bereits BEA im Einsatz, so wird eine Integration dieser Komponenten zu einen funktionierenden Ganzen sicher sehr viel Einfacher, wenn die BEA Produkte Teil der Oracle Fusion Middleware Produktfamilie werden.

SOA nur ein Hype?

Daniel Liebhart — Fri, 31 Aug 2007 14:28:00 GMT

Vielerorts wird SOA als Hype bezeichnet. Jede Software jedes Herstellers wird als Lösung für SOA angepriesen. Leider besteht die Tendenz, mit SOA sämtliche Probleme, die wir schon immer in der IT hatten, lösen zu wollen. Das ist natürlich unsinn. Es wird nach wie vor schwierig sein, Projekte in Time, Budget und Quality zu liefern. Daran ändert auch eine SOA nicht. Es ist auch nach wie vor nicht möglich, die Komplexität einer IT Infrastruktur zu reduzieren. Nur weil eine Schichtung eingeführt wird, heisst das noch lange nicht, dass die Gesamtkomplexität verschwindet.

Dennoch: SOA hat wichtige Vorteile

SOA bedeutet für ein Unternehmen Standardisierung, Kostenersparnis, und Flexibilität. Damit ist SOA das erste Architekturmodell überhaupt, welches bestehende Systeme als integralen Bestandteil eines neuen Systems betrachtet. Die Grundidee hinter „Dienste statt Applikationen" ist die Weiterverwendung ganzer Systeme und die Kombination bestehender Systeme zu einem funktional erweiterten, neuen Gesamtsystem. Erreicht wird dies wird durch die Kapselung ganzer Systeme durch definierte Service-Schnittstellen. Diese Weiterverwendung hat einen grossen Einfluss auf die Kosten eines Systems. Werden bestehende „IT Assets“ eingesetzt, statt Systeme neu zu bauen, sind erhebliche Einsparungen realisierbar. Die Flexibilisierung einer Anwendung durch die Trennung der Business-Logik in statische und dynamische Bereiche ist eine weitere Stärke von SOA. Der statische Bereich der Business-Logik wird als Service realisiert, der dynamische Bereich wird getrennt davon als Prozess oder als Regel modelliert, generiert und ausgeführt. Dadurch rückt die Realisierung von Anwendung näher an die zentrale Aufgabe eines Unternehmens, der Wertschöpfung durch die Umsetzung von kundenorientierten Kernprozessen. Eine Anwendung ist eine Sequenz von einzelnen Prozessschritten. Jeder Schritt stellt einen Service dar. Die Sequenz selbst wird als ausführbarer Prozess graphisch modelliert, als Anweisungen für eine „Process Engine“ generiert und zur Laufzeit ausgeführt. Ändert sich nun ein Geschäftsprozess, so muss lediglich der entsprechend modellierte Prozess nachgeführt werden. Die neuen Prozessinformationen werden geladen und die Änderung ist durchgeführt. Diese Eigenschaft ist im Betrieb eines Informationssystems entscheidend. Auf SOA basierende Systeme sind änderungsfreundlicher und damit wesentlich flexibler als mit konventionellen Mitteln umgesetzte Anwendungen. Alle wichtigen Hersteller wie etwa IBM, Microsoft, Oracle und SAP gehen von ähnlichen SOA-Modellen aus und unterstützen das Konzept mit einer Reihe von Produkten, die im jeweiligen SOA-Stack aufgelistet sind. Die meisten anderen Hersteller von Standardsoftware stellen bereits Funktionen als Services zur Verfügung oder planen die entsprechenden Updates ihrer Produkte. Heute gibt es gute Mechanismen zur Entwicklung von Services in den wichtigsten Programmierumgebungen und für die wichtigsten Programmiersprachen. Man kann davon ausgehen, dass die verschiedenen Produkte verschiedener Hersteller auch aufeinander passen werden. Jedoch ist der Weg zur Industrialisierung von Software jedoch noch weit, da auch die Hersteller lediglich bestehende Funktionalität als Services verpacken. Die Standardisierung betrifft die Schnittstelle und die einzusetzenden Protokolle, jedoch nicht die Semantik der Services. Sie ist erst in den nächsten Jahren zu erwarten.