テレコミュニケーションAPIでのFrameworxの実装

テレコミュニケーション市場の発展のスピードにより、参加者はビジネスプロセスを継続的に改善し、コストを削減し、市場で新しいサービスを開発して開始する時間を最小限に抑える必要があります。 この場合の大きな問題は、組織内で適切なビジネスモデルを構築することです。 YouMagic.Proサービスを実装する過程で、このプロジェクトに携わり始めた各製品のスペシャリストが独自の方法でその開発を見たという事実に直面しました。 インターフェイス、フォームが変更され、コードを書き直したため、サービスでエラーが発生しました。 ある時点で、前述の要件は元のアーキテクチャとの互換性がなくなったため、他の通信会社でビジネスプロセスがどのように実装されるかを確認することにしました。 分析の結果、TMフォーラムのSID Frameworx参照モデルを導入することにしました。 この記事では、参照モデルとは何か、そして将来、ビジネス要件のさまざまな変化に適応できる通信サービスの開発を開始する必要がある場所について説明します。

参照モデル

それで、参照モデルとは何であり、どこから来たのか。



まず、ビジネスエンジニアリングの概念とエンジニアリングアプローチを検討します。 ビジネスエンジニアリングテクノロジーを使用すると、企業を作成、変更、再編成できるだけでなく、さまざまなコンポーネント（戦略、構造、ビジネスプロセス、情報システムなど）の一貫性を確保することができます。その重要な特徴は、再利用に適した形式化された知識の使用です。



正式な知識とは、記述、文書化、および他の人と共有できる知識です。 それらは、図面、仕様、教科書、手順の形式で、グラフィカルな形式で提示されます。 単語、数字、オブジェクトがあります。 実践面では、再利用可能なリソースと形式化された知識は、次のカテゴリに分類できます。







さまざまな再利用可能なリソースの中で、通信用ソフトウェアの開発、実装、および運用のための参照モデルに興味がありました。 これらは、世界中のさまざまな企業での実際の実装経験に基づいて開発された、ビジネスを組織化するための参照スキーム、手順、および方法を表しています。 この記事では、通信会社向けのFrameworx参照モデルの概念に焦点を当てます。

ゼロから設計よりも既存のモデルを実装する利点

テレコミュニケーションと情報技術、および通信会社が提供するサービスの範囲は、非常に動的に発展し、変化しています。 今では、以前の接続のように、ビジネスで1〜2年かけてサービスを開発することはできません。 現在、サービスが市場に参入するのにかかる時間は月単位です。 それらと一緒に、制御情報システムのコンポーネント、およびビジネスプロセス自体は絶えず開発されています。 同時に、企業には、新しいプロセスの本格的な設計を実行する時間がありません。 システムに新しいサービスを実装する制御モジュールの開発、テスト、および実装について何が言えますか。



電気通信会社のビジネスプロセスを管理する上でのもう1つの困難は、顧客とのやり取りを自動化することで、リアルタイムで提供されるサービスを独立して管理する機会を顧客に与えることです。 ほとんどの場合、これはWebインターフェイスを介して行われます。



ほとんどのプログラマー、または単に技術者は、会社のビジネスプロセスに関する質問に答えます。 または、任意の会社の人生から別の例を挙げます。 反対側から見ました。 クライアントと彼の個人アカウントでの仕事をつなぐこともビジネスプロセスです。 また、ユーザーから隠された多数のビジネスプロセスもあります。 たとえば、残高を補充するときにロックを解除します。 サービスの特定のセットまたはボリュームを注文する際の割引の有効化。 ほとんどの場合、これらのビジネスプロセスはすべてサービスで自動化されています。 ビジネスプロセスが自動の場合、サブジェクト（人）は実質的に存在せず、コードはビジネスプロセスのオブジェクトを管理します。 また、サブジェクトはコードであるため、情報が不十分な場合、人間のような決定を下すことはできません。 このオプションでは、自動コードでそれらを操作するための普遍的で効率的なデータモデルの構築が最初になります。



MTT Business製品のコアを設計するプロセスで、既存の経験を調査し、情報フレームワークを使用するソリューションを見つけました。 これらは、モデル、産業または主題分野のデータを構築するための典型的な構造を記述しています。 主なオブジェクトの一般的な説明（たとえば、これはクライアント、サービス、料金など）から始まり、UML表記で既に説明されているコンポーネントの特定の図までです。 彼らはすでに、同様の問題を以前に解決した専門家の経験のベストプラクティスを持っています。

TMフォーラムとFrameworxを選んだ理由

Tele Management Forum（TMフォーラム）は、電気通信会社とそのサプライヤーを結集して、電気通信業界の情報技術の標準、ガイドライン、モデルを作成する非営利団体です。 この協会は、1988年にBritish TelecomとAT＆Tの主導で設立され、最初にOSI / Network Management Forumと呼ばれました。 1989年の初めまでに、OSI / NMフォーラムプロトコルの最初の仕様が承認され、1990年にはすでに13か国の85社が組織に含まれていました。 将来、TMフォーラムは世界のほぼすべての電気通信会社を統合しました。



TMフォーラムの研究開発の主な分野は次のとおりです。

• 新世代の運用システムおよびソフトウェア（NGOSS）の概念の開発。 これは、TMフォーラムの主な取り組みです。 これは、電気通信業界でOSS / BSSシステムを決定、開発、実装するプロセスを簡素化および標準化することにあります。
  
  
  
  
• プロセスのモデリングと自動化。
  
  
  
  
• サービスの消費者との相互作用の規制。
  
  

TMフォーラムのコンセプトは、情報および通信サービスのマーケットリーダーによって世界中で使用されています。

Frameworx

Frameworxは、NGOSSコンセプトの進化版です。 すでに述べたように、この概念の主なタスクは、通信事業者のビジネスプロセスの標準を定義すること、およびデータ管理システムとインターフェイスで使用される表示形式を統一することです。 Frameworxコンセプトの機能は、いくつかの要因になりました。



1.ビジネスプロセスと適用された技術コンポーネントの分離。

すべてのビジネスプロセスは、集中型インフラストラクチャの一部として管理する必要があります。 このために、一連のアクションを提供するメカニズムが使用されます。 また、あるアプリケーションから別のアプリケーションへのビジネスプロセスの進行状況を監視する責任もあります。



2.要素間に非剛体接続がある分散システム。

Frameworxとは、要素間の非剛体接続で「分散システム」を作成することを意味します。 これは、通信会社のすべての業務を管理するための単一のモノリシックアプリケーションの代わりに、統合された相互作用アプリケーションのセットを使用することが提案されていることを意味します。



3.一般情報モデル。

Frameworxアプリケーションは、さまざまな種類のデータを相互に交換できる必要があります。 さらに、各アプリケーションは、他のアプリケーションが送信データのブロックをどのように解釈するかを理解する必要があります。 このような作業モデルは、一般情報モデルと呼ばれます。







コンセプトの基礎は、ビジネスプロセスのカードとモデルによって形成されます。 Frameworxには次の構造が含まれます。

• 拡張ビジネスプロセスマップeTOM（プロセスフレームワーク）。 通信会社のビジネスプロセスの構造を説明します。 このフレームワークのコア要素はビジネスタスクです。 たとえば、個々のタスクのセットが特定のフローに結合される場合、タスクはプロセス要素になります。
  
  
  
  
• 情報モデルSID（情報フレームワーク）。 通信会社のビジネスプロセスに関係するデータの説明と使用に対するアプローチを定義します。 フレームワークの基本要素は、論理/ビジネスエンティティ（情報オブジェクト）です。
  
  
  
  
• TAMアプリケーションマップ（アプリケーションフレームワーク）。 通信企業の情報環境のコンポーネントの典型的な構造を説明します。 このフレームワークの基本要素は機能です。 これは、可能な限り最小の機能単位を形成する特定の機能セットです。 1つ以上の機能の組み合わせがアプリケーションを形成します。
  
  
  
  
• 統合アーキテクチャとインターフェイスの契約上の定義（統合フレームワーク）。 フレームワークの基本要素はサービス/契約です。 サービスは、環境と対話するためにシステムによって外部に公開される機能と情報オブジェクトの組み合わせです。 サービスは、他のアプリケーションがアプリケーションについて知っておくべきことです。
  
  
  
  
• ビジネスメトリックの参照モデル。
  
  
  
  
• 実用的な推奨事項と使用例。
  
  

SIDフレームワーク

情報モデルは、Frameworxの不可欠な部分であり、通信会社のビジネスプロセスに関係するデータの説明と使用に対するアプローチを定義します。



情報構造（SID）は、ビジネスプロセスの実装に必要なすべての情報の基本モデルおよび共通辞書です。 SIDを使用すると、メンテナンス、システム統合、開発、設計の複雑さが軽減されます。



実践の観点から、SIDフレームワークは図の形で表すことができます。

SIDをどのように、どこで適用したか

MTT Business製品には2層アーキテクチャがあります。

• 内部に必要なロジックのみを含むWebポータル。
  
  
• すべてのビジネスプロセスの実装を備えたバックエンドAPI。
  
  

ポータルは、HTTP JSON RPC2.0を介してバックエンドAPIと対話します。 その中のサービスのほとんどが通信サービスの提供を含むことを考えると、第3のレベル、つまり通信ネットワークのレベルがあると言えます。



このような決定を行う際、1つのMTT Business製品ポータルに加えて、同様のサービスとビジネスルールを実装する他のポータルをAPIに接続できることも理解しました。 私たちの期待は満たされ、MTT Business製品の運用開始から1年後、2つのパートナーを同様のサービスとAPIに大幅な変更なしで接続しました。



APIでビジネスロジックを実装するために、いくつかのSIDフレームワークドメインを実装しました：製品、顧客、サービス、リソース。 開発段階でのMTTビジネスサービスの実装では、これらのドメインのすべてのビジネスエンティティ（ABE）を実装する必要はありませんでした。 これは、たとえば、サービスサポートプロセスが他のシステムに実装されており、顧客問題、顧客SLA、サービストラブルなどのビジネスエンティティがこれらのシステムでカバーされているためです。 次の図は、MTT Businessで実装されているビジネスエンティティを反映しています。





MTT Businessには、MTTパートナーが同様のテレコムサービスを実装できるようにするプライベートAPIがあります。 APIのみに注目すると、SIDフレームワークを完全に反映していないことに気付くでしょう。 内部的に実装され、ユーザーAPIから隠されたコアを形成します。 この選択は意図的なものでした-API自体は、抽象化ではなく最終的なビジネスプロセスを反映しています。



SIDには、異なるドメインのビジネスエンティティ間の相互作用を実装するための推奨事項も含まれています。 私たちの場合、主な相互作用は製品、サービス、リソース間でローカライズされています。 これは、対応するSID図に最もよく反映されます。







これらのビジネスエンティティとドメインがMTT Businessでどのように使用されるかを視覚的に表現するために、下の図はMTT Businessの重要なサービスの1つであるVirtual PBXサービスのマーケティング名を反映しています。

次は？

いずれの選択も、それがもたらす影響のその後の評価を伴います。 正式かどうか。 もちろん、このアプローチを選択したとき、コード、システム、サービス、製品のさらなる開発に効果があるかどうかはわかりませんでした。 そして、彼らは、おそらく内部的なものであるとはいえ、正式な監査と評価が彼ら自身に必要であると仮定しました。 ただし、「寿命テスト」は自動的に合格しました。 多数の改善、新しいサービスの導入、マーケティングキャンペーンの実装などの過程で、多くの場合、コードの改良は最小限でした。これにより、参照情報モデルを見ずに、建築設計のサービスで可能なビジネスアイデアよりも多くのビジネスアイデアを実装できました。 現在、企業レベルでデータ管理にこのアプローチを実装して、統合の戦略的目標と2週間でMTTプラットフォームでのサービスの作成を実装する計画があります。



使用したソース



ビジネスエンジニアリングの参照モデルと技術

クドリャフツェフD.V. ビジネスエンジニアリングテクノロジー：教科書。 手当/ D.V. クドリャフツェフ、M.Yu。 アルズマニャン、L.Yu。 グリゴリエフ。 -SPb。：ポリテクニックの出版社。 大学、2014年-427秒