フレームワーク

Frameworxは、通信サービス プロバイダー向けのエンタープライズ アーキテクチャ フレームワークです。

TM フォーラムによって開発されました。

Frameworx は 4 つのフレームワークで構成されています。

• アプリケーション フレームワーク (テレコム アプリケーション マップ(TAM)とも呼ばれる)
• ビジネスプロセスフレームワーク (eTOM)
• 情報フレームワーク（共有情報/データ（SID）モデルとも呼ばれる）
• 統合フレームワーク（TMフォーラム統合プログラム（TIP）で開発）

情報フレームワーク(正式には共有情報/データ モデルまたは SID) は、通信におけるビジネス オブジェクト用の単一の用語セットを提供する統合参照データ モデルです。その目的は、異なる部門、会社、または地理的な場所にいる人々が同じ用語を使用して、同じ現実世界のオブジェクト、プラクティス、および関係を記述できるようにすることです。これは、Frameworx の一部です。

情報フレームワークは、Frameworx 情報モデルとして、ビジネスおよびシステムの観点から、情報/データ参照モデルと共通の情報/データ語彙を提供します。情報フレームワークは、統一モデリング言語を使用して、特定の利害関係者の視点からのニーズを形式化します。

情報フレームワークは、Frameworx ライフサイクルで定義されているように、Frameworx ビューポイント (ビジネス、システム、実装、展開) によって表される 4 つの主要構成要素 (利害関係者) の懸念事項を伝えるための共通言語を提供します。ビジネス プロセス フレームワーク (eTOM)のビジネス プロセスとアクティビティの説明、およびテレコム アプリケーション マップと組み合わせて使用​​すると、情報フレームワークは、ビジネスで理解できるだけでなく、ソフトウェア開発にも使用できるほど厳密な定義を提供することで、組織内のビジネス グループと情報技術グループ間の橋渡しが可能になります。

情報フレームワーク モデルは、さまざまな業界のソースからインスピレーションを得ていますが、その主な起源は、AT&TおよびBT グループの Bill Brook 氏が率いるチームによって作成された Alliance Common Information Architecture (ACIA)と、John Strassner 氏が作成した Directory Enabled Networks - next generation (DEN-ng) モデルです。

2000 年に最初にリリースされたとき、情報フレームワーク モデルはビジネス (BSS) 分野とデバイス管理分野をうまくカバーしていましたが、論理ネットワークと容量を表現する能力が不十分でした。これらの欠陥は、トポロジなどの概念を含むようにモデルを改訂することで解決されていますが、歴史的には、在庫管理などの特定の通信分野ではモデルが十分に活用されていませんでした。

Frameworx はこれらの主要原則に基づいています。

オペレーション サポート システム(OSS) が相互にリンクされると、それらがサポートするビジネス プロセスは IT 資産全体に分散されます。実際には、プロセスはアプリケーション A から始まり、アプリケーション A が何らかのデータを処理し、アプリケーション B を呼び出す必要があることを認識し、アプリケーション B も何らかの処理を行ってからアプリケーション C を呼び出す、という状況になります。その結果、これらのフローが実際にどこにあるかを把握することが非常に困難になります (たとえば、プロセス フローが顧客の注文を受けるためのものである場合、現在その注文を処理しているアプリケーション A、B、または C のどれか)。また、分散型の性質上、プロセスを変更することはさらに困難です。

Frameworx は、アプリケーション間のビジネス プロセスのフローを制御するワークフロー エンジンを使用して、プロセスを集中インフラストラクチャの一部として管理することを提案しています。したがって、ワークフロー エンジンはアプリケーション A でプロセスを開始し、アプリケーション A はワークフロー エンジンに制御を返し、ワークフロー エンジンはアプリケーション B を呼び出します。このように、個々のプロセス フローは中央のワークフロー エンジンによって制御されるため、常にその場所を特定できます。また、エンジンのプロセス定義ツールを使用してプロセスを変更することもできます。明らかに、いくつかの下位レベルのプロセス フローが個々のアプリケーションに組み込まれますが、これはビジネス上重要な処理のレベルより下 (つまり、ビジネス ポリシーとルールが実装されるレベルより下) である必要があります。Frameworx の認定方法論は、顧客が受け入れた間違いなく適切な方法を改善するための機会として、線形に分散されていない設定の範囲に対処するのに役立ちます。

「疎結合」とは、各アプリケーションがシステム全体における他のアプリケーションから比較的独立していることを意味します。したがって、疎結合環境では、1 つのアプリケーションを変更しても、その変更が他のアプリケーションに必ずしも影響を与えることはありません。極端に言えば、これは、アプリケーションが非常に独立しているため、システム全体の動作に影響を与えることなく変更できる「プラグ アンド プレイ」アプリケーションを生み出す機能とみなされることがあります。現時点では、そのような極端はあり得ない理想と考えられています。

「分散システム」は、Frameworx が、すべてのアクティビティを管理するために単一のモノリシック アプリケーションを使用する通信サービス プロバイダー (CSP) に基づいているのではなく、統合され連携する一連のアプリケーションを使用していることを強調しています。

OSS を統合するということは、アプリケーション間でデータを共有する必要があることを意味します。これを効果的に行うには、各アプリケーションが、共有されるデータの一部を他のすべてのアプリケーションがどのように理解/解釈するかを理解するか、共有データの共通モデルが存在する必要があります。これを理解するには、顧客の注文を入力するプロセスを経て、アプリケーション B (課金システム) を使用して請求書を送信する必要のある注文処理アプリケーションについて考えてみましょう。アプリケーション A には顧客の住所の記録があるため、アプリケーション B がこの住所に請求書を送信するようにする必要があります。システム間でこのデータを渡すには、住所情報の共通形式が必要です。各システムで同じ数の住所行を想定する必要があり、各行の長さも同じである必要があります。これはかなり簡単です。しかし、注文アプリケーションがサブ製品のバンドル (銅線、モデム、フィルター セット、ブロードバンド変換で構成されるブロードバンド アクセス製品など) で構成される製品で動作し、課金アプリケーションが単一の製品/注文行のみを想定する場合に発生する困難を想像してみてください。情報を失うことなく階層型製品を非階層型製品に変換することは不可能です。このようにアプリケーション間で共有されるデータの単一の情報モデルは、この問題の解決策となります。これに対する TMF の解決策は、共有情報/データ モデル(SID) と呼ばれます。

1980 年代半ばまで、コンピュータベースの OSS はスタンドアロン アプリケーションとして開発されていました。しかし、1990 年代初頭には、これらを完全に独立したアプリケーションとして使用すると、たとえば、1 つのシステムで注文を受けても、関連するネットワーク機器を構成するために、詳細を別のシステムに再入力する必要があるなどの状況が発生するため、非常に非効率的であることが明らかになりました。スタンドアロンの OSS を相互にリンクして、「フロースルー プロビジョニング」などの機能を実現することで、大幅な効率向上が実現できることが示されました。フロースルー プロビジョニングでは、オンラインで注文すると、人間の介入なしに機器が自動的にプロビジョニングされます。

しかし、何百もの個別の OSS を持つ大規模なオペレータにとって、インターフェースの急増は深刻な問題になりました。各 OSS は他の多くの OSS と「通信」する必要があり、インターフェースの数は OSS の数の 2 乗で増加します。

Frameworx は、共通通信インフラストラクチャ (CCI) の使用について説明します。このモデルでは、OSS は直接相互接続するのではなく、CCI とインターフェイスします。したがって、CCI を使用すると、アプリケーションは CCI を使用して相互にリンクし、連携して動作できます。このように、各アプリケーションには、(他のアプリケーションへの) 多数のインターフェイスではなく、(CCI への) 1 つのインターフェイスのみが必要です。したがって、複雑さは n ²ではなく n のオーダーに軽減されます。

CCI は、セキュリティ、データ翻訳などの他のサービスを提供する場合もあります。

アプリケーションが CCI とどのようにインターフェースするかについての上記の説明から、採用されているテクノロジ (Java/JMS か、Web サービス/SOAP かなど) だけでなく、アプリケーションの機能、使用されるデータ、事前条件と事後条件などについても、これらのインターフェースを文書化する方法が必要であることは明らかです。Frameworx 契約仕様は、これらのインターフェースを文書化する手段を提供するため、これらは契約で定義されたインターフェースです。

Frameworx 契約は、アプリケーション プログラミング インターフェイス (API) 仕様の拡張として考えることができます。

eTOM (enhanced Telecom Operations Map、発音はイートム) は、Frameworx ビジネス プロセス フレームワークです 。

フレームワーク情報は、共有情報/データ モデル(SID) です。

Frameworx ライフサイクル モデルは、組織内での Frameworx の使用と展開を定義することを目的としており、SID、eTOM、および Frameworx アーキテクチャを使用するためのフレームワークを提供します。このモデルは、Zachman Framework、Kernighan、Yourdon、およびObject Management GroupのModel Driven Architectureなど、これまでの多くの研究に基づいています。Frameworx ライフサイクルは、システム開発を要件、システム設計、実装、および運用の 4 つの段階に分けます。

前述のように、Frameworx 契約は、Frameworx システムにおける相互運用性の基本単位です。相互運用性は、Frameworx ライフサイクルで定義された 4 つのビューのそれぞれにとって重要です。たとえば、契約は、提供されるサービスの定義、およびサービスを実装する情報とコードの指定に使用されます。また、契約は、サービスの監視、管理、保守、および契約の外部義務 (SLA (サービス レベル契約) など) の遵守の確保、および何らかの違反があった場合の対策の定義にも使用されます。

アプリケーション フレームワーク (旧称 Telecom Application Map (TAM)) は、主要な Frameworx 成果物の 1 つです。OSS (運用サポート システム) および BSS (ビジネス サポート システム) 機能を提供するさまざまなアプリケーションの役割と機能を考慮します。

そうすることで、フレームワークを参照して調達文書を作成できるようになり、特定のアプリケーションに必要な機能が明確に記述され、既存のアプリケーションの機能の重複が特定され、合理化と機能のギャップの特定が容易になります。

機能分解のレベルは、これらの利点を実現できるレベルですが、過度に規定的になることはありません。

TM フォーラムには、プロセスとデータの明確な定義があります。アプリケーション フレームワークは、機能とデータを認識されたコンポーネントにグループ化する形式化された方法を提供します。これらのコンポーネントは、アプリケーションまたはサービスとして調達可能と見なされます。アプリケーションまたはサービス (Web サービスなど) は、機能/プロセスを実装し、データに基づいて動作またはデータを使用する、比較的粒度の粗いソフトウェアです。日常生活では、ワード プロセッサやメール クライアントなどのアプリケーションを目にしますが、OSS の用語では、アプリケーションは CRM コンポーネント、課金システム、在庫ソリューションなどと見なされます。ただし、これらはある程度分解できることも理解しています。たとえば、課金システムには、評価エンジンなどのいくつかの小さなアプリケーションが含まれます。

「アプリケーション」とは、明確に定義された機能、データ、ビジネス フロー、ルール、インターフェイスで構成される 1 つ以上のソフトウェア成果物の集合として定義されます。これには、アプリケーションとのインターフェイスに使用されるデータ用のデータ モデル、外部および内部のアプリケーション リソースを管理するためのポリシー、アプリケーションとの機能用のフロー モデル、アプリケーション内の機能に対する外部から見えるインターフェイスの契約仕様が含まれます。

アプリケーションは展開可能なパッケージとして実装可能であり、システム市場で入手できます。

アプリケーション フレームワークは、情報フレームワークまたはビジネス プロセス フレームワーク (eTOM)定義の一部ではありませんが、両方にわかりやすい方法でリンクし、それらの間のマッピングも提供します。

• TM フォーラム フレームワーク ページ
• 通信OSSとBSS
• TMFリファレンスページ

• モデル駆動型アーキテクチャ
• サービス指向アーキテクチャ
• 通信管理ネットワーク
• ウェブサービス