Dei schwarze Kiste der Pandora

Die schwarze Kiste der Pandora

Viele Dinge, die wir benutzen, verstehen wir nicht. Wir verlassen uns darauf, daß der Hersteller weiß, was er da macht und sind zufrieden, wenn wir soviel wissen, das wir das Ding benutzen können. Das geht häufig auch überhaupt nicht anders. Zum einen sind viele Dinge zu kompliziert, als das ein einziger innerhalb der ihm zur Verfügung stehenden Lebenszeit das Wissen ansammeln könnte, um sie vollständig zu verstehen. Das gilt nicht nur für den Computer, an dem ich diesen Text schreibe. Das ist auch gerade das Geheimnis, wie die Gesellschaften seit Jahrtausenden zu Wohlstand gekommen sind. Durch Arbeitsteilung macht jeder das, was er am besten kann. Wenn die so entstandenen Waren und Dienstleistungen dann ausgetauscht werden, haben alle wesentlich mehr, als wenn jeder es auf eigene Faust versuchen würde.

Es gibt aber Situationen, wo man vorsichtig sein und sich nicht beliebig ausliefern sollte. So wollen wir zwar nicht alle unsere Lebensmittel selber herstellen, erwarten aber doch, daß wir auf der Packung nachlesen können, was drin ist.

Quelloffene gegen geschlossene Software

Heute hat man in vielen Fällen die Wahl zwischen Software, deren Quellen man einsehen kann und die meistens frei verfügbar ist, und solcher, die als fertiges Programm von einem Hersteller geliefert wird und über deren Funktionsweise man nur soviel erfährt, wie uns der Hersteller gnädigerweise in der hoffentlich mitgelieferten Dokumentation verrät. Die Dinge sind natürlich nicht so einfach schwarz und weiß. Brauchbare quelloffene Software wird in aller Regel auch von Leuten geschrieben, die damit Geld verdienen wollen, allerdings nicht durch den Verkauf der Software sondern ihres Wissens um die Möglichkeiten derselben. Diese Leute haben oft nicht nur keine Lust, gute Dokumentation zu schreiben, sondern es gehört zu ihrem Geschäftsprinzip, das kompliziertere Dinge nur möglich sind, indem man entweder versteht, wie die Software aufgebaut ist oder teure Beratungleistung einkauft. Allerdings ist es in den meisten Fällen immer noch billiger, sich ein oder zwei Wochen durch fremden Code durchzuarbeiten wie ein Projekt an der unzureichenden Dokumentation einer eingekauften Komponente scheitern zu lassen.

Über eins darf man sich aber nicht täuschen. Die Offenheit von Software bedeutet nicht unbedingt, daß ich auch verstehe, was da abläuft, oder gar Änderungen vornehmen kann. Einige Dinge sind so komplex, daß es nur wenige Spezialisten gibt, die da eine Chance habe. Auch die Rolex ist quelloffen. Ich bin aber sicher nicht in der Lage, eine solche Uhr zu öffnen und dann wieder so zusammenzusetzen, daß sie weiterhin funktioniert. Wenn behauptet wird, daß ein quelloffener Verschlüsselungsalgorithmus von jedem auf Hintertürchen überprüft werden kann, ist das eine rein theoretische Aussage, da es jahrelange Studien braucht, die Konsequenzen von dem, was da abläuft, zu verstehen.

Datenstrukturen

Zumindest im Umfeld von Geschäftssoftware geht es fast immer um Daten. Wenn Daten abgelegt werden, so daß sie nur mit der Software verwendet werden können, die sie einmal geschrieben hat, so kann es sein, daß die Daten verloren gehen, wenn es z.B. für dann aktuelle Betriebssysteme keine Version dieser Software mehr gibt.

Hier ist es wichtig, daß bekannt ist, wie die Daten abgespeichert sind, so daß man notfalls eine Software erstellen kann, um an sie heranzukommen.

Abläufe

In einem Geschäftsprozeß werden Daten immer wieder verändert. Dabei kann es vorkommen, daß Zustände entstehen, die so nicht vorgesehen sind. Die Daten sind dann im weiteren Verlauf gar nicht oder nicht mehr korrekt verarbeitbar. Wenn die verwendete Software die Daten in für den Benutzer nicht zugänglichen Strukturen ablegt, ist das Problem nicht zu lösen. Zumindest muß die Software eine Zugriffsmöglichkeit bieten, daß solche Fehler behoben werden können. Ist das nicht der Fall, so ist die Software für den Gebrauch in realen Anwendungen nicht geeignet, denn Fehler werden immer vorkommen. Einen Datenverlust aufgrund dieser Fehler kann man sich aber nicht leisten.

Neben Fehlern gibt es auch die Änderung der äußeren Umstände. Wenn eine Anwendung mit langlaufenden Geschäftsfällen umgeht, kann das im echten Leben bedeuten, daß im ersten Schritt eine Bestellung in China aufgegeben wird. Das Containerschiff braucht Wochen, bis es in Europa ist. Wenn es von Piraten überfallen wird, können daraus auch Monate werden. Bis dahin können schon etliche Partner, des ursprünglich vorgesehenen Geschäftsablaufs, ausgetauscht worden sein. Wenn keine Möglichkeit besteht, den einmal gestarteten Prozeß  nachträglich an die geänderten Rahmenbedingungen anzupassen, so ist er untauglich.

Beispiele

Bei Datenbanken sind die konkreten Datenstrukturen auf der Platte in der Regel nicht bekannt, sofern die Datenbank nicht quelloffen ist. Dies ist solange kein Problem, solange das jeweilige Produkt noch von irgendeinem Hersteller unterstützt wird. Die Zugriffsmöglichkeiten sind hinreichend flexibel, daß alle benötigten Manipulationen an den Daten durchgeführt werden können.

Anders sieht das bei BPEL aus. Dies ist eine neuere Technik, bei der bislang übersehen wurde, eine Zugriffsmöglichkeit auf die damit verarbeiteten Daten und Geschäftsprozesse zu definieren. Wenn mein Container in China abgeschickt worden ist, weiß ich schon Monate zuvor, daß es bei der Anlieferung Probleme geben wird, wenn die Daten aus irgendeinem Grund falsch angelegt worden sind. Machen kann man da aber in der Regel wenig.

Empfehlung

Wenn man schon ein Werkzeug wie BPEL einsetzen muß, daß die genannten Probleme aufweist, sollte das System so gebaut werden, daß das Werkzeug nur Daten intern hält, die für den Ablauf notwendig sind. Alle anderen Daten werden unabhängig - z.B. in einer Datenbank - abgelegt und intern nur referenziert. Das bedeutet konkret, daß die Daten über den Inhalt unseres Containers und die Empfänger nicht im BPEL-Prozeß gehalten werden. Statt dessen werden nur Referenznummern übergeben und die Services, die konkreten Daten benötigen holen sich diese jeweils bei Bedarf anhand der Referenzen.
Damit wird allerdings nur das Problem der beschädigten Daten gelöst. Die Anpassung des laufenden Geschäftsprozesses bleibt weiterhin ein Problem. Dies kann aber zumindest leichter von Beratern des Herstellers gelöst werden, die eventuell einen Hack im Inneren des Systems durchführen können.
Es gibt weitere Gründe für einen solchen Ansatz: Erstens wird die Verarbeitunggeschwindigkeit so erheblich verbessert, da weniger Daten bewegt werden müssen. Zweitens braucht man die Daten in aller Regel meist sowieso zu direktem Zugriff außerhalb, so daß jetzt eine doppelte Datenhaltung vermieden wird.