Teil des Projektplans sollte eine Liste der Dienste sein, deren Funktionsfähigkeit während der Migration möglichst schnell wieder herzustellen ist. Dabei sollte man darauf achten, dass man für die notwendigen Tests nicht auf die Mitarbeit anderer angewiesen ist, sprich: Es sollte eine Testprozedur vorab definiert sein, nach deren erfolgreichem Ablaufen der Dienst als "verfügbar" klassifiziert ist. Wenn hierfür Zugangsdaten notwendig sind, muss der Kunde diese zur Verfügung stellen. Ein Testaccount reicht natürlich, aber dann muss es dem Kunden auch reichen, wenn nur mit dem Testaccount getestet wird.
Ganz wichtig: Die Testprozeduren muss man unbedingt vor dem Beginn der eigentlichen Migration einmal selbst ausgeführt haben. Nur so ist sichergestellt, dass man die Prozedur verstanden hat, und dass der Dienst vorher überhaupt funktionstüchtig war. Wenn man diese Prüfung unterlässt, kann es sein, dass man nach der Migration stundenlang herumdebugged und dann zu dem Schluß kommt, dass der Dienst schon seit Tagen kaputt ist, es nur keinen interessiert hat, man mit der Debuggingaktion nur sein eigenes Projekt verzögert hat und man selbst das Ding gar nicht reparieren kann weil man schlicht nicht schuld daran ist dass es nicht funktioniert.
Wir unterbrechen den kleinen Migrationsleitfaden für die jahreszeitlich üblichen Wunsche für das Jahr 2010
Kommunikation verhindert Mißverständnisse. Das ist in komplexen Systemen wichtig, und zwar insbesondere in einem Migrationsprojekt, wo man den aktuellen Betriebszustand zu Beginn der eigentlichen Migration, der so G*tt will "System funktioniert" heißt, erstmal massiv verschlechtern muss, denn ganz ohne Downtime geht eine Migration in aller Regel nur mit massivstem Materialaufwand.
Deswegen kommt es bei einem Migrationsprojekt darauf an, dass man glasklar mit dem Kunden bespricht, wie die Migration ablaufen wird, wie der Zeitplan ist, und zu welchen Zeitpunkten mit welchen Teilfunktionalitäten des Systems (nicht) gerechnet werden kann. Wenn der Kunde von einem anderen Ablauf der Migration ausgeht als man selbst, gibt das Ärger, und zwar nicht selten mitten in der Migration.
Continue reading "zkmlf: Kommunikation mit dem Kunden"
Bei einer Migration ist es immer wichtig zu wissen, womit man es zu tun hat. Dazu gehört insbesondere die Sammlung von Informationen, die man braucht, um das neue System erfolgreich an den Start zu bekommen.
Continue reading "zkmlf: Sammelt Informationen ein wo Ihr sie kriegen könnt"
Oft stolpert man bei der Vorbereitung einer Migration auf Altlasten, deren Implementierung im neuen System zwar möglich ist, man das aber aus verschiedenen Gründen nicht möchte. Manche Kunden sind dazu bereit, im Rahmen des laufenden Projekts auch an anderen Stellen Anpassungen vorzunehmen, die ihnen in Zukunft das Leben erleichtern. Man sollte sich nicht scheuen, solche Maßnahmen vorzuschlagen - etwas Blick über den Tellerrand hat noch keinem geschadet.
Continue reading "zkmlf: Architekturanpassungen vorschlagen, Altlasten von morgen verhindern"
Oft hat man vor dem Einstieg in die heiße Migrationsphase die Gelegenheit, die neuen Systeme vorzubereiten und zumindest teilweise vorzukonfigurieren. Das sollte man natürlich besonders bei Produkten machen, deren Eigenheiten man noch nicht in- und auswendig kennt, denn außerhalb der heißen Phase hat man Zeit und Ruhe und kann auch mal manche Dinge ausprobieren, die einen vielleicht nur akademisch interessieren. So fasst man Vertrauen zum Produkt und solches Wissen kann man sicher auch irgendwann mal wieder gebrauchen.
Ich baue neue Systeme - so vertretbar möglich - immer erstmal in einer Laborumgebung ("einem Lab") auf, das die Infrastruktur des Kunden möglichst 1:1 nachbildet.
Continue reading "zkmlf: Vorbereitung des neuen Systems"
Der Titel dieses Artikels ist ein alter Fliegerspruch, der in IT-Projekten natürlich auch seine Richtigkeit hat. Guckt Euch die Konfiguration der abzulösenden Systeme an, macht Euch Gedanken über den möglichen Weg vom aktuellen Zustand zum Zielzustand, definiert Euch Meilensteine und für den Kunden akzeptable Bauzustände, bei denen man im Falle eines Falles eine auch längere Pause einlegen oder ganz abbrechen kann. Auf den Originalzustand zurückrollen ist oft keine realistische Option oder macht bereits geleistete Arbeit zunichte. Nichtsdestotrotz sollte man sich diese Option als Manöver des letzten Augenblicks offen halten.
Informiert den Kunden über diese Planung und achtet darauf, dass er die Idee des Bauzustands versteht und nicht erwartet, dass in jedem Bauzustand jede Funktionalität unbedingt funktioniert, und dass er nicht meint, dass bloß weil Ping in die Welt und der Zugriff auf Sp**g*l Online wieder funktioniert, die Migration fertig abgeschlossen ist und alles was jetzt noch nicht funktioniert gleich eine Schlechtleistung des Dienstleisters darstellt.
For some reason, this article written in late 2008 remained unpublished. It's therefore kind of outdated.
When I took over my former work notebook (an hp nc 8000) from my (now former) company, one of the first things I did was swapping its old 120 GB disk for a new 250 GB disk. 250 GB is the biggest disk one can get in the 2.5 form factor with a PATA interface, and there is only one disk in the market, and it's made by WD. So I didn't have much of a choice and ordered one in mid August 2008. It has been working fine until it died this Friday, a mere three months after buying it. This wrecked much of my Friday and the entire weekend for me since I spent the days being a data wrangler, and without my main work tool.
This disk death was the second one this week after having one 40 GB disk (purchased in 2001) die in my other notebook on monday. I've really had it with hardware for the time being.
Continue reading "On 250 GB in an old notebook"
Gestern habe ich kurz erwähnt, dass es sich bei einer größeren Feier in aller Regel lohnt, seine Gäste dazu zu bringen, miteinander zu kommunizieren, und zwar am besten gruppenübergreifend. In diese Artikel erzähle ich Euch, wie wir das auf unserer Hochzeit gemacht haben, was sehr gut geklappt hat.
Continue reading "Namensschilder als Kommunikationshilfe"
Den Strandkorb hat's auch gebraucht, denn es war ordentlich kühl und windig. Aber die Sonne hat geschienen, und man konnte mit langer Hose und Windjacke sehr schön spazieren gehen. Der grüngestreifte Strandkorb hat nichtmal was extra gekostet.
Da nimmt der Herr W. die Arbeit als Lumpensammler sehr ernst. Wir haben darauf geachtet, dass die Fahrstrecke an keinem Bahnhof vorbeiführt.
Der Herr auf der linken Seite fotografiert (dazu noch später mehr), und die Dame auf der rechten Seite habe ich geheiratet.
Fahrradfahren auf Föhr macht nur recht eingeschränkt Spaß: Dort, wo's schön wird, stehen mehr oder weniger lustige Fahrradverbotsschilder. Schade drum.
Diese Schilder scheint es im Dutzend im einschlägigen Geschäft für Tourihochburgen billiger zu geben, das identische Schild steht auch in Hamburg in der Övelgönne.
Sylt wird im allgemeinen überschätzt. Das haben wir gelernt, als wir uns aus der Flitterwoche für einen Tag nach Sylt übersetzen ließen. Das Highlight des Tages war definitiv die Fahrt mit der Adler Express, einem schnellen Wasserstrahlschiff, von Amrum nach Hörnum. Sylt selbst besteht hauptsächlich aus Dünen, auf denen man nichtmal herumlaufen darf, wegen Naturschutz, Kampen ist ein menschenleeres Kaff, List ist ganz nett, aber windig, und Westerland hat in etwa den städtebaulichen Charme von Ludwigshafen. Da muss man selbst für den Strand Eintritt bezahlen. Den Tag hätten wir besser am Strand von Föhr verbracht. Der Vollständigkeit halber hier das Beweisbild vom bisher nördlichsten Punkt unseres gemeinsamen Daseins.
