Inside TimeTac Connect: Wie TimeTac Integrationen mit ETL, Rezepten und wiederverwendbaren Bausteinen beherrscht

Kontext: Warum Unternehmen Integrationen brauchen

In der DevTalk-Session mit dem Titel TimeTac Connect, How we handle Integrations von Anna Kastner (TimeTac) stand ein Thema im Fokus, das in nahezu jedem wachsenden Unternehmen spürbar ist: Softwarelandschaften bestehen heute aus vielen spezialisierten Lösungen. Ein Unternehmen beginnt vielleicht mit einer Buchhaltungssoftware. Mit zunehmender Größe kommt eine HR‑Lösung hinzu. Kurz darauf folgt ein Tool für das Projektmanagement. Schließlich tritt der Bedarf auf, Arbeitszeiten der Mitarbeitenden zu erfassen – genau hier setzt TimeTac an.

Jede dieser Lösungen kann einzeln hervorragend funktionieren. Das Problem beginnt dort, wo Daten nicht zwischen den Systemen ausgetauscht werden. Dann muss die Personalabteilung Daten mehrfach pflegen, auf Konsistenz achten und Fristen im Blick behalten. Für kleine Teams mag das noch handhabbar erscheinen. Für größere Unternehmen ist diese Mehrfachpflege jedoch fehleranfällig, zeitintensiv und schlicht nicht skalierbar. Der Schluss liegt nahe: Systeme müssen Daten austauschen, um zusammen funktionsfähig zu sein. Anders formuliert: Es braucht Integrationen.

Integrationen sind mehr als Schnittstellen: Arbeit an Architektur, Prozessen und Verantwortung

Anna Kastner betonte, dass Integrationen kein Nebenprodukt sind. Dahinter steht ein Set aus aufeinander abgestimmten Aktivitäten: Kommunikation zwischen Stakeholdern, Architekturarbeit, Konzeptentwicklung, Implementierung, Testen und langfristiger Betrieb. Dieses Verständnis ist zentral, weil Integrationen nicht nur technische Adapter sind, sondern ein dauerhafter Bestandteil der Produktlandschaft und Unternehmenskollaboration. Wer Integrationen ernst nimmt, muss Anforderungen sauber erfassen, fachliche und technische Erwartungen abgleichen und diese Erwartungen in robuste, wartbare Bausteine überführen.

Warum TimeTac ein eigenes Integrations-Framework entwickelte

TimeTac stand vor einer klaren Entscheidung. Es gab bereits Integrationen: einzelne Prozeduren und Funktionen innerhalb des Hauptprojekts, die jeweils für bestimmte Anwendungsfälle implementiert wurden. Das funktionierte, wurde mit wachsender Vielfalt aber unübersichtlich. Die naheliegende Idee war, all diese Integrationen und Datenmigrationen in einer gemeinsamen Basis zusammenzuführen.

TimeTac recherchierte kommerzielle Frameworks. Diese erwiesen sich als teuer und boten nicht die Flexibilität, die für die eigenen Anforderungen benötigt wurde. Gleichzeitig verfügte das Team über Erfahrung und Ressourcen, um eigene Komponenten effizient zu bauen und wiederzuverwenden. Also fiel die Wahl auf ein eigenes Framework: TimeTac Connect. Ziel war es, Daten zwischen Systemen verlässlich zu synchronisieren, vorhandene Bausteine wiederzuverwenden und die Implementierung neuer Integrationen planbar zu machen.

Eine weitere bewusste Entscheidung: TimeTac Connect bleibt ein eigenständiges Projekt, getrennt vom Hauptprodukt. Das schafft einen agilen Workflow, unabhängige Releasezyklen und reduziert die Komplexität im Kernsystem. Diese Entkopplung erleichtert Pflege und Weiterentwicklung des Integrationslayers und verhindert, dass Integrationslogik das Hauptprodukt belastet.

Architekturprinzip: ETL als Leitkonzept

Für TimeTac Connect wählte das Team bewusst ein etabliertes Muster aus der Integrationswelt: ETL. Anna Kastner stellte die drei Schritte und die dazugehörigen Bausteine klar heraus.

• Extract: Daten werden aus einer Quelle gelesen. Dafür gibt es Extractors, die den Abruf der Daten kapseln.
• Transform: Daten werden in die Struktur überführt, die das Zielsystem benötigt. Dafür gibt es Transformers. Sie übernehmen die Aufgabe, die Struktur zu verändern. Dieser Baustein folgt dem Prinzip der Single Responsibility: Der Transformer ist allein dafür zuständig, die Struktur der Daten zu ändern.
• Load: Daten werden in ein Ziel geschrieben. Dafür gibt es Loaders, die das Einspielen entlang der vorgesehenen Methode ausführen.

Die Implementierungsrealität zeigt: Bevor man überhaupt extrahieren, transformieren und laden kann, braucht es Verbindungen. Genau dafür existieren Connectors — Komponente, die die Verbindung zu einer konkreten Datenquelle oder einem Ziel herstellen. TimeTac Connect kann mehrere Arten von Systemen anbinden, etwa:

• Microsoft Azure über eine API
• ein lokales Active Directory
• Dateisysteme über eine SFTP‑Verbindung
• externe Datenbanken

Jede Standort‑ und Transportart hat ihren eigenen Connector. Das hält die Verantwortlichkeiten klar und ermöglicht Wiederverwendung.

Rezepte: Integrationen als Puzzle aus Bausteinen

Im Sprachgebrauch von TimeTac sind Integrationen Rezepte. Ein Rezept kombiniert die Bausteine Connector, Extractor, Transformer und Loader zu einer ausführbaren Verarbeitungskette. Das Bild vom Puzzle trifft es gut: Man setzt passende Steine zusammen, ohne Funktionen immer wieder neu zu erfinden. So kann ein Connector für SFTP zusammen mit einem Extractor und einem Transformer in mehreren Szenarien genutzt werden. Das macht Integrationen konsistent, planbar und wartbar.

Typische Integrationen bei TimeTac

Anna Kastner hob zwei Standardfälle hervor, die in vielen Kundenszenarien wiederkehren.

User Provisioning aus HR nach TimeTac

User Provisioning ist eine Schnittstelle, mit der Stammdaten aus einem HR‑System in TimeTac synchronisiert werden. Erstellung, Pflege und Deaktivierung von Nutzenden werden damit automatisiert. Dies reduziert den Verwaltungsaufwand und senkt das Fehlerrisiko deutlich, weil die Quelle der Wahrheit – das HR‑System – systematisch in TimeTac gespiegelt wird.

ERP‑Integration mit Projekten, Aufgaben und Zeitauswertung

Viele Unternehmen pflegen Projekte und Aufgaben in einem ERP‑System wie SAP. Diese Daten werden nach TimeTac synchronisiert, sodass Mitarbeitende ihre Zeiten gezielt auf Projekte buchen können. Die in TimeTac erzeugten Zeitdaten werden anschließend zurück in das ERP oder andere Systeme übertragen. Der Export kann je nach Bedarf täglich, wöchentlich oder monatlich erfolgen und dient unter anderem der Weiterverarbeitung, Analyse oder Lohnverrechnung.

In der Praxis ist der direkte Zugriff auf SAP oft nicht möglich. Daher greift ein typisches Rezept auf Dateien in einem SFTP‑Verzeichnis zu. Der Ablauf sieht dann so aus:

1. Ein SFTP‑Connector verbindet sich mit dem Dateisystem, aus dem Daten zur Synchronisation bereitgestellt werden.
2. Ein Extractor liest die Quelldateien.
3. Ein Transformer bringt die Daten in die Struktur, die TimeTac benötigt.
4. Ein Loader schreibt die Ergebnisse nach TimeTac.
5. In einem zweiten Rezept werden die in TimeTac erfassten Zeitdaten in regelmäßigen Abständen ausgelesen und per SFTP‑Loader an das ERP (z. B. SAP) zurückgeliefert.

So entstehen Ende‑zu‑Ende‑Prozesse mit zwei gekapselten Rezepten: eines für die Datenrichtung zum TimeTac‑System, eines für den Export in das ERP.

Umsetzungserfahrung: Wiederverwendung schlägt Ad‑hoc‑Code

Ein zentraler Punkt aus der Session: Mit der Rezeptlogik werden bestehende Komponenten wiederverwendet. Das senkt die Implementierungshürde. In den Worten von Anna Kastner: Es ist nicht notwendig, jedes Mal alles neu zu erfinden. Entscheidend ist, die Bausteine zu kennen und gezielt zu kombinieren. Das eigentliche Programmieren wird dadurch kalkulierbar.

Mehr Aufwand entsteht in zwei Phasen, die gerade bei Integrationen oft unterschätzt werden: Anforderungsdefinition und Testen. Anforderungen sind anspruchsvoll, weil verschiedene Stakeholder beteiligt sind und ihre Interessen aufeinander abgestimmt werden müssen. Tests sind anspruchsvoll, weil Integrationen reale Datenflüsse berühren, verschiedene Systeme involviert sind und Fehler häufig erst im Zusammenspiel sichtbar werden. Genau deshalb lohnt sich ein klarer Architekturrahmen mit wiederverwendbaren Bausteinen.

Projektgrenzen bewusst setzen: TimeTac Connect als eigenständiges Projekt

TimeTac entschied, das Integrationsframework nicht in das Hauptprodukt einzuchecken, sondern als separates Projekt zu führen. Daraus ergeben sich klare Vorteile:

• Agiler Workflow: Integrationen können sich in ihrem eigenen Tempo weiterentwickeln.
• Unabhängige Releases: Integrationsänderungen müssen keine Produkt‑Releases blockieren und umgekehrt.
• Reduzierte Komplexität: Die Kernlogik von TimeTac bleibt schlank, Integrationslogik ist klar abgegrenzt.

Diese Trennung stärkt die Wartbarkeit und die Fähigkeit, auf neue Integrationsanforderungen zu reagieren.

Stakeholder, Prozesse, Support: Was Integrationen in der Praxis herausfordernd macht

Integrationen betreffen viele Rollen: Kundenseitig HR, Buchhaltung, Projektmanagement, IT; intern Produkt, Entwicklung, Betrieb. Interessen können divergieren. Daraus folgt eine zentrale Aufgabe: Informationen bei neuen Integrationen sorgfältig zu erheben, Erwartungen zu synchronisieren und die Schnittstellen so zu gestalten, dass sie dauerhaft funktionieren. Die Zusammenarbeit mit Kundinnen und Kunden und internen Teams ist tägliche Praxis. Ebenso das Zusammenführen ihrer Interessen.

Langfristige Betreuung gehört dazu. Systeme ändern sich. Datenmodelle entwickeln sich weiter. Neue Anforderungen entstehen. Integrationen sind kein einmaliger Sprint, sondern eine langfristige Verantwortung. Wer sie entwickelt, arbeitet in einem Feld, das – wie Anna Kastner hervorhob – sehr vielfältig ist: Es geht um kontinuierliche Verbesserungen, das Kennenlernen neuer Technologien und den Umgang mit verschiedenen Systemen.

Leitplanken für die technische Umsetzung auf Basis der Session

Aus der Session lassen sich für Engineering‑Teams, die ähnliche Aufgaben lösen, klare Leitgedanken ableiten – ohne über das Gehörte hinaus zu spekulieren:

• Klarer Fokus auf ETL: Trenne Extraktion, Transformation und Laden als eigenständige Verantwortlichkeiten. Das erleichtert Struktur und Wiederverwendung.
• Saubere Verbindungslogik über Connectors: Behandle Verbindungen zu Azure, lokalem Active Directory, SFTP, Dateisystemen oder externen Datenbanken als austauschbare Bausteine.
• Rezepte als ausführbare Ketten: Denke Integrationen als Kombination aus Connector, Extractor, Transformer und Loader. Dieses Muster macht Integrationen planbar und testbar.
• Wiederverwendung zuerst: Nutze bestehende Bausteine, anstatt pro Integration neue Einzellösungen zu bauen.
• Anforderungen und Tests groß schreiben: Plane ausreichend Zeit für die präzise Anforderungserhebung und für Tests ein, weil genau hier die Komplexität sichtbar wird.
• Entkopplung vom Hauptprodukt: Halte den Integrationslayer als separates Projekt, um Releases zu entkoppeln und Komplexität zu kontrollieren.
• Betriebsrealität einplanen: Frequenzen für Im‑ und Exporte (täglich, wöchentlich, monatlich) klar definieren. Transporte über SFTP bewusst gestalten, wenn direkte Systemzugriffe nicht möglich sind.

Einordnung der häufigsten Use Cases

Die beiden Beispielintegrationen – User Provisioning und ERP‑Synchronisation – zeigen das Spektrum der Anforderungen:

• Stammdatenorientiert: Beim User Provisioning ist der Datenfluss klar. Das HR‑System liefert die Quelle der Wahrheit, TimeTac spiegelt die Konten. Die wichtigste Aufgabe ist, Vollständigkeit und Korrektheit sicherzustellen, inklusive Deaktivierung.
• Prozess‑ und Analyseorientiert: Bei ERP‑Integrationen sind Projekte und Aufgaben in einem System führend. TimeTac ermöglicht darauf basierende Zeiterfassung und liefert die aufbereiteten Zeitdaten für nachgelagerte Schritte wie Auswertung oder Lohnverrechnung zurück. Die Taktung der Exporte muss zum Prozess passen.

Beide Szenarien profitieren stark von wiederverwendbaren Rezeptbausteinen. Einmal sauber definierte Transformers und Loaders können über mehrere Mandanten und Setups hinweg eingesetzt werden und verhindern, dass Feinheiten jedes Mal neu kodiert werden müssen.

Warum ETL hier so gut passt

ETL strukturiert nicht nur die Arbeit, sondern reduziert Fehlerquellen. Der Transformer hat die explizite Verantwortung für die Datenstruktur. Dadurch wird transparent, an welcher Stelle eine Anpassung zu erfolgen hat, wenn sich eine Zielstruktur ändert. Extractor und Loader bleiben unverändert, solange sich Schnittstellen und Transportwege nicht ändern. Das führt zu stabilen Integrationen, die sich schrittweise erweitern lassen.

Gleichzeitig erlaubt ETL die Abbildung der realen Gegebenheiten: Direkter Zugriff auf Systeme wie SAP ist in vielen Fällen nicht vorgesehen oder nicht praktikabel. SFTP als Übergabepunkt ist deshalb ein wiederkehrendes Muster. Der Ansatz mit Connectors abstrahiert diese Realität, ohne die Architektur zu verkomplizieren.

Was wir als DevJobs.at aus der Session mitgenommen haben

• Integrationen sind Organisationsarbeit: Stakeholder‑Management, Anforderungserhebung und Tests sind zentrale Erfolgsfaktoren.
• Ein eigenes Integrationsframework lohnt sich, wenn Flexibilität gefragt ist und vorhandene Komponenten wiederverwendet werden können.
• ETL als Grundstruktur schafft Klarheit, insbesondere durch die eindeutige Zuständigkeit der Transformers für Strukturänderungen.
• Rezepte als Puzzleteile sind ein wirksames mentales Modell, um Integrationen zu entwerfen und zu betreiben.
• Operative Realität zählt: Häufig ist SFTP der praktikable Weg. Zeitliche Taktungen sind Teil der Spezifikation, nicht ein nachgelagerter Gedanke.
• Separate Projekte entlasten das Hauptprodukt und machen Integrationsentwicklung beweglicher.

Praktische Schritte zur Anwendung des Ansatzes

Auch wenn jede Unternehmenslandschaft individuell ist, lassen sich aus dem Vortrag unmittelbar nutzbare Schritte ableiten:

1. Systeme und Datenflüsse erfassen: Welche Quellen und Ziele existieren? Wo liegen die führenden Stammdaten? Welche Transporte sind realistisch (z. B. SFTP statt Direktzugriff)?
2. Bausteine identifizieren: Welche Connectors werden benötigt (Azure, lokales AD, SFTP, Dateisystem, externe Datenbank)? Welche Extractors, Transformers und Loaders lassen sich generisch formulieren?
3. Rezepte definieren: Baue pro Datenrichtung ein Rezept. Trenne Import nach TimeTac‑Logik und Export zurück ins Quellsystem.
4. Frequenzen festlegen: Täglich, wöchentlich oder monatlich – die Taktung gehört in die Spezifikation.
5. Anforderungen präzisieren: Stakeholder zusammenbringen, divergierende Interessen früh erkennen und zusammenführen.
6. Testen planen: Datenqualität, Fehlerszenarien und End‑zu‑End‑Abläufe prüfen. Tests so aufsetzen, dass sie die realen Übergaben abbilden.
7. Projektgrenzen setzen: Den Integrationslayer entkoppelt betreiben, um Releases und Verantwortlichkeiten klar zu halten.

Diese Schritte spiegeln den in der Session vorgestellten Weg wider und sind für Teams umsetzbar, die ähnliche Integrationsaufgaben angehen.

Von Einzellösungen zur Plattformlogik

Die Reise von verteilten, separaten Prozeduren hin zu einem wiederverwendbaren Framework ist charakteristisch für wachsende Produktlandschaften. TimeTac zeigt mit TimeTac Connect, wie man Integrationen so strukturiert, dass sie sowohl den kurzfristigen Bedarf decken als auch langfristig tragfähig bleiben. Die Entscheidung für ETL, die konsequente Trennung der Bausteine, die Nutzung von SFTP dort, wo Direktzugriffe nicht möglich sind, und die bewusste Trennung des Integrationsprojekts vom Hauptprodukt ergeben zusammen ein stimmiges Gesamtbild.

Am Ende steht ein pragmatisches Fazit: Durch wiederverwendbare Komponenten wird das Coden einfacher. Der eigentliche Aufwand liegt in der Definition der Anforderungen und im Testen. Integrationen sind Teamarbeit mit vielen Beteiligten und ein Feld, das Abwechslung bietet. Es geht um kontinuierliche Verbesserung, das Kennenlernen neuer Technologien und den Umgang mit unterschiedlichen Systemen.

Fazit

TimeTac Connect, How we handle Integrations von Anna Kastner (TimeTac) liefert ein klares, praxisnahes Bild davon, wie man Integrationen beherrschbar macht. Der ETL‑Ansatz, die Idee der Rezepte und die klare Trennung der Verantwortlichkeiten sind greifbare, übertragbare Prinzipien. Wer Integrationen nicht als einmaliges Projekt, sondern als dauerhafte Kompetenz begreift, gewinnt an Geschwindigkeit, Qualität und Zuverlässigkeit. TimeTac Connect zeigt, wie diese Kompetenz in Form eines eigenständigen, flexiblen Integrationslayers gelebt werden kann.

• 

  

  How to pick the next Front End Framework

  Tomi Močnik von TimeTac zeigt in seinem devjobs.at TechTalk wie die Entscheidung für ein neues Front End Framework im Unternehmen gefallen ist und welche Erfahrungen dabei gemacht wurden.

  Jetzt ansehen
• 

  

  Challenges in mobile application development

  Ludwig Blaikner von TimeTac spricht in seinem devjobs.at TechTalk über den Weg, wie das Team ein Design Proposal zu einer funktionierenden Mobile Software gebaut hat.

  Jetzt ansehen
• 

  

  Are you using debugger and why not?

  Borislav Lazendic von TimeTac zeigt in seinem devjobs.at TechTalk die Vorteile von Xdebug und überprüft, ob an den üblichen Vorurteilen zu diesem Thema auch etwas dran ist.

  Jetzt ansehen