Maßgeschneiderte Anbindung oder standardisierte API-Integration: Worin besteht der Unterschied?

“Das wird eine Maßanfertigung.”

Wer sich schon länger mit Software-Integrationen beschäftigt, hat diesen Satz wahrscheinlich schon öfter gehört.

Traditionell war die Entwicklung maßgeschneiderter Lösungen oft mit einem aufwendigen Prozess verbunden. Berater erstellten Prozessablaufpläne, Entwickler bauten eine spezifische Schnittstelle auf, und irgendwo zwischen den Anwendungen wurden eine externe Datenbank, Skripte, BPA-Tools und andere technische Komponenten eingebunden.

Das kann durchaus gut funktionieren.

Das bedeutet jedoch auch, dass für jede neue Anbindung ein hoher Aufwand an Analyse-, Beratungs- und Entwicklungsstunden erforderlich ist.

Und es ergibt sich ein zweites Problem: Jede maßgeschneiderte Kupplung ist eine einzigartige technische Lösung, die anschließend über Jahre hinweg gewartet werden muss.

Bei Sense-Cloud haben wir daher bereits vor geraumer Zeit aufgehört, Integrationen auf diese Weise zu entwickeln.

Nicht, weil keine maßgeschneiderten Lösungen mehr erforderlich wären.

Da wir jedoch der Meinung sind, dass Sie technische Probleme, die Sie bereits gelöst haben, nicht immer wieder neu lösen müssen.

 

Das Problem bei der herkömmlichen Maßanfertigung

Angenommen, zwei Anwendungen müssen miteinander kommunizieren.

Bei einem traditionellen maßgeschneiderten Projekt wird zunächst untersucht, wie beide Systeme technisch umgesetzt werden können. Anschließend wird festgelegt, wo Daten gespeichert werden, welche Werkzeuge erforderlich sind, wie Daten verarbeitet werden und welche Skripte oder Prozesse dafür entwickelt werden müssen.

Anschließend wird die Verbindung hergestellt.

Beim nächsten Kunden beginnt ein Großteil dieses Prozesses von Neuem.

Das kostet nicht nur Zeit. Es führt auch dazu, dass sich in Unternehmen im Laufe der Zeit eine Landschaft aus verschiedenen maßgeschneiderten Schnittstellen, Datenbanken, Skripten und BPA-Prozessen entwickeln kann.

Jede Kupplung hat ihre eigene technische Geschichte.

Und oft auch sein eigener Entwickler oder Berater, der genau weiß, warum bestimmte Entscheidungen damals getroffen wurden.

 

Was geschieht, wenn dieses Wissen verloren geht?

Hier besteht ein Risiko, das beim Kauf einer Kupplung nicht immer erkennbar ist.

Maßgeschneiderte Lösungen sind nicht zwangsläufig schlecht dokumentiert. Allerdings sind stark kundenspezifische Lösungen oft nicht universell aufgebaut, und die Dokumentation hält in der Praxis nicht immer vollständig mit den im Laufe der Jahre vorgenommenen Änderungen Schritt.

Warum ist diese Datenbank dazwischen?

Warum wird ein bestimmtes Feld zunächst konvertiert?

Warum wird dieses Skript jede Nacht ausgeführt?

Welche Prozesse hängen voneinander ab?

Und was passiert, wenn ein Bauteil ausfällt?

Wenn der ursprüngliche Berater oder Entwickler nicht mehr zur Verfügung steht, muss sich ein Nachfolger zunächst in eine Lösung einarbeiten, die jemand anderes vor Jahren entwickelt hat.

Manchmal kann eine gute Dokumentation dabei helfen.

Manchmal muss jedoch ein erheblicher Teil der Funktionsweise neu untersucht werden.

Und wenn ein Austausch zu kostspielig oder zu riskant erscheint, entsteht ein anderes Muster: Auf der bestehenden Technik wird kontinuierlich weiter aufgebaut.

Ein zusätzliches Skript. Eine neue Tabelle. Eine weitere Übergangslösung. Eine Anpassung im BPA-Tooling.

Jede einzelne Änderung mag zwar sinnvoll sein, doch das Gesamtbild wird dadurch immer schwerer zu verstehen und zu verwalten.

 

Maßarbeit ist nicht das Problem

Unternehmen arbeiten nun einmal unterschiedlich.

Jedes Unternehmen bearbeitet einen Auftrag anders als ein anderes. Ein WMS kann bei Unternehmen A eine andere Rolle spielen als bei Unternehmen B. Und auch Exact kann je nach Unternehmen unterschiedlich eingerichtet sein.

Das möchten wir keineswegs standardisieren.

Der Geschäftsprozess ist gerade der Bereich, in dem maßgeschneiderte Lösungen einen Mehrwert schaffen.

Die entscheidende Frage lautet daher:

Welcher Teil einer Schnittstelle ist tatsächlich kundenspezifisch, und welchen Teil können wir einmalig ordnungsgemäß entwickeln und anschließend wiederverwenden?

Diese Unterscheidung bildet die Grundlage unseres Ansatzes.

 

Clickker vereinheitlicht den Zugriff auf Exact

Auf der Exact-Seite haben wir das Problem wie folgt gelöst: Clickker® | Die dedizierte API für Exact.

Clickker bietet API-Zugriff auf Exact Online, Exact Globe, Globe+ und Exact Financials.

In On-Premise-Exact-Umgebungen läuft Clickker auf dem Server, auf dem Exact installiert ist. Es ist also nicht erforderlich, zunächst eine externe Datenbank zwischen Exact und der anderen Anwendung einzurichten, in die Exact-Daten kopiert oder synchronisiert werden.

Die Verbindung kann direkt eingerichtet werden:

Externe Anwendung ↔ Clickker ↔ Exact

Dadurch müssen wir den technischen Zugriff auf Exact nicht für jede neue Anbindung neu entwickeln.

Auf der anderen Seite der Verbindung befindet sich natürlich nach wie vor eine andere Anwendung.

Dafür wenden wir ein ähnliches Prinzip an.

 

Wiederverwendbare Konnektivitätsblöcke

Im Inneren Clickker Automation Suite (CAS) können wir für externe Anwendungen Konnektivitätsblöcke entwickeln.

Ein solcher Konnektivitätsblock enthält standardisierte Bausteine für die verfügbaren Funktionen einer Anwendung.

Denken Sie beispielsweise an Funktionen für:

• Kunden;
• Artikel;
• Bestellungen;
• Lagerbestand;
• Status.

Sobald diese technische Anbindung einmal eingerichtet ist, können wir die Bausteine bei einer späteren Integration mit derselben Anwendung wiederverwenden.

Dann müssen wir nicht erneut herausfinden, wie wir eine Bestellung abrufen oder wie wir auf Artikelinformationen zugreifen.

Diese technische Grundlage ist bereits vorhanden.

Und das verändert grundlegend die Art und Weise, wie wir eine Integration aufbauen können.

 

Die Maßanfertigung verlagert sich in Richtung des Flusses

Denn selbst bei zwei identischen Anwendungen können sich die Geschäftsprozesse völlig unterscheiden.

Eine Organisation möchte beispielsweise:

Bestellung erhalten → prüfen → in Exact bearbeiten → Bestätigung zurücksenden

Während eine andere Organisation Folgendes benötigt:

Auftrag erhalten → Debitor prüfen → Artikeldaten abrufen → Daten ergänzen → in Exact bearbeiten → Status zurückmelden

Die technischen Bausteine können weitgehend identisch sein.

Aber die Ablauf unterscheidet sich.

Dort gehört die maßgeschneiderte Lösung unserer Meinung nach hin.

Nicht darin, dieselben Systeme jedes Mal aufs Neue technisch zu erschließen, sondern darin, festzulegen was zwischen diesen Systemen geschehen muss.

 

Vom maßgeschneiderten Code zu wiederverwendbaren Bausteinen

Damit verändert sich das Integrationsprojekt.

Traditionell kann der Prozess grob gesagt wie folgt aussehen:

Kundenanfrage → Beratung → technische Analyse → Datenbank und Tools → maßgeschneiderte Entwicklung → Tests → Anbindung

Unser Ansatz verlagert den Schwerpunkt auf Folgendes:

Kundenanforderung → Prozessanalyse → bestehende Konnektivitätsblockaden → kundenspezifischer Ablauf in CAS → Tests → Anbindung

Selbstverständlich ist weiterhin eine Analyse erforderlich.

Und manchmal müssen neue Funktionen entwickelt werden.

Wenn wir jedoch etwas Neues entwickeln, prüfen wir sofort, ob wir es so gestalten können, dass es auch bei einer späteren Implementierung wiederverwendet werden kann.

Dadurch wächst nicht nur die Lösung für eine einzelne Organisation.

Unsere Bibliothek mit wiederverwendbaren Konnektivitätslösungen wächst mit.

 

Geringere Abhängigkeit von einzelnen Beratern

Darin liegt für uns ein wichtiger Vorteil.

Bei der traditionellen Maßanfertigung kann es vorkommen, dass viel technisches Wissen letztendlich nur einer begrenzten Anzahl von Personen zur Verfügung steht.

Bei einem plattformorientierten Ansatz versuchen wir, dieses Wissen so weit wie möglich in standardisierte Komponenten und wiederverwendbare Bausteine unterzubringen.

Ein Entwickler muss nicht erneut herausfinden, wie Exact technisch bereitgestellt wird.

Dafür gibt es Clickker.

Falls für die andere Anwendung bereits ein Konnektivitätsblock vorhanden ist, muss auch diese technische Konnektivität nicht erneut von Grund auf entwickelt werden.

Und die spezifische Geschäftslogik wird innerhalb von CAS als erkennbarer Ablauf eingerichtet.

Das Wissen verlagert sich damit von:

“Wir müssen die Person finden, die diese Verbindung damals hergestellt hat.”

an:

“Dies sind die Standardbausteine, und dies ist der Ablauf, der für diese Organisation eingerichtet wurde.”

Dadurch lassen sich Lösungen besser übertragen, warten und wiederverwenden.

 

Keine Sammlung einzelner maßgeschneiderter Lösungen

Letztendlich soll verhindert werden, dass sich im Umfeld von Exact im Laufe der Zeit eine technische Landschaft aus einzelnen Datenbanken, Skripten, BPA-Prozessen und individuellen, maßgeschneiderten Anbindungen entwickelt.

Denn jede zusätzliche technische Komponente muss ebenfalls verwaltet werden.

Und jede einzigartige Lösung schafft neues Wissen, das irgendwo festgehalten und gepflegt werden muss.

Wir entscheiden uns daher für eine andere Architektur.

• Clickker® | Die dedizierte API für Exact gewährleistet den standardisierten Zugang zu Exact.
• Konnektivitätsblöcke standardisieren die technische Kommunikation mit anderen Anwendungen.
• Clickker Automation Suite nutzt diese Bausteine, um die gewünschten Prozesse und die Geschäftslogik in Abläufen zu gestalten.

Und das Monitoring-Add-on Watcher kann anschließend zur Überwachung der Funktionsweise dieser Integrationen und Abläufe eingesetzt werden.

Auf diese Weise entsteht keine Ansammlung einzelner Integrationsprojekte, sondern eine Architektur, auf der weiter aufgebaut werden kann.

 

Also: Standardlösung oder maßgeschneiderte Lösung?

Unserer Meinung nach ist das eigentlich nicht die richtige Entscheidung.

Eine vollständig standardisierte Anbindung kann für Unternehmen mit abweichenden Prozessen zu starr sein.

Jede Integration jedoch von Grund auf als vollständig maßgeschneidertes Projekt zu entwickeln, ist das andere Extrem.

Aus diesem Grund entscheiden wir uns für:

Das, was gleich ist, standardisieren. Das, was anders ist, konfigurieren. Das entwickeln, was wirklich neu ist. Und das, was wir entwickeln, so weit wie möglich wiederverwendbar machen.

Das Ergebnis ist nach wie vor eine Schnittstelle, die auf den spezifischen Geschäftsprozess des Kunden zugeschnitten ist.

Allerdings muss dafür nicht jedes Mal aufs Neue die gesamte technische Grundlage geschaffen werden.

Das ist für uns der Unterschied zwischen der Entwicklung maßgeschneiderter Software und der Bereitstellung maßgeschneiderter Lösungen mithilfe einer wiederverwendbaren Integrationsplattform.