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

API Domains