Hunderte Systeme integrieren: Wie hello again GmbH mit kleinen, wiederverwendbaren Bausteinen seine Loyalty-Plattform skaliert

Session-Kontext: „Integrating hundreds of different systems“ mit Markus Gasplmayr (hello again GmbH)

In „Integrating hundreds of different systems“ zeigt Markus Gasplmayr, Backend-Entwickler bei hello again GmbH, wie sein Team eine Loyalty-Plattform so konstruiert, dass sie sich mit Hunderten unterschiedlichster Dritt-Systeme verbinden lässt – von Kassensystemen über Online-Shops bis hin zu Buchungs- und CRM-Lösungen. Der Anspruch: maximale Wirkung für die Endkundschaft der Auftraggeber, ohne in einer Flut an individuellen Integrationen zu versinken.

Die Herausforderung ist offensichtlich: hello again liefert nicht eine zentrale App, sondern maßgeschneiderte Loyalty-Lösungen pro Kund:in – für Retail, E‑Commerce, Dienstleister:innen wie Friseursalons bis hin zu Städten und Regionen. Die Spannweite reicht von wenigen tausend bis zu mehreren Millionen Nutzer:innen. Das Produktset deckt App und Web-App für Endnutzer:innen sowie ein Dashboard für Kund:innen ab: Nutzerverwaltung, Loyalty-Mechaniken (Punkte sammeln, Belohnungen einlösen), Feedback, Sharing, Messaging, Analytics – und Integrationen in vorhandene Systeme.

Diese Leitplanke zieht sich durch den gesamten Vortrag: Standardisieren, wiederverwenden, orchestrieren – und nur dort kundenspezifischen Code einsetzen, wo es unvermeidbar ist.

Problemraum: Viele Systeme, viele Einschränkungen – ein skalierbarer Integrationsansatz

hello again begegnet drei Grundtypen von Kund:innen:

1. Typ 1: Uneingeschränkte Möglichkeiten – APIs, Custom Code, volle Offenheit.
2. Typ 2: Eingeschränkte Möglichkeiten – kein Custom Code auf Kundenseite, aber nutzbare Dienste.
3. Typ 3: Keine Möglichkeiten – weder Custom Code noch Services verfügbar.

Zusätzlich erschweren die Realität in Projekten und die Heterogenität die Lage:

• Hunderte verschiedener Systeme, teils Inhouse-Lösungen.
• Unterschiedliche Kombinationen, unterschiedliche Nutzungsarten.
• Teilweise geringes technisches Know-how bei Stakeholdern.

Das erklärte Ziel: keine Wartungslast durch unzählige Einzel-Integrationen, sondern „wirklich einfache und generische Integrationen und Prozesse“ für schnelle Setups und hohe Wartbarkeit.

Architektur im Überblick: Kernsystem plus Integrationspunkte

Im Kern betreibt hello again einen Server mit mehreren Backend-Instanzen, angebunden an Datenbank und Kommunikations-Gateways (Push, E‑Mail, SMS). Die hauseigenen Apps, Web-Apps und das Dashboard sprechen direkt mit diesem Server. Die zentrale Frage lautet: Wie docken Dritt-Systeme an dieses Setup an?

Für Typ‑1‑Kunden (mit offenen Möglichkeiten) gibt es mehrere Pfade:

• Externe APIs für die meisten Funktionen: Nutzerverwaltung, Beleg-/Receipt-Uploads, Reward-Erstellung usw.
• Plugins für ausgewählte Online-Shops (in Zusammenarbeit mit Partnern), die Installation vereinfachen und Kernprozesse wie Nutzersynchronisation und Kauf-/Beleg-Upload automatisieren.
• Konfigurierbare Backend-Services: Webhooks und Coupon-Backends, um externe Systeme per Konfiguration anzubinden – etwa Nutzerprofile bei Signup an ein CRM weiterleiten oder Codes aus der App gegen ein Drittsystem validieren.

Für Typ‑2‑Kunden (eingeschränkte Möglichkeiten, aber nutzbare Dienste) übernimmt hello again die Integrationsarbeit selbst – mit klaren Designzielen: kundenspezifischen Code vom Backend trennen, Setup und Betrieb vereinfachen, und die Wiederverwendbarkeit maximieren.

Für Typ‑3‑Kunden (keine Möglichkeiten) setzt hello again auf minimalinvasive Wege, etwa Datenexporte oder eine POS-Lösung, die ohne Anpassungen in der Kassensoftware auskommt.

Bausteine der Integrationsstrategie

Markus beschreibt mehrere Komponenten, mit denen sich die Breite der Integrationsfälle abdecken lässt:

• Externe APIs: Die Standard-Schnittstelle für Datenaustausch – Nutzerprofile, Belege, Rewards u. v. m.
• Shop-Plugins (mit Partnern): Einfach zu installieren, kapseln gängige Aufgaben wie Sync und Upload.
• Google Cloud-Produkte: Cloud Functions, Cloud Run, Cloud Workflows – als modulare, wiederverwendbare Integrationsbausteine.
• Open Integration Hub: Eine Open-Source-Integrationsplattform, die in früheren Integrationsphasen zum Einsatz kam. Laut Markus traten dort Stabilitäts- und Fehlerprobleme auf, weshalb später Google Cloud Services bevorzugt wurden.
• Konfigurierbare Backend-Services: Webhooks und Custom-Coupon-Backends, um externe Aktionen auszulösen bzw. Codes gegen Drittsysteme zu prüfen – ohne Code im Kernbackend ändern zu müssen.
• POS-Lösung: Ein OS-naher Dienst, der den Druckprozess abfängt, Kund:innendaten abfragt (z. B. Kundenummer bzw. Scan aus der App) und Belege gemeinsam mit der Kundenkennung an den Server sendet. Der Server verarbeitet die Belege via OCR, vergibt anschließend Punkte – alles ohne die Kassensoftware zu verändern.

Principled Design: Klein, spezifisch, konfigurierbar

Dieses Prinzip zieht sich durch die Google-Cloud-Strategie:

• Eine Cloud Function, die ausschließlich „Belege hochladen“ kann und über Konfiguration wiederverwendet wird.
• Eine weitere, die nur „Datei herunterladen“ (z. B. von einem FTP-Server) übernimmt.
• Kundenspezifische Transformations-Funktionen, die Daten ins interne Format bringen.
• Workflows und Scheduler, die diese Bausteine zu End-to-End-Prozessen verketten.

So entsteht ein Werkzeugkasten aus generischen und minimal kundenspezifischen Funktionen, mit dem Integrationen schnell zusammengesteckt werden können.

Integrationspfade nach Kundentyp

Typ 1: Offene Kundensysteme – APIs, Plugins, Konfiguration

Wenn Kund:innen eigene Schnittstellen und Anpassungen ermöglichen, hält sich der Aufwand bei hello again gering. Beispiele:

• Einbindung von CRM oder Drittsystemen über Webhooks (z. B. beim Signup Nutzerdaten weitergeben).
• Nutzung der externen APIs für Kernaktionen: Nutzer synchronisieren, Käufe/Belege hochladen, Rewards erzeugen.
• Shop-Plugins übernehmen Synchronisation und Beleg-Uploads praktisch „out of the box“.

Der Mehrwert liegt in Beratung und Support – die technische Integration wird durch das Angebot an Schnittstellen, Plugins und Konfigurationen stark vereinfacht.

Typ 2: Dienste verfügbar, aber kein Custom Code – hello again übernimmt

Hier verfolgt das Team drei Ziele:

1. Custom Code bleibt außerhalb des Kernbackends.
2. Implementierung und Setup bleiben leichtgewichtig.
3. Höchstmögliche Wiederverwendbarkeit.

Die typischen Aufgaben in diesem Szenario:

• Daten transformieren: Eingangsformate in das interne Datenmodell überführen.
• Dateien aus Fremdsystemen holen und in die Plattform einspeisen.
• Belege an die externe API von hello again übermitteln.

Ursprünglich lief das teils über den Open Integration Hub, aber laut Markus gab es „Stabilitäts- und Fehler“-Probleme. Daher verlagerten spätere Integrationen auf Google Cloud Functions/Run/Workflows. Die Idee bleibt identisch: Kleine, konfigurierbare Module, die jeweils eine eng umrissene Aufgabe lösen, plus eine Orchestrierung, die die Schritte in Abfolge bringt.

Konkrete Bausteine:

• „Upload Receipt“: Eine generische Cloud Function, die formatierte Belege gesammelt zur API hochlädt.
• „Download File“: Eine generische Cloud Function, die Daten (z. B. aus FTP) abholt.
• „Transform Data“: Eine client-spezifische Cloud Function, die individuelle Formate ins interne Schema bringt.

Mit diesen Elementen entstehen Workflows, die sich per Scheduler zyklisch ausführen lassen – ohne das Backend anzufassen. So bleiben Integrationen modular und wartbar.

Typ 3: Keine Optionen – minimalinvasive Workarounds und POS-Lösung

Wenn Kund:innen keine Schnittstellen und keine Anpassungen zulassen, sucht hello again nach minimalinvasiven Wegen, die trotzdem Mehrwert schaffen. Beispiel: Ein einfacher Datenexport reicht, um in einem Workflow „Export holen → transformieren → via API hochladen“ zu realisieren.

Besonders spannend ist die POS-Lösung: Sie wird als separates Stück Software direkt auf dem Betriebssystem des Kassensystems installiert (nicht in der Kassensoftware selbst). Sobald der Kauf abgeschlossen ist und der Druckauftrag ansteht, fängt sie den Druck ab, fragt nach Kund:innendaten (Eingabe der Kundennummer oder Scan via App), schickt den Beleg samt Kennung an den Server – der wiederum via OCR den Beleg verarbeitet und Punkte vergibt. So gelingt eine Integration „ohne die POS-Software anzufassen“.

Zwei konkrete Beispiele aus dem Vortrag

1) Kassenintegration (Typ 1)

Der Standardfluss laut Markus:

1. Nutzer:in zeigt beim Checkout die App, die Kund:innen-ID wird gescannt.
2. Kaufprozess läuft normal weiter.
3. Nach Abschluss sendet das Kassensystem den Beleg an den Server von hello again.
4. Der Server verarbeitet und vergibt Punkte.

Rückgaben, Rewards-Einlösung und weitere Sonderfälle gehören natürlich zur Realität, doch das Grundmuster bleibt schlank. Dank externer API ist der Aufwand auf Seiten von hello again minimal – primär Support beim Implementieren auf Kundenseite.

2) Import von Buchungsdaten (Typ 2/3)

Angenommen, die Buchungsdaten liegen auf einem FTP-Server. Ein Workflow könnte so aussehen:

• Schritt 1: Download – Eine generische Cloud Function lädt die Datei vom FTP-Server herunter (konfigurierbar und wiederverwendbar).
• Schritt 2: Transformation – Eine client-spezifische Cloud Function überführt das Format ins interne Schema.
• Schritt 3: Upload – Eine generische Cloud Function lädt die so vorbereiteten Datensätze via externe API zu hello again.
• Ausführung: Ein Scheduler stößt den Workflow in regelmäßigen Intervallen an.

Der Effekt: Sobald die generischen Bausteine vorhanden sind, beschränkt sich der kundenindividuelle Aufwand auf die Transformation – minimaler Aufwand, maximaler Hebel.

Warum kleine Bausteine große Wirkung haben

Markus’ Leitidee ist die „Zerlegung in kleinste, wiederverwendbare Einheiten“ – ein Muster, das in heterogenen Integrationslandschaften besonders stark wirkt:

• Geringeres Risiko: Fällt ein Baustein aus, betrifft das nicht das gesamte Backend.
• Bessere Wartbarkeit: Fixes lassen sich am betroffenen Modul ausrollen, ohne Kernsysteme anzutasten.
• Schnellere Umsetzung: Standardfunktionen wie „Download“ und „Upload“ sind einmal gebaut und per Konfiguration in vielen Projekten nutzbar.
• Klare Verantwortlichkeiten: Transformationslogik bleibt kundenspezifisch und isoliert, generische Funktionen sind produktübergreifend gleich.

Diese Trennung deckt sich mit den Integrationszielen, die Markus formuliert: Separation vom Backend, Einfachheit in Setup und Betrieb, hohe Wiederverwendbarkeit.

Was die POS-Lösung besonders macht

Die POS-Integration ist oft der schwierigste Teil, weil Kassensoftware in vielen Umgebungen schwer veränderbar ist. Der Ansatz von hello again umgeht dieses Hindernis:

• Installation auf OS-Ebene, nicht in der Kassensoftware.
• Abfangen des Druckvorgangs bei Kaufabschluss.
• Einholen der Kund:innen-ID (Eingabe oder Scan).
• Versand des zu druckenden Belegs an den Server, dort OCR-Verarbeitung und Punktevergabe.

Dadurch entsteht ein „Bypass“, der ohne Änderungen an der Kassensoftware funktioniert – entscheidend für Kund:innen des Typs 3. Gleichzeitig bleibt der Prozess für Nutzer:innen natürlich: App zeigen, scannen lassen, Punkte sammeln.

Iteration der Tooling-Landschaft: Von Open Integration Hub zu Google Cloud

Markus schildert offen, dass nicht jede Toolwahl langfristig gepasst hat. Der Open Integration Hub erfüllte Anforderungen nicht zuverlässig; Stabilität und Fehlerbild waren problematisch. Spätere Integrationen wurden daher mit Google Cloud Functions/Run/Workflows umgesetzt.

Das Ergebnis rechtfertigt den Aufwand: Mit den präsentierten Werkzeugen erreicht hello again schnellere Integrationen, hohe Wiederverwendung und gute Wartbarkeit.

Ergebnisse und Kennzahlen aus dem Vortrag

Markus nennt drei klare Effekte:

• Geschwindigkeit: „Wir konnten den Zeitaufwand für Integrationen tatsächlich halbieren.“
• Wiederverwendung: „Wir können bis zu zwei Drittel unserer Funktionalität wiederverwenden.“
• Wartbarkeit: Durch Trennung von Server und minimalem Custom Code sind Korrekturen und Updates schnell – ohne zu warten oder große Deployments zu orchestrieren.

Diese Aussagen zeigen, dass das Prinzip „kleine Komponenten, klare Orchestrierung, minimale kundenspezifische Logik“ in der Praxis skaliert.

Technische Leitplanken, die wir aus dem Talk mitnehmen

• Baue generische Integrationsbausteine, die nur eine Aufgabe lösen (z. B. „Datei herunterladen“, „Belege hochladen“) – und halte sie konfigurierbar.
• Isoliere kundenspezifische Transformationen in eigene Funktionen; alles andere sollte generisch sein.
• Orchestriere die Schritte per Workflows und führe sie über Scheduler aus – entkoppelt vom Kernbackend.
• Nutze externe APIs und Plugins, wo möglich, um Integrationen auf Kundenseite zu erleichtern.
• Setze auf konfigurierbare Backend-Services (Webhooks, Coupon-Backends), um externe Systeme ohne Codeänderungen anzusprechen.
• Für POS: Denke OS-nah, wenn die Anwendung selbst nicht anpassbar ist – der Druck-Breakpoint ist ein wirkungsvoller Ankerpunkt.
• Akzeptiere Tool-Iteration: Es kann nötig sein, Plattformen zu wechseln, wenn Stabilität, Fehlertoleranz oder Anforderungen sich ändern.
• Messe Erfolg an Geschwindigkeit, Wiederverwendung und Wartbarkeit, nicht an der Anzahl integrierter Sonderfälle.

Fazit: Integration als Produktdisziplin – nicht als Einmalprojekt

„Integrating hundreds of different systems“ mit Markus Gasplmayr (hello again GmbH) macht klar: Der Schlüssel zur Skalierung liegt nicht in einer „mächtigen“ Allzweck-Integration, sondern in vielen sehr kleinen, gut kombinierbaren Komponenten – plus einer klaren Trennlinie zwischen generischen Fähigkeiten und kundenspezifischer Transformation.

Die Kombination aus externen APIs, Shop-Plugins, konfigurierbaren Backend-Services, Google-Cloud-Bausteinen und der OS-nahen POS-Lösung schafft einen Werkzeugkasten, mit dem sich selbst schwierige Umgebungen erschließen lassen. So entsteht ein Muster, das Integrationen beschleunigt, den Wartungsaufwand reduziert und zugleich den Nutzwert der Loyalty-Lösung erhöht – unabhängig davon, ob ein:e Kund:in volle Offenheit, begrenzte Dienste oder „keine Optionen“ mitbringt.

Für Engineering-Teams, die vor ähnlichen Aufgaben stehen, ist die Kernbotschaft pragmatisch und präzise: Zerlege Integrationen in die kleinstmöglichen wiederverwendbaren Schritte, halte Kundenspezifika auf das Nötigste begrenzt – und orchestriere alles sauber. Die gemessenen Effekte bei hello again belegen, dass diese Strategie auch in stark heterogenen Systemlandschaften trägt.

• 

  

  How to build and maintain 1.000 Apps

  Michael Schöndorfer von hello again spricht in seinem devjobs.at TechTalk über die Challenge, eine große – und stetig wachsende – Anzahl an Apps zu entwickeln und zu verwalten.

  Jetzt ansehen

• 

  

  Sebastian Auberger, CIO bei hello again

  Der CIO bei hello again Sebastian Auberger redet im Interview darüber, was neue Devs erwartet – aus technologischer und aus persönlicher Perspektive – und welche Möglichkeiten zur Weiterentwicklung es gibt.

  Jetzt ansehen

• 

  

  Malith Thilakarathne, Mobile Developer bei hello again

  Mobile Developer bei hello again Malith Thilakarathne erzählt im Interview über seinen Einstieg in das Entwickeln von Mobile Apps, was seine aktuelle Arbeit besonders macht und gibt Tipps für Neueinsteiger.

  Jetzt ansehen