Files
Orchestrator/bahn/project-audit/data/confluence-export/pages/27525688-2019-03-11 Fachliche Klaerung zum Thema Common Interface TAF-TAP.md
T
ankn a5f8fb49ab Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2026-06-30 20:39:52 +02:00

5.7 KiB

2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP

Confluence Page ID: 27525688 Version: 1 Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP Labels:


 Besprechungsprotokoll vom 11.03.19

Abstimmung über die Technische TAF/TAP Schnittstelle für Fahrplan (/Vertrieb) und Betrieb   | | Teilnehmer: | | Wolfgang Kuzaj, NMF 11 Benjamin Schmücker, NMK 3(I) Jens Miehlnickel, NMK 3(I) Richard Berger, NVI 2  Jürgen Sievers, NVI  2(A)  Bettina Kranz, NVI 2(A) Dr. Patrick Breun, NMF 11Andreas Haase, IPI

| | Verteiler: TeilnehmerInnen, sowieAndreas A Schumann, NPB 3(P)Ralph Grassel, NMK    Holger Duis, NVI 2(A)    Bernd Völlmeke, NPB 3(Z) Lydia Weitershagen, NVI 2(A)   Holm Zickermann, FIB VS Martin Kiderle, NPB 3(P)    Lars Ladouceur, NPB 3(P)    Julian Holzner, NMF 11    Henning Henke,NMF 2    Sebastian Hassemer, NVI 31  Erstellt von: Bettina Kranz | | Ort/Zeit: | | Frankfurt, Weilburger Str. 22 11.03.19, 10.00 – 12:00Uhr

| | | Nr. | Inhalte/Maßnahmen | Zuständig | Termin | Status | | Agendapunkt: Fachliche Gründe, die für eine gemeinsame Schnittstelle sprechen | |  1.           |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Vorteile eines Common Interface dar. |  Alle | | I | | Agendapunkt: Fachliche Gründe, die gegen eine gemeinsame Schnittstelle sprechen | |  2.          |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Nachteile eines Common Interface dar. | Alle | | I   | | Agendapunkt: Sicht der Enterprise Architektur | |  3.       

    |  Die Sicht der Enterprise Architektur ist, dass alle Zielgruppen des Kunden konsistent mit den benötigten Geschäftsobjekten über alle Prozesse hinweg von der DB Netz beauskunftet werden sollen (360° Sicht auf den Kunden). | Sievers | | I | | Agendapunkt: Diskussion | |  4.       

    | Es ist zu ermittelt, in welchem Umfang es der Wunsch der EVU ist, eine Schnittstelle zu haben, und ob die Kunden dieses Vorhaben der DB Netz unterstützen. Dabei sind insbesondere die entstehenden Kosten und Aufwände auf der Kundenseite sowie die Vor- und Nachteile für den Kunden zu ermitteln und zu bewerten.  | Kuzaj   |   | I   | |  5.       

    | Es istaktuell nicht geklärt, welcher Aufwand inklusive Kosten einem eventuellen, noch nicht ermittelten und erkennbaren Nutzen für die Bereiche Fahrplan und Betrieb gegenübergestellt werden kann. Diese Aufwands-/Nutzenbetrachtung mussaber Basis für die Entscheidung sein. | Kuzaj   |     | I   | |  6.       

    | Es besteht ein Problem der Dateninkonsistenz, welches nicht über eine gemeinsame Schnittstelle gelöst werden kann.  Die fachliche Inkonsistenz resultiert aus den Prozessen und muss aufgrund der Betriebslage auch so sein. Die Datensicht kann sich mehrfach im Prozessverlauf ändern. | Kuzaj   |

  | I | |  7.         | Aus Sicht der Fachbereiche müsste an Stelle einer gemeinsamen Schnittstelle eher an den Prozessen oder an der Transparenz in Richtung Kunde gearbeitet werden. | Fachbereiche   | | I | |  8.        | Die Herstellung der internen Datenkonsistenz ist aktuell bereits im Scope von FIB. | | | I | |  9.       

    | Es gibt keine Nachrichten/Meldungen auf Kundenseite, bei denen der Kunde nicht weiß, an wen er diese adressieren soll. Daher wird aktuell keine Notwendigkeit gesehen, nur eine fachliche Schnittstelle anzubieten.  Es ist im Gegenteil sogar wünschenswert, dass der Kunde entscheiden kann, an wen er die Nachricht senden möchte. | Fachbereiche   |   | I | |  10.         | Fachlich bleiben es zwei getrennte Kanäle, technisch kann zu einem späteren Zeitpunkt noch entschieden werden, ob diese zusammengeführt werden können um nach außen eine oder zwei Schnittstellen anbieten zu können. Es muss noch entschieden werden, ob und unter welchen Anforderungen diese zusammengeführt werden soll. |  Alle   |       | B   | |  11.         | Die einzelnen Projekte werden nun zunächst jeweils ihre eigenen Schnittstellen nach den TAF/TAP Vorgaben und NfA spezifizieren und umsetzen. | Fachbereiche |   | A | |  12.         | Aus Sicht der Enterprise Architektur soll das Ziel weiterverfolgt werden, eine gemeinsame technische Schnittstelle zu bauen, welche eine URL für den Kunden anbietet und zum Beispiel über einen Proxy die Nachrichtenverteilung steuert. Der Vorschlag ist, zunächst mit zwei getrennten fachlichen Schnittstellen zu starten und ggf. später an einer gemeinsamen Schnittstelle zu arbeiten. | Sievers   |      | I   | | 13.        | Es muss nun evaluiert werden, wo die Entscheidungspunkte eine oder zwei technische Schnittstellen liegen. Hierbei muss sichergestellt sein, dass keine negativen Wechselwirkungen aus nicht koordinierbaren Lastspitzen der beiden Kanäle resultieren. | Sievers   |   | A | |  14.         | Falls in Punkt 11 die Umsetzung einer gemeinsamen Schnittstelle beschlossen wird, muss geklärt werden, welches Projekt die Kosten für die technische Schnittstelle trägt. | Sievers   |   | A

Anhang: Protokoll mit Workshop-Präsentation 250