Wem gehört der Integrationscode bei epilot-Projekten?

Wem gehört der Integrationscode in einem epilot-Projekt? Ihnen. Wer epilot mit eigenen Systemen verbindet, lässt dafür Schnittstellen und Mapper entwickeln, und dieser Code ist Teil der eigenen IT, nicht Teil der Plattform. Dieser Artikel erklärt, was das in der Praxis bedeutet, wie die Übergabe in ein eigenes Repository aussieht und wann ein Wartungsvertrag die bessere Wahl ist.

Er richtet sich an IT-Verantwortliche bei Netzbetreibern, Stadtwerken und Energieversorgern, die eine epilot Schnittstelle beauftragen wollen und vorher wissen möchten, wem das Ergebnis am Ende gehört.

Wem gehört der Integrationscode bei einem epilot-Projekt?

Der Integrationscode gehört dem Kunden. Das gilt für die Schnittstellen und Mapper, die ich für Ihr Projekt entwickle, und es ist von Anfang an so vorgesehen, nicht erst auf Nachfrage.

Integrationscode ist Software, die epilot mit Ihren Umsystemen verbindet. Sie empfängt Ereignisse, übersetzt Daten, prüft sie und schreibt sie in andere Systeme oder zurück nach epilot. Ohne diesen Code würden Ihre Prozesse an der Systemgrenze stehen bleiben.

Weil dieser Code Ihre Abläufe abbildet, gehört er auch zu Ihnen. Die konkreten Rechte daran werden im individuellen Vertrag festgehalten, der zu Ihrem Angebot gehört.

Was ist der Unterschied zwischen Integrationscode und der epilot-Plattform?

Die epilot-Plattform ist das Produkt der epilot GmbH, der Integrationscode ist Ihr eigener Code rund um diese Plattform. Beides ist klar voneinander getrennt.

Alle Rechte an epilot liegen bei der epilot GmbH. Lizenzen für die Plattform erhalten Sie ausschließlich bei epilot. Ich verkaufe keine Lizenzen und arbeite an der Plattform selbst nur in Zusammenarbeit mit epilot.

Der Integrationscode dagegen läuft außerhalb der Plattform. Er spricht mit epilot über die offiziellen Wege, die epilot dafür anbietet, etwa öffentliche APIs und Webhooks. Eine Übersicht dieser Wege gibt die epilot Entwicklerdokumentation zu Integrationen.

	epilot-Plattform	Integrationscode
Wem gehört es?	epilot GmbH	dem Kunden
Woher kommt es?	Lizenz bei epilot	individuelle Entwicklung
Wo läuft es?	in der Plattform	in Ihrer eigenen Umgebung oder einer vereinbarten Umgebung
Wer entwickelt es weiter?	epilot	Ihre IT, ein Partner Ihrer Wahl oder ich über einen Wartungsvertrag

Wie arbeiten Sie dabei mit epilot zusammen?

Ich ergänze das Consulting-Team von epilot, ich ersetze es nicht. Für Einführung, Konfiguration und Standardumfang bleibt epilot Ihr Ansprechpartner.

Ich bin Marcel R. G. Berger, Softwareentwickler und Softwarearchitekt mit mehr als 20 Jahren Erfahrung. Ich arbeite mit epilot zusammen, als externer Consultant und Entwickler für Apps und Individualisierungen, und setze dort an, wo der Standard endet.

Daraus ergibt sich eine klare Aufteilung. epilot verantwortet die Plattform, der Integrationscode rund um die Plattform gehört Ihnen. Wann eine solche Integration überhaupt nötig wird, beschreibt der Artikel Wann reicht Low-Code bei epilot nicht mehr?.

Wie sieht die Übergabe in das eigene Repository aus?

Nach der Umsetzung übertrage ich den Code auf Wunsch in Ihr eigenes Repository. Ab diesem Moment liegt alles, was zur Integration gehört, an einem Ort, den Sie selbst verwalten.

Eine Übergabe umfasst in der Regel diese Teile:

• den vollständigen Quellcode der Schnittstellen und Mapper
• die Build- und Container-Definitionen, mit denen sich der Code bauen und betreiben lässt
• Vorlagen für die Konfiguration, ohne Zugangsdaten oder andere Geheimnisse
• die Dokumentation zu Aufbau, Datenflüssen und Betrieb
• die automatisierten Tests

Zugangsdaten gehören nie in ein Repository. Sie bleiben in Ihrer eigenen Verwaltung für Geheimnisse und werden nur über die Konfigurationsvorlagen referenziert.

Der genaue Umfang der Übergabe wird im Angebot festgelegt. So wissen beide Seiten vorher, was am Ende im Repository liegt.

Sinnvoll ist eine kurze gemeinsame Sitzung zur Übergabe, in der Ihre IT den Code einmal selbst baut und startet. Danach ist klar, dass die Unterlagen ausreichen und nichts fehlt, was nur auf einem fremden Rechner liegt.

Warum ist eigener Integrationscode für Netzbetreiber wichtig?

Eigener Integrationscode macht Netzbetreiber unabhängig von einem einzelnen Lieferanten. Wer den Code besitzt, entscheidet selbst, wer ihn betreibt, prüft und weiterentwickelt.

Für Netzbetreiber zählen dabei vor allem vier Punkte.

• Weniger Lieferantenabhängigkeit: Die Integration hängt nicht an einer einzigen Person oder Firma.
• Prüfungen und Dokumentation: Wer Prozesse nachweisen muss, braucht Zugriff auf den Code, der sie ausführt, und auf seine Dokumentation.
• Kontinuität: Fällt ein Lieferant aus, bleibt der Code verfügbar, und der Betrieb kann weiterlaufen.
• Freie Wahl beim Weiterführen: Ihre interne IT oder ein anderer Partner kann die Arbeit übernehmen, ohne bei null anzufangen.

Prüfungen fragen häufig danach, wie ein Datensatz von einem System ins andere gelangt und welche Regeln dabei gelten. Wenn diese Regeln im eigenen Repository liegen, lässt sich die Antwort im Code, in den Tests und in der Dokumentation zeigen.

Gerade bei Abläufen, die über mehrere Systeme laufen, ist das kein theoretischer Vorteil. Eine Integration ist Teil der Infrastruktur, und Infrastruktur sollte nicht an einem fremden Schlüssel hängen.

Wie verringert eigener Code die Lieferantenabhängigkeit?

Eigener Code verringert die Lieferantenabhängigkeit, weil das Wissen über die Integration nicht nur im Kopf eines Entwicklers steckt, sondern im Repository. Code, Tests und Dokumentation zusammen machen die Arbeit für andere nachvollziehbar.

Lieferantenabhängigkeit entsteht meist nicht durch Verträge, sondern durch fehlende Unterlagen. Wenn niemand außer dem ursprünglichen Entwickler weiß, wie eine Schnittstelle gebaut wird, ist jede Änderung an ihn gebunden.

Deshalb gehören Build- und Container-Definitionen zur Übergabe. Mit ihnen lässt sich der Code auf einer anderen Umgebung bauen und starten, ohne dass jemand die Schritte nachraten muss. Die Tests zeigen, was der Code leisten soll, und schützen bei späteren Änderungen vor Rückschritten.

Wie sind die Mapper technisch aufgebaut?

Die Mapper sind individuelle Werkzeuge in Java mit Quarkus, containerisiert, skalierbar und wartbar. Diese Bauweise ist eine bewusste Entscheidung für Code, den auch andere Entwickler übernehmen können.

Java ist in vielen IT-Abteilungen von Energieversorgern verbreitet. Quarkus ist ein Java-Framework für schlanke Dienste, die in Containern laufen. Ein Container bündelt den Dienst mit allem, was er zum Laufen braucht, und lässt sich auf unterschiedlichen Umgebungen gleich betreiben.

Für Sie als Eigentümer heißt das: Der Code setzt auf verbreitete Technik und nicht auf ein Spezialwerkzeug, das nur ein Lieferant beherrscht. Wie ein solcher Mapper im Detail aufgebaut ist, beschreibt der Artikel Mapper zwischen epilot und Umsystemen mit Quarkus.

In meinem aktuellen Projekt bei einem Netzbetreiber in Hessen sind mehrere Drittsysteme über solche individuell entwickelten Schnittstellen an epilot angebunden, weil viele Prozesse dort außerhalb der Plattform laufen. Mehr dazu steht im Abschnitt Aus der Praxis auf der Startseite.

Übertragung ins eigene Repository oder Wartungsvertrag: was passt zu Ihnen?

Beide Wege sind möglich, und beide lassen den Code beim Kunden. Der Unterschied liegt darin, wer sich nach der Umsetzung um Pflege und Weiterentwicklung kümmert.

	Übertragung ins eigene Repository	Wartungsvertrag
Wem gehört der Code?	dem Kunden	dem Kunden
Wo liegt der Code?	in Ihrem Repository	in Ihrem Repository oder an einem vereinbarten Ort
Wer pflegt den Code?	Ihre interne IT oder ein Partner Ihrer Wahl	ich, im vereinbarten Umfang
Was brauchen Sie intern?	Entwickler oder einen Partner, der Java und Container betreibt	einen Ansprechpartner für Anforderungen und Freigaben
Wann passt es?	wenn Sie die Integration selbst weiterführen wollen	wenn Sie Pflege und Weiterentwicklung abgeben wollen
Grundlage	individuelles Angebot	individuelles Angebot

Die Wahl ist nicht endgültig. Ein Wartungsvertrag schließt nicht aus, dass Ihre IT später übernimmt, und eine Übertragung schließt nicht aus, dass Sie später wieder Unterstützung beauftragen.

Was gehört typischerweise in einen Wartungsvertrag?

Ein Wartungsvertrag regelt Pflege und Weiterentwicklung des Integrationscodes nach der Umsetzung. Was genau dazu gehört, wird im individuellen Angebot festgelegt.

Typische Themen sind Anpassungen, wenn sich ein Umsystem ändert, neue Anforderungen aus den Fachabteilungen und die laufende Pflege der Abhängigkeiten. Dazu kommt, dass neue Versionen von Java, Quarkus und den verwendeten Bibliotheken regelmäßig eingespielt werden, damit der Code nicht veraltet. Auch bei einem Wartungsvertrag bleibt der Code Ihr Eigentum.

Was ein Wartungsvertrag im Alltag abdeckt, also Monitoring, Fehlerbehandlung und Updates, beschreibt der Artikel epilot Integrationen im Betrieb. Wie ein Projekt vom Erstgespräch bis zur Übergabe abläuft, zeigt epilot Integrationsprojekt beim Netzbetreiber.

Brauchen Sie dafür einen Anwalt oder reicht das Angebot?

Die konkreten Rechte am Code werden im individuellen Vertrag und im Angebot festgehalten, und dieser Artikel ersetzt keine Rechtsberatung. Er beschreibt, wie die Zusammenarbeit üblicherweise aufgebaut ist.

Ihr Vertragspartner ist die DigitalFreedom Global LLC. Für Netzbetreiber schließen wir den Vertrag auf Wunsch nach deutschem Recht, sonst gilt das Recht des Staates Wyoming. Die Einzelheiten dazu stehen im Abschnitt Vertragspartner auf der Startseite.

Wenn Ihre Rechtsabteilung bestimmte Regelungen zu Nutzungsrechten oder zur Übergabe braucht, sprechen Sie das am besten vor der Auftragsbestätigung an. Dann fließt es direkt in den Vertrag ein.

Wie starten Sie ein Projekt mit eigenem Integrationscode?

Sie starten mit einem kostenlosen Erstgespräch über Ihre Systeme und Abläufe. Danach erhalten Sie ein individuelles Angebot, in dem auch die Übergabe des Codes und auf Wunsch ein Wartungsvertrag beschrieben sind.

1. Erstgespräch: kostenlos und unverbindlich, 30 Minuten über Microsoft Teams.
2. Individuelles Angebot: zugeschnitten auf Ihre Systeme, mit Umfang der Übergabe und Optionen für die Wartung.
3. Umsetzung: Schnittstellen und Mapper werden entwickelt, getestet und mit Ihren Systemen in Betrieb genommen.
4. Übergabe oder Wartung: Der Code geht in Ihr Repository, oder die Weiterentwicklung läuft über einen Wartungsvertrag.

Den gesamten Weg vom Erstgespräch bis zum Betrieb beschreibt der Artikel zum Ablauf eines epilot Integrationsprojekts beim Netzbetreiber.

Alle Leistungen, von der Umsetzung über die Übergabe bis zum Wartungsvertrag, erhalten Sie auf Basis eines individuellen Angebots. Weitere Antworten finden Sie in den häufigen Fragen auf der Startseite, einen Termin können Sie direkt im Buchungskalender wählen.