Risiko-Minimierung bei der Anpassung von CRM, ERP und CMS

Wenn man regelmäßig das „Vergnügen“ hat, mit angeblich anpassbaren Systemen wie CRM, CMS, ERP und Ähnlichen zu tun zu haben, merkt man bald, dass deren Anpassung gar nicht so einfach ist. Allzu oft wird das System durch die Anpassungen „upgrade-resistent“, oder wenigstens fast. Das lässt sich zwar in den meisten Fällen nicht ganz vermeiden, doch kann man einiges tun, um sicherzustellen, dass die Änderungen möglichst wenig Schwierigkeiten bereiten, wenn das Basissystem aktualisiert werden muss.

Das Hauptproblem ist die Vermischung von eigenem Code und Systemcode. Diese geschieht durch verschiedene Vorgänge, die im Folgenden näher betrachtet werden sollen:

• Modifikation von Systemdateien und direkte Bearbeitung von eingebauten Funktionen. Dies ist der schlimmste Fehler, den man überhaupt begehen kann.
• Systemdateien kopieren und die eingebauten Funktionen bearbeiten. Das ist fast so schlimm wie die Dateien direkt zu bearbeiten, weil man immer noch das gleiche Problem hat: Bei Upgrades muss man herausfinden, welche Änderungen man vorgenommen hat und welche Änderungen das Upgrade bewirkt, um dann die Änderungen auf die neuen Dateien zu übertragen. Man hat dabei nur eine geringfügige Trennung zwischen seiner eigenen Arbeit und dem Systemcode gewonnen.
• Selbst erstellte Dateien in der bestehenden Verzeichnisstruktur platzieren. Sofern einem das System nicht ein spezielles Verzeichnis für seine Änderungen bereitstellt, kann man ein enormes Chaos auslösen, wenn man die vorhandene Verzeichnisstruktur nutzt, der Anbieter diese aber mit dem nächsten Release umorganisiert.

Die beste Möglichkeit, mit diesen Problemen umzugehen, besteht darin, eigene Klassen zu erstellen, die entweder die Standardklassen erben oder Teilklassen sind, je nach Sprache und in Abhängigkeit davon, wie der Originalcode geschrieben ist. So kann man Funktionen auf sehr gezielte und eingeschränkte Weise außer Kraft setzen, und falls sich der zugrunde liegende Code einmal ändern sollte, ist der potenzielle Schaden minimal. Man sollte versuchen, wenn möglich Funktionen hinzuzufügen statt sie zu ändern, um zukünftige Konflikte zu vermeiden. So lassen sich schnell und einfach Verweise auf seinen Code finden. Zudem sollte man stets das vom Anbieter spezifizierte Verzeichnis für eigenen Code verwenden, und wenn der Anbieter keines vorsieht, sollte man selbst eines anlegen, das 100-prozentig von der vorhandenen Verzeichnisstruktur getrennt ist.

Das zweite große Problem an der Art und Weise, wie man seine Änderungen vornimmt, besteht im Speichern eigener Einstellungen. Die meisten Systeme speichern Einstellungen in einer Datenbank und nutzen eine Basiskonfiguration zum Starten der Datenbankverbindung (etwa web.config in ASP.NET). Es gibt zwar keine grundsätzlich optimale Weise, um eigene Einstellungen zu speichern, aber es gibt doch eine Reihe von Möglichkeiten.

Man kann web.config (oder die Entsprechung im eigenen System) auch für die Einstellungen nutzen. Der Nachteil von dessen Einfachheit und eingebauten Tools ist jedoch, dass die eigenen Einstellungen außerhalb des Administrationssystems des Systems verwaltet werden. Man wird außerdem zusätzliche Schwierigkeiten bekommen, wenn man sie bei einem anderen System implementiert (oder von der Entwicklung zum Staging und zur Produktion übergeht), weil man die Einstellungen mit der vorhandenen Einstellungendatei zusammenführen muss. Alternativ lässt sich herausfinden, wie man mit der Datenbank des Systems arbeitet. Allerdings stellt nicht jedes System dies sauber dar. Wenn möglich, sollte man sich die Codebasis des Systems daraufhin anschauen, wie es auf Einstellungen zugreift und ob es eine Klasse oder Bibliothek dafür verwendet, um dann selbst zu versuchen diese zu verwenden. Das große Problem bei diesem Ansatz ist, dass möglicherweise kein sauberes Verfahren existiert, um seine Einstellungen in das System zu injizieren oder sie der Administrationskonsole hinzuzufügen. Wenn sich mit einer vernünftigen Lösung diese beiden Probleme beheben lassen, ist dies für gewöhnlich der bessere Ansatz. Doch das muss von Fall zu Fall entschieden werden.

Beim letzten großen Problembereich geht es um das Änderungsmanagement. Es wird fast immer einen Punkt geben, an dem man trotz aller Bemühungen eine dieser Regeln brechen muss. Zum Beispiel waren einmal bei Drupal die E-Mail-Versandroutinen auf Windows-Servern aufgrund von Unterschieden bei den Zeilenschaltzeichen und eines sehr strengen Mailservers unterbrochen. Hier gab es drei Möglichkeiten:

• Eine angepasste Mailroutine schreiben und jeden Verweis im System auf die neue Routine ändern.
• Die vorhandene Routine bearbeiten, um die Änderung zu integrieren.
• Eine eigene Routine schreiben und die vorhandene Routine so bearbeiten, dass sie einfach die eigene Version aufruft.

Die erste Möglichkeit wäre die schlechteste. Obwohl die Kernfunktionalität unberührt bleibt, müsste man doch ziemlich viel anderen Code bearbeiten. In diesem Fall fiel die Wahl auf die zweite Option, einfach deshalb, weil die Änderung so geringfügig war. Der Code wurde dann eindeutig mit Kommentaren gekennzeichnet, und in der Projektdokumentation wurde gut sichtbar der Hinweis vermerkt, den Patch zu portieren, falls der Fehler auch in zukünftigen Versionen von Drupal besteht.

Solche diese Dinge müssen unbedingt dokumentiert werden. Es ist hilfreich, wenn man eine Möglichkeit findet, um sich selbst (oder seinen Nachfolger) dazu zu zwingen, die Dokumentation zu lesen, etwa durch Ablage einer Read-only-Datei in einem Bereich, der bei einem Upgrade nicht überschrieben oder gelöscht wird. Man muss sicherstellen, dass alle vorgenommenen Änderungen am Code anhand der folgenden Informationen klar gekennzeichnet sind:

• wann die Änderung vorgenommen wurde
• in welcher Version die Anwendung vorlag, als die Änderung vorgenommen wurde
• warum die Änderung vorgenommen wurde
• eine kurze Übersicht über die Auswirkungen der Änderung auf das System

Diese Informationen können im Code selbst in Form eines Kommentars stehen oder in den Eincheckhinweisen. Wenn man sie in den Eincheckhinweisen ablegt, ist es entscheidend, dass jedes Einchecken nur eine Änderung darstellt.

Die Arbeit mit dieser Art von Systemen kann zwar mitunter einem Stich in ein Hornissennest ähneln, doch helfen diese Vorschläge hoffentlich, die Risiken so stark wie möglich einzudämmen.