Anpassen aus dem Regal, seien Sie gewarnt

Vor einiger Zeit habe ich festgestellt, dass das C in COTS für Customize steht, also in Wirklichkeit Customize Off The Shelf (und nicht Commercial Off The Shelf). Die Prämisse bei COTS-Produkten ist, dass sie die Kosten für die Systementwicklung und die langfristigen Kosten für die betriebliche Wartung senken. Das klingt wie Musik für das Management und die Beschaffungsabteilungen. Die Realität kann anders aussehen. Die Erkenntnis, dass das C für Customize (Anpassen) steht, verdeutlicht eine der Tücken, derer sich die meisten Menschen bewusst sind: Der Umfang der Anpassungen, die erforderlich sind, damit ein COTS-Produkt in ein Unternehmen passt, kann enorm sein. Aber es gibt noch mehr Fallstricke und in diesem Blog werde ich einige davon hervorheben. Der erste Fallstrick ist, dass viele Beschaffungsabteilungen und das Management immer noch der Meinung sind, dass zu Beginn eines Projekts alles klar ist, wenn man eine ungefähre Vorstellung davon hat, welches Problem gelöst werden muss, und man relativ sicher ist, dass ein positiver Business Case erstellt werden kann. Um sich ein besseres Bild von den Kosten zu machen, werden Service-Integratoren kontaktiert, damit der Business Case erstellt werden kann. Es wird eine Präferenz für eine COTS-basierte Lösung geäußert und von da an konzentrieren sich die Diskussionen auf die Funktionen des COTS-Produkts, die Lizenzkosten und die Stundensätze für professionelle Dienstleistungen. Es wird kaum darauf geachtet, das zu lösende Problem genauer zu analysieren, die Kernanforderungen zu klären und festzustellen, ob ein COTS-Produkt die geeignete Lösung ist. Ein Echtzeit-ETL-Produkt kann z.B. Change Data Capture unterstützen, aber seine Verwendung würde eine wirklich enge Kopplung an das interne Datenmodell des Quellsystems schaffen und erfordert, dass das ETL-Produkt versteht, wie dieses Datenmodell zu interpretieren ist. Obwohl dies technisch möglich ist, ist es aus architektonischer Sicht definitiv nicht zu bevorzugen. Die Auswahl eines COTS-Produkts ist eine Entscheidung, die nicht leichtfertig getroffen werden kann, da sie den Rahmen für Architektur und Design vorgibt und eine Reihe von Konsequenzen mit sich bringt. Diese Entscheidung ist nur schwer rückgängig zu machen. Um diese Entscheidung zu treffen, sollten Sie das Problem, das Sie zu lösen versuchen, die geltenden Einschränkungen, die Vor- und Nachteile des Produkts usw. verstehen. Proof of Concepts liefern wertvolle Informationen und zwingen Sie dazu, wirklich über das Problem nachzudenken, das Sie lösen wollen. Fach- und Technikexperten sollten in der Lage sein, zu entscheiden, welche Anforderungen (sowohl funktionale als auch nicht-funktionale) in den Proof of Concept aufgenommen werden sollen. Verlassen Sie sich nicht allein auf die Experten des Service-Integrators oder COTS-Anbieters, sondern stellen Sie sicher, dass Sie einige neutrale Experten hinzuziehen. Sollten Sie für die Durchführung eines solchen Proof of Concept bezahlen? Definitiv nicht für die Lizenzen, aber für die aufgewendeten Stunden schon. Die Kosten für einen Proof of Concept sollten nur einen Bruchteil der Gesamtkosten ausmachen und Sie können sich eine Menge Geld sparen, wenn Sie einen ernsthaften Proof of Concept durchführen und daraus lernen. Denken Sie daran: Sie bekommen das, wofür Sie bezahlen. Wenn die Entscheidung für ein bestimmtes COTS-Produkt gefallen ist, kommen die nächsten Fallstricke ins Spiel. Auch wenn das Produkt so konzipiert ist, dass es von der Stange funktioniert, muss es immer noch ein bisschen konfiguriert werden. Meistens erweist sich dies als ein erheblicher Aufwand. Jetzt beginnt das Team, sich mit den Anforderungen zu beschäftigen und sie zu verstehen. Einige lassen sich mit den COTS-Produkten leicht umsetzen, andere nicht, und da fangen die Probleme an. Wenn Sie das Gefühl haben, ein Quadrat durch ein rundes Loch zu schieben, wissen Sie, dass Sie das falsche Werkzeug für das vorliegende Problem haben. Die Entscheidung, ein COTS-Produkt (für alles) nicht zu verwenden, ist oft ein politisch heikles Thema. Gehen Sie daher offen damit um und halten Sie sich immer die Option offen, andere Tools zu verwenden, wenn das COTS-Produkt zu einem Hindernis wird. Das Ziel ist nicht die Verwendung des COTS-Produkts XYZ, sondern die Lösung des jeweiligen Geschäftsproblems.Der nächste Fallstrick betrifft die Verwendung von Entwicklungsmethoden. Wenn ein erheblicher Konfigurationsaufwand und/oder benutzerdefinierte Kodierung erforderlich ist, wird es zu einem Entwicklungsprojekt, anstatt einfach ein COTS-Produkt einzusetzen. Wenn es sich um ein Entwicklungsprojekt handelt, sollte es auch als solches behandelt werden, und es müssen bewährte Praktiken wie Versions- und Release-Management, kontinuierliche Integration, automatisierte Tests, automatisierte Bereitstellung usw. angewendet werden. Diese Praktiken tragen zur Qualität des Prozesses bei und ermöglichen es den Teams, Probleme frühzeitig zu erkennen und zu beheben, anstatt sie erst nach dem Go-Live zu beheben. Werden diese Praktiken ignoriert? Ja, zumindest habe ich das schon erlebt. Die Frage ist: "Warum?". Ich vermute, dass eine Ursache die Mischung der Fähigkeiten im Team ist, oder eigentlich das Fehlen dieser Fähigkeiten. Wenn ein Projekt auf der Grundlage eines COTS-Produkts durchgeführt wird, besteht die natürliche Tendenz, nach Teammitgliedern zu suchen, die für dieses Produkt ausgebildet sind. Obwohl sie das COTS-Produkt in- und auswendig kennen, haben sie möglicherweise keinen Software-Engineering-Hintergrund und/oder sind nicht in der Software-Engineering-Community verankert. Sie sind sich dieser Praktiken einfach nicht bewusst. Und selbst wenn sie von der Existenz dieser Praktiken wissen, wissen sie vielleicht nicht, wie sie sie anwenden sollen. Aus diesen Gründen ist es wichtig, dass das Team aus verschiedenen Qualifikationen besteht. Sicherlich brauchen Sie Experten für COTS-Produkte, aber Sie brauchen auch Allround-Softwareingenieure, einen DBA, Betriebssystemexperten usw. Sie sind vielleicht nicht während des gesamten Projekts Vollzeit-Teammitglieder, aber sie müssen kurzfristig verfügbar sein und über den aktuellen Stand des Projekts informiert bleiben. Ein weiterer Grund, warum diese Praktiken nicht angewendet werden, können Einschränkungen des COTS-Produkts sein. Wenn das COTS-Produkt selbst keine Versionsverwaltung unterstützt und eine Integration mit einem bekannten Versionsverwaltungssystem wie Subversion nicht möglich ist, müssen Sie eine Alternative finden. Dies kann einige manuelle Exporte usw. beinhalten, aber die Tatsache, dass dies nicht von Haus aus unterstützt wird, bedeutet nicht, dass diese Praktiken ohne negative Folgen übersprungen werden können. Ein dritter Grund, ein gemischtes Team zu haben, ist die Vermeidung des Golden-Hammer-Syndroms. Wenn das Team nur aus Experten für COTS-Produkte besteht, werden sie versuchen, jedes Problem mit dem COTS-Produkt zu lösen. Selbst dann, wenn ein bisschen Skripting oder die Verwendung von Standard-Befehlszeilen-Tools den Trick viel schneller und mit weniger Aufwand erledigen würde. Die Generierung von Testdaten ist ein Beispiel dafür. Normalerweise reicht ein kleines Skript aus, um Testdaten zu generieren. Ich habe jedoch schon Situationen erlebt, in denen komplette ETL-Workflows im COTS-Produkt entwickelt wurden, um Testdaten zu erzeugen. Das war mit erheblichem Aufwand verbunden und die Geschwindigkeit, mit der die Daten erzeugt wurden, war gering (was zu einem Problem wurde, als die Datenbank mit größeren Datenmengen befüllt werden musste). Ein Allround-Software-Ingenieur muss in der Lage sein, diese Testdaten auf viel effizientere Weise zu generieren. Dies sind einige Fallstricke und Vorschläge, wie man sie umgehen kann, auf die ich gestoßen bin. Sie können vermieden werden, indem man die richtige Mischung von Fähigkeiten einsetzt und sich auf das zu lösende Problem konzentriert, anstatt sich auf COTS-Produkteigenschaften zu konzentrieren. Welche Fallstricke haben Sie gesehen? Wie können wir sie verhindern?