Wie meinen Zuhörern (und dem Veranstalter) zugesagt, hier eine Zusammenfassung meines Vortrages in Kurzform:

Ich habe den Vortrag in drei Themenbereiche gegliedert:

1) Entwicklung von Technologien vom Beginn der Menschheit bis heute!

Seit es Menschen gibt, haben sie Techniken und Technologien entwickelt. Um die Entwicklung von Technologie zu diskutieren, habe ich menschliche Entwicklungen dem Kriterium ihrer Zweckhaftigkeit folgend in zwei Bereiche eingeteilt: Technologien für den Körper und Technologien für den Verstand.

Technologien für den Körper umfassen so alle Entwicklungen, die der Ernährung (”Fressen und Saufen”), des Reduzierens von körperlicher Anstrengung (”Faulheit”), Schützen des Körpers vor Kälte oder Nässe, Bewahren der körperlichen Gesundheit, der Vermehrung bzw. Vermeidung von Vermehrung (Sexualität), der schnellen Fortbewegung (Mobilität), der Entwicklung von Herrschaft und ähnlichem dienen.

Hier sind beispielhaft zu nennen: Jagd, Ackerbau und Viehzucht, Waffen, Feuer, das Rad, Fahrzeuge, Medizin, Schiffe, Fahrrad, geschlossenes Feuer, Lichtquellen, Kraftmaschinen, Automobil, Eisenbahn, Beherrschung der Elektrizität, Flugzeug, Chemie, Pharmazie, Kernspaltung und vieles mehr. Ich habe diese Disziplinen die “Allgemeinen Technologien” genannt.

Technologien für den Verstand umfassen alle Entwicklungen, die dem Erzeugen, Bewahren, Verbreiten und Verarbeiten von Informationen und Ähnlichem dienen. Beispielhaft sind hier: die Entwicklung von Sprache, Bildern und Schrift, Buchdruck, Datenübertragung, Rechenstab, Kurzschrift, Morse-Alphabet, Kabelübertragung, Telefon, Telex, Funk, Rechenmaschine, Schreibmaschine, Schallplatte, Radio, Fernsehen, diverse Aufzeichnungsgeräte, Computer, E-Mail, Internet. Diese Disziplinen habe ich unter dem Begriff der “Informatik” zusammen gefasst. Besonders wichtig waren mir die Begriffe “Digitalisierung” und “Virtualisierung”.

Ordnet man die Entwicklung all dieser Technologien auf einer Zeitachse an, stellt man eine ungeheure Beschleunigung (E-Funktion??) der technologischen Entwicklung fest. Man erkennt auch, wie die “Informatik” die Entwicklung der “Allgemeinen Technologien” vorangetrieben hat. Ohne Buchdruck wären die Technologiesprünge der Neuzeit unmöglich gewesen, ohne mechanische Rechenmaschine hätte keine Atombombe entwickelt werden können und was ein “WEB2″ bringen wird, können wir nur erahnen.

Die gewählte Darstellung lässt einen zweiten wichtigen Aspekt vermuten: Die Entwicklung von relevanten Fortschritt verläuft immer von “unten nach oben”, eigentlich im Sinne eines “automatischen” Prozesses der demokratischen Meinungsbildung und Ziel-/Regelfindung. Dies gilt für die Entstehung von Sprache, Schrift und Mathematik wohl genauso wie für Wikipedia.

2) Zitat von Bertrand Russell

Teil 2 des Vortrages habe ich auf einem Zitat von Bertrand Russel aufgebaut:

Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit!

Russel war nicht nur ein bedeutender Mathematiker und Philosoph des letzten Jahrhunderts, sondern auch eines der großen Idole unserer Jugend. Wenn wir seinem Zitat folgen und davon ausgehen, dass der Zuwachs an Weisheit beim Menschen z.B. seit Goethe nicht wesentlich stattgefunden hat, dann könnte man zu dem Schluss kommen, das der Zuwachs an Technologie das Glück der Menschen nicht mehrt. So kommt die Ethik ins Spiel. Vielleicht hilft ethisches Verhalten das “lag” zwischen Technologie und Weisheit ein wenig zu verkleinern.

3) Überlegungen zur Ethik von Managern

Schwerpunktmäßig habe ich über die Ethik der Entscheidung gesprochen. Führungskräfte (sogenannte Manager) befinden sich in einem großen Dilemma: Sie sollen in ihren Entscheidungen Ziele sinnvoll vereinen, die sich massiv widersprechen. Gewünscht wären jetzt sittlich verantwortete und nach sorgfältiger Güterabwägung getroffene Entscheidungen. Leider ist dies aber schwer und erschwert schnelle Entscheidungen. Deswegen behelfen sich viele Manager und Systeme und erleichtern sich die Entscheidungsfindung, in dem sie einen Trick anwenden:

Das geht ganz einfach. Man muss nur die Anzahl der zu vereinenden Ziele reduzieren, am besten auf ein einziges. Dies vereinfacht das Manager-Leben ungemein, ist aber als höchst unethisch zu bewerten und führt fast immer zu unteroptimalen Entscheidungen mit langfristig massiv negativen Folgen. Zwei Beispiele seien hier genannt. Ganz aktuell erleben wir die Weltfinanzkrise: Das singuläre Prinzip des Shareholder Value hat Profit im Bereich der Hochfinanz unisono als einziges Ziel festgelegt. Und dies hat eine Krise von gigantischem Ausmaß bewirkt. Und alle von Analysten getriebenen Unternehmen sind gefolgt - und ändern ihr Verhalten auch heute nicht, obwohl man es jetzt wirklich gelernt haben sollte! Demnächst in diesem Blog gibt es dazu noch ein oder mehr Beispiele.

Doch auch die Titanic musste untergehen, weil der Kapitän den Auftrag hatte, auf der Jungfern-Fahrt das “Blaue Band” zu gewinnen - und dieses Ziel hat er äußerst gewissenhaft befolgt.

RMD

P.S.

Meinen Zuhörern ein herzliches Danke für die vielen Beiträge in der Diskussion nach dem Vortrag.

Die folgende Geschichte ist für mich deshalb wichtig, weil sie den einzigsten (!) Fall in meiner Karriere erzählt, in denen ich einer kriminellen Nutzung durch Computer persönlich begegnet bin. Deshalb bin ich wahrscheinlich auch so skeptisch gegen den aktuellen “Security-Overkill” (Kennwortschutz und Verschlüsselung auf WLANs, überall VPN-Mechanismen usw.), der übrigens immer mit minimalsten Wissen (zehn Zeichen eines Passworts kriegt man immer raus) umgangen werden kann. In der Tat wäre mir eine offene Welt mit weniger Misstrauen auch in diesem Bereich lieber. Aber jetzt zur Geschichte.

Ich hatte das große Glück, das wahrscheinlich modernste Projekte unterstützen zu dürfen, das es damals in Deutschland gab! Das Projekt hieß START und vernetzte die Rechner der Lufthansa, DB und der TUI. Fast wäre es gescheitert, weil die Netzknotenrechner Datenpakete zwischen den kooperierenden Unternehmen vermittelten und das nach Meinung der Deutschen Bundespost gegen das Fernmeldemonopol verstieß. Aber auch solche (fachfremden) Probleme konnten ebenso wie die technischen Herausforderungen gelöst und damit der Grundstein für eine Erfolgsgeschichte gelegt werden, die heute selbstverständlich geworden ist und allen Beteiligten - Lieferanten, Betreibern und Nutzern - über die vielen Jahre bis heute wesentliche Benefits gebracht hat.

Auf der Mainframeseite waren Systeme unter dem Betriebssystem BS 2000 mit UTM/UDS und auf der Netzseite Rechner der Serie 9600 TRANSDATA mit KOGS und PDN beteiligt.

Es war vor allem eine Herausforderung für die Technik Datenfernverarbeitung - so hieß “network computing” damals. Von Slogans wie “the network is the computer” waren wir Lichtjahre entfernt. Deshalb schlugen wir uns mit dem ISO-7-Schichten-Modell herum. Transportschichten und physikalische und logische Transportquittungen, BCAM und DCAM waren die Herausforderungen. Aber die Vision war für die damalige Zeit einzigartig: echtes Online-Buchung mit sofort gedruckten Tickets direkt aus dem Reisebüro! Klingt heute im Zeitalter des Internet ja ganz harmlos. Wir aber waren die Vorläufer des im Internet gebuchten etx-Tickets - ein für die damalige Zeit nahezu unvorstellbares und sehr visionäres Vorhaben.

Und - wir haben es in vielen Jahren trotz mancher Rückschläge und plötzlich auftauchender und oft unüberwindbar erscheinender Hindernisse geschafft. Aber - wie das System dann im Echteinsatz produktiv zum Laufen kam, gab es ein heftiges Problem:

mehr »

Vor kurzem habe ich mir so richtig einen “Schiefer eingezogen”. In einer Besprechung zur Planung unserer IT-Infrastruktur mit fünf Menschen, vor denen ich fachlich wie menschlich extreme Hochachtung habe, ist mir die ja wirklich unglaubliche These entglitten, dass der “normale Mensch” ein System wie MS-Office oder OpenOffice bzw. Neo-Office in der heutigen Zeit ja nur noch in Sonderfällen braucht. Die Reaktion aller Fünf auf meine Aussage war eindeutig (mir schien, dass mich alle für jetzt endgültig komplett verrückt geworden hielten). Eigentlich wollte ich nur zum Ausdruck bringen, dass zukünftig nur noch Spezialisten wie Berater oder Menschen mit Organisations- oder Sekretariatsaufgaben ein solch komplexes Werkzeug einsetzen würden, “normale” Anwender aber anders arbeiten würden. Aufgrund der von mir gefühlten Reaktion meiner Kollegen habe ich dann natürlich sofort versucht, das Gespräch in ein anderes Fahrwasser zu bringen. Dieses Erlebnis hat mich nachdenklich gemacht, wieso ich eigentlich auf eine solch verrückte Aussage komme und ob ich am Schluss nicht vielleicht sogar Recht habe.

Ich kam auf die Idee, da ich bei mir selbst bemerkt habe, dass ich NeoOffice kaum mehr verwende. Vor meinem Wechsel von einem Windows-PC auf den Mac war ich selbstredend intensiver MS-Office-Nutzer (Sogar meine E-Mails habe ich mit Word erstellt, nicht zuletzt wegen der automatischen Rechtschreibkontrolle in Deutsch und Englisch). NeoOffice habe ich sofort nach Inbetriebnahme meines Macs installiert und war auch gleich so richtig begeistert. Jetzt habe ich den Mac vielleicht seit 8 Wochen und benutze Neo-Office nur noch ganz selten (und MS-Office sowieso nicht mehr), sondern schreibe in der Regel mit TextEdit vom Mac und nutze zusätzlich zweckabhängig ein paar handliche andere Editoren (z.B. wordpress am liebsten im Modus “code”) nach dem Motto schneller und einfacher. Und das ging ganz von selbst. Wie konnte das passieren?

Hier der Versuch einer Erklärung: Word wie auch der OpenWriter sind unheimlich mächtig. Sie können alles. (Fast) jeder Benutzer klagt, dass sie viel zu viel Funktionalität hätten, die kein Mensch benötigen aber das Arbeiten erschweren würde. Und für was kann man Word bzw. OpenWriter wirklich sinnvoll nutzen? Word ist sicher nicht optimal, wenn ich Texte fürs Internet erstelle. Eine wissenschaftliche Arbeit schreibe ich besser mit einem Werkzeug wie LaTeX. Wenn ich das Geschriebene nur drucken oder in einem “final format” (PDF) weitersenden will, verzichte ich gerne auf den Overkill eines “Super-Word-Processors”. Für Entwürfe zum Weiterverarbeiten durch Dritte verwende ich OpenWriter oder ab und zu mal NeoOffice (oder entwerfe den Input-Text gleich in der E-Mail), das funktioniert bestens auch bei dem MS-Office nutzenden Empfänger.

Passiv verwende ich den OpenWriter von NeoOffice zum Lesen von komplizierten .doc-Dokumenten zum Beispiel mit Änderungsverlauf und ähnlichem. Aktiv verwende ich OpenWriter zum Erstellen von formalen Protokollen (passiert alle zwei Wochen). Das sind dann historische Formulare mit vielen Kästen und Linien, so, wie man sie früher hatte, um sie einfach handschriftlich und später mit der Schreibmaschine auszufüllen. Und so was geht wahrscheinlich wirklich mit einem komplizierten Textsystem am besten. Aber brauche ich das? Nur weil ein einfaches Stichwortprotokoll nicht so beeindruckend formal und amtlich wirkt?

Ich hatte mir schon Sorgen gemacht, dass ich keine sinnvolle Arbeit mehr leiste, da ich Office nicht mehr nutze. Eine kleine Umfrage bei hocheffizienten und professionellen Leistungsträgern (oft Nutzer von Mac oder Linux-Systemen wie Ubuntu) hat mir aber gezeigt, dass diese seltsame Entwicklung nicht nur bei mir stattfindet. Viele Normalnutzer in dieser Welt nutzen Office-Software immer seltener und nur noch für ganz besondere Zwecke, aber nicht als generellen Editor. Man hat die Zeit nicht mehr, um ewig an Dokumenten herum zu “friemeln”. Und ich bin ich froh, dass ich mit meiner Ansicht nicht alleine auf dieser Welt bin.

Word ist natürlich immer noch “der Standard”. Häufig wird Word als Editor im Workflow eingesetzt. Auch das ist unteroptimal. Für die Erzeugung komplexen Schriftgutes gibt es hocheffiziente Spezialsysteme, mit denen Anwender komplexe fachliche Dokumente interaktiv mit Hilfe von intelligenten Bausteinen einfachst generieren können. Diese Werkzeuge haben dann auch noch einen vernünftigen Baustein-Erstellungs-Modus, so dass man kein Programmier-Knowhow für die Erstellung der Bausteine braucht. Und schließlich sind sie besser für die Implementierung eines Workflows geeignet  als die individuellen Mega-Editoren, bei denen die Funktionalität der Textbausteine von komplizierter Makro- bzw. Programmiersprachen-Logik gesteuert wird. Ich glaube nicht, dass das Argument “Word ist halt Standard” die Entwicklung von Mega-Software z.B. in VBA oder Makro-Logik zum Zwecke der Dokumentgenerierung rechtfertigt.

Aber nein wird man mir entgegenhalten: Das ist alles falsch! Hat nicht gerade im letzten fiskalischen Jahr Microsoft mit Office astronomische Gewinne eingefahren? Wird Word nicht an allen Volkshochschulen gelehrt? Saugt nicht jeder Computer-Anwender quasi das Word-Know “mit der Muttermilch auf”? 

Die Zeiten ändern sich und haben sich schon geändert. Wieso sollte heute ein junger, unbedarfter Computer-Nutzer ein Bedürfnis nach OpenOffice oder MS-Office haben? Er kann doch alles Notwendige schon mit den vorhandenen Bordmitteln machen. Und was soll ein mobiler Teilnehmer des Internets mit modernen kleinen Endgeräten mit Word anfangen? Ich stelle fest, dass Kids, Teenager und Menschen in den Zwanzigern auch viel schreiben, aber Word oder OpenOffice gar nicht benutzen (und oft gar nicht kennen!). Das “Muttermilch-Argument” zieht nicht mehr. Wird Word ein System für die Herrschaften über 40 (Traue keinem über 40) oder gar die Generation Vorruhestand? Aufgrund unser demographischen Entwicklung hätte Word dann ja genug Nutzer.

Gut, sagt vielleicht einer, auf Word kann man ja verzichten, aber was ist mit Powerpoint. Das braucht doch ein jeder. Das verstehe ich, habe ja auch Jahrzehnte lang alle meine Ideen in Powerpoint entwickelt und in  Powerpoint-Folien gegossen. Ich wollte ja das Gedachte auch gleich vortragen können und mit meinen tollen Folien andere Menschen von meinen Ideen überzeugen! Aber für das Ordnen von Gedanken und das gemeinsame Entwickeln von Erkenntnis erscheint mir dann andere Werkzeuge wie Mindmap oder HyperBloxs geeigneter.  Und um ein Bild zu entwickeln, das wirklich “mehr als Tausend Worte sagt” brauche ich eh ganz andere Werkzeuge als Powerpoint. 

Jetzt höre ich schon den nächsten Einwand: Aber auf die Tabellenkalkulation kann ja wirklich keiner verzichten. Dann wundere ich mich auch wieder. Die meisten Excel-Tabellen, die ich bekomme, sind einfache Listen, meistens ganz ohne Rechenoperationen! In den Zeilen stehen dann Inhalte wie Name, E-Mail-Adresse und Telefonnummer, ein Feld mit Teilnahme ja oder nein, vorne eine laufende Nummer. Excel zeigt nur die Anzahl an - und die oft falsch. Andere “Excels”, die mich erreichen, zeigen mir nur, dass der Absender nicht mehr in der Lage ist, auch nur einfachste Kopfrechnungen durchzuführen. Deshalb auch der Name Tabellenkalkulation - linke Spalte Nettopreis, rechts mit Mehrwertsteuer.

Ja - und dann gibt es noch die “Organisations-Spreadsheets”. Mitarbeiter werden genötigt, mit Excel Stundenzettel oder Reisekostenabrechnungen auszufüllen. Das finde ich grausam, insbesondere weil diese bürokratischen Notwendigkeiten viel besser webbasiert unterstützt werden können.

Natürlich kenne ich auch sinnvolle Einsätze von Excel: In der Hand des richtigen Beraters ist es eine gnadenlose Waffe. Das sind dann Spezialimplementierungen für ganz spezifische Problemstellungen. Nur der Autor versteht Problem und Implementierung. Oder: Ein Obst- oder Gemüsehändler kann aufgrund seines unbewusst/intuitiven und bewussten Marktwissens gut schätzen, zu welchem Preis er welche Menge einer Sorte verkaufen kann. Im Kopf kann er aber mit Sicherheit nicht optimieren, wie er sein Angebot optimal strukturiert. Und wenn er dann über die Fähigkeit verfügt, Excel richtig im Sinne eines kommerzielle Ergebnis-Optimierung und -Maximierung einzusetzen, wird er seinen Gewinn beträchtlich steigern. Auch für die Aufwandsermittlung zur Erstellung eines Werkstückes mag mit Excel gut unterstützt sein. Aber wer ist schon Berater, Gemüsehändler oder Kalkulator.

Zusammenfassung: Sicher gibt es Spezialisten, für die Powerpoint und Excel wie auch Access bzw. die Gegenstücke der OpenSource zentrale Werkzeuge von absoluter Wichtigkeit sind. Manager und Unternehmer sollten jedoch ihre Zeit und Kraft nicht mit solchen Werkzeugen “verfrickeln”, sondern sich um ihre Führungsaufgabe kümmern. Und Ingenieure, Informatiker und Wissenschaftler brauchen keine Bevormundung vom “Big Brother”, sie wissen schon, welche Werkzeuge sie wirklich brauchen. 

RMD

P.S:

Ich kenne übrigens eine ganze Reihe sehr namhafter Informatik-Professoren, die mit Office-Systemen auch nichts am Hut haben. 

Hier der erste Beitrag von Matthias Apitz <guru@UnixArea.de>!

Man soll keine Aufsätze mit Ich anfangen, deshalb dieser Satz vorab. Ich bin Matthias und gern nehme ich die Einladung meines langen Kollegen/Partners Roland Dürre an, und werde in loser Folge ab und an was zu UNIX oder anderen OpenSource Projekten schreiben. Seit mehr als 25 Jahren arbeite ich mit und teilweise für UNIX und denke, dass ich dabei einiges gelernt habe und was ich davon nicht schon wieder vergessen habe, gebe ich gern weiter. Genug der Vorrede, wer mehr über mich wissen will, sei an meine home page verwiesen http://www.UnixArea.de/

Heute soll es um grosse und kleine Computer gehen, wie der Titel sagt. Vor ein paar Tagen habe ich mir den kleinsten Computer gekauft, wenn ich mal meinen programmierbaren Taschenrechner TI 59, den ich als Student hatte, aussen vor lasse. Es ist ein s.g. sub-notebook, Asus eeePC 900: http://en.wikipedia.org/wiki/Eeepc. Das Tolle an dem Teil ist, dass es klein ist, gerade noch gross genug, dass man darauf wirklich schreiben kann und auf dem 9 Zoll display mit 1064×600 Auflösung auch noch was lesen kann. Es hat keine sich drehende Platte, nur eine 20 GByte s.g. SSD (Solid State Disk), das ist ein Speicher, wie man ihn von USB sticks kennt, nur sieht ihn eben das Betriebssystem wie eine normale ATA Festplatte. Und 20 GByte ist viel, auch wenn das Betriebssystem mit allem was man zum Arbeiten, Schreiben und Lesen braucht, davon sich 3 GByte weg nimmt, bleiben immer noch 17. Es wiegt weniger als ein Kilo und gibt keinen Laut von sich (wenn man nicht gerade einen Film oder ein Mp3 darauf abspielt). Und es kommt nicht mit Windows daher, sondern mit einem Linux-derivat der Firma Xandros, dazu später mehr. Es ist wohl auch eine Version mit XP angekündigt, die SSD soll dann dabei nur 12 GByte gross sein, weil ja Microsoft noch bezahlt werden muss (schlechtes hat eben seinen Preis) und der (Kampf-)Preis 400 Euro in Summe nicht übersteigen soll. Das ist, wie gesagt, der kleinste Computer, den ich je mit UNIX hatte, bisher. Darüber später mehr, reden wir erstmal von dem grössten, den ich je “hatte”.

Wer auf meiner home page nach sieht, wird merken, dass ich aus der DDR bin. Ich habe dort an der Universität und später an der Technischen Hochschule in Leipzig gearbeitet, geforscht und auch Kurse gehalten zu Computer Themen und Programmiersprachen. Leute meines Alters und Wissende werden den Begriff CoCom kennen, wer nicht sehe einfach in Wikipedia nach. Kurz, wir sollten damals keine Computer haben und erst recht keine mit UNIX. Das hat nicht funktionieren können und die DDR hat eigene gebaut, einige davon waren Clone (Nachbauten) von IBM (die IBM /360 oder /370 hiess in der DDR ESER 1055 oder 1060) oder von DEC (die PDP-11 war bei uns die SM4-20). Auf denen liefen üblicherweise auch die ge-clonten Betriebssysteme der westlichen Hersteller. Aber eben nur ‘üblicherweise’. Es gab an den Uni’s der DDR ein gemeinsames Forschungsprojekt auf dieser Hardware das als Source (auch wieder entgegen der CoCom-Liste) verfügbare UNIX verschiedener Versionen zum Laufen zu bringen. Das ist uns auf dem ESER 1055 hervorragend gelungen, es lief dort in einer virtuellen Maschine des SVM als VMX (Virtuell Machine UniX) und wurde in Lehre und Forschung eingesetzt. Der Rechner füllte damals ganze (Computer-) Hallen, die grössten Festplatten waren 29 und 100 MByte groß und sahen aus wie Waschmaschinen, solche Top-Lader. An den RAM (damals Ferrit-Kern Speicher) kann ich mich nicht mehr erinnern, sicher was es aber weniger als 1 GByte. Das war also der grösste Rechner, auf dem ich je UNIX installiert habe, und doch war er kleiner in der Leistung als der eingangs erwähnte eeePC, schwächer als mein kleinster heute.

Damals war es übrigens noch nicht einfach mit dem UNIX. Man musste schon Enthusiast sein und um die kostbare Rechenzeit auf dem Großrechner betteln und bekam die meist nur nachts zugeteilt. Anderes und Fragen der Sicherheitsaspekte beim Zugang zu den heiligen Hallen der Computer lasse ich mal weg. Es gab auch Widerstände, analog den heutigen, von Kollegen und Chefs die meinten ein Betriebssystem kann nur von IBM kommen (oder heute von Microsoft). Aber wir haben uns damals durchgesetzt.

mehr »

Wer hat das Radar erfunden? Angeblich gibt es da eine Reihe von Menschen, die dies für sich in Anspruch nehmen können. Auch ein deutscher Professor, der in den 50iger Jahren an der Technischen Hochschule München (heute Technische Universität München) lehrte, gilt als der verkannte Erfinder des Radars. Aber wer hat eigentlich den Warmstart erfunden? So geht meine Computer Vintage Geschichte also jetzt weiter:

Eines unserer hochspannenden Projekte Ende der 70iger Jahre war Dispol und wurde von der Bayerischen Landespolizei gemeinsam mit Siemens entwickelt. Der gesamte Fernschreibverkehr sollte in ein neues IT-basiertes System überführt werden. Dabei sollten echte Fernschreiber genauso am Netz funktionieren wie moderne Datensichtgeräte, für die es auch ein kleines Programm zur Emulation von Fernschreibern gab. Die physischen Fernschreiber waren richtige Bestien. Sie hatten Spannungen von 60 Volt plus/minus und waren schon damals für IT-Verhältnisse unendlich langsam (die Übertragungskapazität war wohl 50 Baud).

mehr »

In meinem letzten Post habe ich bereits über einige Vorteile gesprochen, die sich durch den Einsatz eines IDM-Systems erreichen lassen.

Dies ist aber natürlich noch nicht das Ende der Fahnenstange. Richtig eingesetzt, ergeben sich noch weitere Vorteile:

- Höhere Produktivität bei der Verwaltung der Nutzerkonten: Bedingt durch den höheren Automatisierungsgrad lassen sich mit weniger Aufwand mehr Konten verwalten. Die Verwaltungskosten pro Account sinken.

- Da ein Großteil der Arbeit, die bisher von den Administratoren manuell verrichtet wurde, nun durch das IDM-System übernommen wird, bekommen diese nun endlich den Freiraum, um die im System vergebenen Berechtigungen durchzugehen und auf den aktuellen Stand zu bringen. Ein Problem manueller Rechteverwaltung ist nämlich gerade auch die Tatsache, daß Berechtigungen zwar bei Bedarf mehr oder minder schnell erteilt, jedoch in der Regel nie mehr entzogen werden. Dadurch kommt es zum vielen Leuten bekannten Phänomen des Rechtesammelns (besonders “gefährlich” sind hier v.a. Personen, die oft Abteilungen und Aufgaben wechseln, z.B. gerade auch Praktikanten!). Dies verletzt jedoch das “Least Priviledge”-Prinzip, das besagt, daß jeder nur über die Berechtigungen verfügen sollte, die er zur Ausführung seiner ihm übertragenen Aufgaben minimal beötigt, und das Grundlage einer jeden Rechtevergabe sein sollte. Die Arbeit der Administratoren ist daher auch nach einer IDM-Einführung noch wichtig. Keinesfalls sollte eine solche Einführung zum Anlass genommen werden, personelle Kürzungen vorzunehmen. Hiermit lässt sich vielleicht erreichen, daß der Status Quo zu geringeren Kosten aufrecht erhalten werden kann. Da dieser jedoch meistens nicht von einer besonders hohen Qualität gekennzeichnet ist sollte stattdessen besser die Alternative “steigende Qualität bei gleichen Kosten” realisiert werden.

- Bessere Einhaltung von gesetzlichen Vorgaben, dadurch Vermeidung möglicher Sanktionen (neudeutsch „Compliance“): Gerade im Bereich der IT-Sicherheit gibt es heute eine Vielzahl von Gesetzen und Regeln, denen sich Organisationen unterwerfen müssen (z.B. BGB, GmbH-Gesetz, SOX, Basel II etc.). In einigen Fällen beinhalten diese Gesetze auch (teils regelmäßige) Nachweispflichten, die sich zumeist auf die Beantwortung der Frage reduzieren lassen, wer zu welcher Zeit was gemacht hat. Die Betonung liegt in diesem Falle auf „Wer“. Eine Antwort auf diese Frage kann in Zeiten zunehmend automatisierter Geschäftsprozesse manuell nur schwer erfüllt werden und wäre zumeist mit einem unrentabel hohen Aufwand verbunden. Eine mögliche Lösung besteht daher in der Einführung eines IDM-Systems. Tatsächlich hat sich in den letzten Jahren gezeigt, dass gerade Compliance eine der Haupttriebfedern für die Einführung von IDM-Systemen war.

- Effiziente Unterstützung Service-orientierter Architekturen (SOAs): In den letzten Jahren sind viele Unternehmen dazu übergegangen, neue Prozesse und Dienstleistungen auf Basis von serviceorientierten Architekturen anzubieten. Diese zeichnen sich in der Regel durch eine eher lose Kopplung verschiedener Systeme aus, die zudem in vielen Fällen noch über eigene Benutzer- und Berechtigungsverwaltung verfügen (und die schlimmstenfalls auch noch alle komplett unterschiedlich realisiert sind). Dies kann bei Einbindung in eine SOA zu hohen Aufwänden führen – und bei einem weiteren Ausbau der IT-Landschaft sogar gänzlich unbeherrschbar werden. Auch die Erreichung von Compliance wird auf diese Weise, d.h. ohne ein einheitliches Vorgehen beim Management von Identitäten, Rollen, Berechtigungen und Auditierung, nur schwer erreichbar sein. Man kann deswegen ohne weiteres sagen, dass Service-orientierte Architekturen ohne Identitätsmanagement nur sehr schwer zu verwirklichen sind, und eine sorgfältig geplante “Identitätsschicht” in jede SOA gehört.

Man darf hier jedoch nicht den Fehler machen und IDM als ein einzelnes Produkt sehen, das einmal installiert alle Probleme in diesem Bereich löst (obwohl einem die Softwarehersteller das immer gerne glauben machen wollen). Stattdessen handelt es sich eher um eine Art Technologierahmenwerk, das vor einem tatsächlichen Einsatz immer erst auf das jeweilige Unternehmen angepasst werden muß.

Es gilt daher immer abzuwägen, ab welcher Schwelle sich der Einsatz eines IDM-Systems für ein Unternehmen lohnt, bzw. ab wann so ein Einsatz sogar unverzichtbar ist.

Für diese Berechnung wurden verschiedene Kennzahlensysteme entwickelt, deren Vorstellung jedoch hier den Rahmen sprengen würde. An dieser Stelle möchte ich daher gerne auf einen der nächsten Artikel verweisen.

Soweit die erste Einführung in das Thema Account Management. Der nächste Artikel wird sich dann um das Thema Föderierung drehen. Auch das ist ein sehr spannendes Themengebiet, das gerade dabei ist so richtig in Fahrt zu kommen, und das das Zeug dazu hat, zu einem der wichtigsten Treiber für IDM-Projekte zu werden.

BFI

Hier ein Beitrag für Datenmodellierungsexperten von Jens Gassner, unserem Experten für Datenmodellierung:

Zusammenfassung:  „Entität“ und „Objekt“ sind die Schlüsselwörter dieses Beitrags. Die Unterschiede zwischen diesen Konzepten sind wohlbekannt und werden mit dem Schlagwort „impedance mismatch“ bezeichnet. Hier wird aber das Gemeinsame beider Welten belegt und gezeigt, wie diese Sichtweise einen Beitrag zur begrifflicher Klarheit und zur Verringerung von Modellierungskosten in IT-Projekten leisten kann.

„An entity is an object that doesn’t know how to behave.“ Das ist nur eine der möglichen Antworten auf die Frage nach dem Zusammenhang zwischen Objekten und Entitäten. Eine andere Reaktion ist einfach ein etwas süffisantes Grinsen. Offenbar liegt zwischen Objekt und Entität eine Art Wasserscheide: „Entität“ riecht altbacken, während „Objekt“ Modernität signalisiert. Und in der Tat gibt es wohl kaum eine aktuelle Idee oder Diskussion in der Informatik, die nicht auf dem Gedankengut und dem Vokabular der Objektorientierung aufbaut.

Tabelle zum „Impedance Mismatch“

Die Tabelle nennt einige der Unterschiede, während das bonmot am Anfang – es stammt übrigens von Bachmann, Proponent eines frühen Modellierungswerkzeugs – eher Wert auf das legt, was die beiden Welten verbindet.

Ein Gedankenexperiment: Sie sollen eine Anwendung für ein Sachgebiet Ihrer Wahl bauen. Die Bitte an Sie ist, im Kopf ein Klassendiagramm dafür zu entwerfen, und dann ein Entity-Relationship-Diagramm. Oder umgekehrt, je nach dem, aus welcher der beiden Denkrichtungen Sie kommen. Vergleichen Sie Ihre Klassen und Ihre Entitäten.

Mein Ergebnis: Ein hoher Grad an Übereinstimmung auf einem wesentlichen Teilbereich der Diagramme. Es gibt „Kästchen und Striche“, es gibt die „Zahlen“ an den Strichen. Einige der objektorientierten Kästchen tragen dieselben Überschriften wie ihre Kollegen auf der Entitäts-Seite. An diesen Stellen passt das Netzwerk der Striche gut zueinander und es stimmt auch viel vom Inhalt überein; die Namen für die Datenelemente. Aber bei den Klassen gibt es mehr Einträge: Den Entitäten fehlen die „Methoden“, d.h. im Gegensatz zum Objekt macht die Entität keine Aussage über ihr Verhalten, daher der Bachmannsche Spruch.

Jetzt werfen wir einen Blick auf die Stellen in den Diagrammen, an denen keine Übereinstimmung herrscht.

Objekt, aber keine Entität: Schauen Sie sich auch einmal die Objekte an, zu denen Sie keine Entitäten finden. Das sind Objekte, die für Verarbeitung der Daten oder die Interaktion mit dem Benutzer gebraucht werden. Auch das Eingabefenster auf dem Bildschirm ist in der objektorientierten Denkweise ein Objekt. Um solche Objekte kümmert sich die Modellierung von Entitäten nicht, da zählt nur das, was hinterher in der Datenbank landen soll. Das Klassendiagramm bezieht sich also auf einen größeren Themenbereich als das E/R-Diagramm.

Entität, aber keine Objekt: Umgekehrt gibt es Entitäten, zu denen Sie kein Objekt finden. Aber nur auf den ersten Blick. Bei genauerem Hinsehen finden Sie die fehlenden Daten als Teil anderer Objekte: Die Daten eines Objekts können ineinander verschachtelt sein – anders als bei einer Entität. Für die mächtigeren Datensturkturen ist aber ein Preis zu bezahlen. Ich komme später darauf zurück.

Objekt als weiterentwickelte Entität: Es spricht also einiges dafür, Objekte für eine Weiterentwicklung von Entitäten zu halten. Das ist kein Wunder: Die Entitäten waren zuerst da. Aber auf dem Weg von der Entität zum Objekt ist auch etwas verloren gegangen, nämlich der Schlüssel. “Ein Objekt ist eine Entität, die ihren Schlüssel sucht …”

Schlüssel schaffen Klarheit: Ein Schlüssel identifiziert eine Entität über Dateninhalte. Wer jemals Schlüssel zusammen mit den künftigen Anwendern eines System festgelegt hat, der wird erstens froh sein, wenn er das Ergebnis zusammenhängend aufschreiben kann, for future reference, und wenn er auch Budgetverantwortung hat, wird er zweitens dankbar dafür sein, diese Diskussion geführt zu haben, solange noch nichts programmiert ist. 

Objekte werden einfach durchnummeriert – so kommen die obigen Diskussionen später auf, vielleicht zu spät.

Weiter unten in diesem Text werden wir uns dieses Thema aus einem anderen Blickwinkel ansehen.  Vorerst schauen wir uns praktische Situationen an, die eine Durchgängigkeit zwischen Objekt und Entität wünschbar erscheinen lassen. 

Ein extremes Beispiel für “Objekt = Entität”: Ich war letztens bei der Vorstellung eines Werkzeugs zur Code-Generierung. Man steckt ein graphisch spezifiziertes Modell in den Generator und bekommt eine eine lauffähige Java-Applikation heraus, mit eingeschränktem Funktionsumfang (create, retrieve, update, delete). Die Teilnehmer der Veranstaltung durften sich neue features für die nächste Version des Generators wünschen. Das Ergebnis: Ein Datenbank-Reverser. Dieser liest die Datenstrukturen einer lebendigen Datenbank und macht daraus einen Teil der Eingabe für den Generator. Darüber hinaus braucht der Generator nicht mehr viel, um seine Java-Applikation zu erzeugen. Auf den erzeugten Code kann man aufbauen, fehlende Funktionen einbauen.

Wer sich so einen Datenbank-Reverser wünscht, muss wohl der Meinung sein, dass es praktische Zwecke gibt, für die egal ist, ob das Rechteck Entität oder Objekt heißt.

Datenmodellierung mit objektorientiertem Tool: Ich befasse mich mit Programmen zur Übertragung von Modellen zwischen Modellierungstools. 

Bei den weitaus meisten Klassenmodellen, die auf meinem Schreibtisch landen, handelt es sich um Datenmodelle, die mit einem objektorientierten Modellierungswerkzeug erfasst wurden.  Wie kommt das?

Häufig wird bei Fachkonzepten ein objektorientiertes Modellierungswerkzeug eingesetzt, weil das Fachkonzept über die Daten hinaus auch die Abläufe durchbuchstabieren will. Danach baut man die Datenbank.  Das können die objektorientierten Tools nicht so gut. Also kommt meist der Wunsch auf, die modellierten Klassen in ein Datenbank-Werkzeug zu übertragen.  Der Modell-Transfer liefert dort etwas ab, was als Ausgangspunkt für das Datenbank-Design taugt.

Leider macht sich an dieser Stelle die gedankliche Barriere zwischen Objekt und Entität negativ bemerkbar. 

UML kennt keine Schlüssel - unter anderem. Der Standard für objektorientierte Modellierung heißt UML – Unified Modelling Language. Vor UML gab es eine Vielzahl objektorientierter Systematiken, UML hat den Anspruch, diese zu vereinheitlichen, daher das „U“ im Namen. Entitäten und Relationships und besonders Schlüssel sind bei dieser Vereinheitlichung aber außen vor geblieben.  

Problem gelöst? Nicht ganz. Jeder spezielle Zweck benötigt, jede Organisation schafft ihr eigenes Profil, und im Rahmen eines Projekts werden unterschiedliche Zwecke verfolgt und es sind verschiedene Organisationen beteiligt. Jede Zeit schafft sich ihren eigenen Turm zu Babel.

JJG