Kundenreferenz
ista SE: Internal Developer Platform auf Azure 50 Teams im Self-Service, Time-to-Market -20 %
ista SE · Submetering / Energieabrechnung · 6.000 Mitarbeitende · ~971 Mio. € Umsatz · Wie Pexon Consulting seit Mai 2023 als integraler Teil des zentralen DevOps- und Platform-Teams der ista SE eine Azure-basierte Internal Developer Platform aufbaut: Self-Service für den Head of Platform und bis zu 50 Entwicklungsteams, Security by Default und DORA-Metrics als Plattform-Standard.
Aktualisiert: 30. Juli 2026
Das Wichtigste in Kürze
Wer
Die ista SE, Marktführer im deutschen Submetering und der gesetzeskonformen Energieabrechnung mit rund 6.000 Mitarbeitenden, ca. 971 Mio. € Umsatz, über 60 Mio. installierten Geräten und 14 Mio. Nutzeinheiten, für den Head of Platform und das zentrale DevOps-Team.
Problem
Eine über 40 Jahre gewachsene On-Premise- und Monolithen-Landschaft, zerklüftetes Tooling und manuelle Onboarding-, Release- und Compliance-Schritte bremsten Time-to-Market, während digitale Produkte wie EcoTrend und einfachSmart schnelle Cloud-Iterationen brauchen.
Lösung
Pexon liefert mit sieben Engineers (1 Product Owner, 6 Platform Engineers) eine Internal Developer Platform auf Microsoft Azure: Cloud-First, SaaS-First, Terraform, Kubernetes, GitLab-CI-Templates, Security out-of-the-Box und zentrale DORA-Metrics.
Ergebnis
Nach 12 Monaten sind 25 ista-Entwicklungsteams produktiv onboarded (unter anderem Billing, EcoTrend, AI, Customer Care, DSP), Time-to-Market neuer Features um 20 % gesenkt, Self-Service-Onboarding in Minuten statt Wochen, Rollout Richtung ~50 Teams läuft.
Ergebnisse
-20
% Time-to-Market · schnellere Auslieferung neuer Features durch CI/CD-Templates und Standard-Tooling
25 Teams
onboarded in 12 Monaten · Billing, EcoTrend, AI, Customer Care, DSP und weitere produktiv auf der Plattform
Minuten
statt Wochen · Self-Service-Onboarding neuer Entwicklungsteams inkl. Security-Defaults
~50
Teams im Vollausbau · Plattform ausgelegt ohne lineare Personalsteigerung im Platform-Team
Übersicht Kunde
Branche
Energie · Submetering · Energieabrechnung (ista SE)
Unternehmen
6.000 Mitarbeitende · ca. 971 Mio. € Umsatz · 60 Mio. Geräte · 14 Mio. Nutzeinheiten
Region
Deutschland und internationale Märkte (DACH-Schwerpunkt)
Services
Platform Engineering, Internal Developer Platform, Azure-Migration, Observability, Coaching
Tech-Stack
Microsoft Azure, Terraform, Docker, Kubernetes, GitLab CI, Bash, Go, C#, JavaScript, Java
Projektdauer
Mai 2023 bis laufend · 7 Pexon-Engineers (1 PO + 6 Platform Engineers)
Compliance
Mess- und Eichgesetz · DSGVO · Security by Default · Compliance-by-Design
Status
Produktiv · 25 Teams onboarded · Rollout Richtung ~50 Teams läuft
Ausgangslage
40 Jahre Legacy treffen Wachstumsdruck
Die ista SE ist Marktführer im deutschen Submetering: präzise, gesetzeskonforme Abrechnung von Heizkosten, Warmwasser und verbrauchsabhängigen Nebenkosten für Wohnungen, Bürogebäude und Liegenschaften. Dafür betreibt ista eine der größten IoT-Geräteflotten Europas mit über 60 Millionen Endgeräten. Die IT-Landschaft ist über Jahrzehnte gewachsen. Ein über 40 Jahre alter Abrechnungs-Monolith trägt die Hauptlast des operativen Geschäfts: stabil, aber modernisierungsbedürftig. Für den Head of Platform und die Produktverantwortlichen entsteht daraus ein klassisches Dilemma: den laufenden Abrechnungsbetrieb nicht stören und gleichzeitig digitale Produkte mit Cloud-Geschwindigkeit liefern. Ohne zentrale Plattform-Standards verlieren Entwicklungsteams Velocity, während Operations-Wissen in Silos bleibt.
Zerklüftetes Tooling und manuelle Prozesse
On-Premise-Komponenten und SaaS-Tools ohne durchgängige Standards erschweren es den rund 50 geplanten Entwicklungsteams, neue Features schnell zu releasen. Onboarding, Releases und Compliance-Checks liefen manuell und damit langsam. Es fehlte ein einheitliches Observability-Konzept über Team-Grenzen hinweg. Gleichzeitig besteht ein DevOps-Adoption-Gefälle: manche Teams arbeiten bereits cloud-native, andere noch klassisch. Die Plattform muss beides abdecken, sonst entstehen Schatten-IT und Doppelstandards. Für Product Owner und Platform Engineering heißt das: jedes Team onboardet anders, Reviews sind schwer vergleichbar, und Time-to-First-Deploy hängt vom Zufall der lokalen Expertise ab.
Digitale Produkte brauchen Cloud-Iterationen
Neben dem Kerngeschäft baut ista digitale Produkte wie EcoTrend (Energieverbrauchs-Visualisierung), einfachSmart und MinuteView auf. Diese brauchen moderne Cloud-Plattformen, kurze Feedbackschleifen und durchgängige Observability. Gleichzeitig bleibt Energieabrechnung hochreguliert: Mess- und Eichgesetz sowie DSGVO verlangen, dass Compliance erzwungen wird, nicht nur empfohlen. Smart-Metering-Rollout und Energy-Transition-Use-Cases (ESG-Reporting, CO₂-Bilanzierung, Energieoptimierung) erhöhen den Druck weiter. Ohne Self-Service-fähige Plattform skaliert Personalbedarf im Platform-Team linear mit jedem neuen Produktteam. Genau das wollte ista vermeiden.
You build it, you run it ohne zentrale Standards
Das Plattform-Engineering-Dilemma bei ista: „You build it, you run it“ trifft auf den Wunsch nach zentralen Cloud-, Security- und Tooling-Standards. Ohne klare Trennung zwischen Plattform-Verantwortung und Produkt-Ownership verlieren Entwicklungsteams Geschwindigkeit, während Security und Compliance pro Team neu verhandelt werden. Für ~50 Teams im Vollausbau ist das nicht nachhaltig. Es braucht eine Internal Developer Platform mit Maximum Self-Service bei minimaler kognitiver Last: Teams provisionieren Umgebungen selbst, Security-Defaults und CI/CD-Templates sind bereits geprüft, und der Plattform-Erfolg ist über DORA-Metrics messbar. Pexon wurde genau für diesen hands-on Aufbau ins zentrale DevOps- und Platform-Team integriert.
Lösung & Vorgehen
1
IDP mit Self-Service-First auf Azure
Pexon arbeitet als integraler Teil des zentralen DevOps- und Platform-Teams der ista SE. Das siebenköpfige Pexon-Team (1 Product Owner, 6 DevOps- und Platform Engineers) baut die Internal Developer Platform mit dem Leitprinzip Maximum Self-Service bei minimaler kognitiver Last. Architektur-Entscheidung: Microsoft Azure als Single Cloud mit klaren Landing-Zone-Mustern und nativer Service-Integration, bewusst SaaS-First beim Tooling, wo Alternativen den Selbstbetrieb ersetzen. Trade-off gegen Multi-Cloud oder On-Premise-Tooling: weniger Operations-Wissen-Bindung, schnellere Updates, eine konsistente Entwickler-Erfahrung. Vorkonfigurierte Komponenten (CI/CD-Templates, Artifact Registry, Container-Runtime, Security-Tooling) sind ready-to-use. Neue Teams provisionieren ihre Umgebung in Stunden bzw. Minuten, nicht in Wochen.
2
Terraform, Kubernetes und GitLab-CI-Templates
Zentrale Workloads wandern mit Infrastructure-as-Code (Terraform) von On-Premise nach Azure. Container-Runtime basiert auf Docker und Kubernetes; CI/CD läuft über GitLab CI mit vorkonfigurierten Pipeline-Templates. Die Entscheidung für Templates statt freier Pipeline-Wildwuchs ist bewusst: jedes Team erhält denselben Golden Path für Build, Test, Deploy und Security-Scans, kann aber Workloads isoliert betreiben (Multi-Team-Tenancy). Warum nicht jedes Team eigene Pipelines schreiben lassen? Weil Compliance und Observability sonst zerfallen und Time-to-Market wieder sinkt. Plattform-Komponenten entstehen in Bash, Go, C#, JavaScript und Java, je nach Integrationsbedarf. Observability-Standards greifen teamübergreifend, ohne Produktteams in ein starres Monitoring-Korsett zu zwingen.
3
Security by Default und DORA als Plattform-KPI
Statt Checklisten nach dem Deploy liefert die Plattform geprüfte Defaults: Container-Runtime-Härtung, Secret-Management und Compliance-Einstellungen sind Teil des Onboardings. Energieabrechnung unter Mess- und Eichgesetz sowie DSGVO verlangt erzwungene Guardrails, nicht optionale Policy-Dokumente. Parallel erhebt die Plattform DORA-Metrics zentral: Deployment Frequency, Lead Time for Changes, MTTR und Change Failure Rate über alle Teams hinweg. Trade-off: etwas mehr initiale Governance an der Plattform-Schnittstelle, dafür messbare Velocity und vergleichbare Qualität statt Silo-Dashboards. Für den Head of Platform wird Plattform-Erfolg damit steuerbar: Adoption, Self-Service-Quote und Time-to-First-Deploy ergänzen die DORA-Kennzahlen.
4
25 Teams onboarded und interne Engineers befähigt
In den ersten 12 Monaten onboardete Pexon 25 ista-Entwicklungsteams, darunter Billing, EcoTrend, AI, Customer Care und DSP. Parallel entstehen Coaching und Hands-on-Befähigung interner ista-Engineers: Pexon hinterlässt Plattform-Kompetenz, nicht Abhängigkeit. Geleitet von Senior Platform Engineer Alexander Padberg arbeiten die Engineers direkt im Code, in der Pipeline, in der Architektur und im Team-Onboarding, inklusive Feature-Übernahme und Bug-Fixes im Dienst-Modell. Das unterscheidet Pexon-Engineering von klassischer Strategy-Beratung: die Plattform wird nicht nur konzipiert und übergeben, sondern als Teil des ista-Plattform-Teams betrieben und weiterentwickelt. Der geplante Vollausbau zielt auf rund 50 Teams, ohne dass das Platform-Team linear mitwachsen muss.
Vorher / Nachher
| Dimension | Vorher | Nachher | Effekt |
|---|---|---|---|
| Time-to-Market neuer Features | lange Zyklen durch manuelle Releases und Tool-Wildwuchs | standardisierte CI/CD-Templates und Self-Service-Tooling | -20 % Time-to-Market |
| Team-Onboarding | Wochen mit manuellen Provisionierungsschritten | Self-Service inkl. Security-Defaults | Minuten bis Stunden statt Wochen |
| Plattform-Adoption | fragmentierte On-Premise- und Team-Insellösungen | zentrale IDP auf Azure | 25 Teams in 12 Monaten produktiv |
| Messbarkeit und Security | keine einheitlichen DORA-Kennzahlen, Compliance manuell | DORA-Metrics zentral, Security by Default | steuerbare Velocity bei erzwungener Compliance |
“
Self-Service und Security by Default haben die Spielregeln verändert: neue Teams starten in Minuten statt Wochen, und DORA-Metrics machen Velocity über alle Produktteams hinweg vergleichbar, ohne den Abrechnungsbetrieb zu riskieren.
PE
Platform Engineering
Zentrales DevOps- und Platform-Team · ista SE
Eingesetzte Technologien & Services
Microsoft Azure
Terraform
Kubernetes / Docker
GitLab CI
DORA-Metrics
Go · C# · Java · Bash
Häufige Fragen
Was ist eine Internal Developer Platform (IDP) und warum braucht ein Submetering-Konzern eine?
Eine Internal Developer Platform ist eine zentrale Self-Service-Schicht mit vorkonfigurierten Komponenten für CI/CD, Container-Runtime, Tooling und Security. Entwicklungsteams provisionieren Umgebungen selbst, ohne eigene DevOps-Spezialisten pro Team. Bei ista SE senkt das die kognitive Last und Time-to-Market, während MessEG- und DSGVO-Defaults erzwungen bleiben. Pexon baut genau dieses Muster auf Azure.
Wie lange dauert der Aufbau einer IDP wie bei der ista SE und was kostet der typische ROI?
Die Pexon-Beteiligung bei ista begann im Mai 2023 und läuft kontinuierlich; in den ersten 12 Monaten waren 25 Teams onboarded und Time-to-Market um 20 % reduziert. Die typische Pay-back-Periode einer Internal Developer Platform liegt bei 12-18 Monaten. Kosten hängen von Team-Anzahl, Cloud-Reife und Compliance-Tiefe ab. Ein Festpreis ohne Scope entsteht nicht, der kumulative Effekt bei 25+ Teams ist aber schnell spürbar.
Wie stellt die Plattform DSGVO- und MessEG-Compliance sicher, ohne jedes Team auszubremsen?
Compliance steckt in den Defaults: geprüfte Container-Runtime, Secret-Management und Pipeline-Gates sind Teil des Onboardings, keine nachgelagerte Checkliste. Teams nutzen Self-Service-Templates, die bereits den regulatorischen Rahmen von Energieabrechnung und Datenschutz abbilden. So bleibt Velocity hoch, während Auditierbarkeit und Security-Posture zentral gehalten werden. Genau dieses Security-by-Default-Muster setzt Pexon bei ista um.
Welche Technologien nutzt Pexon für die ista-IDP auf Azure?
Microsoft Azure als Single Cloud, Terraform für Infrastructure-as-Code, Docker und Kubernetes für Container-Orchestrierung, GitLab CI mit Pipeline-Templates sowie Bash, Go, C#, JavaScript und Java für Plattform-Komponenten. DORA-Metrics (Deployment Frequency, Lead Time, MTTR, Change Failure Rate) werden als Plattform-Feature erhoben. Observability läuft plattform-zentral, der konkrete Provider kann je nach Integrationslage variieren.
Lässt sich das ista-IDP-Pattern auf andere Energieunternehmen und EVU übertragen?
Ja. Internal Developer Platform plus Self-Service, Cloud-First auf Azure, Security by Default und DORA-Tracking ist hochgradig wiederholbar für Energieversorger, Netzbetreiber und Submetering-Anbieter, die Velocity ohne Compliance-Kompromisse steigern wollen. Smart-Metering- und Energy-Transition-Workloads brauchen genau diese Entlastung der Produktteams. Pexon hinterlässt Kompetenz im Kundenteam, damit der Rollout intern weiterläuft.
Passende Referenzen
Energie / Versorgung
Gelsenwasser Azure Landing Zone mit Terraform
+100 % Standards · -50 % Deploy-Zeit Tenant-Refactoring und Hub-Spoke für Versorger
Referenz lesen
Platform EngineeringIDP Golden Path auf Azure und AWS
Stunden statt Wochen Self-Service und Terraform für Konzern-Teams
Referenz lesen
Energie / KRITISAKS Call-Routing KRITIS-Energieversorger
99,99 % Verfügbarkeit Hochverfügbare Plattform unter regulatorischem Druck
Referenz lesen
Internal Developer Platform für Energie und Submetering aufbauen
Sie wollen wie die ista SE Self-Service auf Azure, Security by Default und DORA-Metrics für Dutzende Entwicklungsteams? Pexon Consulting liefert Platform Engineering hands-on im Kundenteam.
Sie suchen einen Partner für Ihr Projekt?
Wir analysieren Ihren individuellen Bedarf, geben erste Empfehlungen zu Umsetzungsstrategien und bieten Ihnen transparente Einblicke in unsere Methoden, Technologien und Referenzen.
400+
Projekte seit 2020
100+
Kunden im DACH-Raum
ISO
27001 zertifiziert
3
Hyperscaler Partner