Weitere aktuelle (und nicht mehr ganz aktuelle) Trends in Richtung „Definition der Information“
Seit langem kennen Programmierer in objektorientierten Sprachen die Übereinkunft, öffentlich feilgebotene Variable nur über die „erlaubten“ Zugänge von Set- und Get-Methoden zu ändern und abzufragen.
Zustände, gebildet aus einzelnen Attributen, sind das A und O in der Informatik, der Ingenieurskunst der Information – doch nicht nur das. Die Veränderung der Zustände, die Programme, sind geradezu ihr zentrales Interessensgebiet, könnte man sagen.
Besonders schön lässt sich dies an Cookies sehen, den „Zustandselementen“ der üblichen Internet-Sitzungen via http-Protokoll. In Java benötigt ihr Konstruktor nicht mehr als den Schlüsselbegriff und den Schlüsselwert:
Eigenschaft und Wert.
Klare Sache, weiß jeder, kennt jeder, ha’m wir alles schon gemacht.
Cookies heißen aber nicht Kekse, sondern sind wohl ein Terminus Technicus der Informatiker für „kleine Informationseinheiten“.
Kleine Informationseinheiten sollten aber doch eigentlich besonders schön auf die Natur der Information hinweisen – die einfachsten ihrer Art sollten dann eine Art von „Atom der Information“ darstellen können.
Wenn...
ja, wenn eben berücksichtigt wird, dass Zustände, gebildet aus Eigenschaften und ihren Werten, nur deshalb so genau betrachtet werden, weil sie veränderlich sind. In der Konstanz steckt schließlich (Shannon) keine Information. Doch Veränderlichkeit alleine genügt nicht, der Ausgang beliebiger („zufälliger“) Vorgänge interessiert vielleicht höchstens Statistiker – für Informatiker müssen sie veränderlich durch „Algorithmen“ sein, nicht wahr?
Wieso kommt dann keiner auf die Idee, genau dies (Eigenschaft, Werte, Algorithmus) als „Atome der Information“ zur Definition der Information zu verwenden?
Bei BPO hieß es kürzlich, dass es sich nur für langfristig stabile Problembereiche eignet – nun, wer Information und Informationsverarbeitungen kennt und sich schon mal gefragt hat, wieso eigentlich die Mengenmathematik so wahnsinnig erfolgreich ein Universum beschreiben kann, das aus den Wirren des Quantenrauschens über stehende Wellen und deren Interferenz erzeugt wurde, den wundert’s nicht:
Denn gerade die Janusgesichtigkeit der Information, einerseits Wirkung, sprich permanenter Wechsel, andererseits identifizierbar und wiederholbar, also abbildbare Regelmäßigkeit zu sein, erlaubt es nicht, das eine ohne das andere zu sehen. Die reine Änderung, der Zeitfaktor eines Problems, macht allein keinen Sinn, weil sie nichts Speicherbares an sich hat. Was heute grün ist, ist morgen blau...
Die reine Stabilität, der Raumfaktor eines Problems, macht allein keinen Sinn, weil sie zwar speicherbar ist, dafür keine Geschichte hat und damit keine Prognose erlaubt. Und das ist, wie leidlich bekannt, das Einzige, was wirklich zählt – der Blick in die Zukunft, auf dem unsere Entscheidungen aufbauen.
Was aber Sinn macht, ist eine Art von „Extrembetrachtung“ – Probleme nach „raumartig“ und „zeitartig“ zu kategorisieren, sprich nach ihren „Anteilen an Zeit und Raum“ einzuschätzen: ihrem Verhältnis Veränderlichkeit/Stabilität.
Liegen nur langfristig veränderliche Probleme vor, so erlauben sie nämlich eine recht vollständige Erlernbarkeit (Modellierbarkeit). Ihre Zustände und Abhängigkeiten können also im „Wissen“ fast komplett vorhanden sein, du kannst dein Wissen als „abgeschlossen“ betrachten, als eine Menge im mathematischen Sinne.
Ein solches Problem kannst du wunderbar mit den bekannten mathematischen Funktionen beschreiben, die eigentlich nichts weiter sind als Landkarten auf ihren zugrunde liegenden Mengen. Doch weil das Problem aus informativen Zuständen besteht und deren Anordnung aus der Realität von informativen Veränderungen stammt, sind diese Funktionen prächtig geeignet, tatsächliche Veränderungen darzustellen.
Ein solches Problem kann deshalb auch gut ausgelagert werden, denn durch das ausgezeichnete Wissen können wohlangepasste Schnittstellen bestimmt werden, die effektives Arbeiten kanalisieren, ohne es zu stören – und genau das muss das Interesse der Informationsverarbeitung „Firma“ sein.
Denn jede Informationsverarbeitung hat notwendig ein Ziel:
Physik der
Information, ISBN 3-935031-03-3,
Entstehungsgrund, S. 191
„Eine Voraussetzung ist dabei implizit für jede Informationsverarbeitung gegeben – ihre endlichen Ressourcen zwingen sie immer, Auswahlen zu treffen, denn selbst die Mathematik vermag kein allmächtiges Axiomensystem zu erstellen. Jede Informationsverarbeitung braucht also ein Ziel als Positionierungselement in der Unendlichkeit der Details wie eine Boje im Meer – an dem sich die Masse erkennbarer Wertveränderungen teilt, um zu einer endlichen, verarbeitbaren Anzahl von Ereignissen reduziert zu werden.
Doch nicht nur die Anzahl der Wertveränderungen, die wir als informationsverarbeitendes System akzeptieren wollen, wird durch dieses Ziel bestimmt – auch die Anzahl von Identitäten, ihren Hierarchien und Abhängigkeiten muss dadurch auf ein Maß zurückgeschraubt werden, das überhaupt bewältigt werden kann. Identitäten sind schließlich nie wirklich isoliert zu betrachten – wenn eine Person analysiert wird, so muss immer auch ihre Familiensituation betrachtet werden, ihr Kollegenkreis, ihre Nationalität und Sprache, die Mentalität und Glaubensgrundsätze bestimmen.
Das ist nicht wirklich machbar.
Über die Ziele entscheidet eine Informationsverarbeitung deshalb auch immer, wo die Grenze der Beobachtung zu setzen ist, ab wann der Gewinn an Information durch den Aufwand zur Gewinnung nicht mehr überwiegt. Neben den eigentlichen Bedingungen an die Information muss eine Informationsverarbeitung deshalb immer auch die Belastung ihrer Gewinnung gegen den Ertrag ihrer Gewinnung aufrechnen. Oder mit anderen Worten: Wenn ihr Überleben durch den Aufwand stärker gefährdet ist, als es durch den Vorteil besserer Prognostizierbarkeit durch Information gefördert wird, dann lohnt es sich einfach nicht mehr für eine Informationsverarbeitung.“
Das ist nicht nur das Problem bei der Zugewinnfunktion, das ist auch das Problem bei jedem CIO, der um sein Budget kämpft, nicht wahr?
Was das mit BPO zu tun hat?
Nun, auslagern heißt, wesentliche Teile seines eigenen Systems in ein fremdes zu übertragen – das ist ein sehr riskantes Spiel hinsichtlich des Ziels. Denn als Informationsverarbeitung Typ „Firma“ ist mir klar, dass mein Ziel, Profit zu machen, zwar exakt dasselbe ist wie das derjenigen IV, der ich mein Subsystem übergebe – nur leider ein bisschen zu exakt. Denn so wie ich für mich Profit machen will, so will die andere IV für sich Profit machen.
Das wiederum heißt im Klartext: Ich muss für eine vernünftige Auslagerung garantieren können, dass mein Ziel auch das Ziel der anderen IV bleibt. Klar, nach dem Prinzip von Kosten und Ertrag erscheint es mir, dass es mir unter dem Strich mehr bringt, wenn ich die andere IV für meine gewünschten Ergebnisse bezahle, weil sie dann auch die Arbeit damit hat.
Aber ich gebe auch Kontrolle und damit Einfluss auf: Wer einmal ein Problem mit ML durchrechnete, wird nicht mehr erstaunt sein, wie sehr sich neue oder fehlende Eigenschaften auf die Gesamtstruktur auswirken können.
Hinsichtlich BPO oder anderen Auslagerungsformen hat dies also die Frage zur Folge, ob ich mein System, so wie es ist, weiterführen möchte.
Sprich, ob ich die gewünschten Ergebnisse, die ich zuvor von internen Subsystemen erhielt, nun auch von dem ausgelagerten haben möchte oder ob ich bereit bin, meine ganze Organisation letztendlich an „neue Gegebenheiten“ anzupassen.
Ich schätze, mit der reduzierten Einwirkungsmöglichkeit auf den fremden Dienstleister sollte das Risiko einer Neuausrichtung lieber nicht probiert werden (Stichwort Ziele), soll heißen, dass der fremde Dienstleister möglichst genau die Ergebnisse zu liefern hat, die das eigene Subsystem ebenfalls erbrachte: Er muss geradezu simulieren, der bekannte Teil meines eigenen Subsystems zu sein.
Je unveränderlicher ein Problem ist, umso besser funktioniert diese „Simulation“, einfach deshalb, weil meine Kenntnis über das Problem mir Planung und Kontrolle auch weiterhin ermöglicht. Hier kann ich vernünftig outsourcen.
Je veränderlicher ein Problem ist, umso mehr Kommunikation ist zur Abstimmung aller Subsysteme erforderlich – die Grenzgeschwindigkeit des Max-Planck-Institutes zeigt dies zwar auf einer sehr „niedrigen“ Ebene, aber doch deutlich: Die Zusammenarbeit der Neuronen im Netz muss synchron sein, um Information zu verarbeiten. Ein einzelnes asynchrones Neutron zwingt all die anderen zu Abstimmungsvorgängen, bis Synchronizität wieder hergestellt ist.
Das gilt genauso für hoch entwickelte Informationssysteme. Information ist wiederholbare, identifizierbare Wirkung und deshalb schön verarbeitbar über ihre Zustände und deren Anordnung. Das heißt freilich zwangsweise, dass sowohl die gesamte Breite eines Zustandes rekonstruierbar bleiben muss als auch die Position in der Anordnung. In einer Informationsverarbeitung ist dies tatsächlich immer ein Problem:
Physik der
Information, ISBN 3-935031-03-3,
Die Grundkonstruktion der
Informationsverarbeitung: die Fliege, S. 210
„Denn der Wunsch nach überschaubaren Wirkungsketten ist nichts weiter als der Wunsch, die Kontrolle über die Verarbeitungszustände zu ermöglichen. Überschaubare Wirkungsketten sind freilich nichts weiter als möglichst kurze Ketten, das wiederum kann über Längenbestimmungen erreicht werden.“
Die Dreiecksform, die sich so ganz nebenbei in jeder Hierarchie mit vielen Mitarbeitern, ein paar Leitenden und einem Chef findet, ist als effektive Form der Arbeitsteilung besonders schön im Urbild aller Informationsverarbeitung, im Gehirn zu sehen. Hier fing Mutter Natur auch mit einem wirren System auf Objektebene (JedeMitJedem) an, führte jedoch alsbald die Leiter ein – eine abstrakte Form der „Fliege“. Warum? Weil die Leiter aus sensorischen Neuronen besteht, die Input sammeln (auslegender Teil des Doppeldreiecks „Fliege“), zu der Entscheidungsstelle führen (der Knotenpunkt, an dem die beiden Spitzen der Dreiecke der „Fliege“ aufeinander stoßen) und die Entscheidung dann über die motorischen Neutronen zu den Teilen des Organismus führt, der für die Ausführung der Entscheidung zuständig ist. Die Leiterform ist übrigens bis in unser Gehirn erhalten geblieben, hat sich nur gegenüber den frühen Formen weiter in Richtung „Fliege“ entwickelt, da einer von mehreren Knoten sich zum Zentralgehirn mauserte.
Auch das RTE wird in diese Richtung gehen, schließlich wird SOA als die benötigte Architektur verstanden und SOA wird mit directories arbeiten müssen wie viele andere IT-Systeme auch.
Was das mit erfolgreichem Outsourcing zu tun hat?
Es heißt, dass du deine ganzen Aufgaben nicht nur unter dem Gesichtspunkt Kerngeschäft ja/nein sehen musst, sondern auch unter seinen dynamischen Anforderungen: Kommunikation und Stabilität. Je schneller sich ein Problemgebiet ändert, umso unwichtiger muss es für deine Existenz sein, damit du es auslagern kannst. Unwichtig heißt hier, dass es dir nicht so genau auf das Ergebnis ankommt, dass du leicht verschiedene Abarten davon nutzen kannst – hübsches Beispiel ist hier ein Fuhrpark. Denn sind wir ehrlich: Ob du mit dem Mercedes oder mit dem Fiat fährst, macht nicht wirklich einen Unterschied, solange du Repräsentation nicht als zwingend ansiehst. Änderung in diesem Zusammenhang heißt grundlegende Strukturänderung, sprich Veränderung von Charakteristika maßgeblicher Zustände, die für die Symbolik deiner Abbildungen/Prozesse bedeutsam waren. Wie gesagt, wer gesehen hat, wie schnell eine effiziente Struktur verkommt bei neuen oder fehlenden Eigenschaften, der bekommt Respekt vor solchen grundlegenden Änderungen - und wer ERP-Programme betreut und seine Konzepte wieder und wieder höchst gefährdet sah, weil eine „Kleinigkeit“ übersehen worden war, sicher auch. Beispiel? Ich schätze, das Internet ist kein übles Beispiel für eine grundlegende Strukturänderung, denn es veränderte die Repräsentationsebene der Unternehmen doch beträchtlich.
Änderungen auf dieser Strukturebene sind dagegen nicht die moderne Gesetzgebung, auch wenn diese manchmal für die IT katastrophal flott ist, denn eine Organisation, die nicht gelernt hat, diese permanente (und damit letztendlich wieder stabile) Unsicherheit in ihrem Aufbau zu puffern, hat sicher schon längst die gesamte Buchhaltung und Lohnsteuerabteilung outgesourct: Diese Änderungen sind Teil des „Inhalts“ der Aufgabe, für die die Struktur ausgelegt sein muss, genauso wie ein schwieriger, launischer Kunde das ist.
Je gleich bleibender ein Problemgebiet freilich ist, umso eher kannst du auch wichtige Elemente auslagern. Denn du hast sie bisher bereits gut kennen gelernt, du kannst die Möglichkeiten abschätzen, die Richtlinien festlegen, die Kontrollen machbar gestalten, du kannst die Kommunikation dauerhaft fokussieren, sprich die Schnittstellen zwar breit auslegen, aber wegen der Stabilität auch als zuverlässig betrachten, wenn sie einmal laufen: Buchhaltung und Lohnsteuerabteilung sind hier die üblichen und in vielen Firmen längst ausgelagerten Arbeitsgebiete, gerade auch, weil sich die Ergebnisse Bilanz und V+G oder Lohnsteuerkarte und Lohnauszahlung nur wenig änderten im Laufe der Jahre.
Wichtige, dynamische Aufgabengebiete, die also veränderlich sind und/oder einen hohen Kommunikationsanteil benötigen, solltest du jedoch um deine Kernfunktion herum als interne Subsysteme anordnen, weil dir das die Möglichkeit gibt, die notwendigen Abstimmungen schnell und zügig durchzuführen: RTE.
Denn auch das ist ein Nachteil beim Outsourcen: Alle Abstimmungsvorgänge erschweren und verlangsamen sich.
Zwangsweise.
Und hier wird dann für manche Firmen sogar die Auslagerung von Buchhaltung wieder fraglich – weil die ständig wachsenden Möglichkeiten der IT, Zahlen miteinander in Verbindung zu setzen, einen ständig wachsenden Bedarf an Auswertungen erzeugt. Und je näher die Daten der Buchhaltung vor Ort sind, umso rascher kriege ich meinen Überblick, umso schneller kann ich neue Sichten installieren. Das muss sonst alles verhandelt (abgestimmt) werden.
Ein sinngemäßer Artikel ist in der Computerwoche 14/2004, S. 38 zu finden: „Aus alten Fehlern im IT-Outsourcing lernen“ im Rahmen des Schwerpunkts „Outsourcing“. Ebenfalls hochinteressant ist bei Pro und Kontra, S. 40, der Artikel von Markus Klahn, Proalpha Consulting AG: „Kontra: Know how schützen“. Denn er argumentiert „informationsnah“, von der Ebene der Informationsverarbeitung her, mit den Problemen, die jede solche IV einfach deshalb hat, weil sie notwendig über Abbildungen arbeiten muss, um reale Vorgänge zu erfassen, zu planen, zu steuern und auszuführen. Im Gegensatz dazu argumentiert der Vertreter des Outsourcing „informationsfern“, so sehr, dass er tatsächlich behaupten kann, Know How aus zweiter Hand wäre kein Wissensverlust. So kann nur jemand argumentieren, der nicht weiß, was Information ist und deshalb nicht wissen kann, was Intelligenz und Wissen ist.
„Wissen“ ist dabei die gesamte bereits vorhandene Abbildung einer Intelligenz. Zu beachten ist, dass diese Abbildung nicht nur die Zustände und ihre Reihenfolge umfassen muss, sondern insoweit auch dynamisch sein muss, dass sie diese Zustände/Reihenfolgen abspeichern und abfragen kann.
Wissen, das von anderen erworben wird, aufbereitet in „Knowledge Bases“ und dann dem Kunden zur Verfügung gestellt wird, ist eben nur Wissen aus zweiter Hand, da die Vollständigkeit der Kontexte, der zeitlichen und sachlichen Anordnungen mit überwältigender Wahrscheinlichkeit nicht garantiert werden kann. Das Know How, das von denjenigen erworben wurde, die es in die „Knowledge Base“ stellen, ist dasjenige „aus erster Hand“. Wird Know How den Outsourcern „aus erster Hand“ überlassen, dann werden diese völlig unmöglich in der Lage sein, dieses umfangreiche Wissen nicht auch für andere Kunden zu nutzen – Wissen ist nämlich dann in ihrem Kopf und der lässt sich nicht einfach abschließen. Zumal ein interessanter Satz im Artikel „Offshore-Projekte langfristig planen“, S. 42 darauf hinweist, dass beispielsweise Indien zwar Urheberschutz-Gesetze hat, die seinen ausländischen Kunden gefallen, es aber leider nicht in die juristische „Tat umsetzen“ – weil es eben nicht der Mentalität entspricht.
Wie also der Autor des Pro-Artikels behaupten kann, das Argument eines Know-How-Transfer zum Dienstleister ziehe nicht mehr, ist angesichts seiner eigenen Worte – von der Erstellung der Knowledge-Base durch den Dienstleister als Know-How-Garantie für den Kunden – nicht mehr nachvollziehbar. Meine persönliche Meinung? Das schrieb ein Vertriebler.
Die Frage ist deshalb nicht, ob Know-how-Transfer stattfindet – das tut es immer. Niemand kann halbwegs vernünftig programmieren, ohne die Sache richtig verstanden zu haben.
(Niemand lernt ein Problem so gut kennen, wie die, die die Formeln/Programme aufstellen, das gerade ist das Geheimnis der Mathematik:
Physik der
Information, ISBN 3-935031-03-3,
Mathematik heute, S. 101
„Über die Nachprüfbarkeit von Schlussfolgerungen hinaus, über die Möglichkeit hinaus, solche Regeln auch anderen beizubringen und damit komplexe Zusammenhänge lehren zu können, hat diese Kunst außerdem eine hohe Wirkung auf Kreativität und Fantasie.
Warum? Weil Mathematik durch dieses genaue, schrittweise Vorgehen einen sehr tiefen Einblick in ein Problem gibt. Liegen mathematische Werkzeuge vor, so müssen diese wie alle Abbildungen eine hohe Übereinstimmung mit dem Beschriebenen haben, um als „Werkzeug“ vielseitig einsetzbar zu sein. Ein Problem aber zu kennen, bedeutet, es variieren zu können – das war einer der Vorteile, warum unser Gehirn so mächtig wurde. Die Fantasie ist nichts weiter als die Benutzung eines Denkmodells unter fremdartigen Voraussetzungen oder Einflüssen.“)
Die Frage ist deshalb nur, ob mir dieses spezielle Know how wichtig ist. Denn wenn ich outsource, gebe ich es immer auf, vor allem – und das dann recht schnell und umfassend – in seiner praktischen Anwendbarkeit.
Hannover-Messe – was für eine Vielfalt! Und ganz natürlich interessiert mich besonders der Schwerpunkt „Automation live“. Es ist einfach faszinierend, wie schön sauber gearbeitete Metallelemente sein können, wie sehr die Dekorationen von Schraubenherstellern Kunstwerken ähneln oder wie genau du hinsehen musst, um den Unterschied zu erkennen zwischen der Schaufensterwerbung eines Juwelierladens und der Anordnung von filigranen Ketten aus dem Maschinenbau.
Doch nichts toppt das „lebende Objekt“, nichts fasziniert mehr als die schimmernden Rollen, Ketten und Gelenke in voller Aktion zu sehen. Während wir alle freilich „normale Maschinen“ längst gewöhnt sind, ist ein Computerarm, der Ball spielt mit einem anderen, immer noch etwas Außergewöhnliches.
Na ja gut, vielleicht auch nur für mich, denn ich wette, das klappte nicht nach dem ersten Programmieren, selbst wenn es „nur“ der einfach Ablauf war, dass ein Computerarm den Ball aufhebt, dem anderen gibt und der ihn genau in das Loch wirft, von dem es wieder aufgehoben wird. Aber der Ball fliegt frei durch die Luft, da gibt es trotz schöner mechanischer Wurfformeln sicher ein paar kleine Tücken...
Das Aufwändigste an Demonstration, das von weitem gar fast den Eindruck von Menschlichkeit bot, war VW®’s Stand, wo Fertigungsroboter gezeigt wurden, die Karosserien schweißten und lackierten. Drei kleine, helle Roboter, aufrecht, eifrig auf Laufbändern hin- und hergleitend, bemühten sich in ewigem Reigen um die eine Seite des Fahrzeugs, während zwei große es ihnen „schmackhaft servierten“.
Was mich so verblüffte, war diese Lebendigkeit, die gerade die beiden Großen erzeugten. Sie taten eigentlich auch nichts anderes als viele andere Roboterelemente hier auf der Messe und doch erweckte ihre offensichtliche Zusammenarbeit, diese Karosserie hochzuheben oder auf die Seite zu drehen, um sie den anderen Robotern zu Weiterarbeit anzubieten, den Anschein, als würden hier zwei Menschen etwas fast spielerisch verladen...
nun ja, Leben ist immer Informationsverarbeitung und vielleicht erwecken deshalb auch Maschinen, die „zufälligeren“ Bewegungsmustern folgen können, fast zwangsweise den Eindruck von Lebendigkeit?
Was mich noch verblüffte: Wie kann irgendjemand nicht sehen, was Information ist, wenn alle, und gerade Ingenieure (!), sie schon so perfekt beherrschen?
Vielleicht weil Ingenieure die Theorie nicht als ihre Hauptaufgabe sehen? Müsste es dann nicht den Physikern längst schon aufgegangen sein? Oder den Theoretikern der Künstlichen Intelligenz (AI), die so prächtige Abhandlungen über Wissen und intelligente Automatisierung schreiben?
Physik der
Information, ISBN 3-935031-03-3,
Definition der Information:
Längenbestimmung, S. 137
„Dann haben wir tatsächlich eine Gruppe. Die Wiederholbarkeit sichert uns nämlich praktischerweise die Assoziativität, also die Reihenfolgenunabhängigkeit – genau dies war unsere „Geschichtslosigkeit“ der Transformation.
Und genau diese Gruppe nennen wir Information bezüglich der Eigenschaft, auf die sich all unsere derartig eingeschränkten Transformationen beziehen.
12. Information
Ie := {X, X1, X-1 |
X
wiederholbare, zusammenhängende Transformationen einer
Eigenschaft e,
bei Existenz von X1 als Einselement und
X-1 der Inversen von X für alle X) “
Übersetzung:
Transformation = Wertveränderung einer Eigenschaft = Zustandsänderung
zusammenhängende Wiederholbarkeit von Zustandsänderungen = Regelwerk
Anmerkung: Transformation ist hier nicht im mathematischen Sinne als Funktion gedacht, sondern als tatsächliche Änderung von Zuordnungen, sprich einer Ablösung einer eindeutigen binären Relation zwischen Werten und Eigenschaften durch eine andere, was in der Realität nur durch physikalische Wirkung erreicht werden kann.
Das heißt, dass Information jedwede Veränderung (!) ist, die aus klaren Ausgangssituationen unbeirrbar – und immer dieselben – klaren Endsituationen macht.
Eigenschaften müssen dabei nicht einfach sein, sie können sehr wohl sehr komplex werden, wobei dies nicht der wirklich zentrale Punkt ist. Der wirklich zentrale Punkt ist der, dass ihre Zustände
- wohldefinierbar
- zusammenhängend
- in klaren Abfolgen auftretend
sein müssen. Dann ist die Menge der Zustandsveränderungen, die diese Zustände und ihre Abfolgen erzeugen können, die Information über diese Eigenschaft, mess- und speicherbar durch die Menge dieser Zustände und ihrer Abfolgen.
Das Beispiel der Roboter ist hier wunderschön.
Denn betrachten wir nur die beiden tanzenden Karosserieträger, so kann es sehr wohl Zustände in ihrem Bewegungsablauf geben, die bei gleicher Ausgangsstellung auf eine andere Endstellung führen. Sie drehten und wendeten das Fahrzeug in komplexen Schleifen, da waren sicher Überschneidungen vorhanden - wie bei einer Acht, bei der du einmal von links auf den Mittelpunkt stößt und dann nach rechts weiterlaufen kannst oder umgekehrt. Der Mittelpunkt ist demnach zwar wohldefinierbar, er hängt auch mit allen anderen Punkt der Acht zusammen und doch können zwei verschiedene Endzustände von ihm aus erreicht werden.
Bei den Robotern passt das Beispiel freilich nicht ganz – warum? Weil sie nur Teil eines Systems waren, nicht das System selbst, soll heißen, dass der Zustand des Systems mehr umfasste als ihre Positionen. Auch die anderen Roboter mussten mit berücksichtigt werden und wenn dies geschieht, so ist jeder Zustand nicht nur wohldefinierbar, sondern auch einmalig (wie jedes Mengenelement) und lässt sich damit in klaren Abfolgen sortieren.
Genau das ist ein Programm.
Und genau deshalb machen die Roboter nichts anderes als Information zu verarbeiten, sie stellen damit ein informationsverarbeitendes System dar. Dass die Objekte im dahinter stehenden Software-Programm bis in die Realität hinein reichen und deshalb gewissen Restriktionen unterliegen, ist nicht wirklich ein Unterschied. Jeder Druck auf ein DinA4-Formular ist eine solche „Beeinträchtigung“ von Möglichkeiten, kann viel weniger Komfort bieten als eine GUI, die auf Knopf-, Tasten- oder Fingerdruck reagieren kann.
Und doch handelt es sich immer um ein Programm: nichts weiter als die saubere Bestimmung von Zuständen und die genauso saubere Bestimmung, wie der eine in den nächsten übergeht.
Nichts weiter als die Verwendung von Information.
Ob das „richtige“ Software-Objekte sind, die Werte „nur“ als Variable produzieren und dadurch die Zustände des gesamten Programmsystems definieren oder ob es Roboter sind, deren Positionen in einer realen Welt zu dem Zustand des Gesamtsystems gehören...
oder ob es Gene und Eiweißmoleküle sind, die einen Körper während der Schwangerschaft von einem Zustand in den nächsten führen, bis aus einer Eizelle ein kreischender Säugling wurde...
nichts als Verwendung von Information, deren Wiederholbarkeit Prognostizierbarkeit erlaubt, sodass die Arbeit, die in einen Zustand gesteckt wird, eben auch vom gewünschten Erfolg(szustand) belohnt wird.
Wie bereits erwähnt, arbeite ich mich gerade in Java ein, mit einem wirklich hilfreichen Buch aus dem Internet:
Java ist auch eine Insel (3. Aufl.) von Christian Ullenboom, Copyright © Galileo Press GmbH 2003, ISBN 3-89842-365-4 (Quelle 28.04.2004, Download, ca 8,5 MB):
In Kap. 17.15. werden die Cookies als Informationseinheiten erwähnt, in Kap 18.1 wird die Behandlung ferner Objekte über Funktionsaufrufe beschrieben, die „die Intelligenz der Methode“ verwenden, um zu Eingabeparametern Ausgangswerte zu liefern oder einen Systemzustand zu verändern und in Kap. 18.18 wird das Java Messaging System besprochen, bei der jede Nachricht „aus einem Kopf (Header), einigen Eigenschaften (Properties) und dem Körper (Body)“ besteht.
Es ist überall dasselbe Schema: Variablen/Eigenschaften (Properties), die unveränderliche Kennzeichen darstellen, werden über Methoden/Regeln/Algorithmen Werte/Inhalte/Contente/Bodies zugeordnet, die deshalb zwangsweise veränderlich sind und sein sollen. Der Header, der beim JMS erwähnt wird, hat denn auch „nur“ eine Identifikationsaufgabe. Wie in RDF schon ausgeführt, sind das die grundlegenden Attribute, die Information überhaupt ausmachen: unterscheidbare Eigenschaften und Werte sowie wiederholbare Mechanismen, die diese Werte verändern, immer gleich: Aus gleichen Anfängen müssen immer dieselben gleichen Endzustände werden.
Oh, sicher ist nicht nur Java ein deutliches Signal in Richtung Definition der Information, Methoden und Variable sind schließlich Eigenschaft jeder Programmiersprache, doch seine moderne Funktionsbibliothek, die aus der Erfahrung früherer Zeiten lernen konnte, war vielleicht eher als andere in der Lage, sich auf die wesentlichen Dinge zu konzentrieren.
Wieso aber sieht dann keiner der Java-Programmierer, dass dies alles dasselbe „Schema F“ ist? Interessiert es sie gar nicht mehr, was Information ist? Oder ist es einfach „selbstverständlich“ wie die Nase im Blickfeld oder der Wald aus Bäumen, die beide schlicht übersehen werden aus Routine, aus Fokussierung, aus Zweckmäßigkeit?
Dabei benutzen sie nicht nur das Wort ungeheuer oft, sondern sogar „Intelligenz“ – und zwar unbezweifelbar als Verwendung der programmierten Vorgehensweisen („die Intelligenz der Methode“) – und dies heißt Schritt für Schritt, Statement für Statement, Abfrage für Abfrage...
Zustand für Zustand...
Zugewinnfunktion der Intelligenz:
„’Intelligenz’ ist die Fähigkeit, Information aufzunehmen und zu verarbeiten. Dies geschieht durch Abbildung und ist möglich, da Information durch ihre Regelmäßigkeit durch Zustände und ihre Abfolge gekennzeichnet ist.“
Im Newsletter vom 10.05.2004 der SYS-CON Media (Quelle 15.09.2004) „JDJ Industry Newsletter, Enterprise Java Widens Its Net With EJB3, Monday, May 10, 2004“ gefunden:
„Learn how enterprise service bus (ESB) technology will take messaging to the next level by replacing traditional message queuing middleware. The new ESB backbone, which will enable the next generation of integration and application platform products, will bring radical improvements to the software infrastructure of most enterprises.“
Das erinnerte mich an meinen Kernel, also fragte ich mich, wie dieses ESB aussehen würde und lud mir sofort das White Paper herunter:
„ESB Technology & Innovation, Extending Web services with asynchronous message delivery and intelligent routing“ by Nigel Thomas, Robert Davies, SpiritSoft (Quelle 13.05.2004, 717 KB), S. 2 (30):
„The next-generation enterprise calls for loosely federated resources sharing a common communication and management infrastructure across multiple domains.“
Ja, ohne Kommunikation kein Informationssystem, soweit waren wir schon (Stichwort: die „Fliege“) – doch eigentlich waren wir schon zuvor soweit: Jedes System aus komplexen Komponenten, nicht nur mein Kernel, muss immer auf einer gemeinsamen Basis arbeiten, auf der „Sammelstelle für Schnittstellen“, sozusagen, denn jede Software-Anwendung kann nach Einzelfall-Abhängigkeit gegliedert werden.
„Denn wer die Aufgaben einer Software nach „Einzelfall-Abhängigkeit“ sortiert, kann den Anteil nicht-abhängiger Aufgaben zusammenfassen: zum Systembereich für völlig einzelfallunabhängige Funktionalität, zum „einzelfall-typ-abhängigen“ Klassenanteil, der sich bequem über Metadaten steuern lässt und damit für den ganzen Typ gleichartig aussehen kann bis hin zu dem einzelfall-abhängigen Teil, der sich am allerbesten nicht normiert bearbeiten lässt“
Die Interaktion mit der Welt außerhalb der Software, wie Usern oder Peripherie-Geräten, ist genauso eine einzelfall-unabhängige Aufgabe wie die Bestimmung, was und von wem etwas zu tun sei – das nämlich trifft für jede Komponente zu, die im System irgendetwas zu leisten vermag, ob dies nun ERP, CRM, EAI ist oder jedes andere beliebige DreiBuchstabenKürzel, das sonst noch in Frage kommt.
„ESB Technology & Innovation“, S. 2 (30):
„Enterprise applications also require a standards-based collaboration model to maximize the utilization of this infrastructure. To achieve this, the realtime enterprise uses best practices from real-time infrastructure and server-side grid technologies.“
RTE wird auch hier erwähnt – hängt natürlich alles zusammen, vor allem strukturell, nicht wahr?
Sehr hübsch auch hier die klare Aussage, dass „best practices“ benutzt werden, denn berechnen, so meinen sie, kann man es ja nicht. Warten wir’s ab, ob die ML-Methode nicht doch anwendbar wäre. Bei meinem Kernel war sie es auf allen Ebenen: Bei der Entwicklung der datenanonymen Prozesse genauso wie bei der Logik des zu programmierenden Einzelfalls.
Dass Standards als Basis jeder Kollaboration verwendet werden müssen, ist selbstverständlich – Standards sind die „Sprache“ derjenigen, die miteinander kollaborieren sollen, die Syntax der Kommunikation, die formale, verlässliche Symbolisierung der Inhalte: Sie sind das, was die Menschen vor den Menschenaffen auszeichnet. Jene sind zwar sehr intelligent und weisen auch eine komplexe Körpersprache auf, durch die „Analogie“ dieser Kommunikation ist ihre Kultur, sprich das System ihrer Interaktion, jedoch weitaus leistungsschwächer als die menschliche Variante, die mit Sprache eine so hohe Genauigkeit in der Symbolisierung von Inhalten erreicht hat, dass die Menschen zur herrschenden Rasse auf dem Planeten wurden - während die Menschenaffen letztendlich blieben, wo sie waren.
„ESB Technology & Innovation“, S. 2 (30):
„Although Gartner places J2EE as a Layer 2 technology, we believe the combination of distributed JMX and a J2EEbased application server has the characteristics of a virtual operating system. Using a container or micro-kernel that provides hot deployment and full JMX management of all components and services allows remote activation and management of services.“
(Layer 2 = Distributed Programming Model, Layer 1 = Virtual Operating System, JMX = Java Management Extension)
Wow – zum ersten Mal lese ich eine Namensgebung wie die meinige: „micro-kernel that provides hot deployment and full management of all components and services“. War wohl doch nicht so übel, meine Bezeichnung?
Das freilich ist nicht der Grund, warum ich den Autoren Thomas und Davies zustimme, dass die Systemfunktionen als Operating System angesehen werden müssen, sondern wegen der Übereinstimmung im Arbeitsbereich: Genau wie ein OS haben Systemfunktionen Aufgaben zu erledigen, die für alle weiteren Tätigkeiten in ihrem Verantwortungsbereich entweder nötig oder wenigstens nützlich sind.
„ESB Technology & Innovation“, S. 2 (30):
„the ESB infrastructure can provide on-demand hot deployment and self-annealing infrastructure across Java, Web services, and legacy platforms.... The ESB provides event notification, dynamic routing, and transactional guaranteed delivery; and a well-defined process language is used to allow applications to coordinate activities through a common API.“
Hier kann ich nur neidisch werden, denn natürlich ist mein Kernel nicht zu solcher Allgemeinheit fähig, er war nur in Studio lauffähig. Auch das Problem der generellen Interaktion von Applikationen hatte ich noch nicht gelöst – wenngleich die ML-Methode ein Einstieg dazu war, denn eine formalisierte Beschreibung der Logik sollte auch für die Implementierung nützlich sein. Ist schließlich mein jetziges Projekt.
„ESB Technology & Innovation“, S. 2 (30):
„A Linda-like tuple space combines the “one and only one” delivery semantics of a message queue with the broadcast capability of publish/subscribe and the loose coupling of a peer-to-peer system. A tuple space acts like an associative memory shared by an unlimited number of processes. Processes can add a tuple (essentially, a data object) into the space, or take a tuple out to work on exclusively – waiting until there is a matching object if necessary. Processes can also read tuples without removing them from the space.... Each process works independently of others – taking appropriate inputs from the tuple space and placing outputs back there for successor tasks. The order in which processes execute on a tuple can be less tightly constrained than in a traditional workflow system.“
Hört sich richtig gut an – klar, in dem Moment, wo du Komponenten als Services feilbieten willst, musst du sie über ein Kontrollpaneel ansprechen, über eine „ZVS“ der Dienste, sozusagen, mir scheint freilich, als könnte diese Tupel-Lösung wirklich sehr allgemein gehalten sein. Und das ist ja das größte Kompliment, das du einer Software machen kannst.
„ESB Technology & Innovation“. S.3 (31):
„Rather than developing monolithic or simple two-tier client/server applications, architects are realizing the benefits of a more loosely coupled and multi-layered component model.“
Simple client/server application...
ob deshalb mein Studio-Kollege so aggressiv reagierte, als ich ihm den Kernel vorstellte? Ich hatte mir schon gedacht, dass die Interaktion auf Messaging-Ebene ihm zu „verwurschdelt“ war, er nannte es unübersichtlich, chaotisch, was weiß ich noch...
dabei war mein Code zigmal kleiner als der seine, die Anwendung war keinesfalls komplex, sondern geradezu niedlich – nur ein einziges Fenster, wo der Kollege für jede Datei mindestens eines bastelte, nur ein Druck, wo für jede Datei mindestens ein Druck (dafür waren sie viel hübscher und nicht so „langweilig“)...
Andererseits hatte ich mal irgendwo gelesen, dass nach dem Verständnis für OO wohl noch mindestens ein Jahr Programmiererfahrung nötig sei, um SOA überhaupt zu begreifen. Nun ja, das würde vieles erklären.
„ESB Technology & Innovation“. S.3 (31):
„As a distributed ESB is a grid-like enabling technology, a Web services interface based on the OGSI open source definitions is a natural choice. OGSI is currently the de facto standard for externalizing grid technologies and allows grid services written in one environment to be easily deployed in others.“
Grids: Auch hier ist die Notwendigkeit vorhanden, BlackBoxes zu einem System zusammenzuführen – und da Grid-Computing ebenfalls mit Arbeitsverteilung und Lastenausgleich zusammenhängt, schätze ich, dass hier bereits Methoden zu finden sind, wie sie in meiner ML-Methode grundlegend beschrieben und berechnet werden.
Wäre das dann nicht sehr praktisch für diese Experten, wenn sie die gemeinsamen formalen Grundlagen für alle diese best practices auch kennen würden?
„ESB Technology & Innovation“. S.3 (31):
„In addition, the ESB can offer a scalable rules engine based on an optimized Rete algorithm.“
Rete-Algorithmus? Sollte wohl mal nachsehen...
Was denn ESB mit Information zu tun hat? Weniger – mehr mit Informationsverarbeitung – und zwar der aktiven Sorte, die auf flexibler Abbildung/Virtualisierung beruht...
Was das alles mit der Definition der Information zu tun hat? Nun, mein Kernel war es, der mir zeigte, dass es nicht genügt, best practices zu sammeln, dass die Programmierung nicht das zentrale Problem ist, sondern die „ganzheitliche“ Systembetrachtung. Dafür brauchte ich die ML-Methode, um mir dieses „ganzheitliche“ System zu ermitteln, und das sogar computergestützt – und dafür musste ich endlich klar und deutlich sagen können, was Sache ist.
Wenn ich, fernab jeder „modernen Entwicklung“ – ich arbeitete mit RPG auf der AS/400 und brachte mir parallel Obektorientierung im SOHO bei, mit der ich mithilfe von Studio dann meinen Kernel entwickelte -...
allein, ohne Kontakt zu Universitäten, großen Firmen, Open Source communities, anderen communities…
allein…
wenn ich dann so allein aus meiner physikalischen Ausbildung und Berufserfahrung zur Erklärung meines Kernels und zur Befriedigung des Bedürfnisses, Analysen automatisch in das System zu füttern, meine ML-Methode mit meiner Definition der Information entwickelte...
und wenn dieser Kernel dann tatsächlich an vielen ANDEREN Stellen mit ANDEREN Namen von ANDEREN Leuten praktisch noch einmal erfunden wird...
dann schätze ich, gibt das meiner Definition der Information auch ein erhebliches Gewicht.
Einfach nur - Objektorientierung
Im JavaTM-Tutorial von Sun® (Quelle 09.06.2004) sind ein paar Grundlagen der objektorientierten Programmierung aufgeführt, die sich in ihren Definitionen durch eine beneidenswerte Einfachheit auszeichnen:
- Objekte sind dabei nichts anderes als ein Bündel von Variablen und Methoden (und ähneln damit den wirklichen Objekten, die immer Zustand und Verhalten aufweisen: state and behavior).
- Klassen sind Blaupausen oder Prototypen [im Sinne von Schablonen], in denen die Variablen und Methoden der Objekte desselben Typs festgelegt werden. Oder noch klarer, wie es in der Zusammenfassung ausgedrückt wird: Die Klasse ist der Typ des Objekts.
Ein kurzer Blick auf die Definition der Information und die Anmerkung, dass Eigenschaften nicht unbedingt etwas Simples sein müssen, sondern schlicht alles sein können, was durch eine Menge korrekt beschreibbar ist – und ein Objekt wird zu nichts anderem als einer „Eigenschaft“ mit Anfangs- und Endzustand und wiederholbarem Verhalten, das den einen in den anderen überführt. Ob diese Methoden, die „Transformationen der Eigenschaft“, dann auch eine Gruppe bilden, hängt nicht nur von einem Eins-Element (einem Verhalten, das jeden Zustand in sich selbst überführt ab) und auch nicht nur davon, dass es zu jeder Methode ein „Redo“ gibt, sondern auch davon, ob diese Transformationen noch zusammenhängend sind, soll heißen, dass die Zustände, die das eine Objekt als Ergebnis erzeugt, auch vom anderen Objekt der gleichen Klasse wieder aufgenommen werden können zur weiteren Verarbeitung.
Doch eigentlich ist der „Zusammenhang“ nur mathematisch interessant, nicht wahr? Denn er garantiert eine mathematische Funktion auf der Menge der Werte. Für das Verständnis von Information als dynamischem Regelkreis ist diese Tatsache jedoch nicht gar so bedeutsam – und zeigt, warum objektorientierte Programmierer eigentlich schon längst nicht mehr zufrieden sein dürften mit Informationsdefinitionen, die von Wahrscheinlichkeiten oder Statistiken reden.
Denn ist Wahrscheinlichkeit nicht immer ein Zeichen für fehlende Information? Gleichwahrscheinlichkeit deutet auf totales Fehlen von Information hin (außer der Anzahl der Zustände) und Statistiken werden immer nur dann benutzt, wenn die fehlende Information möglicherweise zwar feststellbar wäre, dies jedoch aufgrund von Machbarkeitsproblemen gar nicht erst versucht wird. Wie also kann Information mithilfe eines Werkzeugs erklärt werden, das nur aufgrund ihres Fehlens benutzt wird? Das funktioniert nicht – und selbst Shannon sprach nur vom „Gehalt“ an Information, der sich über Wahrscheinlichkeiten abschätzen lässt, weil sich Wahrscheinlichkeiten mit der verwendeten Information verändern und deshalb ganz gute Indikatoren dafür sind: Bertrands Paradox.
Angenommen, Eins-Element und Inverse und Zusammenhang existieren wie gefordert, so stecken also die von einer Klasse definierten Variablen alle Zustände und die von ihr definierten Methoden alle Zustandsänderungen zu einer Menge von Vorgängen ab, die eine Gruppe bildet. Die Klasse kann also als „Eigenschaft“ der Informationsdefinition interpretiert werden, ihre Methoden bilden das Regelwerk, das Anfangs- in Endzustände überführt und solange dies wiederholbar geschieht, also aus demselben Anfangszustand auch immer wieder derselbe Endzustand erreicht wird – hat die Sache immer etwas mit Information zu tun.
Dass die Bestimmung des gesamten Zustands bei komplexen Klassen das Problem ist, das nicht nur Fehler erzeugt, sondern praktisch jedes Element der Definition wie Wiederholbarkeit und Zusammenhang sowie Inverse oder Eins-Element in Frage stellt, ist nicht weiter von Belang, denn eine Software hat sich nach dem Idealfall zu richten: Sie muss Information verarbeiten und das heißt schlicht, sie auch zu erhalten, sie muss deshalb nicht nur die von ihr bearbeiteten Zustände genau im Griff haben, sie muss auch ihre Erzeugung kontrollieren können (sprich wenigstens im Test rückwärts aufrollen können: „Inverse“) und sie muss mit möglichst vielen Varianten der von ihr bearbeiteten Zustände fertig werden („Zusammenhang“). Dass sie es nicht wirklich tut, heißt nicht, dass sie es nicht tun sollte, sonst gäbe es wohl kein Qualitätsmanagement in der Software-Industrie.
- Schnittstellen sind Gerätschaften oder Systeme, die von unabhängigen [unrelated] Einheiten verwendet werden, um miteinander zu interagieren. Jede Fernbedienung für den Fernseher ist eine solche Schnittstelle genau wie die englische Sprache, die zwischen zwei Sprechern vermittelt oder die militärischen Vorschriften, die das Verhalten von Soldaten verschiedenen Rangs regelt. Dabei ist wohl die beste Analogie ein „Protokoll“ (eine Übereinkunft in Verhaltensregeln), wie es in anderen objektorientierten Sprachen auch genannt wird [protocol]. Diese „Übereinkunft“ geschieht in Java dadurch, dass eine bestimmte Schnittstelle implementiert wird und somit jede der dort geforderten Methoden [Verhaltensweisen] auch ausgeübt werden kann.
Hier ist die Betonung des dynamischen Charakters von Information gar nicht mehr zu übersehen, nicht wahr? Unsere Informationsverarbeitungen haben sich dem schon so lange gebeugt, wir arbeiten schon so lange damit – aber sind immer noch nicht auf die Idee gekommen, dass die Dynamik nicht (nur) aus der Verarbeitung stammt, sondern aus dem, was zu verarbeiten ist. Und das, obwohl in der Konstanz bekanntermaßen keine Information steckt?
Interessante Nebenbemerkung: Konstruktoren werden nicht zu den Methoden gezählt.
Zu den Transformationen aus der Definition der Information gehören auch keine, die eine Eigenschaft „erzeugen“, die also irgend etwas in einen „Zustand“ versetzt, ohne dass es zuvor einen Zustand gehabt hätte – es sind nur solche, die (bestehende) Zustände einer Eigenschaft ändern.
Und noch 'ne Nebenbemerkung zur Gleichwahrscheinlichkeit: Sie zeigt, dass keine Information – außer der Anzahl der Zustände – über „Etwas“ vorliegt, das diese Zustände erzeugt. Sie bestimmt dann die Wahrscheinlichkeit dafür, dass (in der Zukunft) ein bestimmter dieser Zustände wieder auftaucht über die Anzahl der (bekannten) Ergebnisse, die „Etwas“ produziert. Hat irgendjemand jedoch einen Einblick in die „Produktion“ der Zustände, kann die Vorhersage, welcher Zustand als nächstes realisiert wird, verbessert werden: Die Wahrscheinlichkeit steigt.
Dasselbe geschieht „merkwürdigerweise“, wenn Information verwendet wird.
Weil Information verwendet wurde, steigt Wahrscheinlichkeit, wird die Vorhersage verbessert, was als nächstes geschieht oder was zu einem bestimmten Erfolg führt. Weil die „Produktion der Zustände“ (wenigstens teilweise) bekannt ist und deshalb zur Bestimmung dessen, was (in Zukunft) passiert, sprich was das System unter gegebenen Umständen hervorbringt, besser taugt: Bertrands Paradox.
Wenn gilt, dass aus A (Information wird verwendet) C (Wahrscheinlichkeit verbessert) folgt und wenn dann noch gilt, dass aus C auch A folgt, dann spricht doch einiges dafür, dass B auch gleich A ist, wenn gilt, dass aus B C folgt, nicht wahr?
© bussole IV 2004 (außer Zitate)