Grid Computing feiert dieses Jahr sein 10 Järiges Jubiläum, es sind jedoch keine offiziellen Feierlichkeiten weit und breit zu sehen. Nun, dass kann daran liegen, dass seit 2 Jahren der Begriff Cloud Computing für die Bereitstellung einer grossen Anzahl von verteilten Ressourcen zwecks Durchführung von Aufgaben mit sehr grossem Daten- oder Rechen-Bedarf steht. Tatsächlich haben beide Technologien zum Ziel, die Vision von John McCarthy einem ehemaligen Standford Professor und dem Erfinder von LISP umzusetzen. Er sagte anlässlich des 100 Jährigen Geburtstages des MIT in einer Rede: “computation may someday be organized as a public utility”. Grid Computing ist seit vielen Jahren im wissenschaftlichen Bereich etabliert. Infrastrukturen wie die Deutsche Grid-Initiative (D-Grid) ,  Global Ring Network for Advanced Applications Development (GLORIAD),  Collaborative Climate Community Data and Processing Grid (C3-Grid) , Enabling Grids for E-sciencE (EGEE), E-science grid facility for Europe and Latin America (EELA)  und das  National Virtual Observatory sind in Betrieb und werden für viele Anwendungen eingesetzt.

Der neue Begriff Cloud Computing ist dagegen noch mit recht wenigen Infrastrukturen und Angeboten hinterlegt obwohl Cloud Computing für die neue Art und Weise, wie die Informationstechnologie im 21 Jahrhundert genutzt werden wird steht. IBM hat bereits vor zwei Jahren mit der Einführung seiner Blue Cloud Initiative angekündigt, dass mit dem neu aufkommenden Modell der Zugriff auf Anwendungen global mit jedem beliebigen Gerät erfolgen kann. Salesforce, Amazon, Microsoft, Sun und andere sind im letzten Jahr mit Angeboten gefolgt, die unter dem Namen Cloud Computing virtualisierte Dienste anbieten. (Eine wunderbare Beschreibung von Cloud Computing durch John Willis ist in seinem Blog zu finden)

Was ist nun genau der Unterschied?

IBM sieht Cloud Computing als logisches Resultat aus der Entwicklung vom Distributed Processing zum Grid Computing über Utility Computing und Software as a Service. Ian Forster sieht sogar Grid Computing als integralen Bestandteil von Cloud Computing und umgekehrt. Tja, leider ist der Unterschied nicht sehr genau zu isolieren. Der Grund dafür ist, dass Grid Computing eine längst etablierte Technologie ist während sich Cloud Computing noch auf dem Markt etablieren muss. Das würde also bedeutet Äpfel und Birnen mit einander zu vergleichen und das ist unfair. Tatsache ist jedoch, dass bestehende Grid Lösungen Cloud Computing Infrastrukturen wie beisielsweise die Elastic Cloud benützen, um ihre Dienste bereitzustellen. Und Tatsache ist auch, dass die Dienste des Cloud Computing sehr viel einfacher gestaltet sind als die Dienste des Grid Computing. Der öffentliche und standardisierte Protokollstack des Grid Computing ist weit umfangreicher als derjenige des Cloud Computing.

Wir sind also gespannt, wie sich die neue Technologie Cloud Computing vom Hype zum Markt hin etablieren wird.

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. 

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.

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.

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/)

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.

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.

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.

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