Der Solution Architect bei ryd ist die Brücke zwischen der Integrationsplattform von ryd und der Realität des Partners. Sie analysieren das System eines Partners, wählen den besten Integrationsansatz aus und passen sie an und entwerfen die Architektur, die die Integration ermöglicht. Sie arbeiten eng mit dem Systemarchitekten zusammen, um die Integrationsansätze von ryd auf Basis von praxisnahen Erfahrungen zu verbessern. Sie sind die Person, die Integration ermöglicht – für einen Fintech-, einen Flotten-SaaS, ein ERP- oder einen Automobilhersteller.
Sie arbeiten eng mit Partnerteams (Geschäftsentwicklung, Partnererfolg, Produkt) und Ingenieurteams zusammen.
Kernaufgaben
1. Partnersysteme analysieren
Führen Sie technische Entdeckungen mit Partnern durch – verstehen Sie deren Tech-Stack, Architektur, APIs, Authentifizierungsmodell, Datenanforderungen und Einschränkungen.
Verknüpfen Sie die Geschäftsziele des Partners den Anforderungen der technischen Integration.
Potenzielle Integrationsblocker frühzeitig identifizieren: inkompatible Auth-Modelle, fehlende APIs, Datenformat-Mismatchs, Latenzbeschränkungen, Compliance-Probleme (GDPR, PCI-DSS).
Dokumentiere die aktuelle Zustandsarchitektur des Partners – was er hat, was er braucht, was er ändern kann und was nicht.
Beispiel: Ein SaaS für Flottenmanagement möchte ryd-Transaktionen in seinem Dashboard verwenden. Du analysierst: Haben sie einen Webhook-Empfänger? Können sie unsere Kafka-Ereignisse konsumieren? Brauchen sie Pull (API) oder Push (Webhook)? Welches Datenformat erwarten sie? Wie hoch ist ihre Latenztoleranz? Welche Authentifizierung verwenden sie?
2. Empfehlung von Integrationsansätzen
Wählen Sie aus ryds Katalog der Integrationsansätze die beste Passform für den Partner aus.
Begründe die Empfehlung mit technischer Begründung – nicht nur "dieser Ansatz funktioniert", sondern "dieser Ansatz funktioniert am besten, weil X, und hier ist der Grund, warum Ansatz Y nicht passt, weil Z."
Wenn kein bestehender Ansatz perfekt passt, identifizieren Sie die Lücke und schlagen Sie eine Anpassung oder ein neues Herangehensmuster vor – und geben Sie es an den Systemarchitekten zurück.
Schätzen Sie den Integrationsaufwand, den Zeitplan und die Risiken ab.
Beispielempfehlung: "Für diesen Partner ist der Webhook Push-Ansatz am besten, weil sie bereits eine Webhook-Aufnahmepipeline haben. Wir ordnen ryds Ereignis ihrem Schema zu. Auth über API-Schlüssel + HMAC-Signaturverifikation. Geschätzt: 3 Sprints für die vollständige Integration."order.completedfuel_expense
3. Entwurfsintegrationsarchitektur
Erstellen Sie das hochrangige Integrationsarchitekturdokument: Systemkontextdiagramm, Datenflussdiagramm, Sequenzdiagramme für Schlüsselflüsse, Komponentenabbildung.
Definieren Sie den API-Vertrag: Anfrage-/Antwortschemata, Ereignisnutzlasten, Fehlercodes, Ratenbegrenzungen, Idempotenzschlüssel.
Spezifizieren Sie das Authentifizierungs- und Autorisierungsmodell: OAuth 2.0, API-Schlüssel, mTLS, JWT – je nachdem, was der Kontext des Partners verlangt.
Definieren Sie die Fehlerbehandlungs- und Wiederholungsstrategie: Was passiert, wenn das System des Partners ausfällt? Wenn unser System ausgefallen ist? Wenn Daten fehlgebildet sind?
Spezifizieren Sie nicht-funktionale Anforderungen: Latenz-SLAs, Durchsatz, Datenspeicherung, Protokollierung, Überwachung.
Erstellen Sie ein technisches Low-Level-Design für die Integration: Welche ryd-Dienste sind beteiligt, welche APIs werden aufgerufen, welche Kafka-Themen konsumiert/produziert, welche Datenbanken werden gelesen/geschrieben.
4. Praktische Validierung (POCs)
Baue Proof-of-Concept-Integrationen, um die Architektur vor der vollständigen Entwicklung zu validieren.
Schreibe Integrationstestpakete – simuliere das System des Partners, teste die Integration End-to-End.
Erstelle Sandbox-Konfigurationen, gegen die der Partner testen kann.
Demonstriere den POC dem Partner und dem Engineering-Team von Ryd.
Übergeben Sie die validierte Architektur dem Entwicklungsteam mit klaren Implementierungsrichtlinien.
5. Zusammenarbeit mit dem Systemarchitekten
Gib strukturiertes Feedback zu jeder Integration: was funktionierte, was nicht, was der Partner brauchte, das nicht im Katalog stand.
Identifizieren Sie Muster zwischen den Integrationen: "Drei SaaS-Partner benötigten alle denselben Datenanreicherungsschritt – das sollte eine Plattformfähigkeit sein."
Schlage Verbesserungen für Integrationsansätze basierend auf der realen Nutzung vor.
Tragen Sie zum Integrationskatalog bei – wenn Sie einen neuen Ansatz oder eine Anpassung erstellen, dokumentieren Sie ihn zur Wiederverwendung.
Nehmen Sie an Architektur-Reviews teil – teilen Sie Ihre Erfahrungen mit anderen Solution Architects und dem System Architect.
6. Partnerkommunikation und Stakeholder-Management
Stellen Sie Integrationsarchitekturen den technischen Teams der Partner vor – klar, selbstbewusst und in ihrer Sprache.
Übersetze zwischen den Bedürfnissen von Partnerunternehmen und den technischen Fähigkeiten des ryd.
Managen Sie technische Erwartungen – seien Sie ehrlich darüber, was möglich ist, was Kompromisse erfordert und was außerhalb des Umfangs liegt.
Unterstützen Sie Vorverkaufsaktivitäten – schaffen Sie technische Glaubwürdigkeit in Partnertreffen.
Tragen Sie zu Partnerdokumentationen bei – Integrationsanleitungen, API-Referenzen, Best Practices.
