OOP 2008: Was kommt nach OLTP? - oder: Wo ist die Killeranwendung für Microsoft Oslo

Erst waren Batch-Anwendungen, nun sind OLTP-Anwendungen... und was kommt danach? Was ist denn der Unterschied zwischen beiden? Wo lag die Entwicklung bisher?

Batch-Anwendungen waren asynchron, nicht interaktiv und eher auf ein Rechenzentrum beschränkt. OLTP-Anwendungen hingegen sind synchron, interaktiv und durchaus auch global. Anwendungen haben sich also in ihrem grundsätzlichen Antwortzeitverhalten und der Reichweite verändert. Früher war Warten angesagt, heute regiert die Ungeduld; früher fand EDV unter Verschluss statt, heute soll sie von überall her erreichbar sein.

Soviel zu den Unterschieden zwischen zwei grundlegenden Arten von Software der letzten 50 Jahre. Natürlich hat sich noch mehr getan: von graphischen Benutzeroberflächen bis Business Intelligence. Doch mich interessiert eher, was sich nicht getan hat. Wo hat es eher keine Veränderung gegeben, denn dort liegt das Potenzial für größere Veränderungen.

Stellen SOA und Grid-Computing nicht ebensolche Veränderungen wie die Entwicklung von Batch zu OLTP dar? Nein, zunächst einmal nicht, denn SOA und Grids sind nur Architekturen und keine Anwendungsarten. Batch- und OLTP- haben zwar auch Architekturen, doch darüber hinaus stehen sie für eine bestimmte Form des Umgangs mit Computern und Daten. OLTP und SOA, das sind Äpfel und Birnen.

Aber: C/S und SOA zu vergleichen, das ergibt Sinn. Und damit rühre ich an einer Konstante, glaube ich. Bei aller Veränderung in unseren Anwendungen haben sie sich doch in einem Punkt nicht wirklich weiter entwickelt. Heute wie vor 50 Jahren sind die allermeisten Anwendungen immer noch zentralistisch. Trotz (oder wegen?) LAN und Internet liegen die Daten zentral und Geschäftslogik läuft auch zentral. Daran ändert letztlich auch eine SOA nicht viel.

Und mit diesem Zentralismus geht eine Arbeitsform einher, die sich ebenfalls nicht verändert hat: Daten werden von Menschen sequenziell bearbeitet. Da macht alle Multiuser-Fähigkeit unserer Anwendungen auch keinen Unterschied. Der eine kippt die Daten ins System, der andere holt sie raus und verändert sie, dann bearbeitet sie der nächste usw. An einem Gesamtdatenbestand arbeiten zwar gleichzeitig durchaus Tausende oder gar Millionen. Doch letztlich tun sie das alle isoliert voneinander. Ihre Zusammenarbeit ist über die Zeit gestreckt. Ich nenne das mal asynchrone Kollaboration.

Ob Batch oder OLTP, ob C/S, N-Tier oder SOA: Wir leben heute immer noch in einer Welt zentralistischer Anwendungen, mit denen wir asynchron kollaborieren.

Und nun kommt auch noch Oslo! Microsoft möchte mitspielen bei den großen Enterprise-Anwendungen. So produziert und projiziert man eine große Vision - fängt aber gleichzeitig an, sie schon im kleinen Umzusetzen. Die BizTalk Services (BTS) sind der Anfang. Das ist cool. Wo andere riesige Geldbeträge fordern für einen ESB, da verschenkt Microsoft gleich einen ISB (Internet Service Bus).

Aber was bringts? Ich glaube, das bringt erstmal nur "mehr vom Selben". Mehr Batch und mehr OLTP mit mehr SOA. Das ist natürlich nicht schlecht. Auch OLTP-Anwendungen können jede technologische Vereinfachung und jede Flexibilisierung vertragen. Aber einen so großen Sprung wie von Batch nach OLTP machen sie damit nicht.

Wenn wir jedoch BTS ernst nehmen und mal über den OLTP-Tellerrand schauen, wenn wir mal die bisherigen Konstanten in den Blick nehmen und fragen, ob sie denn weiterhin konstant gehalten werden müssen... dann kommen wir zu einer nächsten Veränderungen der Qualität unserer Anwendungen. OLTP "fühlt sich ganz anders an" als Batch, es ist eine andere Qualität. Aber was könnte sich nun wieder ganz anders anfühlen als OLTP?

Ich glaube, das erfahren wir, wenn wir die bisherigen Konstanten aufgeben: Zentralismus und Nacheinanderarbeit. Denn das wird mit einem ISB wie den BTS jetzt möglich.

Nach OLTP kommt SROC: Serverless Real-time Online Collaboration.

SROC-Anwendungen bieten wiederum eine neue Qualität: Sie machen die Zusammenarbeit von Menschen in Echtzeit an den selben Daten möglich, ohne dafür eine zentrale Infrastruktur aufsetzen zu müssen:

• Serverless: SROC-Anwendungen brauchen weder für die Kommunikation noch für die in Arbeit befindlichen Daten eine zentrale Infrastruktur. SROC-Anwendungen spannen zwischen kollaborierenden Instanzen ein ad hoc Verbindungsnetz auf und arbeiten darüber an einem gemeinsamen virtuellen Datenraum. Ihre Skalierbarkeit muss nur proportional zur Zahl der Kollaborateure sein und nicht zur Gesamtbenutzerzahl, wobei gilt Kollaborateurzahl << Gesamtbenutzerzahl.
• Real-time: In SROC-Anwendungen kollaborieren Benutzer gleichzeitig. Nur wer anwesend ist, kann auch kollaborieren. Ein Chat ist die einfachste Form einer solchen real-time Kollaboration. Das steht im Gegensatz zur bisher üblichen asynchronen Kollaboration in OLTP-Anwendungen, bei dem z.B. Auftraggeber und Auftragnehmer eben nicht gleichzeitig an der Anwendung arbeiten müssen, um dennoch das gemeinsame Ziel zu erreichen. Asynchrone Kollaboration skaliert deshalb sehr gut - aber in diese Skalierbarkeit ist nicht für alle Kollaborationsprojekte nötig oder gar kontraproduktiv. Das weiß jeder, der schon einmal versucht hat, einen Konflikt per Email statt durch persönliche Kommunikation von Angesicht zu Angesicht zu lösen. Aufgaben, die ad hoc Absprachen und Reaktionsschnelligkeit erfordern, wo die Kommunikation fließen muss - das beginnt bei der Terminvereinbarung und endet bei Rettungseinsätzen -, sie werden am besten in real-time bearbeitet.
• Online: Teams, die in Echtzeit an kreativen Problemlösungen aller Art arbeiten, sind heute immer öfter über die Welt verteilt oder finden sich spontan zusammen (z.B. an einem Unfallort). Sie können sich also nicht auf die Existenz einer lokalen Infrastruktur verlassen. Ihr kleinster gemeinsamer Nenner ist das Internet - via LAN und Router oder GPRS. Wenn solche Teams computergestützt zusammenkommen wollen, dann muss das also online, d.h. über das Internet geschehen können, ohne dass Firewalls sie unbebührlich behindern.
• Collaboration: Miteinander statt gegeneinander. Team statt Hierarchie. Das hat inzwischen auch der Letzte begriffen. Dennoch ist Zusammenarbeit nicht gleich Zusammenarbeit. Und auch Collaboration Tools sind nicht alle gleich. Das Thema Collaboration ist nicht neu, aber die bisher breit verfügbaren Kollaborationswerkzeuge jenseits von rundem Tisch, Whiteboard und Chat bieten noch nicht, worum es bei SROC geht. Email, die Änderungsverfolgung in MS Word oder document sharing mit MS SharePoint dienen alle der Kollaboration - aber die findet sequenziell, asynchron statt. Das ist auch wichtig, doch eben nicht genug. Asynchrone Kollaboration verschenkt Chancen, um mit der steigenden Komplexität der (Arbeits)Welt kräftesparend umzugehen. Denn asynchrone Kollaboration verhindert durch die zeitversetzte Interaktion das Entstehen von Synergieeffekten zwischen den eigentlich zusammenarbeitenden Individuen. Ungeplante Kommunikation als Quelle und Träger von Neuem und hilfreicher Redundanz gibt es bei asynchroner Kollaboration kaum. Die Vorteile der Virtualisierung werden dadurch zum Teil wieder zunichte gemacht.

Wie gesagt, nicht dass es bisher keine ausdrücklichen Kollaborationsanwendungen gegeben hätte. Email ist das beste Beispiel für asynchrone Kollaboration, Chat das beste Beispiel für real-time Kollaboration. Napster, Gnutella & Co allerdings weniger, auch wenn sie serverlos und online sind. Es geht dort einfach nicht um echte Zusammenarbeit an großen oder kleinen Projekten. Auch Subversion und Sourceforge sind natürlich Kollaborationswerkzeuge - allerdings serverbasierte. Und Groove... ja, auch ein Kollaborationswerkzeug, aber nicht für die real-time Kollaboration.

Ich glaube, dass SROC das "nächste große Ding" sein wird in der Softwarewelt. Die Menschen wollen zusammenarbeiten und sie wollen und müssen es öfter in Echtzeit tun, weil sie sonst ineffizient arbeiten. Nicht in Echtzeit zu kommunizieren, ist öfter als mal denkt, wie Sand im Getriebe. Aber Menschen wollen für eine Zusammenarbeit in Echtzeit nicht immer auch persönlich zusammenkommen müssen. Oder sie wollen, auch wenn sie zusammen sind, sich bei ihrer Arbeit durch ein Werkzeug unterstützen lassen.

OLTP ist gut, wenn ich bei Amazon bestelle. Batch ist gut, wenn ich Videos über Nacht komprimieren will. SROC ist gut, wenn ich mehr oder weniger ad hoc mit anderen zügig und kreativ ein Problem lösen will. SROC-Anwendungen sind daher ureigenst Anwendungen einer Wissensgesellschaft. Wiki und Chat sind nett... aber nur der Anfang.

Denn Wiki und Chat brauchen große Server oder sind dank Firewalls schwer zu programmieren. SROC-Anwendungen brauchen aber keine solchen Server mehr... und werden dank ISB viel leichter zu programmieren sein.

So glaube ich also, dass die wahren Killeranwendungen für BizTalk Services oder das größere Projekt Oslo nicht die nächste Runde von SOA-Services sind. Die werden sie auch nutzen. Klar. Aber viel spannender ist es, mit diesen Technologien etwas ganz neues zu machen. Und SROC-Anwendungen sind soetwas Neues. Heute gibt es sie nur vereinzelt, aber morgen könnte ihre Zahl explodieren, weil es soviel einfacher wird, ihre Instanzen zu vernetzen.

PS: Allerdings ist eine einfachere Vernetzung durch Firewalls hindurch nur ein erster, notwendiger Schritt. Ein nächster muss sein, die Zusammenarbeit in Echtzeit an dem Gemeinsamen zu vereinfachen. Wie hält eine Wolke von Instanzen einer SROC-Anwendungen, wie halten diese Kollaborateure einen gemeinsamen Zustand? Dazu mehr in einem späteren Posting... Hilfe ist auch hierzu unterwegs.