EII: Mühsam ernährt sich das Eichhörnchen

Der Begriff Enterprise Application Integration hört sich gewaltig an, er schreit förmlich nach teuren Consultants und SAP-Einführung. Allerdings gibt es oft auch kleinere Schritte in diese Richtung, die es sich zu gehen lohnt. Ein Beispiel: Es gibt bei mir in der Arbeit einen Schlüssel zu einem Informationssystem, der nach einer bestimmten Systematik aufgebaut ist, nämlich xxxx-xxxxx (x steht für eine Ziffer). In einem anderen Informationssystem wird dieser Schlüssel aber als xxxxxxxxx eingegeben und abgespeichert. Das macht ständig Probleme bei der Datenzusammenführung. Der letzte, der wusste, warum die Darstellung in diesem System ohne Bindestrich erfolgt, ist jedenfalls seit einem Jahr weg... Also habe ich kurzerhand den RegularExpressionValidator umgestellt und über die bereits eingegebenen Daten eine Stored Procedure laufen lassen, die die Daten konvertiert. Bis jetzt hat sich noch niemand beschwert :-) Und es ergab sich sogar direkt ein praktischer Nutzen. Ich konnte nämlich für unseren Controller mit nur einer SQL-Anweisung eine Auswertung fahren, für deren Ergebnis er sonst hätte ganz schön friemeln müssen.

KM: Datenablage

Gibt es eigentlich in Ihrer Firma eine Arbeitsweisung, in der festgelegt ist, wann und wo welche Daten durch die Bearbeiter abzulegen sind? Wird das auch kommuniziert und überwacht?
Ich finde es jedenfalls nicht hinnehmbar, dass die Versetzung eines Bearbeiters den armen Nachfolger wieder bei Null anfangen lässt. Dieses Prinzip der Verbrannten Erde ist nicht akzeptabel. Eine Person, die keine Daten übergibt, hinterlässt der "Nachwelt" praktisch nichts, zumindest nichts weiter verwertbares. Die Arbeit ist mit hoher Wahrscheinlichkeit verloren. Ist das nicht eigentlich Anreiz genug?
Also:

• Daten raus aus dem privaten E-Mail Postfach


• Anhänge lösen und ablegen


• regelmäßige Sicherung dieser Daten


• Kontakte und Termine in private und dienstliche aufteilen und in getrennten Übersichten führen


• ausreichenden Übergabezeitraum sicherstellen

DB: Datenrespekt

Heute bin ich ein paar Mal über mich selbst erschrocken. Datenbanken sind das Gehirn eines Unternehmens, die in ihnen enthaltenen Daten oftmals unabdingbar für das Bestehen am Markt und vor dem Kunden. Als Admin einer Produktionsdatenbank muss man sich das immer wieder vor Augen führen. Denn nur zu oft, so geht es mir zumindest, ist man in einer Sache so drin, probiert schnell etwas aus, ändert hier was und da, befriedigt mal eben schnell einen Nutzerwunsch, und erst im Nachhinein wird einem so richtig bewusst, dass dieser Quick&Dirty-Ansatz enorme Risiken birgt. Daraus leite ich folgende Handlungsempfehlungen ab, die ich auch versuchen werde, für mich selbst zu berücksichtigen:

• jede Änderung an Programm oder Daten dokumentieren, rollback überlegen


• Durchführung riskanter Änderungen zu Zeiten geringer Last (z.B. abends)


• vor strukturellen Änderungen Extra-Backup und Test auf Spielwiese

Das Wort Datenrespekt gibt es übrigens nicht bei Google :-)