Die 7 Schritte zum Software-Retrofit
Softskills und Hardskills Hand in Hand
Die Software eines hochverfügbaren Lagers ist in die Jahre gekommen und nicht mehr erweiterbar. Der Hersteller ist nicht mehr am Markt. Sie wurden beauftragt, eine neue Lösung für die Lagerverwaltung einzuführen. Herzlich willkommen zu dieser interessanten Aufgabe! Interessante Aufgabe? Ja, Sie haben richtig gehört. Sie werden merken, dass diese Angelegenheit Sie auf allen Ebenen fordern wird [1].
Schritt 1: Überblick verschaffen
Es ist Montagmorgen. Der Auftrag ist klar. Oder doch nicht? Was wissen Sie schon über das Unternehmen und die zu ersetzende Software bzw. das zu ersetzende System? Wird das ein gemütlicher Spaziergang oder doch eher eine eisige Abfahrt ohne Helm? Lassen Sie es uns herausfinden.
Am besten beginnen Sie damit, sich mit der Software und ihrer Einsatzumgebung vertraut zu machen. Dabei ist es wichtig, die aktuellen Nutzer von Anfang an gut in den Retrofit einzubeziehen. Dies erzeugt Vertrauen und ein gewisses Maß an notwendiger Sicherheit bei den Mitarbeitern. Beides werden Sie dringend brauchen, damit die Wissensträger bereit sind mit Ihnen zu kooperieren. Schließlich sind Sie gekommen, um jahrelange Arbeit und auch Gewohnheiten unwiederbringlich abzulösen. Das Verständnis dafür ist nicht unbedingt bei allen Mitarbeitern schon vorhanden.
Gehen Sie behutsam und achtsam vor: Die richtige Wahl der Kleidung und bewusst wertschätzende Worte können Ihnen den Einstieg und das gesamte Projekt erheblich erleichtern.
Die Wahl der Kleidung:
Der erste Eindruck zählt. Das ist eine alte Weisheit, die Sie sich in solchen Momenten zu Nutzen machen sollten. Sprechen Sie mit dem Geschäftsführer oder mit dem Lagermitarbeiter? Jeder wird Sie als "Einer von uns" erkennen wollen, um offen mit Ihnen sprechen zu können. Mit dem Anzug im Lager oder dem Blaumann in der Geschäftsleitung wird das nur schwer gelingen.
Die Wahl der Worte:
Was immer Sie auch für einen ersten Eindruck beim Betreten des Unternehmens gewinnen – behalten Sie ihn lieber für sich. Stellen Sie stattdessen Fragen und schätzen Sie die persönlichen Meinungen wert, die mit Ihnen geteilt werden. Beginnen Sie das Gespräch am besten mit kurzem Smalltalk über Ihre Anreise, das Wetter oder was immer Sie gerade interessiert und zu passen scheint. So kann sich Ihr Gegenüber schon mal an Ihre Stimme und Ihr Gesicht gewöhnen und damit anfangen, Vertrauen zu fassen.
Bedanken Sie sich auch gleich zu Beginn dafür, dass Sie eingeladen wurden und für die Zeit, die Ihr Gesprächspartner Ihnen widmet. Erklären Sie im Anschluss kurz, wozu Sie überhaupt da sind (falls der Gesprächspartner nicht ohnehin der Auftraggeber ist) und was Sie von ihm möchten – was also Ihr Ziel für dieses Gespräch ist.
Fragen Sie nach, was – aus Sicht des Gesprächspartners – zu beachten ist, um den Auftrag gut durchführen zu können. Damit wird er als Experte wahrgenommen und Sie erhalten schon erste wichtige Informationen.
Lassen Sie sich alles Mögliche zeigen und sich im Unternehmen herumführen. So lernen Sie das Haus kennen und bilden Allianzen mit Ihren Gesprächspartnern. Bitten Sie auch darum, weiteren relevanten Personen vorgestellt zu werden.
Versuchen Sie so viele Informationen zu sammeln wie möglich!
Hintergrund: Das SCARF-Modell
Das SCARF-Modell [2]beschreibt fünf grundlegende soziale Bedürfnisse, die einen großen Einfluss auf die Motivation und Kooperationsbereitschaft von Menschen haben. Diese sind:
- Status – Position/Stellung im sozialen System
- Certainty – Sicherheit
- Autonomy – Selbst- bzw. Mitbestimmung
- Relatedness – Zugehörigkeit/Verbundenheit
- Fairness – Gerechtigkeit
Ihre Aufgabe ist es, diese Grundbedürfnisse bei all Ihren Tätigkeiten zu berücksichtigen [3].
Die "harte" Informationsbeschaffung
Nachdem Sie auf der menschlichen Ebene gut angekommen sind, geht es an die "harte" Informationsbeschaffung. Versuchen Sie zunächst, ganz grob herauszubekommen, wofür und von wem das System eingesetzt wird. In jedem Unternehmen gibt es spezielle Fachbegriffe, bzw. Bezeichnungen, welche nur dort verwendet werden. Dies gilt sowohl für technische Begriffe, als auch für Orte bzw. Räume, Rollenbezeichnungen oder die Benennung von Software.
Versuchen Sie so viele Informationen zu sammeln wie möglich! Alles kann dabei wichtig sein, egal ob es sich um organisatorische Funktionen wie Ansprechpartner, Schichtpläne usw. handelt oder auch um Wissenswertes über Betriebssysteme, Rechner oder Netzwerktopologien. Das Ziel dieser Informationsbeschaffung ist es, ein Bild von dem System zu bekommen, das gut genug ist, um die anstehende Aufgabe eingrenzen zu können.
In unserem Beispiel sollte man wissen, welche Bereiche überhaupt von der Lagerverwaltung gesteuert werden. Bedenken Sie, dass dabei auch Überraschungen passieren können wie z. B. dass nicht nur Läger auf dem Gelände, sondern z. B. auch Außenläger gesteuert werden könnten (zur Info: In der Logistik ist das Wort "Läger" als Plural für Lager auch gebräuchlich).
Gleiches gilt für gängige Begrifflichkeiten. Oft meint man, aus seinem eigenen Kontext die Bedeutung eines Wortes zu kennen. Im Kontext des Kunden wird es dann plötzlich ganz anders verwendet. Wissen Sie, was ein "Schwimmbad" ist? Mit diesem Wort bezeichnete ein Unternehmen ein Lager, welches ein wenig feucht war (etwa wie ein Keller) und zu dem eine Treppe mit einem Geländer führte – eben wie in einem Schwimmbad.
In der Praxis werden Sie sehr viele unternehmensspezifische Begrifflichkeiten finden. Trauen Sie sich ruhig nachzufragen, was der Kunde darunter versteht.
Tipp: Schreiben Sie die Definition der Begriffe in ein kleines Glossar. So haben Ihre Kollegen die Möglichkeit, auf diese Informationen zuzugreifen.
Hilfreiche Fragen
- Wozu ist die Software gut und hilfreich?
- Wozu sollte/könnte sie hilfreich sein?
- Welche Hardware nutzt das System?
- Wo wird die Software gehostet?
- Wer arbeitet mit dem System?
- Wie viele Nutzer greifen parallel auf die Software zu?
- Wem gehört die Software (Copyright und rechtliche Verantwortung)?
- Welche Abhängigkeiten existieren?
- Wo ist was? Wie sind die räumlichen Gegebenheiten?
- Wo sind die Grenzen der Software?
- Was soll unbedingt weiterhin so bleiben?
- Welche guten Ideen gibt es schon?
- Und was noch?
Schritt 2: Technische und organisatorische Informationen sammeln
Eines ist klar: Sie alleine wissen herzlich wenig über das System. Eigentlich scheint sich damit niemand mehr "richtig" auszukennen. Ist das wirklich so? Immerhin arbeiten viele Leute mit dem System. Und genau das ist Ihre Chance – es wird aktiv genutzt! Nun ist es an der Zeit, technische und organisatorische Informationen zu sammeln.
Rasenmäher vs. Ping-Pong
In der klassischen Softwareentwicklung verfolgt man bei der Informationssammlung meist entweder den Top-Down- oder den Bottom-Up-Ansatz, ähnlich wie beim klassischen Rasenmähen. Sie werden jedoch bei einem derartigen Projekt mit diesem Entweder-oder an Ihre Grenzen stoßen. Woran das liegt? Nicht immer ist ein System z. B. von der Oberfläche bis zum Zugriff auf die Datenbank (also Top-Down) zu verstehen. Gerade bei solch hoch komplizierten Systemen ist an vielen Stellen domänenspezifisches Wissen gefragt, das niemand mehr alleine komplett besitzt. Und genau dieses Wissen zu erforschen ist Ihre Aufgabe.
Finden Sie besser gute Fragen als gute Antworten.
Versuchen Sie, die Zusammenhänge ans Licht zu bringen. Dazu ist es hilfreich, immer wieder einen Schritt zurückzugehen und einen neuen Ansatz zu versuchen. Dieses Vorgehen ähnelt der Bewegung eines Tischtennisballs in einem Raum. Er tickt scheinbar wahllos über eine Fläche, prallt irgendwo ab und springt dann in eine andere Richtung. Verhalten Sie sich einfach so wie der Ball und beachten Sie dabei, dass Sie am Ende die ganze für Sie relevante Fläche abgedeckt haben. In einem Vortrag von uns verglich ein Teilnehmer dieses Vorgehen mit einem neumodischen Rasenroboter, der am Ende seiner Arbeit den ganzen Rasen gemäht hat, ohne vorher genau bestimmt zu haben, wie er die Fläche abgrasen wird (und dabei die Terrasse ignoriert).
Kooperation fördern
In der Phase des Informationensammelns sind Vertrauen und Hilfsbereitschaft der Menschen wichtig. Dazu braucht es eine offene Kommunikation. Fragen Sie nach Persönlichem und halten Sie sich mit Bewertungen zurück. Üben Sie sich in der "Haltung des Nicht-Wissens" und hören Sie aufmerksam zu. Die folgenden Haltungen werden Ihnen als nützliche Begleiter zur Seite stehen.
Stärken-Orientierung
Bauen sie auf den Stärken und Fähigkeiten auf, die ein System und die damit arbeitenden Menschen bereits besitzen.
Jeder ist Experte seiner jeweiligen Situation
Wann immer ein Mitarbeiter im Widerstand ist, Ihnen also nicht helfen möchte, oder sogar versucht, Sie an Ihrem Vorhaben zu hindern, sollten Sie besonders aufmerksam sein. Das ist dann nämlich ein wichtiger Hinweis darauf, dass der Betreffende Informationen oder Erfahrungen hat, die Ihnen noch fehlen. Nehmen Sie solche Personen besonders ernst und finden Sie in offenen und wertschätzenden Gesprächen mit ihnen heraus, was sie beschäftigt und wie relevanten Sorgen in hilfreicher Weise begegnet werden kann.
Die Haltung des Nicht-Wissens
Sie bringen bestimmt viel Erfahrung auf Ihrem Gebiet mit. Das ist auch gut so – schließlich werden Sie deshalb engagiert. Gleichzeitig birgt diese Erfahrung auch die Gefahr, zu schnell Ideen zu entwickeln, ohne die Besonderheit der jeweiligen Situation mit ihrer Geschichte und ihren Hintergründen zu beachten. Finden Sie stattdessen gerade zu Beginn besser gute Fragen als gute Antworten. Mit ehrlichem Interesse werden Sie noch stärker als Experte wahrgenommen als einer, der mit vorgefertigten Antworten über alles und alle "drüberfährt".
Geduld und Zuversicht
Und dann bleiben Sie unbedingt dran! Die Leute, mit denen Sie hier zu tun haben, rechnen möglicherweise nicht damit, dass sie viele Fragen gestellt bekommen. Es kann gut sein, dass das Finden von Antworten auch einen Nachdenkprozess benötigt. Hier ist es wichtig, dass Sie daran glauben, dass man Ihnen helfen möchte und kann. Wenn Sie misstrauisch sind, sind es auch Ihre Gesprächspartner. Dafür sorgen die Spiegelneuronen – aber das ist eine andere Geschichte...
Vorgehen bei der technischen Informationsbeschaffung
Neben den organisatorischen bzw. fachlichen Informationen ist es wichtig, auch technische Informationen zu sammeln. Neben dem Sammeln von Dokumentationen, Source-Codes usw. kommen hier Techniken zum Einsatz, welche "normalen" Softwareentwicklern bzw. Administratoren unbekannt sind, da sie aus dem Bereich des Hacking bzw. der Computerforensik stammen.
Ebenso wie ein Forensiker bzw. Hacker stehen Sie vor der Aufgabe, sich Zugriff auf ein unbekanntes System zu verschaffen. Dazu gehört die Auflistung der beteiligten Server, das Herausfinden der Netzwerktopologie bis hin zum Hacken von Benutzerkonten. Da jedes System anders ist, gibt es für das richtige Vorgehen kein Patentrezept. Deshalb zeigen wir Ihnen hier ein paar Beispiele:
Beispiel: Informationen sammeln
Eine Art, um Informationen über die verwendete Hardware zu erhalten ist, diese über die im Netz angeschlossenen und miteinander kommunizierenden Geräte zu bekommen. Vorsicht: Nicht alle Geräte kommunizieren über das Netzwerk miteinander! Beachten Sie bitte unbedingt auch Geräte, welche auf anderen Wegen z. B. über serielle Schnittstellen, speziellen Adapterkarten usw. miteinander kommunizieren!
Es gibt Kunden, die nicht wissen, welche Geräte in ihrem Netzwerk vorhanden sind bzw. welche für die zu ersetzende Anwendung miteinander kommunizieren. Um dies herauszufinden ist eine Netzwerkanalyse hilfreich. Ein guter Ausgangspunkt dafür ist in der Regel ein PC, auf dem die betreffende Software ausgeführt wird. Bitten Sie einen Mitarbeiter, seinen PC nutzen zu dürfen, während die Software läuft und führen Sie die Analyse vor seinen Augen durch [4].
Es finden sich auch immer wieder Dinge, an die man erst einmal nicht gedacht hätte (s. Abb.1&2). Dieses war die einzige Dokumentation eines automatischen Paletten-Lagers, gefunden an der Pinnwand des Lagerleiters. Sie war sehr hilfreich, denn nur hier war die interne Nummerierung der Fördertechnikelemente angegeben. Genau diese Nummern wurden in den Telegrammen genutzt, welche zur Steuerung dieser Elemente dienen. Als wir den Netzwerkverkehr mitschnitten, konnten somit relativ einfach jene Telegramme gefunden werden, die zu einem Fördertechnikelement gehörten. Die Source-Codes der Anbindung lagen auf einer Diskette im Schaltschrank...
Schritt 3: Gesammelte Informationen gruppieren
Im letzten Schritt haben Sie viele Informationen zusammengetragen, indem Sie das System von den unterschiedlichsten Seiten beleuchtet haben. Nun geht es darum, ein wenig Ordnung in diese Informationen zu bringen.
Dabei gilt es nicht nur das Gefundene zu gruppieren, sondern auch die Lücken zu identifizieren, welche noch geschlossen werden müssen. Hierzu bietet sich eine Mindmap an, da sie schnell erstellt ist und auch noch nachträglich umgruppiert werden kann.
Tipp: Jeder Ast sollte höchstens 5 Knoten haben. Hat ein Ast mehr, so unterteilen Sie ihn weiter [5].
Versuchen Sie Kategorien mittels einiger Fragen zu bilden:
- Welche technischen Informationen habe ich herausgefunden?
- Welche organisatorischen Informationen habe ich herausgefunden?
- Welche speziellen Gegebenheiten gilt es bei diesem Kunden zu beachten?
- Welche Punkte konnte ich nicht klären, bzw. bedürfen einer weiteren Klärung?
Immer wieder gibt es Menschen, die sich an Dinge erinnern, wenn man sie nett danach fragt. Finden Sie heraus, wer bei der Einführung dabei war und wer von ihnen noch im Unternehmen beschäftigt ist, indem Sie z. B. alte Projektprotokolle lesen, Organigramme betrachten oder einfach die Kollegen fragen. Vielleicht sind die betreffenden Personen noch in der Firma – nur in einer anderen Abteilung oder in einer anderen Rolle.
Und denken Sie daran: Seien Sie freundlich zu diesen Mitarbeitern – sie werden Ihnen dann sicher gerne weiterhelfen! Sollten Sie diesen jedoch "dumm kommen", so werden Sie im besten Fall ignoriert, wenn nicht sogar an Ihrer weiteren Arbeit gehindert.
Schritt 4: System stabilisieren
Bevor Sie das System modifizieren, sollten Sie es stabilisieren. Was nützt Ihnen eine tolle neue Programmfunktion, wenn Sie diese nicht im Produktivbetrieb einsetzen können, da das alte System ausgefallen ist?
Hilfreiche Fragen:
- Kann das System virtualisiert werden?
- Ist Spezialhardware nötig? Kann diese ggf. gebraucht beschafft werden?
- Läuft das System vielleicht auch auf anderer Hardware?
Coma Scale
Wichtig dabei ist, zu erkennen, was zuerst stabilisiert werden muss. Ein einfaches Hilfsmittel um kritische Teile zu identifizieren ist die Software Coma Scale [6]. Im Rettungsdienst dient die "Glasgow-Coma-Scale"[7] zur einfachen, schnellen Bewertung von Notfallpatienten. Das gleiche Prinzip wird auch bei der Software Coma Scale verwendet.
Versuchen Sie zusammen mit der Fachabteilung die unten stehenden Fragen zu beantworten. Die Formulierungen sind dabei absichtlich so gewählt, dass auch Nicht-ITler sie verstehen. Nach der Auswertung sollte allen Beteiligten bewusst werden, in welchem Zustand sich ihr System befindet und welche Teile zuerst stabilisiert werden sollten.
Natürlich decken diese Fragen nicht alle Probleme der Software ab. Sie werden jedoch erstaunt sein, wie wenige, auch aktuelle Systeme, die vollen 12 Punkte erreichen, obwohl es sich dabei um Basisanforderungen handelt.
Software-Coma-Scale Version 1.4
| Frage | Punkte |
|---|---|
| Aktuelle Sourcen vollständig vorhanden und übersetzbar | 2 |
| Sourcen unvollständig / nicht übersetzbar | 1 |
| Sourcen nicht vorhanden | |
| Administrator-Zugriff zum Server | 2 |
| Benutzer-Zugriff zum Server | 1 |
| Kein Zugriff zum Server | |
| Entwicklerteam der Anwendung im Projekt | 2 |
| Entwicklerteam der Anwendung im Zugriff | 1 |
| Entwickler nicht mehr aufzutreiben | |
| Server hat aktuelle Hardware/Betriebssystem | 2 |
| Server/Betriebssystem nicht aktuell (kann aber beschafft werden) | 1 |
| Server/Betriebssystem nicht aktuell, neue Beschaffung nicht möglich | |
| Drittsoftware (Datenbanken, Libraries...) laufen in aktueller Version auf aktuellem Betriebssystem | 2 |
| Drittsoftware (Datenbanken, Libraries...) laufen auf aktuellem Betriebssystem | 1 |
| Drittsoftware (Datenbanken, Libraries...) läuft nicht auf aktuellem Betriebssystem | |
| Backup vorhanden – Wiederherstellung getestet | 2 |
| Backup vorhanden – Wiederherstellung nicht getestet | 1 |
| Kein Backup vorhanden |
Auswertung
| Punkte | Handlungsbedarf |
|---|---|
| 12 Punkte | Alles ok! |
| 6-11 Punkte | Hier besteht Handlungsbedarf, um im Fehlerfall vorbereitet zu sein. |
| 0-5 Punkte | Sofortiger akuter Handlungsbedarf, da in einem Fehlerfall nicht das Problem behoben werden kann, sondern erst aufwändige Vorarbeiten erledigt werden müssen. Das System ist akut gefährdet. |
Stabilisierung auf der Seite der Mitarbeiter
Das Ziel der Stabilisierung ist also das Aufrechterhalten der Geschäftsabläufe.
- Geben Sie rechtzeitig bekannt, wann eine technische Veränderung bevorsteht.
- Zeigen Sie frühzeitig auf, mit welchen Neuerungen bei der Bedienung zu rechnen ist.
- Bitten Sie die Mitarbeiter um Unterstützung beim Testen und heißen Sie Beschwerden als wichtige Informationsquelle willkommen.
- Geben Sie den Leuten von Anfang bis Ende das Gefühl, dass sie ein wichtiger Faktor dafür sind, ob dieser Retrofit in deren Sinne erfolgreich sein kann oder nicht und dass Sie ihre Hilfe brauchen.
Schritt 5: Testsysteme aufbauen
In der modernen Softwareentwicklung ist es selbstverständlich, dass man getrennte Entwicklungs-, Test- und Produktivsysteme hat. Diese durchaus legitime Anforderung ist schwerer umzusetzen, als man denkt. Systeme, wie die in unserem Beispiel, sind oft seit Jahren nicht betreut worden. Wären sie betreut gewesen, so wären Sie jetzt nicht hier!
Um ein Testsystem aufzubauen, stellen Sie sich zunächst folgende Fragen:
- Welche Hardware wird benötigt?
- Welche Teile des Systems sind zu testen?
- Welche 3rd-Party-Software wird benötigt?
- Haben wir die Lizenzen?
- Welche Informationen sollten Mock-ups liefern (positive und negative Fälle berücksichtigen)?
- Wie kann das Verhalten vom Referenzsystem mit dem Verhalten des aktuellen Systems verglichen werden?
Erst, wenn diese Fragen beantwortet sind, können Sie anfangen, ein Testsystem aufzubauen. Hierbei ist Kreativität gefordert!
Beispiel: Da die alte Hardware eines AIX-Servers nicht mehr zu beschaffen war, "erweiterten" wir die Produktivserver um Plattenplatz, welcher von einem alten PC mit Linux per NFS zur Verfügung gestellt wurde (s. oben).
Ein Testsystem aufzubauen wird in der Regel einfacher, wenn x86-kompatible Hardware eingesetzt wird, weil die produktive Hardware virtualisiert werden kann. Vorsicht: Ändern Sie die IP-Adressen/Namen des Testsystems, um eine Kommunikation des Testsystems mit dem Produktivsystem zu vermeiden. Wir erinnern uns an ein Beispiel, bei dem im Produktivsystem nur noch jeder zweite Datensatz über die Schnittstelle gemeldet wurde, weil das Testsystem die anderen Aufträge abgegriffen hatte!
Hilfreiche Fragen
Wichtig ist auch hier, die eigenen Grenzen zu kennen. Niemand kann alles wissen und gerade in solch einer unklaren Situation ist der Kontakt zu anderen enorm wichtig. Fragen Sie sich daher:
- Wann brauche ich Unterstützung?
- Wen brauche ich als Unterstützung?
- Wie erhalte ich die Unterstützung von diesen Personen?
- Wie finde ich überhaupt heraus, was wichtig zu testen ist?
- Was brauchen die Leute, um hier fleißig mit zu testen?
- Wie erreiche ich, dass der Kunde diesen Weg, der umständlich zu sein scheint, mitgeht und bezahlt?
Schritt 6: Sollzustand definieren
Das Ziel in diesem Schritt ist es, ein klares Bild davon zu bekommen, wie das System aussehen soll, wenn der Retrofit fertig sein wird. Vergessen Sie dabei alle technischen Zwänge und konzentrieren Sie sich stattdessen auf die Wünsche und Bedürfnisse der unterschiedlichen Stakeholder.
Anforderungen und Wünsche
Bei der Informationsbeschaffung haben Sie wahrscheinlich viel über die Bedürfnisse und Wünsche der aktuellen Anwender und anderer Beteiligter gelernt. Jede Beschwerde über das alte System ist gleichzeitig ein noch schlecht formulierter Wunsch an den Retrofit. Versuchen Sie, diese Wünsche zu erkennen oder fragen Sie gezielt danach, z. B. mit der oft hilfreichen Frage: "Was brauchen Sie stattdessen?" Seien Sie allerdings auch transparent, was die Rahmenbedingungen (z. B. Budgetvorgaben) betrifft, damit die Erwartungen diese nicht übersteigen und dann am Ende enttäuscht werden. Fragen Sie eventuell noch nach, welche Konsequenzen es hätte, wenn bestimmte Wünsche nicht erfüllt würden.
Hilfreiche Fragen
- Wer wird mit dem System später arbeiten?
- Was will derjenige damit (möglicherweise anders) machen?
- Was brauchen diese Menschen, um mit dem System gut arbeiten zu können?
- Haben Sie alle relevanten Personen persönlich nach Ihren Bedürfnissen und Anwendungsfeldern gefragt?
- Was hätten sie gerne beim neuen System und welchen Nutzen hat das?
- Was ist die minimale System-Anforderung, die erfüllt werden muss?
- Was wäre ein idealer Zustand?
- Welche Besonderheiten müssen wir berücksichtigen?
- Welche Service-Level-Agreements muss das neue System garantieren?
- Welche geschäftsorientierten KPIs gibt es? (Wenn es keine gibt, dann definieren Sie welche, damit Sie zeigen können, dass das retrofitted-System mindestens genauso gut ist, wie das alte.)
- Welche Hard- und Software-Technologien sollte das System nutzen?
- Welche Quality-of-Service-Charakteristiken müssen erreicht werden?
Schritt 7: Zwischenziele definieren und umsetzen
Erst jetzt wird das System wirklich verändert. Planen Sie die Veränderungen immer von zwei Seiten: Definieren Sie, was getan werden muss, um das jeweilige Zwischenziel zu erreichen und beschreiben Sie mögliche Fehlerszenarien sowie Lösungen für den Fall, dass etwas schief geht. Erinnern Sie sich bitte daran, dass es hier um Hochverfügbarkeitslösungen geht.
- Schätzen Sie den Arbeitsaufwand großzügig ein, damit Sie Zeitdruck vermeiden und auf unvorhergesehene Zwischenfälle reagieren können.
- Zerstören Sie, wenn möglich, nichts, damit Sie jederzeit wieder einen Schritt zurück gehen können.
- Bauen Sie auf alledem auf, was schon funktioniert. Damit gewinnen Sie Zeit und Sicherheit beim Retrofit. Es muss nicht immer alles neu erfunden werden.
- Antizipieren Sie Probleme und definieren Sie entsprechende Vorgehen dazu.
- Nutzen Sie die Mitarbeiter Ihres Kunden aktiv als Tester. Informieren Sie sie über jeden Schritt im Voraus, sodass das geänderte System schnell und intensiv beobachtet werden kann. Machen Sie es den Mitarbeitern so leicht wie möglich Ihnen Rückmeldungen zu geben, z. B. "Morgen um 10:00 Uhr werden wir den Server X ersetzen. Bitte geben Sie uns gleich persönlich oder telefonisch (Tel: 0123 456789) Bescheid, wenn Sie Probleme entdecken sollten."
- Planen Sie nicht nur wie Sie ein Feature in Betrieb nehmen, sondern auch, wie Sie es in der zur Verfügung stehenden Zeit wieder deaktivieren können.
Beispiel: Da das Umstellen einer IP-Adresse bei einem alten Unix-System das Übersetzen des Betriebssystem-Kernels zur Folge hatte, war ein kleines Zwischenziel das Umstellen der IP-Adresse, welches dann in einer Frühstückspause umgesetzt wurde.
Und noch einmal: Seien Sie kreativ! Egal wie viel Arbeit Sie vorher in das Zwischenziel stecken – wichtig ist, dass Sie immer ein lauffähiges System haben. Schließlich sprechen wir hier nicht von einem Hobby-System, sondern von einem System, welches bei Ausfall einen immensen finanziellen Schaden anrichten kann. Bei einem Hochregallager können dies z. B. schnell mehrere hunderttausend Euro pro Schicht sein!
Zusammenfassung
Ein Retrofit ist eine spannende Aufgabe. Zuerst gilt es, wie ein Detektiv beim Lösen eines Kriminalfalls den Tatort sorgfältig zu untersuchen, alle relevanten Beteiligten zu identifizieren und wertschätzend zu befragen. Dabei hören Sie auch Ungesagtes zwischen den Zeilen und sind geschickt bei Ihren Ermittlungen, um möglichst niemandem auf die Füße zu treten. Danach sind sämtliche Fakten zu sichten und zu ordnen. Durch ausgeklügelte Kombinationen entdecken Sie Ungereimtheiten und Lücken, um anschließend zu hilfreichen Schlüssen zu kommen.
Am Ende lächeln Sie zufrieden in die Kamera.
Und dann wechseln Sie den Job und führen wie ein Chirurg eine heikle Organtransplantation bei Ihrem Patienten durch. Während Sie operieren, achten Sie peinlich genau auf die Erhaltung sämtlicher Vitalfunktionen. Am Ende soll Ihr Patient sein Leben schließlich ohne Einschränkungen und mit möglichst höherer Lebensqualität als zuvor fortsetzen können.
Wenn am Ende der Kunde zufrieden ist, sollten Sie es Columbo, Sherlock und Co gleichtun. Zünden Sie Ihre wohlverdiente Pfeife oder Zigarre an (wählen Sie hier bitte eine für Sie erstrebenswerte Belohnung) und lächeln Sie zufrieden in die Kamera.
- T. Ronzon: Software Retrofit in High-Availability Systems: When Uptime Matters, Ausgabe 2/2016, IEEE Software
- D. Rock: SCARF Model - Influencing Others with Dr David Rock, 8. Aug 2010.
SCARF: Die fünf Grundbedürfnisse des Menschen, S. 58-62, iX Kompakt 4/2015 – Agiles IT-Projektmanagement, Heise Medien Gmbh & Co. KG, Oktober 2015 - D. Rock: Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, HarperBusiness, Okt 2009.
- 2c Tipp: Telnet - das unbekannte Schweizer Messer
- A. Binstock: Mind Maps: The Poor Man's Design Tool, Dr. Dobbs October 02, 2012
- Glasgow-Coma-Scale
- Online-Version der Software-Coma-Scale
T. Ronzon: Tool Talk: Es ist tot Jim! - Vorstellung der Software-Coma-Scale (SCS) zur schnellen Beurteilung von Systemen, JavaSPEKTRUM, Ausgabe 05/2015
Möller, T. Ronzon, H. Schwentner: Architekturarchäologie: Altsysteme durch schrittweise Untersuchungen verstehen, iX Developer 01/2017 Sonderheft, S.48,
SE-Radio Episode 148: Software Archaeology with Dave Thomas
G. Robles, J. M. Gonzalez-Barahona, J. J. Merelo: Beyond source code: The importance of other artifacts in software development (a case study), Volume 79, Issue 9, September 2006, Pages 1233–1248
S. W. Ambler: Agile Legacy System Analysis and Integration Modeling, 2012,
