Was die „AI-Native ODA“-Roadmap für Ihre Entscheidung bezüglich der OSS-Plattform bedeutet

Im Sommer 2026 nutzte das TM Forum die Veranstaltung „DTW Ignite“ in Kopenhagen, um seine Strategie „Race to 2030“ vorzustellen und die KI-native „Open Digital Architecture“ (ODA) zu präsentieren – eine von der Branche unterstützte Roadmap, die Telekommunikationsbetreiber von isolierten KI-Experimenten hin zu koordinierten, bereichsübergreifenden autonomen Betriebsabläufen führen soll. Eine im Rahmen der Initiative durchgeführte Umfrage unter 80 Betreibern ergab, dass 81 % bis 2030 eine Autonomie der Stufe 4+ anstreben, wobei 20 % davon ausgehen, dieses Ziel bereits 2027 zu erreichen.

Für mittelgroße Glasfaseranbieter mag dies wie eine Angelegenheit für große Netzbetreiber erscheinen. Das ist es jedoch nicht. OSS-Anbieter richten ihre Plattformen bereits neu auf AI-native ODA-Anforderungen aus, und Beschaffungsgespräche werden zunehmend von Begriffen rund um AI-native und ODA-bezogene Themen geprägt. Architekturentscheidungen, die in den kommenden Planungszyklen getroffen werden, werden beeinflussen, ob Ihre Plattform auf einen autonomeren Betrieb skaliert werden kann – oder ob später möglicherweise zusätzliche Integrationsarbeiten erforderlich werden. Zu verstehen, was diese Roadmap tatsächlich von einer OSS-Plattform verlangt, ist mittlerweile eine praktische geschäftliche Frage und nicht mehr nur ein Anliegen von Normungsgremien.

Autonomie der Stufe 4+ stellt spezifische technische Anforderungen – nicht jede Plattform erfüllt diese

Autonomie der Stufe 4+, wie sie durch die ODA des TM Forums definiert wird, zielt auf eine hochautomatisierte, domänenübergreifende Entscheidungsfindung ab, bei der Systeme im Rahmen definierter Richtlinien, Kontrollen und Eskalationsregeln agieren können. Dies erfordert drei Dinge von einer OSS-Plattform: komponierbare Komponenten, die unabhängig voneinander aktualisiert und orchestriert werden können, eine umfassende API-Abdeckung über wichtige Betriebsbereiche wie Provisioning, Assurance, Bestandsverwaltung und Abrechnung sowie eine KI-Governance-Ebene, die steuert, wie Agenten agieren, eskalieren und geprüft werden.

Viele ältere OSS-Architekturen wurden nicht für dieses Maß an Kombinierbarkeit konzipiert. Sie basieren auf eng gekoppelten Modulen, bei denen die Änderung einer einzigen Funktion bereits ein erneutes Testen des gesamten Systems erforderlich machen kann. Das Hinzufügen von KI zu dieser Architektur bedeutet in der Regel, externe Tools anzuhängen, die um die Plattform herum arbeiten, anstatt durch sie hindurch. Das kann zu instabilen Integrationen, eingeschränkter Beobachtbarkeit und technischer Verschuldung führen – nicht zu autonomen Abläufen.

Die Kluft zwischen „KI-gestützt“ und „KI-nativ“ ist real und hat direkte Auswirkungen darauf, wie schnell Ihr Team auf Netzwerkereignisse reagieren, neue Dienste einbinden oder skalieren kann, ohne zusätzliches Personal einzustellen.

„ODA-konform“ ist mittlerweile ein Marketingversprechen – Netzbetreiber müssen dies überprüfen

Da das Rahmenwerk des TM Forum branchenweit anerkannt ist, behaupten Anbieter schnell, damit im Einklang zu stehen. Einige dieser Behauptungen sind fundiert. Andere spiegeln eher eine teilweise API-Abdeckung oder Roadmap-Absichten wider als die tatsächlichen aktuellen Fähigkeiten. Als Käufer dürfen Sie die ODA-Bereitschaft nicht für bare Münze nehmen.

Ein nützlicher Ausgangspunkt ist es, den Anbietern vier direkte Fragen zu stellen:

1. Welche Open APIs des TM Forum sind derzeit implementiert – und auf welchem Konformitätsniveau?

2. Wie werden KI-Agenten innerhalb Ihrer Architektur gesteuert, geprüft und eingeschränkt?

3. Können Ihre Komponenten unabhängig voneinander aktualisiert oder ersetzt werden, ohne dass dies systemweite Auswirkungen hat?

4. Inwiefern entspricht Ihre Plattform-Roadmap dem ODA-Komponentenmodell des TM Forum?

Anbieter, die sich wirklich an ODA orientieren, werden diese Fragen konkret beantworten. Weniger ausgereifte Aussagen bleiben oft auf der Ebene allgemeiner Roadmap-Formulierungen und gehen nicht auf konkrete Implementierungsdetails ein. Es lohnt sich, diesen Unterschied zu klären, bevor Sie einen Vertrag unterzeichnen.

Die Architektur, für die Sie sich jetzt entscheiden, legt die Obergrenze dafür fest, was Sie später automatisieren können

Die „Race to 2030“-Roadmap ist nicht nur eine Herausforderung für Anbieter – sie ist auch eine Herausforderung für die Planung der Netzbetreiber. Wenn Ihre aktuelle OSS-Plattform keine komponierbare, API-orientierte und durch KI steuerbare Architektur unterstützt, erfordert der Weg zur Autonomie der Stufe 4+ entweder einen umfassenden Plattformwechsel oder eine lange Reihe kostspieliger Integrationen. Beides ist mit Aufwand verbunden.

Bei Netadmin verfolgen wir die Entwicklungen des TM Forum im Rahmen unserer laufenden Arbeit zu Standardisierung, APIs und zukunftsfähiger OSS/BSS-Architektur aufmerksam. Doch unabhängig davon, welche Plattform Sie gerade evaluieren, gilt derselbe Grundsatz: Die heute getroffenen Architekturentscheidungen legen die Obergrenze dafür fest, was Sie im Jahr 2028 und darüber hinaus automatisieren können.

Was als Nächstes zu tun ist:

• Vergleichen Sie Ihre aktuelle OSS-Plattform mit dem ODA-Komponentenmodell des TM Forum – schon eine grobe Einschätzung deckt Lücken auf.

• Bitten Sie Ihren OSS-Anbieter um eine konkrete ODA-Konformitätserklärung und nicht nur um eine allgemeine Aussage zur Übereinstimmung.

• Prüfen Sie, welche offenen APIs Ihre Plattform derzeit abdeckt, und ermitteln Sie, in welchen Bereichen keine API-Abdeckung besteht.

• Identifizieren Sie ein oder zwei domänenübergreifende Workflows (z. B. „Fehler bis zur Behebung“, „Auftrag bis zur Aktivierung“), bei denen die Automatisierung derzeit durch die Plattformarchitektur blockiert wird.

• Beziehen Sie die ODA-Entwicklungsstrategie in Ihre nächste Anbieterbewertung oder Vertragsverlängerungsgespräche ein – nicht nur die aktuelle Funktionsparität.

Die AI-native ODA-Roadmap entwickelt sich zu einem De-facto-Maßstab für die OSS-Beschaffung. Betreiber, die sie als strukturiertes Bewertungsinstrument nutzen – anstatt die Behauptungen der Anbieter ungeprüft zu übernehmen –, sind besser aufgestellt, um Plattformentscheidungen zu treffen, die bis 2030 und darüber hinaus Bestand haben.

Weiterführende Links:

Primärquelle

Netadmin MCP Services

Schöpfen Sie das Potenzial von KI mit Netadmin MCPs voll aus