Gastautor(en)
Dienstag, der 27. Mai 2008

Objekte, Entitäten und der “Impedance Mismatch”

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“

Entität Objekt

Verarbeitungseinheit

Treffermenge

einzelnes Objekt

Ausdrucksfähigkeit

Daten

Daten und Programm

Entwicklungsperspektive

Datenbank

gesamte Anwendung

Stil

deklarativ

prozedural

Identifikation

inhaltlich

technisch

Datenstruktur

flach

geschachtelt

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.

Mehraufwand durch zweckentfremdete UML-Konstrukte. Wer also mit einem UML-Tool Datenmodellierung betreibt, muss bestehende UML-Konstrukte zweckentfremden. Dabei erfindet jeder seine eigene Systematik. Jedes Klassenmodell, dessen persistente Klassen ich in ein Datenbank-Design-Tool übertragen soll, sieht daher anders aus – nicht nur auf der inhaltlichen Ebene, das ist ohnehin klar, aber auch syntaktisch. Also geht der Transfer nicht ganz ohne Arbeit ab: Die Eigenarten der verwendeten Modellierungssystemantik müssen erkannt und per Programm neutralisiert werden. Erst dann kann auf der Transfer auf Knopfdruck laufen.

UML-Erweiterungen. UML hält aber einen Trost bereit. Bei der Abbildung von realen Sachverhalten setzt es klugerweise nicht auf Vollständigkeit, sondern auf Erweiterbarkeit. Kann man etwas nicht mit UML-Mitteln abbilden, z.B. den Schlüssel einer Entität, dann kann man UML erweitern. Wer das tun möchte – das können Personen, Projekte oder Organisationen sein – der schafft sich die fehlenden Beschreibungselemente selbst, packt sie in ein so genanntes „UML-Profil“ und lädt dieses in ein modernes UML-Modellierungstool. Danach kann man mit dem Tool auch die vormals fehlenden Dinge erfassen – z.B. den Schlüssel einer Entität. Das Profil verteilt man zusammen mit dem Tool, so dass ein Benutzer nicht bemerkt, ob er nun reines UML verwendet oder mit einem Profil arbeitet.

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

Roland Dürre
Donnerstag, der 22. Mai 2008

Korruption, Monokultur, Multikultur, Shareholder Value

Die Siemens AG steht zurzeit häufig und leider meistens negativ in den Medien. Mich berührt das, da Siemens mein erster und mich prägender Arbeitgeber war. Besonders oft wird Siemens mit dem so genannten „Korruptionsskandal“ in Verbindung gebracht.

Zum Thema Korruption habe ich vor 5 Jahren gemeinsam mit Marc Borner – einem Studenten der Philosophie aus Darmstadt – für ein Seminar der Wolfgang-Goethe-Universität einen Vortrag mit dem Titel „Das Käufliche des Unkäuflichen“ ausgearbeitet und bei verschiedenen Unis und Gremien gehalten. Noch heute bekomme ich Rückmeldungen, deshalb bin ich gerne bereit, das Thema zu reaktivieren und bei Interesse auch wieder vorzutragen.

Die (belegten und begründeten) Botschaften in Kurzform waren:

mehr »

Roland Dürre
Dienstag, der 20. Mai 2008

IF-Blog 2-wochen-news – #3

Liebe Freunde, sehr geehrte Damen und Herren!

IF-Blog läuft jetzt auf wordpress 2.5, Mark Bendix hat gestern Nacht die Portierung durchgeführt! Und Felix Lange hat eine wunderschöne Eintrittsseite gebaut, die ab sofort unter www.IF-Blog.de bewundert werden kann.

Die Autoren waren diesmal (Pfingsten und schönes Wetter) nicht ganz so fleißig. Hier die neuen Beiträge seit der letzten 2-Wochen-News:

die interface geschichte #2 & #3

Roland Dürre erzählt über die schwere Geburt der InterFace Connection GmbH (die spätere InterFace AG).

Teil 1 / Teil 2 / Teil 3

grundlagen des account management

Die Fortsetzung der IdM-Serie von Bernhard Findeiss. mehr…

vintage computer festival europe – vortrag it-nostalgie #1

Bericht über eine Computer-Veranstaltung in München zu Computern aus dem Vintage-Zeitalter und Geschichten, wie es damals war. mehr…

Der erste Übersichts-Beitrag von Bernhard Findeiss zum Thema Identity Management ist jetzt auch auf Englisch verfügbar.

Und demnächst startet die Scrum-Serie (inklusive Gratis-Scrum-Plakat zum Runterladen)!

Roland Dürre
Sonntag, der 18. Mai 2008

Vintage Computer Festival Europe – Vortrag IT-Nostalgie #1

Am Samstag, den 26.April 2008 fand in München das Vintage Computer Festival Europe (VCFe) statt.

Das VCFe ist ein Treffen für Liebhaber nostalgischer Computer und Software. Die Veranstaltung beinhaltet eine Ausstellung, einen Flohmarkt für alte Computer, Zubehör und Teile. Parallel findet ein Rahmenprogramm mit interessanten und gut besuchten Vorträgen statt. Das Münchener Treffen ist „Ableger“ einer relevanten Bewegung, die ihren Anfang in den USA hatte. Die größte Veranstaltung findet in San Francisco statt. Hans Franke (ein ehemaliger Siemens-Kollege) organisiert jährlich das Münchner Meeting, es war auch in 2008 wieder eine gelungene und gut besuchte Veranstaltung.

Die klassischen Sammeldisziplinen wie Briefmarken oder Modelleisenbahnen sind „out“, Automobilia hat seinen Höhepunkt überschritten. Die Zukunft gehört wohl alten Computern und nostalgischer Software. Opa sitzt in Zukunft nicht mehr im Sessel über seinem Briefmarkenalbum, er bastelt auch nicht mehr im Keller an seiner Modelleisenbahn. Der moderne Opa sitzt gemeinsam mit der Oma im Arbeitszimmer, gemeinsam bringen sie alte Computer zum laufen.

So entwickeln sich auch die Sammlerpreise: Briefmarkensammlungen, die noch vor Jahren einen echten Vermögenswert dargestellt hätten, vergilben auf den Dachböden und sind nahezu wertlos geworden. Die Liebhaberpreise für Eisenbahn- und Automodelle geben mehrheitlich nach, die Preise für alte Computer dagegen beginnen zu steigen.

Und die Mädchen kann man auch nicht mehr zu sich nach Hause locken mit „Komm mal, ich zeig Dir mein Briefmarkenalbum“. Das wird in Zukunft so gehen: „Komm mal, ich habe da so einen wunderschönen alten Commodore mit einem ganz tollen alten Spiel!“

Ich kann also den Besuch des VCFe im nächsten Jahr nur empfehlen!

Dieses Jahr war ich eingeladen, einen Vortrag über IT-Projekte und IT-Probleme aus der IT-Steinzeit zu halten. Hans Franke hatte meinen Vortrag im Programm des VCFe wie folgt angekündigt:

Als Flops noch ohne Mega auskamen!

Ein vom Hersteller nicht vorgesehener, kreativer Umgang mit neuen IT-Anwendungen ist keine Erfindung der Internetgeneration – genauso wenig wie spektakuläre Fehlschläge und Sicherheitslücken.

Dieser Vortrag erzählt wie Fahrkartenverkäufer der DB beim Umstieg von mechanischen Fahrkartenmaschinen zur Mainframe-Abwicklung neue Wege fanden, oder wie ein Hauptspeicherausbau ganze Polizeiflotten verschwinden lassen konnte. Auch wenn manches aus 30 Jahren Entfernung weniger dramatisch wirkt, es war beileibe nicht immer bayerisch gemütlich.

So habe ich in meiner gut 35-jährigen Erfahrung gekramt und vieles gefunden. Stundenlang könnte ich aus der Zeit der Lochstreifen- und karten erzählen. Mit dem mobilen Lochkartenstanzer und dem Microfiche-Lese-Gerät waren wir auch am Sonntag unterwegs und reparierten die Fehler an zentralen IT-Systemen. Der Vortrag hat mir und nach meinem Eindruck auch den Zuhörern viel Spaß gemacht und deshalb veröffentliche ich ihn hier als „Fortsetzungsroman“ in mehreren Teilen.

Am Anfang des Vortrages habe ich die Siemens IT-Technologie gewürdigt, die in den ersten 50 Jahren des Computerzeitalters eine auch weltweit herausragende Stellung hatte.

(Nicht nur) in Deutschland war neben IBM Siemens der herausragende IT-Hersteller. Es gab bei Siemens mehrere in Deutschland entwickelte Prozessor- und Rechner-Linien, verschiedene Betriebssysteme wie BS1000, BS2000, PDN, Amboss und weitere für Prozeßrechner und Spezialsysteme. MS-Dos und Unix waren noch weit weg. Compiler und Interpreter für alle möglichen Sprachen angefangen bei ADA über Cobol, Fortran bis hin zu Lisp und Prolog waren selbstverständlich vorhanden. An diversen Datenbanken, Office- und Dokumentations-Systemen, Warenwirtschaftssystemen und beliebig weitereer System- und Anwendungs-Software wurde in Hülle und Fülle geschrieben.

Es gab alle Arten von Peripherietechnologie, unterschiedliche Speichersysteme, hochmoderne Laser- und Stahlband-Drucker, Netzwerktechnologien und Kommunikatonsprotokolle, Terminals oder Spezialendgeräte. Alles wurde in Deutschland entwickelt und hergestellt. Auch fast alle Bauteile wie Prozessoren, Speicher oder modernste Technologien wie Glasfaser wurden hierzulande entwickelt, das bei Siemens vorhandene Know-how war einzigartig. Und das ergänzte sich exzellent mit der Kommunikationstechnologie, ob Endgeräte wie später Mobile Telefone oder zentrale Vermittlungssysteme.

Kooperationen mit führenden Technologieherstellern wie Xerox brachten zusätzlich modernste Technik in die Siemens Labors. Innovationen wie Teletext oder Bildschirmtext zeigten in die Zukunft, große Plotter und Industrieroboter beeindruckten uns. Es war ein Programm ohne Grenzen mit einem Know-how-Pool, der seinesgleichen gesucht hat – und der nicht mehr vorhanden ist.

Meine erste kleine Geschichte fängt Ende der 70iger an: In großen Projekten war noch BS 1000 angesagt (BS 2000 war gerade erst im Kommen), als Transaktionsmonitor wurde das damals bewährte und verbreitete System ASMUS (Abkürzung für „Axel Springer Mehrfach-User-System“) eingesetzt. Entwickelt wurde mit assembler-basierten Makrosprachen (Columbus-Assembler), Cobol war die innovative aber oft zu aufwendige Variante. Wir haben damals DISPOL aufgebaut, da ging es unter anderem darum, den Fernschreibverkehr über ein Paketvermittlungsnetz abzuwickeln (mit echten Fernschreibern an Rechnern oder Fernschreiberemulationen auf Datensichtgeräten) und die Anwender mit einem neuen Fachverfahren zu verbinden.

Und eines Tages die Hiobsbotschaft im Projekt: der Mainframe braucht mehr Speicher! Da ging es aber nicht um Megabytes sondern „nur“ um eine dreistellige Zahl von Kilobytes im unteren Bereich. Ich glaube, es waren sogar nur 100 kilobyte. Das Problem war nur, dass der unvorhergesehene zusätzliche Speicherbedarf wertemäßig im sechsstelligen DM-Bereich lag. Ein Polizeibeamter hat dann lakonisch bei Weißwurst und Bier gemeint: Die 100 Kilobyte kosten uns ja mehr als 30 Polizeiautos. So hat der Mainframe eine ganze Polizeiflotte aufgefressen.

Im Vortrag habe ich dann ein paar weitere Geschichten aus der Zeit vor mehr als 35 Jahren erzählt, die ich in den nächsten Wochen als kleine Beiträge veröffentlichen werde.

RMD

Weiter

Hier meine persönliche InterFace Geschichte:

Teil 3:

Die Gründung 1983 – 1984

Bis 1982 war ich bei Softlab. Softlab war aus meiner Sicht ein exzellentes Unternehmen, bei dem ich mich ziemlich wohl fühlte. Trotzdem entwickelte sich bei mir eine innere Unruhe. Zu einem weiteren Job-Wechsel hatte ich keine Lust. So stellten sich mir zwei Alternativen: Ich konnte Freiberufler werden – oder ein Unternehmen gründen. Beim ersteren hatte ich Angst vor sozialer Einsamkeit. Das zweite hatte seinen Reiz, ich hatte aber hohen Respekt vor der Gründung eines Unternehmens.

Mit Peter Schnupp, der die InterFace GmbH gegründet hatte und nur noch in Teilzeit für Softlab tätig war, war ich gut befreundet. Peter hatte – wie immer – eine einfache Lösung: „Komm doch zur InterFace und gründe von dort aus etwas Eigenes!“. Und sicherheitshalber stellte er dann auch gleich Barbara (da schon meine Ehefrau) ein. Wir hatten schon zwei Kinder und Barbaras Firma, die GfS lag in den letzten Zügen.

mehr »

Bernhard Findeiss
Freitag, der 16. Mai 2008

Grundlagen des Account Management

In meinem letzten Post (nachzulesen hier) habe ich kurz die Klassifikation von IdM-Systemen nach dem FIDIS-Modell vorgestellt.

Darauf aufbauend möchte ich nun gerne etwas über die Grundlagen des Typ 1-Identitätsmanagement erzählen : Was versteht man darunter, und was sind hierbei die Herausforderungen und Schwierigkeiten?

Beim nächsten Mal werde ich dann darauf eing ehen, warum es sich dennoch lohnt, und in einigen Fällen sogar unerläßlich ist.

Basis dieses Artikels ist im übrigen ein Foliensatz über einen Vortrag, den ich letztes Jahr an einem „Blue Friday“ der InterFace AG gehalten habe. Wenn jemand an diesem Foliensatz interessiert ist, oder natürlich auch daran, daß ich diesen Vortrag bei einer anderen Gelegenheit nochmal halte, so lade ich ihn gerne ein, sich bei mir zu melden ( unter bernhard.findeiss (at) interface-ag.de).

Wie bereits im letzten Post erwähnt, kann Account Management definiert werden als die konsistente Verwaltung von Identitäten und deren Zugriff auf IT-Ressourcen eines Unternehmens über die gesamte Dauer ihres Lebenszyklus hinweg.

Dies beinhaltet u.a.:

– Personen: Interne sowie externe Mitarbeiter, aber auch technische Objekte, soweit sie Zugang zu Ressourcen benötigen (etwa Drucker, die automatisiert EMails verschicken können etc.).

– Speicherung von identitätsbezogenen Daten (Zulieferung zumeist aus Personalsystemen)

– Weitergabe von Daten an Zielsysteme, z.B. um Benutzerkonten einzurichten, Berechtigungen zuzuweisen bzw. zu entziehen, bzw. ganz allgemein zur Synchronisation von Daten zwischen IdM-System und Zielsystem. Die Zahl und die Art der anzubindenden Zielsysteme trägt im Übrigen maßgeblich zur Komplexität von IdM-Projekten bei.

– Unterstützung von Workflows, die im Unternehmensalltag benötigt werden, z.B. Anlage/Änderung/Löschung von Identitäten, Zuweisung/Entziehung von Ressourcen, Definition von Rollen etc.

Account Management ist für Unternehmen natürlich beileibe kein neues Thema, sondern wird in der Regel bereits genauso lange praktiziert, wie zugriffsgeschützte (IT-) Ressourcen vorhanden sind. Bisher wurde ein Großteil dieser Arbeit jedoch von einem Administrator „per Hand“ erledigt, was natürlich mit sehr viel Aufwand verbunden ist, und auch eine höhere Fehlerrate beinhaltet, als wenn man dies automatisiert durch Anbindung an ein IdM-System macht.

Zudem hat man auch noch das Problem der Datensynchronisierung, da man natürlich auch hier sicherstellen muß, daß alle Systeme, zu denen eine Person Zugang haben soll, auf dem selben Satz von Identitätsdaten basieren. Diese sind aber nicht fest, sondern können sich im Laufe der Zeit ändern (etwa durch Heirat oder Umzug). Die Daten dann konsistent zu halten kann durchaus eine Herausforderung darstellen (z.B. Auflösung von Widersprüchen zwischen 2 Systemen).

Um dieses Problem zu lösen wurden in den 1990er-Jahren die ersten Verzeichnisdienste eingeführt. Diese sammeln alle personenbezogenen Daten und stellen sie über eine einheitliche Schnittstelle zur Verfügung (am bekanntesten dürfte hier LDAP sein). Diese Schnittstelle wird dann in Bezug auf die Stammdaten als „führend“ definiert, sodass alle anderen Systeme sich damit abgleichen können.

Leider aber konnten auch hiermit nicht alle Probleme gelöst werden. Nicht alle relevanten Systeme unterstützen die Externalisierung von Identitätsdaten, bei manchen (z.B. Personalsystemen) kann dies aus verschiedenen Gründen sogar unerwünscht sein.

Mithilfe eines Identitätsmanagementsystems lässt sich jedoch auch diese Situation in den Griff kriegen:

Man erlaubt allen Systemen ihre Datenhoheit zu behalten, lediglich relevante Änderungen werden an das IdM-System weitergegeben. Dieses übernimmt daraufhin die Synchronisierung mit der restlichen Systemlandschaft. Auch auf diese Weise ist es möglich, die Konsistenz der Identitätsdaten über alle Systeme eines Unternehmens hinweg zu garantieren.

Dies ist einer der Vorteile der Einführung eines IdM-Systems. Über weitere Vorteile werde ich beim nächsten Mal schreiben.

Roland Dürre
Montag, der 5. Mai 2008

Die InterFace Geschichte #2

Hier meine persönliche InterFace Geschichte:

Teil 2:

Wie ich zu Softlab kam!?

Zu Softlab wechselte ich 1980. Peter Schnupp gründete damals die InterFace GmbH, er war aber überwiegend noch für Softlab tätig. Peter war einer der drei Gründer der Softlab GmbH. Er war der technische Visionär und damals schon eine kleine Legende. Peter war ein sehr kreativer „IT-Freak“, der durch die Räume „wuselte“ und für alle Mitarbeiter da war. Sein Markenzeichen war die qualmende Zigarre und man konnte schon von weitem riechen, wenn er kam. Einmal blieb er so auch bei mir hängen – und wir suchten ziemlich lange gemeinsam an einem Fehler.

Bis Anfang 1980 war ich bei Siemens. Zwei Jahren hatte ich bei UB D ST DFÜ 112 (Unternehmensbereich Datenverarbeitung Systemtechnik Datenfernübertragung – ein so genanntes Entwicklungslabor) verbracht. In diesem Labor habe ich viel gelernt, ich hatte auch sehr sympathische Kollegen und Super-Chefs (Gernot Hennig und Peter Jilek, beide sollten später bei Siemens noch so richtig Karriere machen, Peter Jilek ist heute im Aufsichtsrat der InterFace AG). Ich hatte bis zum Vorstand 9 (!) Führungsebenen über mir. Mit Karriere war es im Labor nicht so weit her, deswegen habe ich dann in den Vertrieb Sonder-/Großprojekte gewechselt. Dort waren die Aufstiegschancen besser und dort liefen auch die großen Projekte der Siemens AG wie ITS, Start, SNATCH, Dispol und viele mehr. War dort zwei weitere Jahre – war eine tolle Zeit.

mehr »

Liebe Freunde, sehr geehrte Damen und Herren,

seit der letzten News sind in IF-Blog folgende Beiträge neu veröffentlicht worden:

was ist eigentlich identitätsmanagement und warum sollten wir etwas darüber wissen?
Der erste Fachbeitrag unseres IdM-Spezialisten Bernhard Findeiss. mehr…

von ottobrunn nach unterhaching #1 (die 4-ampel-geschichte)
Auch Strassen haben ein Leben oder was einem täglich so auffällt (Und Teil 2 ist auch schon fertig). mehr…

auf welchem menschenbild baut moderne führung auf?
Manuskript eines Vortrages gehalten von Roland Dürre an der Universität Augsburg und an der technischen Universität München. mehr…

unternehmenskulturen, bullshit bingo und der outlook-kalender
Die Auswirkungen von Kalenderspionage auf die Unternehmenskultur (Deutsch,Englisch). mehr…

anstand (von dr. frank schütz)
Der erste Beitrag von Dr. Frank Schütz (Deutsch). mehr…

interface geschichte (#1)
Roland Dürre berichtet, wie es in 1975 anfing (Deutsch) mehr…

unternehmenskulturen, bullshit bingo und der outlook-kalender #2
Was bringt ein öffentlicher Groupware-Kalender dem Unternehmen? (Deutsch) mehr…

Neben „Freiheit“ liegen jetzt auch „Computer Policy und Car Policy“ und „Unternehmenskulturen …“ auf Englisch vor.
Und auf den Pages stellt sich das Team vor und beschreibt sein Selbstverständnis.

Roland Dürre
Samstag, der 3. Mai 2008

Von Ottobrunn nach Unterhaching #2 (Rad/MVV/AUTO)

Hier die Fortsetzung meiner Reflektionen zu meinem Arbeitsweg:

Wenn ich von zu Hause mit dem Fahrrad nach Unterhaching fahre sind es hin und zurück 12 km. Ein gutes Fahrrad kostet durchaus um die 20 cent/km (Abschreibungen auf Anschaffungspreis, Verschleiß wie Reifen, Kette, Ritzel, Wartung und Reparaturen). Wenn man die notwendigen Arbeiten nicht selber ausführt, kommt man auch ganz schneller drüber.

Fahrrad:

Kosten: 12 km à 20 cent 2,40 EURO (ohne erhöhten Kleider-Verschleiß)

Zeitbedarf: von Tür zu Tür ca. 45 Minuten.

Vor- und Nachteile: Ab und zu werde ich nass. Der Genussfaktor ist vom Wetter abhängig. Aber man gewöhnt sich auch an Regen und Kälte. Und der Anzug leidet unter Radfahren.

Man kommt nicht nur mit dem Fahrrad von Ottobrunn/Riemerling nach Unterhaching. Ich kann auch das Auto nehmen, öffentlich fahren, Inline Skaten oder Joggen.

Mit dem Auto geht ein wenig schneller als mit dem Fahrrad. Zur Rush-Hour kann es aber auch länger dauern. Die Kosten sind eine Frage der Betrachtung. Rechne ich nur den Diesel (das Auto habe ich ja sowieso), dann ist es billig. Autoweg ist ein wenig weiter, also 13 km. Auf 100 km brauche ich so zwischen 6 und 7 Liter, also 1 Liter. Das macht 1,40 (Dieselpreis 2. Mai in Ottobrunn). Wenn ich eine Vollkostenrechnung mache, dann bin ich vielleicht bei 35 cent den Kilometer, also 4,55 EURO. Da wir bei InterFace eine geräumige Tiefgarage haben (vor allem auch für unsere Gäste) brauche ich keinen Parkplatz suchen.

Auto:

Kosten: Nur Diesel 1,40 EURO / Vollkostenrechnung 4,55 EURO (ohne von InterFace gestellten Parkplatz – 40 EURO im Monat)

Zeitbedarf: von Tür zu Tür ca. 4o Minuten

Vor- und Nachteile: Gelegentlich stehe ich im Stau, keine Bewegung, dafür warm und trocken. Und das stehen vor den Ampeln macht mich manchmal aggressiv. Keine Bewegung, müsste dann Abends ins Fitness-Studio.

Die motorisierte Alternative zum Auto ist übrigens mein C1 von BMW, ein reines Lustobjekt. Braucht ein bisschen weniger Benzin und macht richtig Spaß. Aber da kommt dann das schlechte Gewissen: „Du könntest auch Radfahren“.

Wenn ich öffentlich fahren will, dann nehme ich die S-Bahn. Von zu Hause zum Bahnhof in Ottobrunn brauche ich genau 7 Minuten. Die S6 fährt in 11 Minuten nach Giesing, dort habe ich 10 Minuten Aufenthalt und fahre mit der S5 in 6 Minuten nach Unterhaching. Vom Bahnhof Unterhaching zu InterFace sind es 5 Minuten. Macht dann zusammen 27 Minuten reine Fahrt und Umstiegszeit und 12 Minuten Fußweg.

S-Bahn:

Kosten: 2 Einzelfahrkarten 4,40 EURO, mit Streifenkarte (4 Streifen à Euro 2,10)4,20

Zeitbedarf: Hin und zurück und von Tür zu Tür 1:18 Stunden (wenn S-Bahn pünktlich!?)

Vor- und Nachteile: In der S-Bahn kann man lesen. Zu gewissen Zeiten ist sie überfüllt und ich muss stehen. In Giesing beim Umsteigen ist es ab und zu sehr zugig. Und das Problem mit der Pünktlichkeit. Die Zuverlässigkeit der S-Bahn im Münchner Raum ist doch sehr unterschiedlich. Und wenn man den Anschluss in Giesing verpasst, dann wartet man halt auch mal 20 Minuten.

So ein Vergleich ist doch mal ganz interessant, vielleicht regt er zum Nachdenken an. Bei mir gewinnt das Fahrrad mit deutlichem Abstand, der öffentliche Verkehr landet (leider) auf dem letzten Platz.

Ich kann auf meinem Arbeitsweg auch Joggen, Inline Skaten oder Taxifahren. Taxifahren habe ich noch nie ausprobiert. Joggen und Inline Skaten ist aber der Luxus pur. Kann ich mir gelegentlich leisten, weil wir bei InterFace eine schöne Dusche im Keller haben und bei mir immer ein sauberer Anzug mit Zubehör im Schrank hängt.

RMD