NGOSSは一体何ですか？ 私は「NGOSS契約」に関連してこの用語を多く使用しましたが、OSS/BSSスペースやTMFに慣れていない人にとっては、それは不思議なことかもしれません。 大規模で活発なプロフェッショナルサービス会社であるTata Consultancy Servicesは、最近、oss/BSSの”再想像”に関する論文を行いました。 二つの文書の間には興味深いコントラストと類似点があり、探索する価値があります。
NGOSSは”次世代運用支援システム”の略です。 これは、少なくとも15年間広く使用されている用語であり、TMFの仕様でよく使用されています。 TMFのものの多くはメンバー専用ですが、要約することを除いて、私はそれを引用することはできません（または、私がその時点でメンバーでない場合は、それ これは、身体が「変革」の未来をどのように見ているかの公開された要約です。 それは変換の同じプロセスの専門家サービスのビューを反映しているので、タタの論文は興味深いです。
タタ紙の開口部は、帯域幅に関する通常の決まり文句を持っています。 “企業はますます新しい現実に沿って、主にオンラインモデルに適応するように、高帯域幅と信頼性の高いネットワークサービスの必要性が急増してい その結果、通信サービスプロバイダー（Csp）は、サービスに対する指数関数的な需要を経験しており、現在のレートでスケーリングを継続するために仮想化技術の進歩に依存しています。”
これの問題は、それがplatitudeステータス（もう一つの”指数関数的な”需要声明と私は吐き出すでしょう）に加えて、本当の問題は需要の成長ではなく、利益の収縮で 彼らは成長のために段階的に充電することができれば、どのオペレータも、帯域幅の需要の増加に不満はありません。 彼らはできないので、販売する帯域幅以外のものを見つけるか、より高い帯域幅サービスが比例して高い価格を生成しないという事実を相殺するた
この同じ問題は、”OSS機能の再考”と呼ばれる次のセクションを着色します。 Ossの近代化のためのTMFの目標を挙げていますが、その利益圧縮の問題に対処することを意味するものはありません。 実際、この文書のそのセクションは、多くのオペレータ戦略家がOSS/BSS全体を廃棄してやり直すことを支持している理由です。 有用な目標が設定されていないわけではありません（自動化は将来のOSS/BSSの属性の1つです）が、それらを達成することについてはあまり言われてい次のセクションにある
は、”うまく調整されたOSS機能の駆動”と呼ばれています。 このセクションでは、最終的に有用な推奨事項を作成します。OSS/BSSはイベント駆動型にする必要があります。 TMFは、実際にはOSSと運用自動化の重要なコンセプトの源であったため、ここで希望を持っていました。 悲しいことに、この用語も概念もタタの論文では提起されていません。 それが言うことは、”将来のOSS機能は、ハイブリッド（物理、論理、および仮想）ネットワークリソースの自動化されたエンドツーエンドのオーケストレーションをサポー「
TMFの論文は、対照的に、「接続性は利益率の低いビジネスとして正しく見られ、急速にコモディティ化されている」という声明で始まります。”オペレータの目的は”敏捷な技術の基礎および作動モデルとの彼らの内部の世界を右に得ることである。”TMFには明らかにこの内部の世界での主要なOSS/BSSターゲットが含まれていますが、明らかにアジャイル技術基盤がインフラストラクチャに拡張しなければならないのと同じように。
彼らの”内部の世界を整理する”メカニズムは、含意によって、5Gである。TMFは、”5Gへの非常に高価なシフトを最大限に活用するために重要だ”と述べているが、それはフォーラムの元CEOが”消費者やスマートホーム個人にとって、”接続性”は本質的な価値を持つ傾向があり、購入するのに有効なものである”と述べている次の段落で矛盾しているようである。 しかし、規模を拡大するにつれて、業界の変革の領域に入るにつれて、接続性はソリューションに結びついている限りでのみ評価されます。”5Gは、すべての大衆市場のインフラがそうであるように、明らかに消費者のための接続戦略です。 ビジネスサービスを意味する”業界変革の領域にスケールを上げる”と仮定すると、鍵はソリューションを販売することです。
これは、事業者が”デジタルサービスプロバイダ”事業を企業に集中させ、ソリューションを提供するためにSaaSプロバイダがあることを主張するようです。 すでにこれらの顧客にソリューションを販売している非常に活発で競争力のあるパブリッククラウドビジネスがあることを考えると、それは 特に、ビットごとの利益の問題の大部分が、消費者サービスを食べ放題になっている場合はどうなりますか？
この決議は、VODAFONEの引用やTMFの論文の他のコメントによると、「現在「サービス」と呼ばれているものは、電話会社だけではなく、電話会社を含むさまざまなパート”したがって、telcoは実際にはデジタルサービスプロバイダではなく、デジタルサービスインテグレータまたは再販業者です。 利益の圧迫を逃れる手段として変革を見ているビジネスは、他のプレイヤーのサービスの再販業者になることができますか？
TMFのビジョンは、本当にOSS/BSSを超えたものを目指しているのではなく、そこにサービスを提供する人たちと提携することによって、運用やサービスが接続性を超えたものに進化することを示唆しているように思われる。 それは、「デジタル変革」の全目的を打ち破り、telcoを現在のレベルの分離とコモディティ化だけでなく、まったく新しいレベルに閉じ込めている可能性が
両方の論文は、OSS/BSS変換が不可欠であることを示唆しているようで、少なくともイベント駆動型のアプローチが答えであることを暗示しています。 それは実際には良いアイデアですが、それは”どのように？「イベント駆動型にするためには、システムはイベントの概念（明らかに）と「状態」またはコンテキストの概念の両方を認識する必要があります。 プロトコルハンドラーを見たことがある人は、異なるコンテキスト/状態で同じメッセージを別の方法で処理する必要があることを知っています。 たとえば、サービスの「orderable」状態で「data packet」メッセージを取得することは明らかにエラーですが、「data transfer」状態では問題ありません。 状態とイベント、および関連するプロセスが存在するためには、状態/イベントテーブルが必要です。
状態/イベントテーブルは、協調システムの集合的なコンテキストの記述であり、それらを構築することを考えることは、ソフトウェアアーキテクトが亀裂を通って何かが起こるのではなく、すべての可能性を考慮するように強制するという点で有用である。 ただし、状態/イベントテーブルの値と、可能な状態とイベントの数との間には競合が発生する可能性があります。 複雑なネットワークを1つの巨大でフラットなシステムとして見ると、実装するには大きすぎるテーブルがあります。 TMFと私自身のExperiaSphereの作業は、複雑なシステムをそれぞれ独自の状態/イベント関係を持つ「意図モデル」に分割することによってこれを処理しました。 階層的な構成、要するに。 それはNGOSS契約が説明したものです。
ここでのポイントは、両方の論文が独自の最強のポイントであるべきものを逃していることです。 サービスデータモデルがプロセスにイベントを駆動する場合、プロセスはサービスデータモデルだけから必要な情報を取得できます。
あなたがOSS/BSS近代化の話からNGOSS-Contractアプローチを引き出すならば、あなたは最初の決まり文句からOSS/BSS近代化の概念全体を悩ませてきたことが残って プロジェクト方法論に焦点を当てている限り、ボトムアップとトップダウンについて話すことができますが、プロジェクト方法論はプロジェクトを ソフトウェアアーキテクチャは、方法論から出てくる必要があります。 それは別の要素であり、正しいプロセスの結果ですが、大量のデータに杖を振って”トップダウン、トップダウン！”
それは私のタタ紙の問題を要約しています。 ITとネットワークのプロジェクト方法論は、アプリケーションまたはサービスアーキテクチャにつながり、ソリューションのコンポーネントの要件と統合および管理 プロジェクトは出力ではなく、出力へのパスです。 Tata paperの問題は、OSSの近代化への道を探していて、代わりに特定の製品、または少なくともアーキテクチャを探しているときに、プロジェクト方法論のさら TMFは別のパスによって同じ場所に向かっているようです—あなたの元の敵とのパートナーシップによって変換します。
タタの論文は、”業界標準の役割”というセクションで、重要な問題を提起しています。 この論文では、トップダウン設計のためのTMFモデルとONFモデルを挙げていますが、「近代化された」OSS/BSSは、ネットワークおよびサービスエコシステムの残りの部分とより緊密に統合されなければならないことは明らかです。 私たちは、すべての可能なネットワーク戦略のすべての可能な部分のための標準を持っており、いくつかのケースでは、標準も競合しています。 私たちは最近、例えば、二つの異なる操作API仕様の統一のための拍手を聞きました。 私たちは、最初の場所でそれらを持っているようになった方法を尋ねる必要があります。
TMFの論文は、この未来の断片化を受け入れるだけでなく、それに依存しているようです。 OSS/BSSを超えたものの機械化を放棄し、その”超えた”ものを利用して擬似インテグレータとしてサービスを作成することに焦点を当てます。 わかりました、それはTMF（OSS/BSS支配の団体）が取るための不合理な見解ではないかもしれませんが、それはほとんど統一されたイニシアチブ-変革でなければならないものに直面しながら混乱したままにするための公式です。
TMFはOSS/BSSを近代化するための論理的な体であり、TMFは（NGOSS契約で）データモデルを介してプロセスにイベントステアリングの中心的なパラダイムを考案したと私の見解であり、それはこの近代化に不可欠である。 論文で説明されている他のすべて、誰もが開発または調和しているすべてのAPI、運用と管理のあらゆる側面を目的としたすべての標準活動は、そのNGOSS それが行われた場合、結果はまさに”NGOSS”の略です。
TMF NGOSS契約のモデルは、ネットワークドメインに足を踏み入れると、同じように価値があり、さらに価値があります。 真の”契約”状態/イベントプロセスは、ネットワーク部分を含むサービスライフサイクルに関するすべてを管理できます。 したがって、ネットワーク中心のソリューションは、サービス、OSS/BSS、ドメインに簡単に拡張できます。 このアプローチの普遍性は、サービスライフサイクルの自動化が有用であるために普遍的でなければならないため、業界にとっ
また、最先端のcloud-thinkに基づいている必要があります。 両方の論文はそれに同意しているように見えますが、どちらもそれをどのようにもたらすかという問題をスカートしています。 あなたが何かを達成するために現在のツールを使用することを計画している場合は、それらのツールの面であなたのアプローチをフレーム すべての仕様を書くことができるという概念を受け入れることはできませんし、単に上部の目標を下部の任意の機能に変換することもできません。 それは、標準プロセスが結論に至るまでに何年もかかることを考えると、あなたを噛む可能性が特に高いです。 私たちは今日5Gを展開しており、標準は完成しておらず、おそらく2022年までにはなりません。 事業者がすでに臨界点に近づいているインフラストラクチャRoiの低下に直面していることを考えると、その時間があるのだろうかと思います。
NGOSSの契約は約13年間続いており、TMFはかつてそれが非常に限られた牽引力を得ていると私に言った。 私が言ったように、私はメンバー専用のものにアクセスすることはできませんが、現在のTMFの資料では再生されていないようです。 問題は、まず狭いOSS/BSSドメイン内で、次により広いライフサイクル自動化ミッション内で、TMFが独自の（見事でユニークな）洞察を促進する準備ができてい そうであれば、TMFはNGOSSの進化において正当な役割を果たし、サービスライフサイクル全体の自動化の基礎を定義します。 そうでなければ、トーチを拾うのは他の標準団体やオープンソースグループ次第であり、TMFはそれ自身のスペースでの関連性のために戦わなければならない。
