Zum Ende des Banners springen
Zum Anfang des Banners springen

3. Funktionale Architektur

Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 44 Nächste Version anzeigen »

High Level Information Model

  • Party (AG): Endkundeninformationen sind für Bereitstellungen und Entstörungen notwendig (zB. Technikertermine). Diese können als Werte mitgeliefert werden. API ist somit für die Prozess-Unterstützung nicht zwingend notwendig.
  • Party (LE): Kunden und Vertragsinformationen sind für Bereitstellungen und Entstörungen notwendig, eine Referenz ist aber in der Regel ausreichend (fachlicher Schlüssel oder Resource.id). API ist somit für die Prozess-Unterstützung nicht zwingend notwendig. 
  • Agreement: siehe oben
  • Product Catalog: Für dieses FIT Release wurde entschieden die notwendigen Produktstrukturen, als Schema in den APIs zu definieren. Die vorab abgestimmten Produktangebote können dann als Referenzen mit den Aufträgen mitgeliefert werden. Somit ist eine aktive Abfrage des Produktkataloges nicht zwingend notwendig. Die FIT API Spezifikationen unterstützen aber den katalogbasierten Ansatz und dieser kann, ohne weitere Anpassung der APIs eingeführt werden. 
  • Service: Die Referenz des Services ist notwendig um den Service-Test und die Service-Aktivierung anstoßen zu können, Einen aktive Abfrage des Service Bestandes ist aber nicht im Rahmen der analysierten Prozesse notwendig,
  • Resource: Referenzen auf Resources wie HomeId, ONT, Leistungsübergabepunkt können Aufträge notwendig sein. Falls eine einfache Referenz nicht ausreichend ist, können Informationen auch als Werte mitgeliefert werden. Ausnahme = Leistungsübergabepunkt (ServiceAccessPoint) welcher im Rahmen der Verfügbarkeit

Core Business Flows

Siehe Business Prozesse maps Open API

High Level Prinzipien

  • Data centric operations
  • Decoupling: autonomous, product & process agnostic capabilities
  • Entity-Centric
  • State / Lifecycle
  • Asynchrounous pattern: notifications
  • Asynchrounous pattern: task resources

Datenzentrischer Betrieb 

Das Konzept des datenzentrischen Betriebs ermöglicht dynamische, flexible Prozesse auf Basis klar definierter und abgregenzter Verantwortungsbereiche (API Domäne). Folgendes charakterisiert Data-centric Operations:
• vollständig automatisierte Präsentationen für den engagierten Benutzer;
• Informationen, die für den engagierten Benutzer nützlich und konsumierbar (verständlich und kontextbezogen) sind
• engagierter Benutzer, der die Kontrolle über den Dienst hat;

Status und Lifecycle


Langläufige Prozesse


API Domains


  • Keine Stichwörter