Projekt-Ideen

Typ 2: Die Add-on-Anwendung

Viele Unternehmen sind recht zufrieden mit Ihrer großen Branchenlösung.

Bis auf die Stellen eben, wo man noch mehr Individualität bräuchte.

Weil man mit den Daten der Branchenlösung noch mehr machen möchte, was diese Anwendung aber nicht vorsieht, oder weil man weitere Daten hat, die damit in Verbindung stehen.

Der Hersteller der Branchenlösung ist normalerweise an Ihren individuellen Erweiterungswünschen wenig interessiert. Weil sein Konzept die möglichst große Anzahl möglichst gleicher Installationen ist.

Und auch um Schnittstellen zum Export der Daten bittet man oft lange und mühsam oder gar vergeblich.

Wenn man dann stattdessen mit Excel und ähnlichem loslegt, hat man ruckzuck dieselben Daten mehrfach erfasst und verwaltet, mit Unstimmigkeiten ohne Ende.

Die Lösung ist eine Add-on-Anwendung, die zwar die Daten noch einmal in einer eigenen Datenbank verwaltet. Aber sie nimmt sie aus einer Export-Schnittstelle der „großen“ Anwendung.

Auf die Export-Schnittstelle kann man auch verzichten, wenn das Datenmodell der Datenbank dokumentiert ist. Dann kann man im Normalfall auch guten Gewissens die Original-Datenbank lesen.

Beeinträchtigungen der fremden Anwendung durch höhere Serverlast und Transaktionssperren müssen natürlich ausgeschlossen sein!

Das gilt aber nur für das Lesen. Schreibende Zugriffe auf eine fremde Anwendung sind normalerweise als riskante „Hackerei“ anzusehen!

Ausnahme: Wenn die fremde Anwendung Import-Funktionalitäten vorsieht, ist es legitim, das wir darüber Daten aus unserer Add-on-Anwendung in das Hauptsystem zurückspielen.

Das habe ich schon mehrfach in Kundenprojekten umgesetzt.

Die Add-on-Anwendung übernimmt also in einem regelmäßigen Datentransfer die originalen Daten von der fremden Anwendung und füllt sie in ihre eigene Datenbank.

Dort kann man - ohne jede Beeinträchtigung der „großen“ Anwendung - so ziemlich alles damit machen: Verknüpfung mit zusätzlichen Daten, Aufbereitungen aller Art, komfortable Übersichten.