Brownfield-Modernisierung
Es läuft seit achtzehn Jahren, es trägt das Geschäft, und niemand kann mehr vollständig sagen, was darin passiert. Wir machen Struktur, Logik und Abhängigkeiten sichtbar, bevor irgendjemand etwas anfasst.
Gespräch anfragenÖffentlich sichtbare Signale · keine Anmeldung · Ergebnis in Sekunden
Lieber ohne Eingabe? Wie wir arbeiten · Was die Discovery kostet
Was dieser Check nicht sieht
Genau diese vier Punkte sind der Inhalt einer Discovery – belegt statt vermutet.
Befund besprechen →Keiner davon handelt von Technologie. Alle vier handeln davon, dass Wissen verschwunden ist, während das System weiterlief.
Ändern dauert bei uns sechs Monate. Auch Kleinigkeiten.
Nicht weil die Änderung schwer wäre, sondern weil niemand mit Sicherheit sagen kann, was sonst noch daran hängt. Also wird getestet, was ohnehin nie kaputtging – und das Eigentliche übersehen.
Die Dokumentation? Die ist von 2011.
Sie beschreibt ein System, das es so nicht mehr gibt. Gefährlicher als keine Dokumentation ist eine, der man noch glaubt.
Herr K. weiß das. Der ist aber nächstes Jahr weg.
Das Wissen, das über zwanzig Jahre entstanden ist, steht in keinem Repository. Es steht in einem Kopf, und dieser Kopf hat ein Austrittsdatum.
Der Anbieter sagt: neu bauen oder gar nichts.
Eine Neuentwicklung ist die teuerste Art, dasselbe Nichtwissen noch einmal zu produzieren. Wer nicht weiß, welche Regeln im Alten stecken, kann sie im Neuen nicht abbilden.
Quellcode, Datenbankschemata, Schnittstellen, Logs, Tickets, Betriebsdaten. KI liest die Mengen, die ein Team in Workshops nie durcharbeiten könnte – und wir bewerten, was dabei herauskommt. Am Ende steht keine Vermutung, sondern eine Karte.
Beispielhafte Darstellung, keine Kundendaten. Die gestrichelten Kanten sind der eigentliche Ertrag: Stellen, an denen etwas passiert, das in keinem Dokument steht. Genau dort kippen Modernisierungsprojekte.
Wir sammeln, was da ist: Repositories, Schemata, Schnittstellendefinitionen, Betriebslogs, Tickets, alte Fachkonzepte. Dazu vier bis sechs Gespräche mit denen, die das System heute am Leben halten.
Agenten arbeiten den Bestand durch: Modulgrenzen, Aufrufketten, Datenflüsse, tote Pfade, doppelte Logik, Geschäftsregeln, die ausschließlich im Code stehen. Wir prüfen die Funde und verwerfen, was nicht trägt.
Je Komponente eine Entscheidung mit Begründung: behalten, kapseln, zerlegen, migrieren, ersetzen, stilllegen. Priorisiert nach Geschäftswert, Risiko und Abhängigkeitstiefe – nicht nach technischer Eleganz.
Eine Sitzung mit allen, die entscheiden. Sie bekommen die Karte, die Roadmap und eine Pilotempfehlung – und die Liste dessen, was wir nicht herausfinden konnten. Die ist oft die nützlichere.
Ein System, das stabil läuft und in absehbarer Zeit nichts Neues können muss, ist kein Problem. Es ist eine abbezahlte Maschine. Wer daran etwas ändert, ohne einen Grund zu haben, verbrennt Geld.
Teuer wird Altsoftware erst, wenn das Geschäft etwas verlangt und die Antwort „geht nicht“ lautet. Das hat selten mit dem Alter zu tun und fast immer damit, dass niemand mit Sicherheit sagen kann, was an einer Änderung noch hängt.
Kein Rahmenvertrag, keine Vorstudie über die Vorstudie. Ein abgegrenztes System, ein Festpreis, ein Termin, an dem etwas auf dem Tisch liegt.
Anwendungen, Datenbanken, Schnittstellen, Abhängigkeiten – belegt und unterschieden von vermutet.
Welche Komponenten Sie nicht anfassen können, ohne dass anderswo etwas ausfällt.
Je Komponente eine begründete Empfehlung mit Aufwandsspanne, nicht eine Gesamtempfehlung.
Der Bereich, an dem sich Methode und Zielarchitektur mit dem geringsten Risiko beweisen lassen.
Jedes ist einzeln buchbar, und keines setzt voraus, dass Sie das nächste schon zugesagt haben. Die Reihenfolge ergibt sich aus der Sache, nicht aus dem Vertrag.
Die Discovery sagt, was da ist. Das Assessment sagt, was daraus folgt: vertiefte Analyse je Komponente, priorisierte Roadmap, Aufwandsspannen mit Begründung – und eine Entscheidungsvorlage, die im Investitionsgremium ohne Übersetzer besteht.
Ein abgegrenzter Bereich wird tatsächlich modernisiert. Nicht als Machbarkeitsstudie, sondern in Betrieb. Danach ist belegt, ob Zielarchitektur und Methode tragen – und was der Rest realistisch kostet. Eine Zahl aus dem eigenen Haus schlägt jede Schätzung.
Ihre Teams arbeiten künftig selbst so. Werkzeuge, Prüfmechanismen, Guardrails als Code, Risikoklassen und Freigabewege – eingerichtet in Ihrer Pipeline, an Ihren echten Änderungen erprobt. Kein Tool-Training, sondern ein Arbeitsmodell, das nach uns weiterläuft.
Was beim ersten System Handarbeit war, wird beim fünften eine Strecke: wiederholbare Analyse- und Migrationspipelines, mit denen Ihre Leute ein System nach dem anderen durchziehen. Der Aufwand je System sinkt, weil die Methode steht und nicht jedes Mal neu erfunden wird.
Die Zusammenarbeit mit skillbyte verschafft uns direkten Zugang zu exzellenter KI-Technologie. Gemeinsam wollen wir Produktions- und Verwaltungsprozesse noch intelligenter und effizienter gestalten.
Aus einem Service-Projekt, nicht aus einer Discovery – die Zahl belegt die Arbeitsweise, nicht dieses Angebot. Zum Proof Sheet →
Wer liest ihn?
Die Frage kommt spätestens sechs Monate nach dem Copilot-Rollout, und sie hat noch kaum jemand beantwortet. Hundert Entwickler mit KI erzeugen mehr Änderungen, als hundert Reviewer prüfen können. Wer die Kontrolle proportional mitwachsen lässt, gibt den Produktivitätsgewinn wieder ab. Wer sie weglässt, merkt es im Betrieb.
Entwickelt unter der Annahme, dass Menschen den Code schreiben. Skaliert nicht mit dem Volumen.
Gebaut für Volumen: Die Prüfung skaliert mit dem Ausstoß, die Reviewer müssen es nicht.
„Hat jemand das gelesen?“
„Lässt sich belegen, dass es tut, was es soll?“
Die Prüfung hängt an prüfbaren Eigenschaften, nicht an Lesegeschwindigkeit. Ihr Team liefert dreimal so viel, die Kontrolle kommt mit.
Reviewer lesen nicht mehr jede Zeile. Sie entscheiden über Architektur und über die Änderungen, die wirklich wehtun können.
Jede Änderung trägt Herkunft, Risikoklasse und Prüfergebnis. Wenn jemand fragt, ziehen Sie den Nachweis, statt ihn zu rekonstruieren.
Seit 2019 in Industrieprojekten, 40+ Unternehmen, gemessen bei TROESTER: Lösungszeit im Service von 6 Stunden auf 76 Minuten.
Die Analyse schafft Verständnis über das System, das Sie haben.
Das Engineering-Modell sorgt dafür, dass das nächste nicht wieder eines wird, das niemand mehr versteht.
Die Analyse arbeitet auf Kopien. Was wir sehen und was nie – vor Projektstart schriftlich, für IT-Sicherheit und Betriebsrat.
EU-Hosting, DSGVO-konform, Auftragsverarbeitung inklusive. Auf Wunsch vollständig auf Ihrer Infrastruktur.
Kein Portal, hinter dem Ihr Wissen verschwindet. Alles liegt am Ende dort, wo Ihre Teams arbeiten.
Das KI-Modell ist bei uns austauschbar, die Methode nicht. Läuft mit den führenden Modellen – oder lokal, wenn Ihre Daten das Haus nicht verlassen dürfen.
Sie können mit KI Quellcode, Schemata und Betriebsdaten in einer Größenordnung auswerten, die manuell nicht geht. Das ist der ganze Hebel, und er ist groß. Er ersetzt keine Architekturentscheidung.
Welche Komponente gekapselt und welche zerlegt wird, welche Geschäftsregel wirklich noch gilt, welches Risiko tragbar ist – das bleibt Ingenieursarbeit mit Verantwortung. Wer Ihnen vollautomatische Modernisierung verkauft, hat entweder ein kleines System vor sich oder eine große Rechnung im Hinterkopf.
Und einen Fall gibt es, in dem wir abraten: Wenn das System in zwölf Monaten ohnehin durch Standardsoftware ersetzt wird, lohnt die Grabung nicht. Dann sagen wir das im Erstgespräch, nicht in Woche drei.
Byte: Schön, dass Sie bis hier gelesen haben. Das sind die sechs Fragen, die im Erstgespräch wirklich kommen – ehrlich beantwortet, bevor Sie fragen müssen.
Nein. Die Analyse arbeitet auf Kopien: Repositories, Schemata, Schnittstellendefinitionen, Logs, Tickets – read-only. Ein NDA steht vor dem ersten Artefakt, und vor dem Start klären wir schriftlich, welche Daten wir sehen, wo sie liegen und was nach Projektende gelöscht wird.
Ein Festpreis, abhängig von Umfang und Zahl der Systeme – kein Rahmenvertrag, keine Tagessätze nach Aufwand. Wird ein Folgemodul gebucht, rechnen wir die Discovery an. Die konkrete Zahl nennen wir im Erstgespräch, wenn wir wissen, worüber wir reden.
Typische Bestände sind Mainframe und COBOL, Java, .NET, PL/SQL und proprietäre Altsprachen. Entscheidend ist nicht die Sprache, sondern ob Artefakte vorliegen: Quellcode, Schemata, Betriebsdaten. Was maschinenlesbar ist, lässt sich durcharbeiten.
In Summe etwa einen Arbeitstag, verteilt über die zwei Wochen: vier bis sechs Gespräche in den ersten Tagen mit denen, die das System heute am Leben halten, und die Übergabesitzung am Ende. Dazwischen arbeiten wir, nicht Sie.
Wenn das System in zwölf Monaten ohnehin durch Standardsoftware ersetzt wird, lohnt die Grabung nicht – dann sichern Sie Daten und Ansprechpartner und lassen es stehen. Das sagen wir im Erstgespräch, nicht in Woche drei.
Nein. Sie liest Mengen, für die nie jemand Zeit bezahlt hätte, und macht daraus prüfbare Behauptungen. Welche Komponente gekapselt wird, welche Regel noch gilt, welches Risiko tragbar ist – das bleibt Ingenieursarbeit mit Verantwortung, und sie braucht Menschen aus Ihrem Haus.
Legacy-Modernisierung · Discovery zum Festpreis
Software altert.Systeme müssen es nicht.
30 Minuten, kein Vertrieb. Wir sagen Ihnen, ob eine Discovery bei diesem System etwas bringt. Falls nicht, sagen wir Ihnen auch, warum.
0221 95490614