---
title: "Fallstudie: SEEBURGER BIS 5 zu IBM Sterling für die ÖBB"
description: "KONDEVS verantwortete Business-Analyse und Anforderungsmanagement für die Migration einer ganzen SEEBURGER-BIS-5-Anwendung zu IBM Sterling bei den ÖBB."
canonical: "https://www.kondevs.com/de/case-studies/"
language: "de"
type: "website"
image: "https://www.kondevs.com/images/og-default.png"
---

> Den vollständigen Index dieser Website finden Sie in [llms.txt](https://www.kondevs.com/llms.txt); die ganze Website in einer Datei: [llms-full.txt](https://www.kondevs.com/llms-full.txt).

# Fallstudien

Projekte, über die wir öffentlich sprechen können: was migriert wurde, auf welchen Plattformen und wofür KONDEVS verantwortlich war.

Bahn · Österreich · 2019-2021

## ÖBB: eine ganze SEEBURGER-BIS-5-Anwendung zu IBM Sterling migriert

| Kunde | Österreichische Bundesbahnen (ÖBB), Wien |
| --- | --- |
| Zeitraum | 2019-2021, zwei Jahre |
| Unsere Rolle | Business-Analyse und Anforderungsmanagement, ein Berater von KONDEVS |
| Umfang | Die ganze Anwendung: jedes Modul, jede Schnittstelle und API |
| Plattformen | Von SEEBURGER BIS 5 zu IBM Sterling |

### Die Aufgabe

Die ÖBB haben eine Integrationsanwendung von SEEBURGER BIS 5 zu IBM Sterling migriert. Es war kein Pilot und keine erste Welle: Die Migration umfasste jedes Modul der SEEBURGER-Installation mit all ihren Schnittstellen und APIs.

### Was KONDEVS getan hat

Zwei Jahre lang verantwortete KONDEVS die Business-Analyse und das Anforderungsmanagement der Migration. Diese Arbeit macht aus einer laufenden Anwendung Anforderungen an die Zielplattform: was jedes Modul und jede Schnittstelle heute tut, was sie auf IBM Sterling tun muss und wie sich das prüfen lässt.

KONDEVS hat das mit einem Berater geleistet, der während der gesamten Migration mit den Teams des Kunden gearbeitet hat.

### Ergebnis

Die ganze Anwendung, jede Schnittstelle und jede API, wurde von SEEBURGER BIS 5 zu IBM Sterling migriert.

## Wie wir eine Migration von SEEBURGER zu IBM Sterling angehen

Was wir in einen Wechsel zwischen Integrationsplattformen einbringen, in der Reihenfolge, in der wir arbeiten:

1. ### Erst die Bestandsaufnahme, dann das Ziel.

Eine SEEBURGER-Installation, die seit Jahren läuft, enthält mehr als ihre Dokumentation: Mappings, partnerspezifische Regeln, Zeitpläne und Fehlerbehandlung. Jedes davon ist eine Anforderung, bis feststeht, dass es nicht mehr gebraucht wird.

2. ### Verhalten statt Konfiguration.

SEEBURGER und IBM Sterling bilden Prozesse, Mappings und Partnerprofile unterschiedlich ab, deshalb funktioniert eine Eins-zu-eins-Kopie der Einstellungen selten. Eine Anforderung beschreibt, was eine Schnittstelle empfängt, umwandelt und liefert und wann sie anhalten oder es erneut versuchen muss; wie IBM Sterling das umsetzt, entscheidet das Umsetzungsteam.

3. ### Jede Anforderung prüfbar.

Für jede Schnittstelle: Beispielnachrichten, das erwartete Ergebnis und ein Abnahmekriterium. Eine Migration ist fertig, wenn die neue Plattform dieselben Ergebnisse liefert wie die alte, nicht wenn ihre Konfiguration vollständig ist.

4. ### APIs und Dateiflüsse in einer Bestandsaufnahme.

Synchrone APIs und asynchrone Datei- oder EDI-Flüsse teilen sich Partner und Daten. In getrennten Listen verbergen sie die Abhängigkeiten, die über die Reihenfolge der Umstellung entscheiden.