Portfolio → Pega
Portfolio-Auftakt
Wir haben uns bewusst auf eine einzige Plattform spezialisiert – weil Pega genau das beherrscht, worauf es in regulierten, langlebigen und komplexen Systemen ankommt. Je komplexer die Anforderung, desto größer der Vorsprung.
Fünf Gründe
Eine Plattform ist nur so stark wie die, die sie beherrschen. Und Pega entfaltet ihre Stärke genau dort, wo es schwierig wird: bei hohen Fallzahlen, vielen Beteiligten, mehrstufigen Workflows und strengen regulatorischen Anforderungen. Unsere Spezialisierung – ausschließlich Pega, seit 2018, in rund 500 Projekten – sorgt dafür, dass dieser Vorsprung im Projekt auch ankommt.
Mit Pega wird eine Anwendung einmal gebaut – und ist zugleich auf allen Endgeräten verfügbar, vom Desktop bis zum mobilen Gerät, ohne separate Entwicklung. Auch die Lokalisierung folgt diesem Prinzip: Dieselbe Anwendung wird in jede vom Kunden gewünschte Sprache übersetzt, ohne dass die Fachlogik dupliziert werden muss.
Pega baut Anwendungen nicht als isolierte Kopien, sondern als Schichten, die voneinander erben. Eine gemeinsame Basis trägt die Fachlogik; darüber liegen Schichten für einzelne Mandanten, Regionen oder regulatorische Varianten. Ändert sich etwas Grundsätzliches, wird es einmal an der Basis angepasst und wirkt überall – ändert sich etwas Lokales, bleibt es auf seine Schicht begrenzt. Für Organisationen mit vielen Behörden, Standorten oder Tochtergesellschaften heißt das: eine Basis pflegen statt zehn fast identische Anwendungen.
Pega denkt vom Kunden her: Die Customer Journey wird zentral modelliert – über alle Kanäle und in allen Sprachen hinweg. Nicht der Kunde passt sich der Software an, sondern die Software dem Prozess. Das ist der entscheidende Unterschied zu Standardsoftware, bei der Organisationen ihre Abläufe an die Grenzen des Systems anpassen müssen.
Mit Werkzeugen wie Pega Blueprint und integrierter KI beschleunigt sich die Entwicklung erheblich – laut Pega um ein Vielfaches gegenüber klassischer Java-Entwicklung.
Geschäftskritische, regulierte Prozesse verlangen oft, dass Daten und Betrieb das eigene Haus nicht verlassen. Pega läuft mit vollem Funktionsumfang dort, wo es die Anforderungen verlangen – in der Cloud, im eigenen Rechenzentrum oder hybrid. Betriebsmodell und Datenhoheit richten sich nach den Anforderungen des Kunden, nicht nach den Grenzen der Plattform.
Souveränität
Digitale Souveränität wird oft als Alles-oder-Nichts-Frage diskutiert: entweder vollständige Unabhängigkeit von US-Technologie oder gar keine Auseinandersetzung mit dem Thema. Das ist die falsche Frage. Eine vollständige Abschottung ist weder realistisch noch das Ziel der aktuellen Debatte – auch die EU spricht nicht von Autarkie, sondern von Kontrolle und Handlungsfähigkeit im Ernstfall. Die eigentliche Frage lautet: Wie weit lässt sich das Risiko senken, ohne den Betrieb zu gefährden?
Pega bietet mit Cloud, EU Service Boundary und Client-Managed-Betrieb heute mehrere Optionen. Die passende Wahl hängt von der Kritikalität des jeweiligen Systems ab, nicht von einer pauschalen Entscheidung für die ganze IT-Landschaft. Die meisten unserer Kunden betreiben ihre Systeme selbst – auch dort bleiben wir Partner, nicht nur bei der Umsetzung: Wir unterstützen bei Architekturentscheidungen, Systemsizing und im laufenden Applikationsmanagement, unabhängig davon, wo und wie eine Anwendung am Ende betrieben wird.
Wir beziehen Pega-Container-Images und Helm-Charts nicht laufend live vom Hersteller, sondern prüfen, härten und versionieren sie in einem eigenen Repository. Das Ergebnis: Kein Deployment ist auf einen externen Download zur Laufzeit angewiesen, jede Softwarekomponente ist geprüft, jeder Betriebsstand lückenlos auditierbar.
Wer erst im Ernstfall verhandelt, verhandelt aus der schwächeren Position. Drei Instrumente regeln das vorab: Survival-Klauseln sichern das Nutzungsrecht am Bestand auch bei Vertragsende. Escrow-Vereinbarungen mit erweiterten Freigabe-Triggern sichern den Zugriff auf den Quellcode nicht nur im Insolvenzfall, sondern auch dann, wenn ein Hersteller aus anderen Gründen nicht mehr liefern darf. Und Exit-Klauseln regeln von vornherein, wie ein geordneter Übergang aussieht, statt ihn im Streitfall neu auszuhandeln.
Wir sind technologieoffen: Je nach Anforderung setzen wir bewusst europäische Sprachmodelle wie Mistral ein – etwa dort, wo Datenhoheit im Vordergrund steht – ebenso wie andere marktführende Modelle, wenn die Aufgabe das verlangt. Wer sich nicht an einen einzelnen Anbieter bindet, bleibt handlungsfähig, wenn sich ein Anbieter ändert oder ausfällt, und kann für jede Aufgabe das jeweils passende Modell wählen.
Am Ende zählt weniger die grundsätzliche Haltung zur Souveränität als die Summe der Architekturentscheidungen, die man heute trifft.
Architektur-Karussell
Low-Code-Differenzierung
Die klassischen Low-Code-Vorteile sind Gattungsargumente — die bietet praktisch jede Plattform. Der eigentliche Unterschied liegt im Variantenmanagement ohne Duplikate: Länder, Sprachen und Organisationen auf einer gemeinsamen Basis abbilden, statt für jede Variante eine eigene Anwendung zu pflegen. Genau diese Tiefe ist der Punkt, an dem sich Pega von anderen Low-Code-Plattformen unterscheidet.
