(57)【要約】１実施例において、セカンドデーオペレーションのトポロジーベースの管理のための方法は、第２のシステムで動作しているクラウドサービスを識別すること、第１のシステムを介して、該第２のシステムの既存の実現済みのトポロジーを、該第１のシステムの推測された実現済みのトポロジーとして発見すること（該既存の実現済みのトポロジーは該第２のシステムによって提供される）、該第１のシステムによる該推測された実現済みのトポロジーのインスタンス化時に、該第１のシステムを介して、該クラウドサービス内で実行される管理プロセスを定義すること、及び、該第１のシステムを利用して該管理プロセスを実行することを含むことができる。【選択図】図３
2017534109.tif 000002
【特許請求の範囲】
【請求項１】
セカンドデーオペレーションのトポロジーベースの管理のための方法であって、
第２のシステムによって配置もしくは管理されるクラウドサービスを識別するステップと、
前記第２のシステムによって管理される既存の実現されているトポロジーを、第１のシステムによって、該第１のシステムの推測された実現済みのトポロジーとして発見するステップであって、前記既存の実現されているトポロジーは、前記第２のシステムによって提供されるかまたは、該第２のシステムによって変更もしくは管理されることからなる、ステップと、
前記第１のシステムによる前記推測された実現済みのトポロジーのインスタンス化時もしくはその後に、該第１のシステムによって、該クラウドサービス内で実行される管理プロセスまたはライフサイクル管理アクションを定義するステップと、
前記第１のシステムを用いて前記実現されているトポロジーに対して前記管理プロセスを実行するステップ
を含む方法。
【請求項２】
前記既存の実現されているトポロジーを発見するステップが、コンフィグレーション管理データベース（ＣＭＤＢ）内における関係を調べることによって前記既存の実現されているトポロジーを発見することを含む、請求項１の方法。
【請求項３】
前記第1のシステムを用いて、前記発見された、推測された実現済みのトポロジーを改良するステップを含み、該改良するステップが、該推測された実現済みのトポロジーに複数のポリシーを関連付けることを含むことからなる、請求項１の方法。
【請求項４】
前記発見された、推測された実現済みのトポロジーを改良する前記ステップが、前記推測された実現済みのトポロジーに複数のＬＣＭＡを追加することを含むことからなる、請求項３の方法。
【請求項５】
前記発見された、推測された実現済みのトポロジーを改良する前記ステップが、
ＧＵＩを介して変更を入力することと、
前記発見された、推測された実現済みのトポロジーに対する変更をコードで書くこと
とのうちの少なくとも一方によって実行されることからなる、請求項１の方法。
【請求項６】
前記発見するステップが、
ドメイン内の配置されたシステムに関する知識と、
前記ドメイン内の前記配置されたシステム間の関係と、
前記ドメイン内のノードタイプに固有のポリシーと
に基づいて前記推測された実現済みのトポロジーを発見することを含むことからなる、請求項１の方法。
【請求項７】
前記管理プロセスを定義するステップが、
プロバイダー選択プロセスと、
配置プロビジョニングもしくは移動プロセスと、
動作監視プロセスと、
セキュリティ監視プロセスと、
使用監視プロセスと、
コンプライアンス監視プロセスと、
イベント及びインシデントを処理することと、
通知及び推奨を管理することと、
改善プロセス
とのうちの少なくとも１つを含む管理プロセスを定義することを含むことからなる、請求項１の方法。
【請求項８】
前記管理プロセスを実行する前記ステップが、前記推測された実現済みのトポロジーを実行計画に変換することを含み、前記実行計画は、前記推測された実現済みのトポロジーに基づいてクラウドサービスをインスタンス化するための実行可能なロジックを含み、該クラウドサービスのインスタンス化がポリシーによってガイドされることからなる、請求項１の方法。
【請求項９】
前記実行計画に基づいて、前記実現済みのトポロジーを変更し、監視し、及びインスタンス化するステップと、前記第１のシステムによって追跡された前記実現済みのトポロジーを更新するステップを含む、請求項８の方法。
【請求項１０】
セカンドデーオペレーションのトポロジーベースの管理を容易にするためのシステムであって、
前記システムは、クラウドサービス管理を開発し、実行し及びサポートするためのプラットフォームを備え、
前記プラットフォームは、
前記プラットフォームによって提供も管理もされていないクラウドサービスの既存の実現されているトポロジーを、該プラットフォーム用の推測された実現済みのトポロジーとして発見するための発見エンジンと、
発見されたクラウドサービスの前記推測された実現済みのトポロジーを格納するためのコンテンツリポジトリと、
ＬＣＭＡ及びポリシーガイダンスを利用して前記推測された実現済みのトポロジーを編集するためのユーザーインターフェースと、
前記発見された、推測された実現済みのトポロジーを更新するために、該トポロジーに対して実行される複数の管理プロセス
を含むことからなる、システム。
【請求項１１】
前記発見エンジンがさらに、前記既存の実現されているトポロジーの更新を受け取って、該更新された既存の実現されているトポロジーを再発見するためのものであり、前記推測された実現済みのトポロジーは最良の推測であり、前記推測された実現済みのトポロジーに関する欠落しているトポロジー情報は、手動更新または自動ツールによって更新可能である、請求項１０のシステム。
【請求項１２】
前記発見エンジンは、別のシステムから、インスタンスに対する変更及び通知に関する情報を受け取り、前記発見エンジンは、前記変更を、格納されているインスタンスの更新に反映することからなる、請求項１０のシステム。
【請求項１３】
前記推測された実現済みのトポロジーに対するポリシーによってガイドされるアクションを実行するための実行エンジンを備える、請求項１０のシステム。
【請求項１４】
前記既存の実現されているトポロジーは、前記プラットフォームによって提供される第１の既存の実現されているトポロジーを含み、さらに、前記プラットフォームによって提供されないかまたは他のシステムによって管理することもできる第２の既存の実現されているトポロジーを含むことからなる、請求項１０のシステム。
【請求項１５】
セカンドデーオペレーションのトポロジーベースの管理を容易にするためのコンピュータープログラム製品であって、
前記コンピュータープログラム製品は、コンピューター使用可能プログラムコードを含むコンピューター可読記憶媒体を備え、
前記コンピューター使用可能プログラムコードは、
プロセッサによって実行されたときに、プラットフォームによって提供も管理もされていないクラウドサービスの既存の実現されているトポロジーを、該プラットフォーム用の推測された実現済みのトポロジーとして発見するためのコンピューター使用可能プログラムコードと、
プロセッサによって実行されたときに、発見されたサービスの前記予測された実現済みのトポロジーを格納するためのコンピューター使用可能プログラムコードと、
プロセッサによって実行されたときに、ＬＣＭＡ及びポリシーガイダンスを用いて前記推測された実現済みのトポロジーを編集するためのコンピューター使用可能プログラムコードと、
プロセッサによって実行されたときに、前記発見された推測された実現済みのトポロジーに対して処理される管理プロセスを確立するためのコンピューター使用可能プログラムコード
を含むことからなる、コンピュータープログラム製品。
【請求項１６】
前記推測された実現済みのトポロジーは、トポロジーモデルまたはトポロジーテンプレートに関連付けられる必要はない、請求項１５のコンピューター可読記憶媒体。
【請求項１７】
プロセッサによって実行されたときに、前記推測された実現済みのトポロジーを編集するための前記コンピューター使用可能プログラムコードは、前記推測された実現済みのトポロジーに細部及び要素を追加するためのプログラムコードを含むことからなる、請求項１５のコンピューター可読記憶媒体。
【請求項１８】
プロセッサによって実行されたときに、前記推測された実現済みのトポロジーを編集するための前記コンピューター使用可能プログラムコードは、前記推測された実現済みのトポロジーに、ＬＣＭＡノードタイプ及びポリシーを関連付けるためのコンピュータープログラムコードを含むことからなる、請求項１５のコンピューター可読記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
ますます多くの企業体及び個人が、たとえば、いくつかあるクラウド関連の目的の中でも特に、商品やサービスを販売したり、業務記録を維持したり、個人にコンピューティング資源へのアクセスを提供したりするために、クラウドコンピューティング、及び、クラウドコンピューティングシステムを通じて提供されるサービスを利用するようになってきている。クラウドコンピューティングは、クラウドの利用者に、該クラウド上に構築されたサービスもしくはそれらのサービスの組み合わせとして、スケーラブルで統合化されたコンピューティング、ストレージ（記憶装置）、及びネットワーキング能力を提供する。クラウドコンピューティングシステムがあるエンティティ（企業体など）のために生成される場合には、クラウドを、該エンティティによってまたは該エンティティのために、設計し、提供（プロビジョニング）し、配備（デプロイ）し、及び維持することができる。クラウドコンピューティングシステムを設計し、提供（プロビジョニング）し、配備（デプロイ）し、及び維持することは、難しい作業でありうる。
【先行技術文献】
【特許文献】
【０００２】
【特許文献１】（補充可能性あり）
【図面の簡単な説明】
【０００３】
【図１】本開示にしたがう設計図のブロック図である。
【図２】本開示にしたがうアーキテクチャ由来のトポロジーを示すブロック図である。
【図３】本開示にしたがう、クラウドサービスを設計し、提供（プロビジョニング）し、配置（デプロイ）し、監視し、及び管理するためのトポロジーベースの管理ブローカーの機能の概要を示すブロック図である。
【図４】本開示にしたがう、クラウドサービスを設計し、提供（プロビジョニング）し、配置（デプロイ）し、監視し、及び管理するためのトポロジーベースの管理ブローカーの機能の概要を示すブロック図である。
【図５】トポロジーベースの管理ブローカーの共通のプラットフォームを示すブロック図である。
【図６】本開示にしたがう、トポロジーを設計する方法を示すフローチャートである。
【図７】本開示にしたがうシステムの１例を示す。
【図８】本開示にしたがうシステムの１例を示す。
【図９】本開示にしたがうシステムの１例を示す。
【図１０】本開示にしたがう、トポロジーのノードに関連付けられた構成要素のトポロジーを構成する構成要素のプラットフォームの１例を示すブロック図である。
【発明を実施するための形態】
【０００４】
クラウドコンピューティングシステムは、複数のインスタンスでトポロジーを利用しながら、ユーザーにサービスを提供することができる。従来のシステム及び方法は、該システムに既知であり及び／又は該システムによって提供（プロビジョニング）されるトポロジーを要求することができる。たとえば、従来のシステムは、トポロジーを提供（プロビジョニング）して、該提供（プロビジョニング）されたトポロジーを該システムから管理することに頼ることができる。いくつかの実施形態では、システムによって生成されないトポロジーを管理することは利点でありうる。本明細書に記載されている方法及びシステムは、システムによって生成されなかったトポロジー（たとえば推測された実現済みの（inferred realized）トポロジー）を発見して管理するための能力を提供することができる。いくつかの実施形態では、システムは、トポロジー設計、トポロジーモデル、及びトポロジーテンプレートを実現されているトポロジーインスタンスから分離することによってイネーブル（たとえば使用可能）にされる。システムは、実現されているインスタンスであって、該システムが、該インスタンス用のモデル及び／又は設計を有していないところの該インスタンスを管理することができる。さらに、システムは、該実現されているトポロジーを、外部のシステムから、インポートし（取り込み）、及び／又は発見し、及び／又は変更すること、及び、該実現されているトポロジーを管理するために該実現されているトポロジー（の経過など）を追跡し続けることを可能にすることができる。
【０００５】
クラウドコンピューティングは、ユーザーのデータ、ソフトウェア、及び計算に対するサービスを提供する。クラウドサービス内のリソースに配置（デプロイ）されているアプリケーションは手動で配置（デプロイ）される場合がある。この手動配置には、かなりの管理時間がかかる。アプリケーションを手動で配置（デプロイ）するステップは、インフラストラクチャの提供（プロビジョニング）及びインスタンス化を含みうる。これは、ミドルウェアやＤＢ＋アプリケーションなどのアプリケーションもしくはプラットフォームのインストールをリンクすること、または、配置（デプロイ）されたインフラストラクチャに関する十分な知識を有していてもいなくてもイメージを配置（デプロイ）することを含みうる。手動配置はさらに、アプリケーションを配置することを試みるユーザーによって起動される多くの一連のステップを含みうる。したがって、配置されたインフラストラクチャにアプリケーションを手動でリンクすることは、大量のコンピューティング資源及び人的資源を消費し、また、ミス、並びに、アプリケーションと背後にあるインフラストラクチャとの間の矛盾する問題を引き起こし得る。配置されたインフラストラクチャへのアプリケーションのリンクを、いくつかのツール、スクリプト、及び実行ファイルで自動化することができ、この場合、オーケストレータが、それらのプロセスの一連の実行を自動化する。クラウドサービス内のリソースに配置されるアプリケーションの設計、提供（プロビジョニング）、配置（デプロイ）、及び管理（ないし維持）に使用されるいくつかのデバイス（装置）は、データセンター、プライベートクラウド、パブリッククラウド、マネージドクラウド（managed cloud）、ハイブリッドクラウド、及びそれらの組み合わせを含むことができる。
【０００６】
より具体的には、ネットワークを介してユーザーに提供されるクラウドサービスを、クラウドサービスマネージャを用いて、設計し、提供し、配置し、及び管理することができる。クラウドサービスプロバイダーやその他の（企業などの）エンティティもしくは個人は、クラウドサービスを設計し、提供し、また、配置することができる。クラウドサービスマネージャは、いくつかのサービス、アプリケーション、プラットフォーム、または、クラウド環境において配置され、実行され、及び管理されるインフラストラクチャ能力から適切に構成されたクラウドサービスを管理する。この場合、それらの設計をユーザーに提供することができ、該ユーザーは、カタログから市場またはＡＰＩコールを介してそれらの設計を注文し、要求し、及び購入して、同じメカニズムによって、それらの設計に基づいて配置されたクラウドサービスのライフサイクルを管理することができる。クラウドサービスプロバイダー（たとえばファーストデーオペレーション）とクラウドサービスマネージャ（たとえばセカンドデーオペレーション）は同じエンティティであっても異なるエンティティであってもよい。より詳細に後述する、ヒューレットパッカード社によって設計されて供給されているCLOUD SERVICE AUTOMATION（ＣＳＡ）などのクラウドサービスマネージャにおけるサービス設計は、「設計図（blueprint）」で表現される。
【０００７】
設計図は、サービスを構成する全ての構成要素を提供もしくは管理して、特定のライフサイクル管理アクションを実行するために実行されるワークフローの集合に関してサービスを記述する。設計図によって定義されているそれらのワークフローの機能のうちのいくつかは、リソースプロバイダーに対するコールとして実行される実際のライフサイクル管理アクションである。該リソースプロバイダーは、それらのコールを、リソースプロバイダーによって提供された特定のリソースまたはインスタンスに固有の良好に形成されかつ交換された命令に変換する。
【０００８】
図１は、本明細書に記載されている原理の１例にしたがう設計図（１００）のブロック図である。設計図中のそれぞれのオブジェクト（１０２−１、１０２−２、１０２−３、１０２−４、１０２−５、１０２−６、１０２−７、１０２−８、１０２−９、１０２−１０、１０２−１１、１０２−１２）を、リソースプロバイダーを呼び出すアクションワークフローに関連付けることができる。クラウドサービスを設計し、提供し、配置し、及び管理する設計図（１００）アプローチにはいくつかの課題が存在する。設計図は、関係によって関連付けられた特性及びアクションを含むオブジェクトからなるが、該設計図の構造は、たとえば、クラウドサービスをサポートするシステムの実際の物理的なアーキテクチャなどの物理的なトポロジー（物理トポロジー）との関係を識別しない。これは、たとえば、システムに関連付けられたポリシーを記述するために、追加のメタデータを設計図（１００）に関連付けることを難しくする。さらに、ポリシーと設計図（１００）中のノードとのこの関連付けは、配置されることになるクラウドサービスの設計者または管理者にとって直感的に理解できるものではない。
【０００９】
さらに、同じ理由によって、設計図（１００）の構造は、CONTINUOUS DELIVERY AUTOMATION（ＣＤＡ）がそうであるように、アプリケーションのモデルまたはインフラストラクチャのテンプレートとして使用するのが難しい。ＣＤＡは、バージョン、構成（コンフィグレーション）、及び他のアプリケーション要素を管理しつつ、インフラストラクチャ要件及びアプリケーション要件を独立にモデル化するトポロジーデザイナー内で使用されるシステムツールである。ＣＤＡも、ヒューレットパッカード社によって開発されて供給されている。上記と同じ理由によって、設計図（１００）の構造は、アプリケーションのモデルとして使用するのが難しい。なぜなら、設計図は、該アプリケーションのアーキテクチャを記述していないからである。さらに、設計図は、インフラストラクチャのテンプレートとして使用するのが難しい。なぜなら、設計図は、インフラストラクチャのアーキテクチャを記述していないからである。この結果、アプリケーションのモデル並びにインフラストラクチャもしくはプラットフォームのテンプレートをモデル化し、及び、アプリケーションのモデルとインフラストラクチャもしくはプラットフォームのテンプレートを互いにマッピングすることを目的とするシステムは、該設計図と簡単には両立しない。なぜなら、それらは、それらのサービスをモデル化する異なる方法に基づいているからである。
【００１０】
本システム及び方法は、クラウドサービスを構成するシステムの物理的なアーキテクチャを定義するアーキテクチャ記述トポロジーを記述する。図２は、本明細書に記載されている原理の１例にしたがう、アーキテクチャ由来のトポロジー（２００）を示すブロック図である。図２に示されているように、アーキテクチャ由来のトポロジー（２００）は、互いに関連付けられた複数のノード（２０１、２０２、２０３、２０４、２０５、２０６、２０７、２０８、２０９、２１０、２１１、２１２、２１３、２１４、２１５）を含むことができる。トポロジー（２００）内のノード間の関連付けは、白抜き矢印によって示されている。トポロジー（２００）内の複数のノード（２０１、２０２、２０３、２０４、２０５、２０６、２０７、２０８、２０９、２１０、２１１、２１２、２１３、２１４、２１５）を、塗りつぶし矢印によって示されているように、互いに集約させることもできる。集約（aggregation）は、単一の接続が維持することができるスループットを超えてスループットを高め、及び、リンクの１つが故障した場合に備えて冗長性を提供するのと同時に、複数のネットワーク接続を組み合わせる（集約する）ことを記述するために使用されるコンピューティング用語である。
【００１１】
たとえば、ロード（負荷）バランサ（２０１）、ウェブサーバーサービス（２０２）、アプリケーションエンタープライズアーカイブ（２０３）、及びデータベース（２０４）は、互いに関連付けられている。ウェブサーバーサービス（２０２）は、ウェブ仮想マシン（２０５）、そのセキュリティグループ（２１３）及びウェブ仮想ローカルエリアネットワーク（２０９）と集約される。同様に、アプリケーションエンタープライズアーカイブ（２０３）は、JavaBeans Open Source Software Application Server（ＪＢｏｓｓ）サービス（２０６）、ＪＢｏｓｓ仮想マシン（２０８）及びこれに関連するセキュリティグループ（２１４）、及び、セキュアアプリケーション仮想ローカルエリアネットワーク（２１０）などのアプリケーションサーバーサービスと集約される。さらに同様に、データベース（２０４）は、データベース仮想マシン（２０７）及びそのセキュリティグループ（２１５）、及び、セキュアデータベース仮想ローカルエリアネットワーク（２１１）と集約される。ウェブ仮想ローカルエリアネットワーク（２０９）、セキュアアプリケーション仮想ローカルエリアネットワーク（２１０）、及びセキュアデータベース仮想ローカルエリアネットワーク（２１１）はルーター（２１２）に関連付けられる。
【００１２】
したがって、アーキテクチャ由来のトポロジー（２００）のインスタンス化に基づくクラウドサービスを、該トポロジー内の複数のノード間で定義された複数の関係を有するノードのトポロジーとして表すことができる。複数の特性及びアクションは、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。さらに、複数のポリシーが、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。さらに、複数のライフサイクル管理アクション（ＬＣＭＡ）が、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。
【００１３】
したがって、本システム及び方法は、トポロジーと設計図の両方をサポートすると共に、同じライフサイクル管理エンジンを使用するクラウドサービスブローカーまたはマネージャを記述する。図３に関連して説明するライフサイクル管理エンジンは、クラウドサービスのライフサイクル管理、及び、アプリケーションのモデルとインフラストラクチャのテンプレートのマッピングをサポートする。本システム及び方法はまた、クラウドサービス内の提供（プロビジョニング）プロセス、配置（デプロイ）プロセス、監視プロセス、及び改善プロセスを管理するためのポリシーベースのフレームワークを記述する。さらに、本システム及び方法は、より詳細に後述するように、ＣＳＡ、ＣＤＡ、及び設計図によってサポートされる利用（使用）モデルをサポートする。
【００１４】
本明細書及び特許請求の範囲で使用されている「自律計算」、「自律型コンピューティング」という用語は、予測できない変化に適合する一方で、ユーザー及びオペレータに対して固有の複雑さを隠す分散したコンピューティングリソースの自己管理特性として広義に理解されるべきことが意図されている。自己管理には、自己コンフィグレーション、自己最適化、自己監視、自己改善（自己修復）、自動提供（プロビジョニング）、自動改善、または、それらの組み合わせを含めることができる。
【００１５】
本明細書及び特許請求の範囲で使用されている「ブローカー」という用語は、クラウド内のトポロジーの設計、提供（プロビジョニング）、配置（デプロイ）、及び、そのトポロジーに基づいてインスタンス化されたサービスの維持（ないし保守）及びライフサイクル管理を管理する任意のコンピューティング装置またはコンピューティング装置のネットワーク内のコンピューティング装置の集合として広義に理解されるべきことが意図されている。
【００１６】
本明細書及び特許請求の範囲で使用されている「クラウドサービス」という用語は、リアルタイム通信ネットワークを通じて接続された複数のコンピューティング装置を介して提供される任意の数のサービスとして広義に理解されるべきことが意図されている。クラウドサービスには、分散したハードウェア資源及びソフトウェア資源を実施ないし実装する分散システムで提供されるサービスを含めることができる。１例では、クラウドサービスを、プライベートクラウド、パブリッククラウド、マネージドクラウド、ハイブリッドクラウド、または、それらの組み合わせで提供される任意のサービスとすることができる。別の例では、クラウドサービスを、たとえばデータセンターなどの物理的に独立したマシンで提供されるサービスとすることができる。
【００１７】
本明細書及び特許請求の範囲で使用されている「ハイブリッドクラウド」という用語は、複数のクラウドサービスを提供するために互いに結合された複数の固有のコンピューティングクラウドとして広義に理解されるべきことが意図されている。
【００１８】
さらに、本明細書及び特許請求の範囲で使用されている「ノード」または「コンピューティング装置」という用語は、ネットワーク内の任意のハードウェア装置、仮想デバイス（仮想装置）、ハードウェア装置のグループ、仮想デバイス（仮想装置）のグループ、または、それらの組み合わせとして広義に理解されるべきことが意図されている。ノードには、たとえば、多くのタイプのハードウェア装置及び仮想デバイス（仮想装置）の中でも特に、サーバー、スイッチ、データ処理装置、データ記憶装置、ロードバランサ、ルーター、及び、それらの仮想実施形態を含めることができる。さらに、ノードは、該ノードがその一部であるトポロジーの実行及びインスタンス化の前の本明細書に記載されているハードウェア装置及び仮想デバイス（仮想装置）を表すことができる。
【００１９】
さらに、本明細書及び特許請求の範囲で使用されている「トポロジー」という用語は、ノードのグラフを表すデータとして広義に理解されるべきことが意図されており、この場合、それらのノード間の枝は、該ノード間の関係を表している。それらのノードは、ネットワーク内に配置された任意の数のコンピューティング装置を含むことができる。したがって、ネットワークのトポロジーは、ネットワーク化されたコンピューティング装置の物理的及び論理的レイアウト、及び、コンピューティング装置間の関係の定義を含むことができる。本明細書においてさらに定義されている複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）を、それらのトポロジー、それらのトポロジーの一部、それらのトポロジー内のノード、それらのトポロジー内のノードのグループ、及び、それらの組み合わせに関連付けることができる。
【００２０】
さらに、本明細書及び特許請求の範囲で使用されている「設計図」という用語は、クラウドサービスの配置（デプロイ）及びクラウドサービスのライフサイクル管理の自動化を可能にする実行フローとして広義に理解されるべきことが意図されている。設計図は、たとえば、オペレーティングシステム、アプリケーションスタック、データベースなどのサービスに含まれる複数のハードウェア及び／又は仮想化された構成要素の機能記述を含むことができる。設計図はさらに、ハードウェアと仮想化された構成要素との間の構成（コンフィグレーション）及び接続性の機能記述を含むことができる。設計図はまた、機能記述を配置（デプロイ）できるようにするための複数の配置モデルを含むことができる。設計図はさらに、ユーザーが、配置（デプロイ）されたサービスのいくつかのオプションの例を構成ないし設定することができるようにするための一組のユーザー構成可能オプションを含むことができる。設計図は、アーキテクチャ由来ではない実行可能なトポロジーの例である。
【００２１】
さらに、本明細書で説明した設計図に加えて、本開示は、実行可能なトポロジーの利用を提供する。したがって、本システム及び方法は、設計図由来のトポロジーとアーキテクチャ由来のトポロジーの両方の実行及びインスタンス化を提供する。設計図由来のトポロジーとアーキテクチャ由来のトポロジーは両方とも実行可能である。したがって、本明細書及び特許請求の範囲で使用されている「トポロジー」という用語は、インスタンス化されるネットワークの特性を定義する実行可能なロジックとして表すことができる実行可能なロジックまたは解釈可能なロジックの任意の組として広義に理解されるべきことが意図されている。トポロジーは、複数のノードを定義することができる。さらに、トポロジーは、それらのノードに、複数のグループとしてまたは個々にまたはそれらの組み合わせで関連付けられた複数のポリシー及びライフサイクル管理アクションを定義することができる。１例では、設計図をトポロジーとして表現することができる。この例では、設計図由来のトポロジーはまた、複数のノードと、それらのトポロジー内のノード、それらのトポロジー内のノードのグループ、それらのトポロジーの一部、トポロジー全体、及びそれらの組み合わせに関連付けられた複数のポリシー及びライフサイクル管理アクションとを定義することができる。
【００２２】
さらに、本明細書及び特許請求の範囲で使用されている「ポリシー」という用語は、クラウドサービス内の提供（プロビジョニング）、配置（デプロイ）、監視、発見、実施、及び改善の管理を支援するために使用される任意のデータまたはメタデータとして広義に理解されるべきことが意図されている。それらのポリシーは、クラウドサービス環境内の複数のコンピューティング装置に関連付けられている提供（プロビジョニング）タスク、配置（デプロイ）タスク、監視タスク、発見タスク、実施タスク、及び改善タスクに適用可能な複数のルールまたはルールの組（集合）を表すことができる。
【００２３】
さらに、本明細書及び特許請求の範囲で使用されている「ユーザー」という用語は、任意の個人または（企業などの）エンティティであって、それらの個人またはエンティティのためにまたはそれらの個人またはエンティティによって、クラウドサービスが、設計され、提供（プロビジョニング）され、配置（デプロイ）され、監視され、ポリシーが実施され、インシデントが改善され、その他のやり方で管理され、または、それらの組み合わせが行われるところの個人またはエンティティとして広義に理解されるべきことが意図されている。１例では、ユーザーは、クラウドサービスの使用をある費用で購入することができる。たとえば、ユーザーは、クラウド資源及びサービスを使用するために会費を支払うことができ、この場合、該ユーザーを加入者（または会員）として分類することもできる。別の例では、ユーザーは、クラウドサービスの設計者または管理者でありうる。さらに別の例では、ユーザーは、クラウドサービスを管理する任意の個人でありうる。
【００２４】
さらに、本明細書及び特許請求の範囲で使用されている「複数の」という用語またはこれと類似の用語は、１（１を含む）から無限大までの任意の正の数として広義に理解されるべきことが意図されている（ゼロは数ではなく数がないことを意味する）。
【００２５】
以下の説明では、説明の便宜上、本システム及び方法を完全に理解できるようにするために、多くの特定の細部が説明される。しかしながら、当業者には、本装置、システム、及び方法を、それらの特定の細部なくして実施できることが明らかであろう。本明細書において「１例」またはこれと類似の用語が使用されている場合には、それは、その例に関連して記載されている特定の特徴、構造、または特性が、記載されている通りに含まれるが、他の例には含まれなくてよいことを意味している。
【００２６】
本システムを、たとえば、ネットワーク内の複数のコンピューティング装置の設計、提供（プロビジョニング）、配置（デプロイ）、及び管理を含む該ネットワーク内の任意のデータ処理状況で使用することができる。たとえば、本システムを、複数のコンピューティング装置が、それが実在であれ仮想であれ、サービス志向のネットワーク内で設計され、提供（プロビジョニング）され、配置（デプロイ）され、及び管理されるクラウドコンピューティング状況で使用することができる。別の例では、本システムを、独立型のデータセンターまたはクラウドコンピューティング状況内のデータセンターにおいて使用することができる。サービス志向のネットワークは、たとえば、複数のアプリケーションをホストするＳａａＳ（Software as aService：サービスとしてのソフトウェア）や、たとえば、とりわけ、オペレーティングシステム、ハードウェア、及び記憶装置を含むコンピューティングプラットフォームをホストするＰａａＳ（Platform as a Service：サービスとしてのプラットフォーム）や、たとえば、とりわけ、サーバー、記憶要素、ネットワーク、及び構成要素（コンポーネント）などの装備をホストするＩａａＳ（Infrastructure as a Service：サービスとしてのインフラストラクチャ）や、ＡＰＩａａＳ（API as a Service：クラウド型ＡＰＩサービス）や、その他の形態のクラウドサービス、またはそれらの組み合わせを含むことができる。本システムを、１つまたは複数のハードウェアプラットフォームにおいて実施することができ、この場合、該システム内のモジュールは１つのプラットフォームにおいてまたは複数のプラットフォームにわたって実行される。それらのモジュールを、種々の形態のクラウド技術及びハイブリッドクラウド技術で動作させることができ、または、クラウドにおいてもしくはクラウド外で実施することができるＳａａＳとして提供することができる。
【００２７】
さらに、本システムを、パブリッククラウドネットワーク、プライベートクラウドネットワーク、ハイブリッドクラウドネットワーク、その他の形態のネットワーク、または、それらの組み合わせにおいて使用することができる。１例では、本システムによって提供される方法は、たとえば、サードパーティーによってネットワークを通じたサービスとして提供される。別の例では、本システムによって提供される方法は、ローカル管理者によって実行される。さらに別の例では、本システムを、単一のコンピューティング装置内で使用することができる。このデータ処理状況では、単一のコンピューティング装置は、本明細書に記載されている装置（デバイス）及び関連する方法を利用して、クラウドサービスを配置（デプロイ）し及び該クラウドサービスのライフサイクルを管理することができる。本明細書に記載されている例では、クラウドサービスの設計、該クラウドサービス内の複数のコンピューティング装置及び関連するソフトウェアの提供（プロビジョニング）、設計されて提供されたクラウド資源及びサービスの配置（デプロイ）、該クラウド資源及びサービスの管理、及びそれらの組み合わせを、サービスとして提供することができる。
【００２８】
本開示の例を、システム、方法、またはコンピュータープログラム製品として具現化することができ、及び、本開示の例は、本明細書では一般的に「回路」、「モジュール」、または「システム」と呼ぶ場合がある、もっぱらハードウェアによる実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態の形態を取ることができる。さらに、本開示の例は、コンピューター可読プログラムコードを含む（ないし格納している）複数のコンピューター可読媒体に具現化されているコンピュータープログラム製品の形態を取ることができる。１以上のコンピューター可読媒体の任意の組み合わせを使用することができる。
【００２９】
非一時的なコンピューター可読媒体を、コンピューター可読信号媒体とは対照的なコンピューター可読記憶媒体とすることができる。コンピューター可読記憶媒体を、たとえば、電子、磁気、光学、電磁、赤外線、もしくは半導体システム／装置／デバイス、または、これらの任意の適切な組み合わせとすることができる。コンピューター可読記憶媒体のより具体的な例は、１以上のワイヤ（電線）を有する電気的接続、携帯型コンピュータディスケット（たとえばフロッピーディスク）、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭまたはフラッシュメモリ）、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、光学式記憶装置、磁気記憶装置、または、これらの任意の適切な組み合わせを含むことができる。本開示の文脈において、コンピューター可読記憶媒体を、命令実行システム／装置／デバイスによってまたはそれらに関連して使用されるプログラムを含むことができもしくは格納することができる任意の有形の媒体とすることができる。
【００３０】
本開示を通じて、種々のコンピューティング装置が記述されている。それらのコンピューティング装置は、データ処理装置、データ記憶装置、及びデータ通信装置を含む実在のまたは仮想のコンピューティング要素を含むことができる。それらの種々の装置を、実在する物理的な装置に関連して説明することができるが、任意の数の該装置を仮想装置（仮想デバイス）とすることができる。それらの仮想装置は、エミュレートされたコンピューターアーキテクチャの仕様及び現実世界のコンピューターの機能に基づくソフトウェアベースのコンピューターを記述するものであるが、複数の関連するハードウェア装置を含み、または、それらのハードウェア装置に機能的に接続される。したがって、本開示の例を、ハードウェア要素、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）ソフトウェア要素、または、ハードウェア要素とソフトウェア要素の組み合わせによって実施することができる。
【００３１】
いくつかの例では、自己コンフィグレーションは、「配置（デプロイ）する」ための指示または命令に基づいてアプリケーションを配置（デプロイ）し及び該アプリケーションを構成（ないし設定）する該アプリケーションの特性を意味する。たとえば、トポロジーを、配置（デプロイ）及び構成（ないし設定）を決定する複数のポリシーに関連付けることができる。別の例では、トポロジーは、アプリケーションの配置（デプロイ）及び構成（ないし設定）を決定するプロビジョニングロジックを含むことができる。該ロジック、ポリシー、またはそれらの組み合わせはトポロジーと共にパッケージ化される（組み込まれる）ので、それらをクラウド管理システムによって自己配置することができる。かかる自己コンフィグレーションは、ワークフローを実行することを含むことができるが、該ワークフローにおいて、それらのアクションは、サービスを提供するために、クラウド環境の複数のアプリケーションプログラミングインターフェース（ＡＰＩ）をコールする。
【００３２】
いくつかの例では、アプリケーションを自動提供（自動プロビジョニング）することができる。たとえば、（実行ファイル、トポロジー、該トポロジーに関連付けられたポリシーを含むことができる）アプリケーションを、サービスとしてインスタンス化するべく選択することができる。それらのポリシーは、監視、イベント処理、インシデント処理、及び改善トポロジーを記述するポリシーを含むことができる。それらのポリシーを、配置（デプロイ）するために、図３及び図４に関連して説明されているシステムなどのプラットフォームに渡すことができる。提供（プロビジョニング）ポリシーを、能力及び要件を含む提供（プロビジョニング）ポリシーをコンテキスト情報で評価することができ、及びＬＣＭＡを実行するためにどのリソースプロバイダーを使用するかを決定するためのリソースプロバイダーポリシーを評価することができる提供（プロビジョニング）ポリシーエンジンへの入力とすることができる。監視ポリシーも本明細書で説明されている。
【００３３】
別の例では、アプリケーションを自己提供（自己プロビジョニング）することができる。この例では、ＡＰＩを用いて、図３及び図４のシステムに該ＡＰＩを構築することができる。それらのＡＰＩは、該システムにサービスを提供（プロビジョニング）して最適化させるために実行ファイルすなわちインストール可能な（ソフトウェア）生成物、トポロジー、及びポリシーを渡す。
【００３４】
図３及び図４は、本明細書に記載されている原理の１例にしたがう、クラウドサービスを提供（プロビジョニング）し、配置（デプロイ）し、監視し、発見し（もしくは見つけ）、保護し、及び改善するための設計段階と共に、トポロジーベースの管理ブローカー（３００）のブロック図を示している。図３及び図４のシステムは、より詳細に後述するように、トポロジーと設計図の両方をサポートする一方で、同じライフサイクル管理エンジンを使用する。
【００３５】
１例では、複数のトポロジーデザイナー（３０１）によって、新たにトポロジー（３０２）を設計することによって、トポロジー（３０２）を生成することができる。この例では、複数の提供（プロビジョニング）ポリシー（３０３）を含むようにトポロジー（３０２）を設計することができる。システム（３００）及びトポロジー（３０２）は、サービス（３１２）をインスタンス化するための特定のやり方を定義する（もしくは定める）ことができる。したがって、インスタンス化されたサービス（３１２）を、インスタンス化されたサービス（３１２）の提供（プロビジョニング）中に自己コンフィグレーション（自己構成ないし設定）することができる。別の例では、トポロジー（３０２）を、異なる管理ツールまたは管理ブローカー（３００）を用いて発見する（見つける）ことができる。これらの例では、既存の実現されているトポロジーを、別のエンティティ及び／又はシステムによって提供（プロビジョニング）することができ、及び、異なる管理ツールまたは管理ブローカー（３００）を用いて管理することができる。
【００３６】
別の例では、複数のスティッチング法を用いて、複数のアプリケーションモデル（３１９）と複数のインフラストラクチャテンプレート（３２０）をスティッチする（結合する）ことによって、トポロジー（３０２）を生成することができる。この例では、システム（３００）、及び対応する能力ポリシー、要件ポリシー及び提供（プロビジョニング）ポリシーを有するアプリケーションモデル（３１９）は、トポロジー（３０２）に対して最良のインフラストラクチャテンプレート（３２０）を自己選択することができる。この例では、トポロジー（３０２）を自己設計することができる（または、トポロジー（３０２）は自己設計機能を有することができる）。この場合、トポロジー（３０２）は、本明細書に記載されているように、自己コンフィグレーションする、すなわち、サービス（３１２）をインスタンス化するための特定のやり方を定義することができる。
【００３７】
アプリケーションを、自己コンフィグレーション可能なものであることに加えて、自己回復が可能なものとすることができる。自己回復は、サービス（３１２）またはアプリケーションを監視し、メトリクスなどの収集されたデータに基づいて生成されたインシデントを自己改善（ないし自己修正）する該サービス（３１２）または該アプリケーションの能力を意味しうる。いくつかの例では、自己回復は、トポロジー（３０２）に含まれているポリシー（３０３）にしたがって監視し及び改善（ないし修正）することを含むことができる。別の例では、自己回復は、トポロジー（３０２）自体に含まれている改善（ないし修正）ロジック及び監視ロジックを実行することを含むことができる。
【００３８】
図５は、本明細書に記載されている原理の１例にしたがう、図３及び図４のトポロジーベースの管理ブローカー（３００）の共通のプラットフォーム（５００）を高レベルで示すブロック図である。図５に示されているように、ＣＳＡ（５０１）及びＣＤＡ（５０６）の共通のプラットフォームは、サービス設計の側面（５０４）及びサービス実施（サービスフルフィルメント）の側面（５０５）の共通の使用によって表されている。ＣＳＡ（５０１）の場合は、ＣＳＡ（５０１）のセルフサービスポータル（５０２）及びサービス消費（５０３）という側面は、ＣＤＡ（５０６）のＣＤＡ拡張の側面（５０７）が使用するのと同じリソース（資源）を使用する。このように、クラウドサービスをインスタンス化する全ての使用例は、共通のプラットフォームによってサポートされる。したがって、複数のトポロジーデザイナーによって、及び／又は、アプリケーションモデルとインフラストラクチャテンプレートとのスティッチングプロセスによって、トポロジーは新たに設計されうるが、本システム及び方法はまた、本明細書に記載されているシステム及び方法を用いて、同じシステム内で設計図を実行する。以下で、この側面を、図３及び図４に関連してより詳細に説明する。
【００３９】
図３及び図４に示されているように、１つまたは複数のトポロジーデザイナー（３０１）が、クラウドサービストポロジーの種々の例を設計するのに貢献する。代替的には、トポロジーを、図６〜図９に関連してより詳細に説明するように、発見する（見つける）ことができる。１例では、トポロジー設計は、ハードウェア装置、及びグラフィカルユーザーインターフェース（ＧＵＩ）やコーディングスクリプトなどのソフトウェアモジュールを使用する設計ツールを用いて実行される。（人間である）設計者は、設計ツール（３０１）を用いてトポロジーを設計する。したがって、トポロジー（３０２）の設計は、自律的な設計法、及び／又は人間によって提供される設計法によって達成される。１例では、トポロジーデザイナー（３０１）を、インフラストラクチャ及び該インフラストラクチャのライフサイクル状態を指定するインフラストラクチャテンプレート（図４の３２０）を生成することと共に、アプリケーションモデル（図４の３１９）とそれに関連する構成要素を個別に生成することを可能にするＡＰＩを利用するインターフェースとすることができる。図３に示されているように、少なくとも１つの例において、これらの方法は、アプリケーションインフラストラクチャにポリシーを関連付けるために使用され、この場合、該ポリシーは、段階（ステージ）、バージョン、及び／又はコンプライアンスを特定する。
【００４０】
トポロジーベースの管理ブローカー（３００）全体のうちの図３に示されているサブシステムは、クラウドサービス内において、ポリシーを提供（プロビジョニング）し、配置（デプロイ）し、監視し、発見し（すなわち見つけ）、実施し、及び該クラウドサービス内のインシデントを改善（ないし修正）することができるサブシステムを含む。トポロジーが設計図由来であってもアーキテクチャ由来であっても、それらのタスクは全て、ＬＣＭＡ及びポリシーと共にトポロジーを用いて実行される。したがって、本システム及び関連する方法はまた、ＣＳＡまたは他がサポートする全ての使用例（たとえば、cloudfoundry（クラウドファンドリー）、heroky、openshif、Amazon Web Service（ＡＷＳ：アマゾンウェブサービス）beanstalk、Azure及び／又は、管理ブローカー（３００）の通知なしに自動で改善または修正されるもの）をサポートする。ＣＳＡは、「Managing a Hybrid Cloud Service」と題するMaesに対する国際特許出願ＰＣＴ／ＵＳ２０１２／０４５４２９に記載されている（該出願の内容全体は参照により本明細書に組み込まれるものとする）。より詳細に後述するように、図３に示されているサブシステムは、複数のタイプのポリシー及びライフサイクル管理アクション（ＬＣＭＡ）を使用して、配置（デプロイ）されたクラウドサービス内においてポリシーを提供（プロビジョニング）し、配置（デプロイ）し、監視し、発見し（見つけ）、実施し、及び、該クラウドサービス内のインシデントを改善（ないし修正）する。
【００４１】
さらに、トポロジーベースの管理ブローカー（３００）全体のうちの図４に示されているサブシステムは、図３に示されているサブシステムと同じスタックに対して、トポロジーのインフラストラクチャ及びアプリケーション要件を別個にモデル化することができるサブシステムを含む。本システム及び関連する方法はまた、ＣＤＡの使用例などのＣＤＡサブシステムがサポートする全ての使用例（たとえば、cloudfoundry（クラウドファンドリー）、heroky、openshif、Amazon Web Service（ＡＷＳ：アマゾンウェブサービス）beanstalk、Azure及び／又は、管理ブローカー（３００）の通知なしに自動で改善または修正されるもの）をサポートする。ＣＤＡは、「Cloud Application Deployment」と題するMaesに対する国際特許出願ＰＣＴ／ＵＳ２０１２／０４１６２５に記載されている（該出願の内容全体は参照により本明細書に組み込まれるものとする）。
【００４２】
このようにして、図３及び図４のサブシステムは、共通のスタック下で動作し、並びに、トポロジー、実現されているトポロジー、推測されたトポロジー、推測された実現済みのトポロジー、及び、ポリシーを共通に使用する能力を有するコンピューティングシステムと同じ及び／又は異なるトポロジーベースの管理ブローカー（３００）内で共に動作して、トポロジーを構成し、及び、複数のプロバイダーの関連する技術をサポートする全ての使用例をサポートする。したがって、１例では、本システム及び方法は、同じスタック及び／又は異なるスタックにおいて、クラウドサービスの（たとえばアーキテクチャ由来の）設計されたトポロジー、複数のポリシー、及び、トポロジーノードに関連付けられた複数のＬＣＭＡ、トポロジーノードのサブセット、及び／又は、トポロジーノードの全てのセット（全集合）を利用することによって、ＣＤＡ及びＣＳＡによってそれぞれ使用される異なるモデル、テンプレート及び設計図を両立（ないし調和）させる。
【００４３】
図３に示されているように、トポロジーデザイナー（３０１）は、ライフサイクル管理（ＬＣＭ）トポロジー（３０２）を設計して、それを、トポロジーベースの管理ブローカー（３００）に提示ないし与えることができる。１例では、本明細書に記載されているトポロジーデザイナー（３０１）を、トポロジーベースの管理ブローカー（３００）に一体化された部分とすることができる。別の例では、トポロジーデザイナー（３０１）を、トポロジーベースの管理ブローカー（３００）とは別個のものとすることができる。別の例では、複数の人が、トポロジー（３０２）を設計するためにトポロジーデザイナー（３０１）を使用することができる。それらの個人は、トポロジーの設計の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。さらに他の例では、トポロジーデザイナー（３０１）をサードパーティーによって動作させることができる。
【００４４】
ＬＣＭトポロジー（３０２）は、複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、及び、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）間の複数の関係を定義する（ないし定める）ことができる。図３には７つのノードが示されているが、任意の数のノードをトポロジー（３０２）中に設計して、任意のデータ処理目的を達成することができる。１例では、トポロジーベースの管理ブローカー（３００）は、トポロジー（３０２）を拡張マークアップ言語（ＸＭＬ）ファイルとして表現することができる。別の例では、トポロジーベースの管理ブローカー（３００）は、トポロジー（３０２）をJavaScript Object Notation（JSON：ジェイソン）フォーマット（オブジェクトを表すためのJavaScriptスクリプト言語から得られた人間が読むことができるデータ交換用に設計されたテキストベースのオープンスタンダード）で表すことができる。さらに別の例では、トポロジーベースの管理ブローカー（３００）は、トポロジー（３０２）を、人間が読むことができるデータシリアライゼーションフォーマットであるＹＡＭＬ構文フォーマットで表すことができる。
【００４５】
図３では、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）間の関係は、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）を接続する線として示されている。ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、または、それらの組み合わせは、複数のポリシー（３０３）に関連付けられる。ポリシー（３０３）は、ノードもしくはトポロジーを記述する同じファイル内、または、該ノードもしくはトポロジーに関連付けられているファイル内に提供されるデータもしくはメタデータである。１例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、たとえば、トポロジー（３０２）の設計を提示した場合に、管理者によって該トポロジー（３０２）の設計中に実行することができる。別の例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、ユーザーが、たとえば、購入または要求としてトポロジー（３０２）の設計を選択した場合に、該トポロジー（３０２）の設計中に実行することができる。
【００４６】
いくつかの実施形態では、トポロジー（３０２）を、実現されているトポロジーとすることができる。実現されているトポロジーを、トポロジー（３０２）を利用するエンティティによって生成されたトポロジー（３０２）とすることができる。いくつかの実施形態では、トポロジー（３０２）を推測された実現済みのトポロジーとすることができる。該推測された実現済みのトポロジーを、トポロジー（３０２）を利用することを試みるエンティティによって生成されなかったトポロジー（３０２）とすることができる。該推測された実現済みのトポロジーを、発見された（見つけられた）トポロジー（３０２）とすることができる。該推測された実現済みのトポロジーを、ＣＭＤＢ（コンフィグレーション管理データベース）における関係を調べることによって、または、ドメイン内の配置されたシステムに関する関係及び配置されたシステム間の関係を調べることができる類似のシステムにおける関係を調べることによって発見する（見つける）ことができる。
【００４７】
推測された実現済みのトポロジーの発見を、エンタープライズマップデータ及び／又は手動編集、ガイダンス編集、及び／又は、データセンター及び該データセンターによって配置（デプロイ）されたサービスに関する知識を有するオペレータによって行うことができる設計によって支援することができる。いくつかの実施形態では、推測された実現済みのトポロジーの発見を、本明細書に記載されているように、複数の推測された実現済みのインスタンスを生成するための手入力及び／又は手動設計によって支援することができる。推測された実現済みのトポロジーを、トポロジー（３０２）のサービスを管理するシステムとは異なるシステムによって提供されるクラウドサービスのトポロジー（３０２）とすることができる。たとえば、該推測された実現済みのトポロジーを、cloudfoundry（クラウドファンドリー）、heroky、openshif、Amazon Web Service（ＡＷＳ：アマゾンウェブサービス）beanstalk、Azure及び／又は、管理ブローカー（３００）の通知なしに自動で改善または修正されるものに類似のＰａａＳに配置されたサービスに適用することができる。該推測された実現済みのトポロジーは、実現されているトポロジーと同様に動作することができ、及び／又は、該推測された実現済みのトポロジーを、実現されているトポロジーと同様に利用することができる。いくつかの実施形態では、複数のアプリケーションを、セカンドデーオペレーションのために管理ブローカー（３００）において構成ないし構築することができる。いくつかの実施形態では、複数のアプリケーションを、ファーストデーオペレーション無しでセカンドデーオペレーションのために管理ブローカー（３００）において構成ないし構築することができる。
【００４８】
本明細書で使用されている「ファーストデーオペレーション」は、管理ブローカー（３００）におけるアプリケーション開発を意味している。さらに、ファーストデーオペレーションは、アプリケーション開発者及び／又はトポロジー開発者が、管理ブローカー（３００）の配置されたシステムの関係のマップを得ることを可能にすることができる。本明細書で使用されている「セカンドデーオペレーション」は、クラウドサービスのアプリケーションが開発された後における該クラウドサービスの動作、配置、管理、及び提供（プロビジョニング）を含むことができる。したがって、ファーストデーオペレーションのないセカンドデーオペレーションは、管理ブローカー（３００）におけるアプリケーションの開発なくして、クラウドサービスを管理及び／又は提供（プロビジョニング）することを含む。いくつかの実施形態では、ファーストデーオペレーションのないセカンドデーオペレーションを、複数のサービスインスタンスを推測された実現済みのトポロジーにマッピングして、本明細書に記載されている実現されているトポロジーと同じ及び／又は類似のやり方で該推測された実現済みのトポロジーを利用することによって達成することができる。
【００４９】
ポリシー（３０３）は、ノードもしくはトポロジーを記述する同じファイル内、または、該ノードもしくはトポロジーに関連付けられているファイル内に提供されるデータもしくはメタデータである。１例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、たとえば、トポロジー（３０２）の設計を提示した場合に、管理者によって該トポロジー（３０２）の設計中に実行することができる。別の例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、ユーザーが、たとえば、購入または要求としてトポロジー（３０２）の設計を選択した場合に、該トポロジー（３０２）の設計中に実行することができる。
【００５０】
いくつかの実施形態では、ポリシー（３０３）を、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々に関連付けることができる。いくつかの実施形態では、ポリシー（３０３）を、図４に示されているように、複数のアプリケーションモデル（３１９）の各々に関連付けることができる。さらに、いくつかの実施形態では、ポリシー（３０３）を、図４に示されているように、複数のインフラストラクチャテンプレート（３２０）の各々に関連付けることができる。たとえば、ポリシー（３０３−１、３０３−２．３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）を、対応するノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に割り当てることができる。本明細書にさらに記載されているように、ポリシー（３０３−１、３０３−２．３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）は、アプリケーションのコンプライアンスを含むことができる。
【００５１】
本明細書で使用されている、アプリケーションのコンプライアンス及び／又はノードのコンプライアンスは、それぞれ、アプリケーションの所望の状態及び／又はノードの所望の状態である。該コンプライアンスは、異なるシステムによって提供されるポリシーを含むことができる。たとえば、該コンプライアンスを第１のシステムによって提供することができ、トポロジーを第２のシステムによって管理することができる。すなわち、トポロジー及び／又はシステムを別々に提供及び／又は管理することができる。本明細書に記載されているコンプライアンスをモデル化するためのポリシーベースの方法及びシステムは、セカンドデーオペレーション、ＣＳＡ、及び／又は、従来のＳＡタイプのソリューションに適合するクラウドサービスに対する（またはクラウドサービスとの）オペレーションをサポートすることができる。
【００５２】
複数の一般的なポリシーをトポロジーにマッピングすることができる。本明細書にさらに記載されているように、複数の一般的なポリシー（たとえば、一般的なコンプライアンスポリシー）は、本明細書に記載されている一般的なポリシーの中でも特に、ＦＩＰＳ、セキュリティポリシー、及び／又は、パッチングポリシー（patching policy）などのポリシーを含む。それらの一般的なポリシーを、前処理して、トポロジー中を移動し、及び／又はノードタイプを識別し、及び／又は同じもしくは類似の範囲を有する一般的なコンプライアンスポリシーを識別し、及び／又はノードの所望の状態を表現するなどのいくつかの方法を利用してトポロジーにマッピングすることができる。
【００５３】
本明細書にさらに記載されているように、トポロジー及び／またはシステムの管理者及び／または開発者に通知するために、通知ポリシーを利用することができる。いくつかの実施形態では、アプリケーション及び／又はノードの定義された所望の状態と実際の状態との間の隔たりを指定ないし特定することによって、それらの通知を生成し及び／又は送ることができる。より詳細に後述するように、いくつかの実施形態では、それらの通知を、インシデントのタイプに基づいて特定のユーザー及び／又はシステムに送るように指定することができる。いくつかの実施形態では、通知を送ることは、所望の状態と実際の状態との間の隔たりが特定の閾値を超えたときに実行すべきスクリプトを識別することを含むことができる。
【００５４】
さらに、１例では、トポロジーまたはトポロジーの一部にポリシー（３０３）を加えることによって、該トポロジーの設計（ないし構成）を変えることができる。この例では、トポロジー（３０２）の要素に加えられたポリシー（３０３）は、複数の他のポリシーに影響を与えうる。たとえば、あるノードの可用性が高いことを示すポリシーのトポロジー（３０２）への関連付けは、たとえば一群のノードを要求するために、ポリシー（３０３）及びトポロジー（３０２）を全体として発展させうる。このようにして、ポリシーはトポロジー（３０２）の設計を駆動することができる。
【００５５】
ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、またはそれらの組み合わせは、さらに、複数のライフサイクル管理アクション（ＬＣＭＡ）（３０４）に関連付けられる。ＬＣＭＡ（３０４）がそれらのノードに関連付けられる例では、単一のＬＣＭＡを所与の１つのノードに関連付けることができる。複数のＬＣＭＡをトポロジー（３０２）の一部またはトポロジー（３０２）全体に関連付けることができる例では、それらのＬＣＭＡは、リソースプロバイダーの調整（オーケストレーション）を受ける。
【００５６】
ＬＣＭＡは、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）として表され、この場合、それらのＬＣＭＡは、トポロジー（３０２）の実行中に呼び出され（コールされ）、及び、複数のコンピューティング資源が、所与のクラウド能力のライフサイクルを管理するために提供される。１例では、アプリケーションプログラミングインターフェース（ＡＰＩ）を実行するために、該ＡＰＩのＵＲＩ（uniform resource identifiers）を介してそれらのＬＣＭＡにアクセスして呼び出し（コール）を実行することができる。１例では、それらのＬＣＭＡは、ポリシー（３０３）に関連して本明細書に記載されているデータまたはメタデータを含むファイル内の参照によって提供される。
【００５７】
１例では、それらのＬＣＭＡは、デフォルトでは、１つのノードまたは複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）が表しているコンピューティング装置に基づいて、トポロジーの例に関連付けられる。別の例では、それらのＬＣＭＡは、トポロジーの例に関連付けられたポリシー、アプリケーション、及び異なる関連する（もしくは適切な）リソースプロバイダーのポリシーに基づいてアクションを実行するために、リソースプロバイダーをどのようにして選択するかを定義する（ないし定める）複数の機能（もしくは関数）ＦActionを明示的に提供することによって該トポロジーの例に関連付けられる。それらの機能（もしくは関数）は、該トポロジーの例に関連付けられたポリシー、該アプリケーション、及び該異なる関連する（もしくは適切な）リソースプロバイダーのポリシーに基づいてアクションを実行するために、リソースプロバイダーをどのようにして選択するかを定義する（ないし定める）。
【００５８】
本明細書では、ポリシー（３０３）及びＬＣＭＡ（３０４）が、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、アプリケーションモデル（３１９）、インフラストラクチャテンプレート（３２０）、またはそれらの組み合わせに関連付けられることを示すために、ポリシー及びＬＣＭＡは、要素３０３及び３０４でそれぞれ示されている。１例では、ポリシー及びＬＣＭＡとトポロジーの例との関連付けは、図６〜図９に記載されているように、トポロジーデザイナー（３０１）を介して実行され、及び／又は、発見される。
【００５９】
図示されていないが、１例では、グループを構成するノードのサブセット（部分集合）を、複数のポリシー（３０３）及び複数のＬＣＭＡ（３０４）に関連付けることもできる。この例では、複数のノード、たとえば、ノード（３０２−２、３０２−３、３０２−４、３０２−６、３０２−７）を、複数のポリシー（３０３）及びこれに関連付けられている複数のＬＣＭＡ（３０４）にグループとして関連付けることができる。ノードのいくつかのグループ分けがトポロジー（３０２）全体内に存在しうる。１例では、ノードのグループは（部分的に）重なり合っていてもよく、その場合、ノードの第１のグループ内のある１つのノードが、ノードの第２のグループにも属して、それらの第１及び第２のグループの両方のポリシー（３０３）及びＬＣＭＡ（３０４）に従うという場合がある。ポリシー、及びポリシーと個々のノード及びノードのグループとの関連付けについては、より詳細に後述する。
【００６０】
ノードに関連付けられたポリシー（３０３）を、任意のやり方で、表現して、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に結び付けることができる。１例では、ポリシー（３０３）は、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の特性を定義する（ないし明らかにする）ことによって、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられる。別の例では、ポリシー（３０３）は、メタ言語表現によって、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられる。
【００６１】
アプリケーションモデルに関連付けられたポリシー（３０３）を、任意のやり方で、表現して、アプリケーションモデル（３１９−１、３１９−２、３１９−３）に結び付けることができる。１例では、ポリシー（３０３）は、アプリケーションモデル（３１９−１、３１９−２、３１９−３）の特性を定義する（ないし明らかにする）ことによって、アプリケーションモデル（３１９−１、３１９−２、３１９−３）に関連付けられる。別の例では、ポリシー（３０３）は、メタ言語表現によって、アプリケーションモデル（３１９−１、３１９−２、３１９−３）に関連付けられる。
【００６２】
インフラストラクチャテンプレートに関連付けられたポリシー（３０３）を、任意のやり方で、表現して、インフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）に結び付けることができる。１例では、ポリシー（３０３）は、インフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）の特性を定義する（ないし明らかにする）ことによって、インフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）に関連付けられる。別の例では、ポリシー（３０３）は、メタ言語表現によって、インフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）に関連付けられる。
【００６３】
ポリシー（３０３）は、トポロジー（３０２）が実装されることになるかまたは実装されているクラウドサービス環境内の複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、複数のアプリケーションモデル（３１９−１、３１９−２、３１９−３）、及び／又は、複数のインフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）のライフサイクル管理に関連付けられた提供（プロビジョニング）タスク、監視タスク、発見タスク、実施タスク、管理タスク、及び改善（ないし修正）タスクをガイドする（たとえば、これらのタスクが該ポリシーにしたがうようにする）のに適用可能な複数の記述、メタデータ、ワークフロー、スクリプト、ルール、または、ルールの組（集合）である。ポリシー（３０３）は、トポロジーベースの管理ブローカー（３００）のＡＰＩのアクセス制御及び使用（利用）制御を定義する（ないし定める）。さらに、ポリシー（３０３）は、インスタンス化されたサービスを管理または使用するために使用されるＡＰＩのアクセス制御及び使用制御を定義する（ないし定める）。たとえば、監視システム（３１３）によってセキュリティ上の脅威が検出されたときは、改善（ないし修正）オプションは、複数のアクセス制御ポリシーを変更することができる（または該変更することを含むことができる）。
【００６４】
ポリシー（３０３）を、クラウドサービスのトポロジー全体内の複数の個々のノード、ノードの複数のグループ、ノードのクラスの複数のノード、ノードのサブセット、または、クラウドサービスのトポロジー全体、またはそれらの組み合わせに関連付けて、それらに対して動作可能とすることができる。ポリシー（３０３）が、個々のノード、ノードのグループ、またはクラウドサービスのトポロジー全体に対して作動すると、該ポリシーは、クラウドサービスのトポロジー全体内の個々のノード、ノードのグループ、ノードのクラスのノード、ノードのサブセット、または、クラウドサービスのトポロジー全体に対してライフサイクル管理アクションをどのように行うかすなわちどのように実行するかをガイドする。
【００６５】
１つのタイプのポリシー（３０３）の１例は、「ファーストデーオペレーション」に関連付けることができるプロビジョニングポリシーである。プロビジョニングポリシーは、実行されると、トポロジーが提供され、配置され、及び実行されるときに、クラウド及びクラウドサービスを構成するコンピューティング装置及び／又はアプリケーションモデル（３１９）の特性を定義する（または明らかにする）。コンプライアンスポリシー及び／又は段階（ステージ）及びバージョンポリシーを、プロビジョニングポリシーの一部とすることができる。このプロビジョニングは、インフラストラクチャテンプレート（３２０）及びトポロジー（３０２）のプラットフォームを含むことができる。プロビジョニングポリシーは、たとえば、ノードの物理的な位置などの特性の定義を含むことができる。プロビジョニングポリシーはまた、たとえば、地理的なまたは配置タイプのプロビジョニングポリシーの中でも特に、インターネットへのアクセスの有無にかかわらず、またはファイアウォールの使用の有無にかかわらず、ネットワークゾーン、テスト、試作、製造、段階（ステージ）、バージョン、リリース（公開ないし発売）、及び／又は、パッチなどの地理的な位置または配置タイプの位置などの特性の定義を含むことができる。この例では、ポリシーは、サーバー装置に関連付けることができるプロビジョニングポリシー要素であって、該サーバー装置がある国の特定の地理的領域、たとえば、米国の西海岸に対する東海岸などの特定の領域に配置されることを要求し、または、特定のサーバー設備（ないしサーバー機能）、または他の任意の特定の要件及び／又は地理的な位置を要求するプロビジョニングポリシー要素を有することができる。
【００６６】
コンピューティング装置の物理的な位置を定義する（ないし明らかにする）プロビジョニングポリシーに関して、他の特性は、たとえば、該位置のセキュリティのレベル、または、ノードが配置されているインターネットへのアクセスを含むことができる。他のプロビジョニングポリシーはまた、たとえば、いくつかあるプロビジョニングポリシーの中でも特に、ノードが、たとえば、非武装地帯（ＤＭＺ）または境界ネットワークなどのインターネットまたはイントラネットに接続されることになるか否か、ノードがファイアウォールで保護されているか否か、ノードがインターネットにアクセスできるか否か、ノードが別のノードの最上位に配置されることになるか否か、及び、ノードが特定のインフラストラクチャ要素またはプラットフォームを用いて別のノードの最上位に配置されることになるか否かに関係なく、該ノードが結合されているネットワーク内の速度、たとえば該ネットワークの帯域幅を含むことができる。
【００６７】
プロビジョニングポリシーはまた、実行されると、トポロジー（３０２）に基づく提案されたクラウドサービス内のノードの要件及び能力に依存しうる。要件は、いくつかある要件（必要性）の形態の中でも特に、たとえば、処理、メモリ（記憶装置）、及びオペレーティングシステム（ＯＳ）の要件に関連するサーバーまたはネットワーク要件などのノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の要件を定義する（ないし明らかにする）。たとえば、要件ポリシーは、ノードが、特定のオペレーティングシステムなどの該ノードに関連付けられている特定のソフトウェアまたは特定のソフトウェアバージョンを必要とすることを示すことができる。別の例では、要件ポリシーはまた、特定のノードが、該ノードに関連付けられている追加のハードウェア装置（たとえば、特に、サーバー装置、サーバー群、または可用性の高い構成など）を必要としうることを示すことができる。
【００６８】
とりわけ、プロセッサの特性、メモリ、容量、ＯＳ、ミドルウェアのタイプ及びバージョンなどの能力は、それぞれのノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、複数のアプリケーションモデル（３１９−１、３１９−２、３１９−３）、及び／又は、複数のインフラストラクチャテンプレート（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）が何を提供するかを定義する（ないし明らかにする）。したがって、１例では、能力ポリシー（３０３）は、ノードが、ある所定の速さ（速度）でデータを処理できることを示すことができる。別の例では、能力ポリシーは、メモリデバイス（記憶装置）が１テラバイト（ＴＢ）のデータ記憶空間を有することができることを示すことができる。
【００６９】
さらに別の例では、要件ポリシー（３０３）は、ノードが、特定のコンピューティングプラットフォーム、テスト、試作、製造、段階（ステージ）、バージョン、リリース（公開ないし発売）、及び／又は、パッチを必要とすることを示すことができる。トポロジー（３０２）を設計するときに、該トポロジーまたはメタデータの関連付けは、ハードウェアアーキテクチャ及び（アプリケーションフレームワークを含む）ソフトウェアフレームワークを含むコンピューティングプラットフォーム内の複数のハードウェア装置を定義する（ないし明らかにする）データを取得することをサポートする。該メタデータが与えられるかまたは関連付けられると、該メタデータを用いて、たとえば適切なデータセンターなどのコンピューティングプラットフォーム内の適切な要素をより良好に選択するために、プロビジョニングポリシー（３０３）をガイドする。インフラストラクチャテンプレート（３２０）へのアプリケーションモデル（３１９）のスティッチングに関連してより詳細に後述するように、該メタデータが与えられるかまたは関連付けられると、該メタデータを用いて、トポロジーのフラグメントと他のフラグメントとのマッチングをガイドすることもできる。
【００７０】
能力ポリシー（３０３）に関しては、ノードは、該ノードがどのような種類の装置（またはデバイス）であるか、該ノードが実行できるまたは実行しているソフトウェアのバージョンは何か、及び、該ノードは何をすることができるかを定義する（または明らかにする）ことができる。能力ポリシーの１例は、多くの能力の中でも特に、ノードをアプリケーションサーバーとして定義ないし明らかにし、または、ノードが、Java Platform（ジャバプラットフォーム）、EnterpriseEdition（Ｊ２ＥＥ）環境を提供し、または、ノードが、特定のオペレーティングシステムもしくはあるバージョンのオペレーティングシステムもしくは特定のリリースされたあるバージョンのオペレーティングシステムを動作させるという、該ノードに関連付けられた定義を含むことができる。本明細書に記載されているように、これを用いて、たとえば、他に何かを配置（デプロイ）することができるか、または、他のどのような装置がクラウドサービスを使用できるかを決定することができる。
【００７１】
割り当てることができる別のタイプのポリシー（３０３）には監視ポリシーがある。監視ポリシーは、実行されると、いくつかのタイプの監視に関連するポリシー（３０３）の中でも特に、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の動作状況の監視、ノードのセキュリティ監視、ノードのコンプライアンス監視、ノード間及びノードのグループ間の分析、ノードの使用（状況）監視、パフォーマンス監視、及び、たとえば、メトリクスの収集、ビジネスインテリジェンス（ＢＩ）、ビジネスアクティビティ監視（ＢＡＭ）及び分析／ビッグデータデータ統合などのインテリジェンス監視を定義する（ないし明らかにする）ポリシー（３０３）である。
【００７２】
監視ポリシー（３０３）はまた、どのような種類の監視が期待されているか、及び、監視をどのように実施するかを定義する（ないし明らかにする）ことができる。ノード動作に関する監視ポリシー（３０３）の例には、ノード、ノードのグループ、及びクラウドサービス全体の多くの動作パラメータの中でも特に、ネットワーク内の種々のノードのパフォーマンス（性能など）、ＣＰＵレベル及び負荷を監視すること、データが１つまたは複数のノードによって処理される速度またはデータをノード間で交換する速度を監視すること、及び、ネットワークの任意のレベルにおける１つまたは複数のノードで動作しているアプリケーションの動作状態を監視することが含まれる。
【００７３】
別の例では、監視ポリシーはまた、インスタンス化されたトポロジー内で生じた監視されたイベントをどのように処理するかを定義する。この例では、監視ポリシーは、該イベントを受け取って処理すること、該イベントから生じるインシデントの改善に関する決定をすること、及び、該インシデントに関する通知メッセージを送ることに関してイベントハンドラ（３１６）を支援する。プロビジョニング（たとえばファーストデーオペレーション）中のまたはそれとは異なる状況（たとえばセカンドデーオペレーション）にあるトポロジーベースの管理ブローカー（３００）内のイベントの処理についてはより詳細に後述する。すなわち、監視ポリシーは、監視から得られた監視されたイベントへの対処の仕方、たとえば、該イベントをどのように処理するか、該イベントをどこに送るか、どのような装置または個人が該イベントに対処するか、該イベントの処理から生じたインシデントをどのように処理するか、該イベント及びインシデントをどのように処理するか（たとえば、いくつかある処理の形態の中でも特に、イベントを集め、イベントをフィルタリングし、または、イベントを相互に関連付けるやり方）、及び、結果として生じたインシデントをどのように処理するかなどを定義する部分を含む。
【００７４】
監視ポリシー（３０３）はまた、セキュリティに関する監視ポリシー（３０３）を含む。セキュリティポリシー（３０３）は、既知のもしくは疑わしいセキュリティ問題に関連しているものとして既知の異常な挙動をどのように監視するかを定義する。セキュリティに関する監視ポリシー（３０３）の例には、いくつかあるセキュリティに関する監視ポリシー（３０３）の中でも特に、ノードまたはノードのグループが攻撃を受けているか否か、クラウドサービス内で起こる奇妙な挙動またはクラウドサービスへの干渉の有無、及び、ノードまたはノードのグループにウィルスまたはその他の異常があるか否かを監視することが含まれる。
【００７５】
監視ポリシー（３０３）はまた、コンプライアンスに関する監視ポリシー（３０３）を含む。コンプライアンスに関する監視ポリシー（３０３）の例には、いくつかあるコンプライアンスに関連する監視ポリシー（３０３）の中でも特に、ノードまたはノードのグループがオペレーティングシステムの適切なバージョンを動作させているか否かの判定、ノードで動作しているリリースされたソフトウェアプログラムに関連付けられた最新のパッチがインストールされているか否かを判定すること、インストールされたパッチが適正なパッチであるか否かを判定すること、ノード及びクラウドサービスを提供するために使用されたコードまたは（ソフトウェア）生成物が、任意の脆弱性または問題について適切にチェック及び検査されたことを確認すること、ノード及びクラウドサービスに対する管理及びアクセス制御またはノード及びクラウドサービスの管理が適切か否かを判定すること、提供（プロビジョニング）されたシステムの設定が、プロビジョニング、セキュリティ、または他のコンプライアンス要件（たとえば、適正なロギングレベル、アクセス制御の適正な設定、及び、パスワードの適正な設定）に適合しているか否かを判定することが含まれる。
【００７６】
監視ポリシー（３０３）はまた、使用に関する監視ポリシー（３０３）を含む。使用に関する監視ポリシー（３０３）の例には、いくつかある使用に関連する監視ポリシー（３０３）の中でも特に、どれだけ多くのユーザーがノードまたはノードのグループのＣＰＵを使用しているかを判定すること、どれだけの量のメモリ（記憶装置）をユーザーが利用しているかを判定すること、どれだけ多くの金額がユーザーに課金されているかを判定すること、ユーザーが、ネットワークトポロジーの設計、提供（プロビジョニング）、配置（デプロイ）、及び監視にわたるサービス提供に対して料金を支払ったか否かを判定することが含まれる。
【００７７】
さらに、ポリシー（３０３）は、実行されると、トポロジー（３０２）またはクラウドサービス内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）またはノードのグループのアクセス制御を定義する管理ポリシー（３０３）を含むことができる。たとえば、管理ポリシー（３０３）は、トポロジー（３０２）またはクラウドサービス内のノードに誰がアクセスすることができるか、及び、どのような条件の下で、それらの個人がそのようなアクセスを得ることができるかを定義するポリシー（３０３）を含むことができる。
【００７８】
さらに、ポリシー（３０３）は、実行されると、トポロジー（３０２）内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）内またはそれらのノード間、または、ノードのグループ内またはノードのグループ間の分析及びビッグデータ監視を確保するために必要なもの、及び、これが予想通りに起こることを確保するために必要なものを定義する分析ポリシー（３０３）を含むことができる。たとえば、分析ポリシー（３０３）は、複数のワークフローを定義することができ、この場合、監視システム（３１３）は、該ワークフローによって、クラウドサービスを構成ないし設定し、分析を提供し、ビッグデータを収集し、及び、該データを処理するように動作することができる。
【００７９】
さらに、ポリシー（３０３）は、トポロジー（３０２）の配置（デプロイ）及び実行中に問題またはインシデントが発生した場合に、トポロジー（３０２）内で行われるべきアクションを定義する（または定める）改善ポリシー（３０３）を含むことができる。改善ポリシー（３０３）は、改善プロセス中に、プロビジョニング（たとえばファーストデーオペレーション）中のまたはそれとは異なる状況（たとえばセカンドデーオペレーション）にあるトポロジーベースの管理ブローカー（３００）によって取られる複数のアクションを定義するポリシー（３０３）を含むことができ、及び、（１）ユーザー、購入者、または管理者に通知を提供すること、（２）該ユーザー、購入者、または管理者からの命令を取得すること、（３）該ユーザー、購入者、または管理者によって入力された手動アクションを行うこと、（４）該ユーザー、購入者、または管理者からの命令を受け取った後に自律的なアクションを行うこと、（５）該ユーザー、購入者、または管理者からの命令を受け取ることなく自律的なアクションを行うこと、（６）該ユーザー、購入者、または管理者に通知することなく、または、該ユーザー、購入者、または管理者から命令を受け取ることなく、自律的なアクションを行うこと、（７）ユーザーまたは管理者に、承認を得るために改善アクションを提案して、該ユーザーまたは管理者またはそれらの組み合わせによって承認された場合には、該提案した改善アクションを実行すること、を含むことができる。
【００８０】
１例として、トポロジー（３０２）によってインスタンス化されて実現されたまたは推測されたクラウドサービスの障害が発生する場合があり、改善ポリシー（３０３）は、本明細書に記載されている可能性のあるシナリオに基づいてその障害を処理できる方法を定義することができる。さらに、改善ポリシー（３０３）は、任意の数の条件の下でインシデントを改善ないし修正するために実行すべき実際のルール及びアクションのワークフローを提供し、または、それらの改善アクションを行うことを決定し、該アクションの調整（オーケストレーション）及び実施（フルフィルメント）を行う権限を誰にまたはどの装置に委ねるかを示す。別の改善の例は、たとえば、トポロジー（３０２）に基づいて実現されたクラウドサービス内のサービス内容合意書（ＳＬＡ）またはサービス品質（ＱｏＳ）に基づいてサービスのレベルを維持する潜在的な必要性を考慮することができる。この例では、リソース（資源）の要求の増加をサポートするためのリソースの追加を、本明細書に記載されている可能性のあるシナリオに基づいて処理することができる。インスタンス化された実現済みのまたは推測された配置（デプロイ）済みのトポロジーの監視及びイベント処理については、より詳細に後述する。
【００８１】
本明細書に記載されているように、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）は、該ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた複数のライフサイクル管理アクション（ＬＣＭＡ）（３０４）を含むことができる。該ＬＣＭＡ（３０４）は、トポロジー（３０２）が実施されるクラウドサービス環境内のポリシー（３０３）によって起動されたときにプロセッサによって実行される、ポリシー（３０３）に関連付けられた複数のアクションである。該ＬＣＭＡを、クラウドサービスのトポロジー全体内の複数の個々のノード、ノードの複数のグループ、ノードのクラスの複数のノード、ノードのサブセット、または、クラウドサービスのトポロジー全体、またはそれらの組み合わせに関連付けて、それらに対して動作可能とすることができる。該ＬＣＭＡが、個々のノード、ノードのグループ、またはクラウドサービスのトポロジー全体に対して実行されると、該ＬＣＭＡは、該ＬＣＭＡ内で定義されているように、クラウドサービスのトポロジー全体内の個々のノード、ノードのグループ、ノードのクラスのノード、ノードのサブセット、または、クラウドサービスのトポロジー全体に対してアクションを取る。ＬＣＭＡ（３０４）は、いくつかあるライフサイクル管理アクションの中でも特に、たとえば、トポロジー内のコンピューティング資源の提供（プロビジョニング）（たとえばファーストデーオペレーション）、実現されているまたは推測されたトポロジーの発見及び／又は更新（たとえばセカンドデーオペレーション）、該トポロジーの全てもしくは一部の複製、該トポロジー内のコンピューティング資源の修正（ないし変更）、該トポロジー内でのコンピューティング資源の移動、該トポロジー内のリソースの破壊（ないし無効化）もしくは抹消などのアクションを含む。
【００８２】
本明細書に記載されている種々のポリシー（３０３）は、トポロジー（３０２）に基づくサービスのインスタンス化の前、該インスタンス化中、及び該インスタンス化の後にトポロジー（３０２）のライフスタイルを通じてどのようなアクションが実行されるかを定義する（ないし定める）。さらに、本明細書に記載されている種々のポリシー（３０３）は、それらのアクションをどのように実行するかを定義する。さらに、本明細書に記載されている種々のポリシー（３０３）は、それらのアクションの権限をどの装置（もしくはデバイス）、またはどの個人、またはそれらの組み合わせのどれに委ねるかを定義する（ないし定める）。さらに、本明細書に記載されている種々のポリシー（３０３）は組み合わせを定義する（ないし定める）。たとえば、イベントの操作及び処理、または改善で使用される任意の監視ポリシー（３０３）は、クラウドサービスのどのような装置（もしくはデバイス）または部分を監視しまたは改善（ないし修正）するか、または、そのような監視及び改善（ないし修正）をどのように実行するか、または、誰にもしくはどのような装置（もしくはデバイス）に、監視、及び改善（ないし修正）、またはそれらの組み合わせの役割を委ねるかを定義する（ないし定める）ことができる。
【００８３】
本明細書に記載されているシステム及び方法の成果として、インスタンス化されたサービス（３１２）が、ユーザーに使用のために提供される。インスタンス化されたサービス（３１２）は、設計されたトポロジー（３０２）、及び、該トポロジー（３０２）内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に適合する複数のコンピューティング装置を含む。インスタンス化されたサービス（３１２）は、本明細書に記載されているポリシー（３０３）に基づいて機能する。インスタンス化されたサービス（３１２）を構成するコンピューティング装置は、多くのコンピューティング装置の中でも特に、たとえば、サーバー、スイッチ、クライアント装置、及びデータベースを含むことができる。実現されている及び／又は推測されたトポロジー（３０２）は、インスタンス化されたサービス（３１２）に基づいて、ＬＣＭエンジン（３１１）もしくは他の装置（デバイス）によって得られる。
【００８４】
インスタンス化されたサービス（３１２）に加えて、監視システム（３１３）は、それがまだ存在しない場合には配置（デプロイ）され、または、それがインスタンス化されたサービス（３１２）を監視するためにすでに利用できる状態になっている場合には、セットアップ及び構成（ないし設定）される。プロビジョニング（たとえばファーストデーオペレーション）中のまたはそれとは異なる状況（たとえばセカンドデーオペレーション）にあるトポロジーベースの管理ブローカー（３００）に監視システム（３１３）を含めることによって、トポロジーベースの管理ブローカー（３００）は、集中管理及びセキュリティ（converged management and security：ＣＭ＆Ｓ）環境を提供する。１例では、該ＣＭ＆Ｓ環境を、ヒューレットパッカード社によって開発されて供給されているＣＭ＆Ｓ環境とすることができる。別の例では、該ＣＭ＆Ｓ環境を、「Hybrid Cloud Environment」と題するMaes他に対する国際特許出願ＰＣＴ／ＵＳ２０１２／０５９２０９に記載されているＣＭ＆Ｓ環境とすることができる（該国際出願の全内容は参照により本明細書に組み込まれるものとする）。該ＣＭ＆Ｓ環境は、ハイブリッドクラウド環境全体にわたって共通の能力を確保するために、配置（デプロイ）時にサービスモデルに管理機能及びセキュリティ機能を結合する能力と共に、アプリケーション及びサービス開発並びに配置（デプロイ）に対して、テンプレートベース及びモデルベースのアプローチを提供する。ＣＭ＆Ｓはまた、異種のインフラストラクチャ、管理、及びセキュリティツールを含みうるプライベートクラウド環境及びパブリッククラウド環境にわたってポータビリティ（移植性）を提供する。さらに、ＣＭ＆Ｓは、インフラストラクチャのリソース（資源）が、パブリッククラウまたはパブリッククラウドとプライベートクラウドにわたるハイブリッド環境においてオンプレミスであるか否かにかかわらず、アプリケーションのリリースの効率的な配信及び管理を提供する。ＣＭ＆Ｓはまた、異質のシステム、ネットワーク、及びクラウド環境における、役割ベースの予測される、及びリアルタイムのパフォーマンス（性能など）及びリスクインサイト（リスク洞察）、並びに、ビジネスインテリジェンス（ＢＩ）、ビジネスアクティビティ監視（ＢＡＭ）及びビッグデータ分析などの分析を提供する。
【００８５】
さらに、ＣＭ＆Ｓを、自己管理サービスまたは自立管理サービスをサポートするプラットフォームとして使用することができる。したがって、ＣＭ＆Ｓは、本明細書に記載されているプログラミングモデルをサポートすることができる。
【００８６】
１例では、監視システム（３１３）は、本明細書に記載されているトポロジー（３０２）、及び、該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた監視ポリシー（３０３）に基づいて動作する。この例では、監視システム（３１３）は、インスタンス化されたサービス（３１２）内の監視のためのいくつかの項目の中でも特に、トポロジー（３０２）、及び該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の動作、セキュリティ、コンプライアンス、及び使用（たとえば使用状況）を監視するために使用される。
【００８７】
１例では、監視システム（３１３）は、それが既に存在する場合には、インスタンス化されたサービス（３１２）を監視するために配置（デプロイ）される。この例では、トポロジー（３０２）を設計するときに定義された監視ポリシー（３０３）に適合するように既存の監視システム（３１３）を構成することによって、複数の既存の監視デバイス（装置）を用いて、自律的に、または人間が介入して、またはそれらを組み合わせて、インスタンス化されたサービス（３１２）を監視することができる。この例では、既に存在する監視システム（３１３）を、本明細書に記載されているようにインスタンス化された、実現された、及び／又は推測されたトポロジー（３０２）（及びインスタンス化するための）、及び／又はトポロジー（３０２）の発見されたノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた監視ポリシー（３０３）に基づいて、または、ユーザーからの入力に基づいて、または、それらの組み合わせに基づいて構成することができる。
【００８８】
したがって、たとえば、トポロジー（３０２）のノードに関連付けられたポリシー及びＬＣＭＡを用いた自動化されたもしくは手動のマッチング（適合化）プロセスによって生成されたアーキテクチャトポロジーなどの設計されたトポロジーは、プロビジョニング（提供）時に修正（ないし変更）される。これを、プロビジョニングポリシーを完全にまたは得られる最良の態様で満たすトポロジーを決定するために、プロビジョニングポリシーエンジン（５０２）またはリソースオファリングマネージャ（３０８）を用いて該プロビジョニングポリシーを実行することによって実施することができる。最も良く適合するトポロジーを得ることは、リソースプロバイダーの能力及び選択基準を記述している、リソースオファリングマネージャ（３０８）によって提供される複数のリソースプロバイダーポリシー（３０８−１）を含むことができる。リソースオファリングマネージャ（３０８）は、たとえば、リソースプロバイダー（該プロバイダーからリソースが得られる）を選択し、及び、トポロジー（３０２）に対して他の変更を加えることもできる。
【００８９】
トポロジー（３０２）は、矢印５０７で示されているように、プロビジョニングポリシーエンジン（５０２）によって、受け取られたプロビジョニングポリシー（３０８−１）毎に変更されて、インタープリタ（５０３）に送られる。インタープリタ（５０３）は、矢印５０８で示されているように、実行計画を作成するためにプロビジョニングポリシーを解釈する任意のハードウェア装置、またはハードウェアとソフトウェアの組み合わせである。その後、トポロジー（図１Ａの３１２）のインスタンスを生成するために、その結果が、解釈されて、ワークフローまたは一連の直列及び／もしくは並列のスクリプトを含む実行計画（５０８）に変換される。１例では、インタープリタ（５０３）は、独立型の装置（またはデバイス）であるか、または、ＬＣＭエンジン（図１Ａの３１１）に含まれる。実行計画（５０８）は、複数のワークフローまたは一連の直列及び／もしくは並列のスクリプトを含む。トポロジーＬＣＭエンジン（３１１）は、それらのワークフローまたは一連の直列及び／もしくは並列のスクリプトを取得し、矢印５０９で示されているように、リソースオファリングマネージャ（３０８）を介してリソースプロバイダーを呼び出して、ブロック５０５において、インスタンス化されたサービス（３１２）を生成する。それらのワークフローまたは一連の直列及び／もしくは並列のスクリプトが実行可能である（これはアーキテクチャ記述トポロジーの場合にあてはまる）場合には、それらのワークフローまたは一連の直列及び／もしくは並列のスクリプトに関連付けられたアクションは、ＬＣＭエンジン（３１１）によって実行される。
【００９０】
上記のシーケンスベースのトポロジーの場合は、実行計画（５０８）を設計図として表すことができる。これとは逆に、設計図を、実行計画（５０８）として表すことができる。ポリシー（３０３）及びＬＣＭＡ（３０４）によって拡張（ないし展開）されたノードを有する設計図を、インフラストラクチャトポロジーの処理と類似のやり方で処理することもできる。この例では、順次的なサービス設計（５０６）の形態の設計図は、図５に関連して説明したように、処理のためにインタープリタに入力される。
【００９１】
より詳細に後述するように、トポロジーライフサイクル管理エンジン（３１１）による実行計画（５０８）の実行によって、イベント及びインシデントを監視し、イベント処理し、及びイベント及びインシデントの処理及び改善をするための装置（デバイス）のプロビジョニングを含むクラウドサービスのインスタンス化が行われる。実行計画（５０８）によって定義されるワークフローまたは一連の直列及び／もしくは並列のスクリプトを実行するトポロジーライフサイクル管理エンジン（３１１）の成果は、ブロック５０５に示されているように、インスタンス化されたサービス（３１２）である。より詳細に後述するように、さらに、実現されたトポロジー（３１４）を、インスタンス化されたサービス（３１２）に基づいて生成し、及び格納することができる。
【００９２】
本明細書に記載されている監視ポリシー及び改善ポリシーについては、同じタイプの処理を適用することができるが、インスタンス化されたサービス（３１２）及びそれの実現されたトポロジー（３１４）内で定義された複数の実現されたポリシーを入力として有する。このプロセスでは、追加のＬＣＭＡ（３０４）を、生成して、更新されたインスタンス化されたサービス（３１２）内のリソースをプロビジョニングするのを支援するために使用することができる。アーキテクチャトポロジーまたは設計図に関するＣＳＡ／ＣＤＡの使用例についての下記の説明は、それらの全ての使用例に共通のエンジン、パターン、及びプラットフォームの概念を示している。
【００９３】
本システム及び方法を、たとえば、OpenStack Foundation（オープンスタックファウンデーション）によって開発されて提供され、及び、Apache LicenseにしたがってリリースされたオープンソースソフトウェアであるＨＥＡＴコマンド言語インタープリタなどの任意のサードパーティーモデリングと共に使用することができる。ＨＥＡＴは、実行計画の空間における一組のスクリプトフィッティングの生成を支援することができるが、ＨＥＡＴは、データを解釈または翻訳し、及び、該データをスクリプトに変換することによってサポートを提供することができる。本システム及び方法は、ＨＥＡＴインタープリタにポリシー（３０３）及びＬＣＭＡ（３０４）を追加し、及び、上記のように実行することができる。
【００９４】
さらに、本システム及び方法は、トポロジー、及びトポロジーを表すためのクラウドコンピューティング標準である、クラウドアプリケーション（ＴＯＳＣＡ）用のオーケストレーションＯＡＳＩＳ仕様を使用することができる。この例では、ポリシー（３０３）及びＬＣＭＡ（３０４）は、ＴＯＳＣＡベースのトポロジーに加えられる。
【００９５】
したがって、トポロジー（３０２）を提供（プロビジョニング）し及び配置（デプロイ）するために、ポリシー（３０３）及びＬＣＭＡ（３０４）がそのようなプロビジョニング及び配置（デプロイメント）を起動するときに、ポリシー（３０３）及びＬＣＭＡ（３０４）を、ファンクションコール（関数呼び出し）（３０５）またはスクリプトとして実施することができる。リソースオファリングマネージャ（３０８）を、トポロジーベースの管理ブローカー（３００）内に設けて、ポリシー（３０３）及びＬＣＭＡ（３０４）に基づいてトポロジー（３０２）内においてコンピューティング資源を管理し及び提供することができる。
【００９６】
リソースオファリングマネージャ（３０８）は、ライフサイクルマネージャ（３１１）を実行するために複数のプラグインを提供する。上記したように、リソースオファリングマネージャ（３０８）は、リソースプロバイダーが複数のリソースプロバイダーの選択プロセスをガイドするのを支援することができるように、複数のリソースポリシー（３０８−1）を複数のリソースプロバイダーのプラグインに関連付ける。ノードに関連付けられたポリシー（１０３）などの非リソースプロバイダーポリシーは、それらが、トポロジー（３０２）の設計中にノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられるという点で異なる。
【００９７】
トポロジー（３０２）の配置（デプロイ）を介して生成されるクラウドサービス内にリソースを提供するために、リソースオファリングマネージャ（３０８）を、たとえば、管理者、またはサービスプロバイダーによって動作させることができる。上記したように、リソースオファリングマネージャ（３０８）は、複数のリソースプロバイダーポリシー（３０８−１）を定義し、複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、トポロジー（３０２）、またはトポロジー（３０２）の一部にそれらの複数のリソースプロバイダーポリシー（３０８−１）を関連付けるためのハードウェア及びソフトウェアを備える。トポロジー（３０２）が配置（デプロイ）されると、リソースオファリングマネージャ（３０８）は、ポリシー（３０３）、ＬＣＭＡ（３０４）、及びリソースプロバイダーポリシー（３０８−１）に基づいてトポロジー（３０２）を実施するユーザーにコンピューティング資源を提供する。結果として、それらのＬＣＭＡは、トポロジー（３０２）に関連付けられたポリシー（３０３）、及びリソースプロバイダーポリシー（３０８−１）の関数である。
【００９８】
したがって、１例では、リソースオファリングマネージャ（３０８）は、複数のサービスプロバイダーからのコンピューティング資源を、トポロジー（３０２）内に配置（デプロイ）するために、どのような条件の下で選択することができるかを定義する複数のリソースプロバイダーポリシー（３０８−1）を実施することができる。この例では、ノードに関連付けられたポリシー（３０３）並びにリソースプロバイダーポリシー（３０８−１）は、リソースオファリングマネージャ（３０８）からのどのリソースを、配置（デプロイ）されることになるインスタンス化されたトポロジー（３０２）内での提供（プロビジョニング）のために選択するかを定義する。たとえば、ノード（３０２−１）に関連付けられたポリシーが、提供（プロビジョニング）されたコンピューティング資源を（セキュリティ上）安全な設備内に配置することを要求しており、かつ、リソースオファリングマネージャ（３０８）によって提供されたリソースのポリシーが、それらの利用可能なコンピューティング資源が（セキュリティ上）安全な設備内に配置されていないことを示している場合には、その特定のサービスプロバイダーによって提供された安全でない（保護されていない）コンピューティング資源は選択されない。このように、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられたポリシー、及びリソースオファリングマネージャ（３０８）に関連付けられたポリシーは、どのコンピューティング資源をトポロジー（３０２）内に提供（プロビジョンニング）して配置（デプロイ）することができるかを決定する。
【００９９】
トポロジーベースの管理ブローカー（３００）は、カタログ（３１０）内にトポロジー（３０２）を格納することができる。１例では、設計されてカタログ（３１０）に格納されたトポロジー（３０２）を、セルフサービスポータル（３０９）を介して任意の関心を持っているパーティに利用できるようにすることができる。別の例では、アプリケーションプログラミングインターフェース（ＡＰＩ）を、セルフサービスポータル（３０９）の代わりにまたはそれに加えて、提供することができる。この例では、カタログ（３１０）から複数のトポロジー（３０２）に対して要求することができる、トポロジーベースの管理ブローカー（３００）内で実行されるアプリケーションによって、該ＡＰＩを使用することができる。
【０１００】
別の例では、第１のユーザーまたは団体のために作成されたトポロジーを得るためにトポロジーが格納されているカタログ（３１０）を調べて、トポロジー（３０２）を注文しまたは購入する（または該トポロジーに加入する）ことによってそれらのトポロジーのうちのいくつかをユーザーのトポロジーとして使用する機会をユーザーに与えることができる。さらに別の例では、第１のユーザーまたは団体のために作成されたトポロジーを得るためにトポロジーが格納されているカタログ（３１０）を調べ、及び、それらのトポロジーのうちのいくつかを得て、後述のスティッチングプロセスを用いて、アプリケーションモデルがインフラストラクチャテンプレートに構築される例などのように、他のいくつかのトポロジーをそれに追加するための機会をユーザーに与えることができる。
【０１０１】
さらに別の例では、第１のユーザーまたは団体のために作成されたトポロジーを得るためにトポロジーが格納されているカタログ（３１０）を調べて、それらのトポロジーのうちのいくつかを得て、新たに設計されたトポロジーやカタログ（３１０）に格納されているトポロジーなどの他のいくつかのトポロジーをそれに追加するための機会をユーザーに提供することができる。さらに別の例では、第１のユーザーまたは団体のために作成されたトポロジーを得るためにトポロジーが格納されているカタログ（３１０）を調べて、それらのトポロジーのうちのいくつかを得るための機会、及び、予め定義された全てのトポロジー及びそれらの予め定義されたトポロジーによって記述ないし表現されたそれぞれのサービスの側面を含む新しいクラウドサービスを構築するための機会をユーザーに与えることができる。
【０１０２】
別の例では、ユーザー、サービスデザイナー、またはそれらの組み合わせは、新たにトポロジーを設計することができ、または、カタログ（３１０）に格納されているトポロジーに基づいてトポロジーを設計することができ、または、カタログ（３１０）に格納されているトポロジーに部分的に基づいてトポロジーを設計するができる。トポロジー（３０２）の設計を、複数のユーザー、デザイナー、及び管理者間に分けることができる。トポロジー（３０２）の設計は、トポロジーの設計を複数のトポロジーに分割して、それぞれの部分である個々のトポロジー及びトポロジー全体に複数の特性、ＬＣＭＡ、及びポリシーを付属させることを含むことができる。ユーザーはまた、所望のトポロジーを注文することができ、ユーザーには、選択されたトポロジーを承認し、及び、作成されたクラウドサービスにおいて複数のアプリケーションを実行することによって該トポロジーを調べて動作させる機会を与えることができる。
【０１０３】
別の例では、所望のトポロジー（３０２）に関連付けられた呼び出し機能（コール機能）を呼び出し（ないし作動させる）アプリケーションプログラミングインターフェース（ＡＰＩ）を利用できるようにすることができる。セルフサービスポータル（３０９）の例では、カタログ（３１０）を、ユーザーが利用できるようにすることができ、及び、カタログ（３１０）は、ユーザーに対して所望のトポロジー（３０２）に関連付けられた１つまたは複数のアイテム（項目）を識別することができ、及び、複数のサービスを注文する能力をユーザーに提供することができ、及び、選択されたトポロジー（３０２）の配置（デプロイ）を提供することができる。１例では、トポロジー（３０２）の配置（デプロイ）を、いつかある考慮事項の中でも特に、たとえば、サービス内容合意書（ＳＬＡ）、クラウドサービスのコスト、及びポリシーに基づいて配置（デプロイ）する前に、承認ワークフローによって定義ないし規定されているとおりにユーザーまたは管理者（マネージャ）によって承認することができる。さらに別の例では、トポロジー（３０２）が設計されてカタログ（３１０）に格納されると、それらのトポロジー（３０２）を、商業用語、及びトポロジー（３０２）を使用できるやり方についての関連する記述によって識別することができる。
【０１０４】
トポロジー（３０２）が設計されると、ユーザーの代わりにトポロジー（３０２）を提供（プロビジョニング）して、ＳＬＡ内にサブスクリプションを生成することができる。トポロジーライフサイクル管理（ＬＣＭ）エンジン（３１１）は、コンピューティング資源を提供（プロビジョニング）及び配置（デプロイ）してユーザーが使用するクラウドサービスを形成するためにトポロジー（３０２）を実行するデータ処理装置である。トポロジーＬＣＭエンジン（３１１）は、生成されたトポロジー（３０２）を分析して、該トポロジー（３０２）をインスタンス化して実現するための実行計画の形態の実行ロジックを形成する一組のスクリプトを生成する。１例では、該一組のスクリプトは、コンピューティング資源の一連の提供（プロビジョニング）及び配置（デプロイ）を定義する。トポロジーＬＣＭエンジン（３１１）は、トポロジー（３０２）、及び該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられたポリシー、並びに、リソースオファリングマネージャ（３０８）によって管理されるリソース用に設定されたポリシーを適用する。
【０１０５】
上記のシステム及び方法の成果として、インスタンス化されたサービス（３１２）がユーザーに使用のために提供される。インスタンス化されたサービス（３１２）は、設計されたトポロジー（３０２）、及び、該トポロジー（３０２）内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に適合する複数のコンピューティング装置を含む。インスタンス化されたサービス（３１２）は、上記のポリシーに基づいて機能する。インスタンス化されたサービス（３１２）を構成するコンピューティング装置は、多くのコンピューティング装置の中でも特に、たとえば、サーバー、スイッチ、クライアント装置、及びデータベースを含むことができる。実現されたトポロジー（３１４）は、インスタンス化されたサービス（３１２）に基づいて、ＬＣＭエンジン（３１１）または他の装置によって得られる。
【０１０６】
インスタンス化されたサービス（３１２）に加えて、監視システム（３１３）は、それがまだ存在しない場合には配置（デプロイ）され、または、それがインスタンス化されたサービス（３１２）を監視するためにすでに利用できる状態になっている場合には、セットアップ及び構成（ないし設定）される。トポロジーベースの管理ブローカー（３００）に監視システム（３１３）を含めることによって、トポロジーベースの管理ブローカー（３００）は、集中管理及びセキュリティ（converged management and security：ＣＭ＆Ｓ）環境を提供する。１例では、該ＣＭ＆Ｓ環境を、ヒューレットパッカード社によって開発されて供給されているＣＭ＆Ｓ環境とすることができる。別の例では、該ＣＭ＆Ｓ環境を、「Hybrid Cloud Environment」と題するMaes他に対する国際特許出願ＰＣＴ／ＵＳ２０１２／０５９２０９に記載されているＣＭ＆Ｓ環境とすることができる（該国際出願の全内容は参照により本明細書に組み込まれるものとする）。該ＣＭ＆Ｓ環境は、ハイブリッドクラウド環境全体にわたって共通の能力を確保するために、配置（デプロイ）時にサービスモデルに管理機能及びセキュリティ機能を結合する能力と共に、アプリケーション及びサービス開発並びに配置（デプロイ）に対して、テンプレートベース及びモデルベースのアプローチを提供する。ＣＭ＆Ｓはまた、異種のインフラストラクチャ、管理、及びセキュリティツールを含みうるプライベートクラウド環境及びパブリッククラウド環境にわたってポータビリティ（移植性）を提供する。さらに、ＣＭ＆Ｓは、インフラストラクチャのリソース（資源）が、パブリッククラウドまたはパブリッククラウドとプライベートクラウドにわたるハイブリッド環境においてオンプレミスであるか否かにかかわらず、アプリケーションのリリースの効率的な配信及び管理を提供する。ＣＭ＆Ｓはまた、異質のシステム、ネットワーク及びクラウド環境における、役割ベースの予測される、及びリアルタイムのパフォーマンス（性能など）及びリスクインサイト（リスク洞察）、並びに、ビジネスインテリジェンス（ＢＩ）、ビジネスアクティビティ監視（ＢＡＭ）及びビッグデータ分析などの分析を提供する。
【０１０７】
１例では、監視システム（３１３）は、上記したように、トポロジー（３０２）、及び、該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた監視ポリシーに基づいて動作する。この例では、監視システム（３１３）は、インスタンス化されたサービス（３１２）内の監視のためのいくつかの項目の中でも特に、トポロジー（３０２）、及び該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の動作、セキュリティ、コンプライアンス、及び使用（たとえば使用状況）を監視するために使用される。
【０１０８】
１例では、監視システム（３１３）は、それが既に存在する場合には、インスタンス化されたサービス（３１２）を監視するために配置（デプロイ）される。この例では、トポロジー（３０２）を設計するときに定義された監視ポリシーに適合するように既存の監視システム（３１３）を構成することによって、複数の既存の監視デバイス（装置）を用いて、自律的に、または人間が介入して、またはそれらを組み合わせて、インスタンス化されたサービス（３１２）を監視することができる。この例では、既に存在する監視システム（３１３）を、上記したように、トポロジー（３０２）、及び該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた監視ポリシーに基づいて、または、ユーザーからの入力に基づいて、または、それらの組み合わせに基づいて構成することができる。
【０１０９】
別の例では,これまで存在していなかった監視システム（３１３）を、トポロジー（３０２）を定義及び／又は発見する監視ポリシー（３０３）に基づいて提供（プロビジョニング）して配置（デプロイ）することができる。この例では、監視システム（３１３）は、インスタンス化されたサービス（３１２）の提供（プロビジョニング）及び配置（デプロイ）と同時に提供（プロビジョニング）及び配置（デプロイ）される。さらに、この例では、監視システム（３１３）は、本明細書に記載されているように、トポロジー（３０２）、及び該トポロジー（３０２）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた監視ポリシーに基づいて配置（デプロイ）及び管理される。本明細書における任意の例において、トポロジー（３０２）によって概略が示される、インスタンス化されたサービス（３１２）及び監視システム（３１３）を含む完全なサービスが生成される。
【０１１０】
トポロジーベースの管理ブローカー（３００）はさらに、実現されたトポロジーシステム管理（ＲＴＳＭ）データベース（３１５）を含むことができる。ＲＴＳＭデータベース（３１５）は、実現されたトポロジー（３１４）及び／又は推測された実現されているトポロジーの論理的システムリポジトリであり、任意の形態のデータリポジトリでありうる。１例では、ＲＴＳＭデータベース（３１５）は、データベース管理システム（ＤＢＭＳ）を備える。該ＤＢＭＳは、データを取り込んで分析するための、ユーザーと対話するハードウェア装置とソフトウェアモジュールの組み合わせ、及び／又は他のアプリケーション、及び／又はデータベース自体である。１例では、ＲＴＳＭデータベース（３１５）は、コンフィグレーション管理データベース（ＣＭＤＢ）である。ＣＭＤＢは、実現されたトポロジー（３１４）の構成要素の全てに関連する情報のリポジトリである。
【０１１１】
ＲＴＳＭデータベース（３１５）のＤＢＭＳは、実現されたトポロジー（３１４）のデータベースの定義、生成、問い合わせ（クエリーの実行）、更新、及び管理を可能にするように設計される。実現されたトポロジーは、本明細書に記載されているポリシーが関連付けられているトポロジー（３０２）のモデルである。したがって、実現されたトポロジー（３１４）は、ポリシー（３０３）が種々のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に適用される、トポロジー（３０２）のモデルを含む。実現されたトポロジー（３１４）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の複数の特性は、該実現されたトポロジー（３１４）内で定義される。それらの特性は、トポロジーベースの管理ブローカー（３００）によって生成または更新される任意のインスタンス化されたサービス（３１２）の任意の詳細を含み、及び、多くの特性の中でも特に、たとえば、ノードのインターネットプロトコル（ＩＰ）アドレス、ノードの特性及びコンピューティングパラメータを含むことができる。
【０１１２】
トポロジー（３０２）は、実現されたトポロジー及び／又は推測された実現されているトポロジーでありうる。本明細書に記載されている「実現された（または実現されている）トポロジー」は、該実現されたトポロジーを利用する（企業などの）団体によって開発されマッピングされたトポロジー（３０２）でありうる。「推測された実現されているトポロジー」は、発見されたトポロジーであるトポロジー（３０２）でありうる。推測された実現されているトポロジーを、いくつかの方法を用いて発見することができる。推測された実現されているトポロジーを発見することは、複数のサービスインスタンスを該推測された実現されているトポロジーにマッピングすることを含むことができる。いくつかの実施形態では、推測された実現されているトポロジーを発見することは、ユニバーサルＣＭＤＢ（たとえばｕＣＭＤＢ）または類似のシステムにおける複数の関係を調べることを含むことができる。いくつかの実施形態では、該複数の関係を調べることは、クラウドシステムの配置（デプロイ）されたシステムに関する情報を発見すること、及び、該配置（デプロイ）されたシステムに関する該発見された情報間の関係を調べることを含む。
【０１１３】
推測された実現されているトポロジーを発見することは、配置（デプロイ）されたシステムに関する該発見された情報間の関係を調べるのを支援するためにエンタープライズマップデータを利用することを含むことができる。さらに、推測された実現されているトポロジーを発見することは、該推測された実現されているトポロジーの複数の手動編集、手動ガイダンス（手動案内）、及び／又は手動設計を実行することを含むことができる。いくつかの実施形態では、推測された実現されているトポロジーの手動入力及び／又は手動設計によって、複数の推測された実現されているインスタンスを生成することによって、該推測された実現されているトポロジーを発見することができる。本明細書に記載されているように、該推測された実現されているトポロジーを、トポロジー（３０２）及び実現されたトポロジーと同じ及び／又は類似のやり方で利用することができる。
【０１１４】
いくつかの実施形態では、トポロジー、実現されたトポロジー（３０２）、及び／又は、推測された実現されているトポロジーを、他のシステム及び／もしくは他のエンティティによって提供されるかまたは他のシステム及び／もしくはエンティティによって管理されるクラウドサービスに適用することができる。たとえば、それらのクラウドサービスを、cloudfoundry（クラウドファンドリー）、heroky、openshift、AWS beanstalk、Azure、管理ブローカー（３００）には知られていないエンティティによって自動で改善または修正されるものなどのＰａａＳシステムなどのサービスによって提供しまたは管理することができる。
【０１１５】
推測された実現されているトポロジー及び／又は実現されたトポロジーを発見することは、管理ブローカー（３００）が、ファーストデーオペレーションなしで、管理ブローカー（３００）において構築／開発されるセカンドデーオペレーション用のアプリケーションを有することを可能にすることができる。本明細書に記載されているように、ファーストデーオペレーションのないセカンドデーオペレーションは、同じエンティティによって開発されなかったクラウドサービスを提供（プロビジョニング）し及び／又は管理することを含むことができる。さらに、実現されたトポロジー及び推測された実現されているトポロジーを、管理ブローカー（３００）によって用いて、管理ブローカー（３００）によってこれまでは管理及び／又は提供（プロビジョニング）されなかったサービスを管理及び／又は提供（プロビジョニング）することができる。
【０１１６】
ＲＴＳＭ（３１５）は、実現されたトポロジー（３１４）のそれぞれのインスタンスを格納するリポジトリである。このように、トポロジー（３０２）が、設計、提供（プロビジョニング）、及び配置（デプロイ）されるたびに、トポロジーベースの管理ブローカー（３００）は、そのトポロジー（３０２）の実現されたトポロジー（３１４）を取り込む。したがって、ＲＴＳＭ（３１５）は、トポロジーベースの管理ブローカー（３００）内で、すなわち、後述の改善プロセスを通じてインスタンス化された全てのトポロジー（３０２）の実現されたトポロジー（３１４）を含み、及び、実現されたトポロジーまたはインスタンス化されたサービス（３１２）の修正（ないし変更）を格納する。したがって、１例では、既存のトポロジー（３０２）の修正（ないし変更）の全てのインスタンスにおいて、その修正（ないし変更）から生じた実現されたトポロジー（３１４）もまたＲＴＳＭ（３１５）に格納される。改善プロセスについは以下でより詳細に説明する。
【０１１７】
トポロジーベースの管理ブローカー（３００）内で起こり得ることであるが、いくつかのイベントがトポロジーベースの管理ブローカー（３００）内で生じうる。それらのイベントは、多くのコンピューティング関連のイベントの中でも特に、たとえば、インスタンス化されたサービス（３１２）のノード内のポリシー障害、インスタンス化されたサービス（３１２）内の１以上のハードウェアもしくはソフトウェア構成要素の障害、インスタンス化されたサービス（３１２）の権限のないアクセスを含むことができる。さらに、監視システム（３１３）は、インスタンス化されたサービス（３１２）内で起こり得る複数のパフォーマンス関連イベント及び使用関連イベントを監視する。それらのパフォーマンス関連イベント及び使用関連イベントは、多くのパフォーマンス関連イベント及び使用関連イベントの中でも特に、たとえばユーザーのビジネスの顧客による複数のノード内のプロセッサの使用（たとえば稼働時間などの使用状況）や複数のノードの使用（たとえば稼働時間などの使用状況）など、及び、データ記憶装置内の残りのデータ記憶空間のレベル（たとえば量）を含むことができる。
【０１１８】
１例では、監視システム（３１３）は、該監視システム（３１３）によって検出された任意のイベントをイベントハンドラ（３１６）に知らせる。イベントハンドラ（３１６）は、監視システム（３１３）からの検出されたイベントに関連付けられたデータを受け取って、該検出されたイベントから生じうる複数のインシデントを生成するために該データを処理する任意のコンピューティング装置である。
【０１１９】
したがって、トポロジーベースの管理ブローカー（３００）は、監視システム（３１３）によって検出されたイベントを処理する。監視システム（３１３）によって検出されたイベントの処理を、イベントハンドラ（３１６）によって実行することができる。イベントハンドラ（３１６）は、監視システム（３１３）から任意の種類または任意の量のデータを受け取ることができる。上記したように、イベントハンドラ（３１６）によって監視システム（３１３）から受け取ったデータは、インスタンス化されたサービス（３１２）全体、及び、該インスタンス化されたサービス（３１２）内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ及びそれらの個々のノードの動作及び使用（たとえば使用状況）に関連付けられた任意のデータを含むことができる。１例では、イベントハンドラ（３１６）は、該イベントデータに対する複数の要求を実行する。この例では、イベントハンドラ（３１６）は、所定の時間後に、ランダムに、別のイベントによってトリガされたときに、または、それらの組み合わせのタイミングで、監視システム（３１３）にイベントデータ（の有無）についてポーリングすることができる。上記したように、１例では、イベントの操作及び処理（の権限）を、別のシステムまたはサードパーティーのサービスに委ねることができる。たとえば、イベント及びインシデント及びインシデント識別の関連付け及びフィルタリングなどのイベント処理を、ヒューレットパッカード社によって開発されて供給されている一組のサービス管理ソフトウェアツールであるHP BUSINESS SERVICE MANAGEMENTに委ねることができる。改善プロセスを、HP OPERATIONS MANAGER I（HP OMi）またはSITESCOPE（両方共、ヒューレットパッカード社によって開発されて供給されている一組のソフトウェアツールを含んでいる）に委ねることができる。セキュリティイベントの通知、処理、及び改善を、ヒューレットパッカード社によって開発されて供給されている一組のサービス管理ソフトウェアツールであるHP ARCSIGHTに委ねることができる。１例では、HP ARCSIGHTは、インスタンス化されたサービス（３１２）に関連付けられたサービス契約書（ＳＡ）にしたがうために、該ＳＡを参照することができる。
【０１２０】
監視システム（３１３）から受け取ったデータは、イベントハンドラ（３１６）によって処理され、イベントハンドラ（３１６）は、イベントが改善アクションを必要としているか否か、トポロジーベースの管理ブローカー（３００）またはインスタンス化されたサービス（３１２）のユーザー、管理者、サードパーティー、もしくは他のユーザーにイベントを通知するか否か及びどのように通知するかを決定する。イベントハンドラ（３１６）が、イベントに関して改善アクションを取るべきと決定した場合には、イベントハンドラ（３１６）は、該イベントに基づいてインシデントを生成し、該イベントに関連付けられたデータが改善エンジン（３１７）に送られる。１例では、イベントハンドラ（３１６）は、複数の処理タイプを用いて監視システム（３１３）から受け取ったイベントを処理することができる。イベントハンドラ（３１６）が実行することができる処理のタイプには、いくつかあるイベント処理の形態の中でも特に、イベントのフィルタリング、関連付け、集約（集合化）、及びそれらの組み合わせが含まれる。１例では、インシデントを生成するために、複数のイベント全体に、複数の形態のイベント処理を施すことができる。この例では、それらのイベントは、個々では、改善を必要とするインシデントの生成をサポートできないが、複数のイベントは、イベントハンドラ（３１６）によって分析されると、インスタンス化されたトポロジー（３１２）内の問題が、ポリシー（３０３）に合致していないこと、または、改善（ないし修正）の必要があることを示すことができる。
【０１２１】
別の例では、インシデントを、複数のチケットサポートシステムから識別することができる。たとえば、情報技術（ＩＴ）サービス管理システム（ＩＴＳＭ）（３１６−１）はインシデントのソースでもありうる。ＩＴＳＭシステム（３１６−１）は、ユーザーのニーズを満たすＩＴサービスを実施し、及び該サービスの品質を管理する。１例では、ＩＴＳＭシステム（３１６−１）は、ユーザー、サービスプロバイダー、サードパーティー、またはそれらの組み合わせによって管理され、この場合、サービスチケットは、それらのグループのうちの１つまたは個人によってオープンされる。別の例では、ＩＴＳＭシステム（３１６−１）は、監視システムによって検出されたイベントに基づいてサービスチケットを自動的に入力することができる。ＩＴＳＭシステム（３１６−１）が、インスタンス化されたシステム（３１２）、または該システムの複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）が適切に提供（プロビジョニング）されていない、または、不適切に提供（プロビジョニング）されている、または、他の点でインスタンス化されたシステム（３１２）に適さないと判定した場合には、ＩＴＳＭシステム（３１６−１）は、イベントハンドラ（３１６）と同様に、改善エンジン（３１７）に送られるインシデントの形態の改善決定を提供することができる。
【０１２２】
イベントハンドラ（３１６）及びＩＴＳＭシステム（３１６−１）によって生成されたインシデントを、トポロジーベースの管理ブローカー（３００）またはインスタンス化されたサービス（３１２）のユーザー、管理者、サードパーティー、もしくは他のユーザーに通知の形態で知らせることができる。上記したように、改善ポリシーは、改善アクションをどのように実行するかを定義し、及び、（１）ユーザー、顧客、または管理者への通知の提供、（２）ユーザー、顧客、または管理者からの命令の取得、（３）ユーザー、顧客、または管理者によって入力された手動アクションをとること、（４）ユーザー、顧客、または管理者から命令を受け取った後に自律的アクションをとること、（５）ユーザー、顧客、または管理者から命令を受け取ることなく自律的アクションをとること、（６）ユーザー、顧客、もしくは管理者に通知することなく、または、ユーザー、顧客、もしくは管理者から命令を受け取ることなく自律的アクションをとること、またはそれらの組み合わせを含むことができる。このように、システム内における通知の発行は、改善ポリシーによって定義される。
【０１２３】
改善エンジン（３１７）は、プロセッサを介して、イベントハンドラ（３１６）及び／又はＩＴＳＭシステム（３１６−１）によって報告されたインシデントを修正するためのロジックを実行する。改善エンジン（３１７）によって生成された改善（ないし修正）策は、多くの改善アクションの中でも特に、たとえば、追加のコンピューティング資源の割り当て、異なるコンピューティング資源の割り当て、ある地理的領域から別の領域へのコンピューティング資源の再割り当てを含むことができる。１例では、改善エンジン（３１７）によって取られる改善アクションは、設計されたトポロジー（３０２）に関連付けられたポリシーに適合しないコンピューティング資源の不適切な割り当てを修正するために実施される。別の例では、改善エンジン（３１７）によって取られる改善アクションは、インスタンス化されたサービス（３１２）内の複数のコンピューティング資源の障害を直すために実施される。さらに別の例では、改善エンジン（３１７）によって取られる改善アクションは、インスタンス化されたサービス（３１２）、並びに、該サービス内のコンピューティング資源のグループ及び個々のコンピューティング資源のセキュリティレベルを調整するために実施される。任意の数の理由のために、任意の数の他の改善アクションを、改善エンジン（３１７）によって実施することができる。
【０１２４】
１例では、改善エンジン（３１７）によって取られる改善アクションは、上記しように、ユーザー、管理者、サードパーティー、または他のユーザーに通知してまたは通知することなく実施される。さらに、別の例では、改善エンジン（３１７）によって取られる改善アクションは、ユーザーとの対話なしに、すなわち、ユーザーからの承認なしに自律的に実施される。
【０１２５】
さらに別の例では、改善エンジン（３１７）によって取られる改善アクションは、顧客、管理者、サードパーティー、または他のユーザーからのユーザーインタラクション（対話）を用いて実施される。この例では、改善エンジン（３１７）は、セルフサービスサブスクリプション管理エンジン（３１８）にデータを送る。セルフサービスサブスクリプション管理エンジン（３１８）は、プロセッサを介して、管理システム（３１３）によって検出されたイベント、並びに、イベントハンドラ（３１６）及びＩＴＳＭシステム（３１６−１）によって生成されたインシデントに関する情報をユーザーに提示するためのロジックを実行する。セルフサービスサブスクリプション管理エンジン（３１８）はまた、プロセッサを介して、それらのイベント及びインシデントを改善（ないし修正）するための複数の推奨（推薦）をユーザーに提示するためのロジックを実行する。
【０１２６】
１例では、セルフサービスサブスクリプション管理エンジン（３１８）は、プロセッサを介して、複数のグラフィカルユーザーインターフェース（ＧＵＩ）（３１８−１）をユーザーに提示するためのロジックを実行する。この例では、それらのＧＵＩ（３１８−１）は、ユーザーが、実現されたトポロジー（３１４）、及び、監視システム（３１３）によって検出されたイベント、並びに、イベントハンドラ（３１６）及びＩＴＳＭシステム（３１６−１）によって生成されたインシデントを見る（及び調べる）ことができるようにする。このように、ユーザーは、セルフサービスサブスクリプション管理エンジン（３１８）によって生成されたＧＵＩ（３１８−１）を介して、実現されたトポロジー（３１４）内の問題を識別することができる。さらに、ＧＵＩ（３１８−１）は、ユーザーが、推奨された改善アクションを選択して、該改善アクションをどのようにして実行できるかを定義することを可能にする。
【０１２７】
別の例では、セルフサービスサブスクリプション管理エンジン（３１８）は、プロセッサを介して、実現されたトポロジー（３１４）内の問題を、該問題、及び該実現されたトポロジー（３１４）内のどのノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）が該問題に関連付けられているかに関する情報と組み合わせて表す複数のインジケータを、該実現されたトポロジー（３１４）の表現内においてユーザーに提供するためのＡＰＩを実行することができる。
【０１２８】
改善エンジン（３１７）が、イベントハンドラ（３１６）及びＩＴＳＭシステム（３１６−１）によって報告されたインシデントを修正するためにロジックを実行すると、及び／又は、ユーザーが、セルフサービスサブスクリプション管理エンジン（３１８）を介して、取るべき改善アクションを選択すると、トポロジーベースの管理ブローカー（３００）は、それらのインシデントを修正（ないし改善）するために複数のライフサイクル管理アクション（ＬＣＭＡ）に対する複数のコール（呼び出し）を実行する。ＬＣＭＡは、いくつかあるＬＣＭＡの中でも特に、たとえば、実現されたトポロジー（３１４）の全てもしくは一部を含む複数のコンピューティング資源の複製、移動、複写、または抹消を含むことができる。
【０１２９】
トポロジーＬＣＭエンジン（３１１）は、コンピューティング資源を提供（プロビジョニング）し及び配置（デプロイ）して新たなインスタンス化されたサービス（３１２）を形成するために、改善プロセスによって生成された新たなトポロジー（３０２）を実行する。したがって、トポロジーＬＣＭエンジン（３１１）は、セルフサービスサブスクリプション管理エンジン（３１８）及び改善エンジン（３１７）から受け取ったＬＣＭＡを実現されたトポロジー（３１４）に繰り返し適用して、新たな後続のインスタンス化されたサービス（３１２）を生成する。
【０１３０】
改善プロセスは、監視システム（３１３）、イベントハンドラ（３１６）、ＩＴＳＭシステム（３１６−１）、改善エンジン（３１７）、セルフサービスサブスクリプション管理エンジン（３１８）、トポロジーＬＣＭエンジン（３１１）、及びそれらの組み合わせの全ての機能を含んでいる。この改善プロセスの任意の数の繰り返しを一連の実現されたトポロジー（３１４）に適用して、新たなインスタンス化されたサービス（３１２）を連続的に生成することができる。こうして、新たなインスタンス化されたサービス（３１２）は、設計されたトポロジー（３０２）、並びに、実行されたＬＣＭＡによって改善プロセスを介してなされた変更に適合する複数のコンピューティング資源を含むことになる。したがって、トポロジーＬＣＭエンジン（３１１）を有するトポロジーベースの管理ブローカー（３００）は、新たな後続のインスタンス化されたサービス（３１２）から新たな後続の実現されたトポロジーを得て、該後続の実現されたトポロジーをＲＴＳＭ（３１５）に格納する。
【０１３１】
上記に基づいて、トポロジーベースの管理ブローカー（３００）は、ユーザーとの対話を用いてまたはユーザーとの対話なくして自律的に、インスタンス化されたサービス（３１２）を提供（プロビジョニング）し、配置（デプロイ）し、及び維持することができる。したがって、このように、インスタンス化されたサービス（３１２）において実行される複数のアプリケーションは、たとえばＡＰＩをコールする（呼び出す）ことによって、該インスタンス化されたサービス（３１２）において自己実行することができる。
【０１３２】
上記したように、設計図（１００）の構造は、CONTINUOUS DELIVERY AUTOMATION（ＣＤＡ）と同様に、アプリケーションのモデルまたはインフラストラクチャのテンプレートを使用するのが難しい。ＣＤＡは、バージョン、コンフィグレーション（構成）、及び他のアプリケーション要素を管理する一方で、インフラストラクチャ要件とアプリケーション要件を別個にモデル化する、トポロジーデザイナー内で使用されるシステムツールである。ＣＤＡもまた、ヒューレットパッカード社によって開発されて供給されている。上記と同じ理由で、設計図（１００）の構造は、アプリケーションのモデルとして使用するのが難しい。なぜなら、設計図はアプリケーションのアーキテクチャを記述しないからである。さらに、設計図は、インフラストラクチャのテンプレートとして使用するのが難しい。なぜなら、設計図は、インフラストラクチャのアーキテクチャを記述しないからである。その結果、アプリケーションモデル及びインフラストラクチャもしくはプラットフォームのテンプレートをモデル化し、該アプリケーションのモデル及びインフラストラクチャもしくはプラットフォームのテンプレートを互いにマッピングすることを目的とするシステムは、設計図とは簡単には両立ないし整合しない。なぜなら、それらは、それらのサービスをモデル化する異なる方法に基づいているからである。配置（デプロイ）されたサービスにおいて実行される複数のアプリケーションのモデルと該サービスのインフラストラクチャのテンプレートとの間の両立ないし整合については以下で説明する。
【０１３３】
図４に示されているように、トポロジーベースの管理ブローカー（３００）はさらに、図３Ａに示されているサブシステムと同じスタックにおけるトポロジーのインフラストラクチャ要件及びアプリケーション要件を別個にモデル化することができるサブシステムを含んでいる。しかしながら、上記したように、本システム及び関連する方法はまた、ＣＤＡがサポートする全ての使用例をサポートする。上記したように、ＣＤＡは、バージョン、コンフィグレーション（構成）、及び他のアプリケーション要素を管理する一方で、インフラストラクチャ要件とアプリケーション要件を別個にモデル化する、トポロジーデザイナー内で使用される複数のソフトウェアツールである。ＣＤＡもまた、ヒューレットパッカード社によって開発されて供給されている。
【０１３４】
図４に示されているトポロジーベースの管理ブローカー（３００）のサブシステムを用いて、インスタンス化されたサービス（３１２）において実行される複数のアプリケーション用のトポロジーを設計することができる。図４のサブシステムは、アプリケーションをサポートし、及び、適切なインフラストラクチャテンプレートに適合するアプリケーションモデルを提供するトポロジーを提供（プロビジョニング）し、配置（デプロイ）し、及び維持することを支援する。１例では、配置（デプロイ）されたトポロジーにおいて実行されるアプリケーションのモデルは、該トポロジーのインフラストラクチャトポロジーを定義するテンプレートと容易に両立ないし整合する設計されたトポロジーを利用する。
【０１３５】
トポロジーデザイナー（３０１）を用いて、アプリケーションモデル（３１9）を設計して作成することができる。アプリケーションモデル（３１９）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（３０２）に関連して述べたように、アプリケーションモデル（３１９）は、複数のノード（３１９−１、３１９−２、３１９−３）を含む。複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）は、アプリケーションモデル（３１９）のノード（３１９−１、３１９−２、３１９−３）の各々に関連付けられている。
【０１３６】
トポロジーデザイナー（３０１）を用いて、複数のインフラストラクチャ及び／又はプラットフォームテンプレートを（３２０）を作成することもできる。それらのテンプレート（３２０）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（３０２）に関連して述べたように、テンプレート（３２０）は、複数のノード（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）を含む。複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）はまた、テンプレート（３２０）のノード（３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）の各々に関連付けられている。
【０１３７】
１例では、トポロジーデザイナー（３０１）、セルフサービスポータル（３０９）、及びリソースオファリングマネージャ（３０８）の各々またはそれらの組み合わせは、複数のポリシー（３０３）及びＬＣＭＡ（３０４）を、アプリケーションモデル（３１９）及びインフラストラクチャテンプレート（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）に関連付けることができる。別の例では、アプリケーションモデル（３１９）及びインフラストラクチャテンプレート（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）を、ポリシー及びＬＣＭＡに関連付けるために、上記のように、別個のポリシーエンジン及びＬＣＭＡエンジンを設けることができる。
【０１３８】
図４に示されているように、複数のモデル（３１９）を、複数のインフラストラクチャテンプレート（３２０）に対して可能性のあるマッチング状態またはほぼマッチングした状態として提示することができる。１例では、トポロジーデザイナー（３０１）を使用するのではなく、複数のアプリケーションモデル（３１９）リソースを、トポロジーベースの管理ブローカー（３００）内に設けることができる。この例では、トポロジーベースの管理ブローカー（３００）は、たとえば、カタログ（３１０）、ＲＴＳＭ（３１５）、別のモデル（の）ソース、またはそれらの組み合わせから、アプリケーションモデル（３１９）を取得することができる。ユーザーは、それらのモデルソースを閲覧ないし検索して、インフラストラクチャテンプレート（３２０）と両立ないし整合しうる複数のアプリケーションモデル（３１９）を得ることができる。このように、トポロジーデザイナー（３０１）は、複数のアプリケーションモデル（３１９）を設計することができ、または、複数のアプリケーションモデル（３１９）を上記のリソースから得ることができる。したがって、それらのアプリケーションモデル（３１９）を、上記のように、トポロジーデザイナー（３０１）によって設計されたアプリケーショントポロジー、または、実現されているアプリケーショントポロジーとすることができる。
【０１３９】
同様に、図４に示されているように、複数のテンプレート（３２０）は、アプリケーションモデル（３１９）に対して可能性のあるマッチング状態またはほぼマッチングした状態として提示されている。１例では、トポロジーデザイナー（３０１）を使用するのではなく、複数のテンプレート（３２０）リソースを、トポロジーベースの管理ブローカー（３００）内に設けることができる。この例では、トポロジーベースの管理ブローカー（３００）は、たとえば、カタログ（３１０）、ＲＴＳＭ（３１５）、別のテンプレート（の）ソース、またはそれらの組み合わせから、テンプレート（３２０）を取得することができる。ユーザーは、それらのテンプレートソースを閲覧ないし検索して、アプリケーションモデル（３１９）と両立ないし整合しうる複数のテンプレート（３２０）を得ることができる。このように、トポロジーデザイナー（３０１）は、複数のテンプレート（３２０）を設計することができ、または、複数のテンプレートを上記のリソースから得ることができる。したがって、それらのテンプレート（３２０）を、上記のように、トポロジーデザイナー（３０１）によって設計されたインフラストラクチャトポロジー、または、実現されているインフラストラクチャトポロジーとすることができる。
【０１４０】
トポロジーベースの管理ブローカー（３００）はさらに、実現されているトポロジーシステム管理（ＲＴＳＭ）データベース（３１５）を備えている。ＲＴＳＭデータベース（３１５）は、実現されているトポロジー（３１４）の論理的システムリポジトリであって、任意の形態のデータリポジトリでありうる。１例では、ＲＴＳＭデータベース（３１５）は、データベース管理システム（ＤＢＭＳ）を含む。該ＤＢＭＳは、データを取り込んで分析するための、ユーザーと対話するハードウェア装置とソフトウェアモジュールの組み合わせ、及び／又は他のアプリケーション、及び／又はデータベース自体である。１例では、ＲＴＳＭデータベース（３１５）は、コンフィグレーション管理データベース（ＣＭＤＢ）である。ＣＭＤＢは、実現されたトポロジー（３１４）の全ての構成要素に関連する情報のリポジトリである。
【０１４１】
ＲＴＳＭデータベース（３１５）のＤＢＭＳは、実現されたトポロジー（３１４）のデータベースの定義、生成、問い合わせ（クエリーの実行）、更新、及び管理を可能にするように設計される。実現されたトポロジーは、上記のポリシーが関連付けられているトポロジー（３０２）のモデルである。したがって、実現されたトポロジー（３１４）は、ポリシーが種々のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に適用される、トポロジー（３０２）のモデルを含む。実現されたトポロジー（３１４）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の複数の特性は、該実現されたトポロジー（３１４）内で定義される。それらの特性は、トポロジーベースの管理ブローカー（３００）によって生成または更新される任意のインスタンス化されたサービス（３１２）の任意の詳細を含み、及び、多くの特性の中でも特に、たとえば、ノードのインターネットプロトコル（ＩＰ）アドレス、ノードの特性及びコンピューティングパラメータを含むことができる。
【０１４２】
ＲＴＳＭ（３１５）は、実現されたトポロジー（３１４）のそれぞれのインスタンスを格納するリポジトリである。このように、トポロジー（３０２）が、設計、提供（プロビジョニング）、及び配置（デプロイ）されるたびに、トポロジーベースの管理ブローカー（３００）は、そのトポロジー（３０２）の実現されたトポロジー（３１４）を取り込む。したがって、ＲＴＳＭ（３１５）は、トポロジーベースの管理ブローカー（３００）内で、すなわち、後述の改善プロセスを通じてインスタンス化された全てのトポロジー（３０２）の実現されたトポロジー（３１４）を含み、及び、実現されたトポロジーまたはインスタンス化されたサービス（３１２）の修正（ないし変更）を格納する。したがって、１例では、既存のトポロジー（３０２）の修正（ないし変更）の全てのインスタンスにおいて、その修正（ないし変更）から生じた実現されたトポロジー（３１４）もまたＲＴＳＭ（３１５）に格納される。トポロジーベースの管理ブローカー（３００）はさらに、実現されているトポロジーシステム管理（ＲＴＳＭ）データベース（３１５）を備えている。ＲＴＳＭデータベース（３１５）は、実現されたトポロジー（３１４）の論理的システムリポジトリであり、任意の形態のデータリポジトリでありうる。１例では、ＲＴＳＭデータベース（３１５）は、データベース管理システム（ＤＢＭＳ）を備える。該ＤＢＭＳは、データを取り込んで分析するための、ユーザーと対話するハードウェア装置とソフトウェアモジュールの組み合わせ、及び／又は他のアプリケーション、及び／又はデータベース自体である。１例では、ＲＴＳＭデータベース（３１５）は、コンフィグレーション管理データベース（ＣＭＤＢ）である。ＣＭＤＢは、実現されたトポロジー（３１４）の構成要素の全てに関連する情報のリポジトリである。
【０１４３】
ＲＴＳＭデータベース（３１５）のＤＢＭＳは、実現されたトポロジー（３１４）のデータベースの定義、生成、問い合わせ（クエリーの実行）、更新、及び管理を可能にするように設計される。実現されたトポロジーは、上記のポリシーが関連付けられているトポロジー（３０２）のモデルである。したがって、実現されたトポロジー（３１４）は、ポリシーが種々のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に適用される、トポロジー（３０２）のモデルを含む。実現されたトポロジー（３１４）のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の複数の特性は、該実現されたトポロジー（３１４）内で定義される。それらの特性は、トポロジーベースの管理ブローカー（３００）によって生成または更新される任意のインスタンス化されたサービス（３１２）の任意の詳細を含み、及び、多くの特性の中でも特に、たとえば、ノードのインターネットプロトコル（ＩＰ）アドレス、ノードの特性及びコンピューティングパラメータを含むことができる。
【０１４４】
ＲＴＳＭ（３１５）は、設計された及び／又は推測された実現済のトポロジー（３１４）のそれぞれのインスタンスを格納するリポジトリである。このように、トポロジー（３０２）が、設計、提供（プロビジョニング）、推測、及び配置（デプロイ）されるたびに、トポロジーベースの管理ブローカー（３００）は、そのトポロジー（３０２）の実現されたトポロジー（３１４）を取り込む。したがって、ＲＴＳＭ（３１５）は、トポロジーベースの管理ブローカー（３００）内で、すなわち、後述の改善プロセスを通じてインスタンス化された全てのトポロジー（３０２）の実現されたトポロジー（３１４）を含み、及び、実現されたトポロジーまたはインスタンス化されたサービス（３１２）の修正（ないし変更）を格納する。したがって、１例では、既存のトポロジー（３０２）の修正（ないし変更）の全てのインスタンスにおいて、その修正（ないし変更）から生じた実現されたトポロジー（３１４）もまたＲＴＳＭ（３１５）に格納される。
【０１４５】
複数のリソースプロバイダーポリシー（３０８−１）を、トポロジー（３０２）内の複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けることができる（ブロック７０４）。リソースプロバイダーポリシー（３０８−１）は、複数のリソースの選択をガイドする複数のリソースプロバイダーのオファリングに関連付けられた任意のポリシーである。１例では、リソースプロバイダーポリシー（３０８−１）を、コンピューティング資源のコンピューティング能力を定義する動的な機能とすることができる。この例では、たとえば処理能力などのコンピューティング資源の能力の定義されたレベルがトポロジー（３０２）内の複数の要件を満たす場合には、該定義されたレベルを提供するコンピューティング資源を、ＬＣＭエンジン（３１１）及びリソースオファリングマネージャ（３０８）によって提供（プロビジョニング）することができる。
【０１４６】
図６は、本明細書に記載されている原理の１例にしたがう、トポロジーを設計する方法を示すフローチャートである。図６の方法は、アプリケーションモデル（図４の３１９）を生成するステップ（ブロック６３０）から開始することができる。１例では、トポロジーデザイナー（３０１）を用いて、アプリケーションモデル（図４の３１９）を設計して作成し、このようして、アプリケーションモデル（図４の３１９）を生成することができる。別の例では、アプリケーションモデル（図４の３１９）を、いくつかあるアプリケーションモデル（図４の３１９）のソースの中でも特に、たとえば、カタログ（図３の３１０）、ＲＴＳＭ（図３の３１５）、またはＤＳＬデータベース（図４の３２３）などの複数のアプリケーションモデル（図４の３１９）のソースから得ることができる。アプリケーションモデル（図４の３１９）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（図３の３０２）に関連して本明細書に記載されているように、アプリケーションモデル（図４の３１９）は、複数のノード（図４の３１９−１、３１９−２、３１９−３）を含む。
【０１４７】
アプリケーションモデルを生成するステップ（ブロック６３０）は、自己管理、自動管理、またはそれらの組み合わせとしてアプリケーションを設計するステップ（ブロック５３２）を含むことができる。複数のインフラストラクチャテンプレート（図４の３２０）を生成することもできる（ブロック５３４）。１例では、トポロジーデザイナー（３０１）を用いてインフラストラクチャテンプレート（図４の３２０）を設計して作成することができる。別の例では、インフラストラクチャテンプレート（図４の３２０）を、いくつかあるインフラストラクチャテンプレート（図４の３２０）のソースの中でも特に、たとえば、カタログ（図３の３１０）、ＲＴＳＭ（図３の３１５）、またはＤＳＬデータベース（図４の３２３）などの複数のインフラストラクチャテンプレート（図４の３２０）のソースから得ることができる。インフラストラクチャテンプレート（図４の３２０）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（図３の３０２）に関連して本明細書に記載されているように、インフラストラクチャテンプレート（図４の３２０）は、複数のノード（図４の３１９−１、３１９−２、３１９−３）を含む。１例では、複数の人が、トポロジーデザイナー（３０１）を用いて、アプリケーションモデル（図４の３１９）及びインフラストラクチャテンプレート（図４の３２０）を設計することができる。それらの個人は、トポロジーの設計の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。
【０１４８】
複数のアプリケーションモデル（図４の３１９）が、複数のインフラストラクチャテンプレート（図４の３２０）にスティッチ（結合）される（ブロック９０３）。１例では、スティッチングエンジン（図４の３２１）は、たとえば、ＤＳＬデータベース（図４の３２３）、またはインフラストラクチャテンプレート（３２０）の他のソースに格納されている複数のインフラストラクチャトポロジー（図４の３２０）を取得して、複数のアプリケーションモデル（図４の３１９）を複数の適切なインフラストラクチャテンプレート（図４の３２０）にスティッチすることができる。別の例では、インフラストラクチャテンプレート（図４の３２０）を、複数のトポロジーデザイナー（３０１）によって新たに設計することができる。
【０１４９】
スティッチングエンジン（図４の３２１）は、アプリケーションモデル（図４の３１９）（及び／又はインフラストラクチャテンプレート（図４の３２０））に関連付けられたポリシー及びＬＣＭＡに基づいて、任意のタイプの方法を用いて、アプリケーションモデル（図４の３１９）をインフラストラクチャテンプレート（図４の３２０）にスティッチ（結合）することができる。１例では、スティッチングエンジン（図４の３２１）は、マッチング処理を使用することができ、該処理において、スティッチングエンジン（図４の３２１）は、アプリケーションモデル（図４の３１９）のノード（図４の３１９−１、３１９−２、３１９−３）に関連付けられたポリシー、要件、及び能力を、インフラストラクチャテンプレート（図４の３２０）のノード（図４の３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）のポリシー、要件、及び能力とマッチングさせる。この例では、スティッチングエンジン（図４の３２１）は、本明細書に記載されているテンプレートソースを閲覧ないし調べて、マッチングまたはほぼマッチングする状態を見出すことができる。マッチングが見つかると、スティッチングエンジン（図４の３２１）は、アプリケーションモデル（３１９）の複数のノード（図４の３１９−１、３１９−２、３１９−３）を、マッチングするインフラストラクチャテンプレート（図４の３２０）の複数のノード（図４の３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）にマッチングさせる。
【０１５０】
アプリケーションモデル（図４の３１９）をインフラストラクチャテンプレート（図４の３２０）にスティッチするためにスティッチングエンジン（図４の３２１）が使用することができる別の方法は、アルゴリズム的マッチング法を含むことができる。この方法では、スティッチングエンジン（図４の３２１）は、マッチング判定を実行する際にポリシーを利用するアルゴリズムを用いて数学的に判定を行う。１例では、これは推論手法を含むことができ、該方法において、アプリケーションレベルにおける要件が、ＤＳＬデータベース（図４の３２３）内のそれらの要件をサポートする構成要素にタグ付けされるかまたは他のやり方で関連付けられ、この場合、インフラストラクチャトポロジー（図４の３２０）全体が先ず統合された後に、該統合が、アプリケーションモデル（図４の３１９）に拡張される。
【０１５１】
複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）は、アプリケーションモデル（図４の３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付けられる。１例では、複数のポリシー（３０３）及びＬＣＭＡ（３０４）とアプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）との関連付けを、トポロジーデザイナー（３０１）、セルフサービスポータル（３０９）、及びリソースオファリングマネージャ（３０８）の各々によって（単独で）、または、それらの組み合わせによって実行することができる。別の例では、本明細書に記載されているように、アプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）を、ポリシー（３０３）及びＬＣＭＡ（３０４）に関連付けるために、別個のポリシーエンジン及びＬＣＭＡエンジンを設けることができる。
【０１５２】
１例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック６３６に関連して記載されているスティッチングプロセスの前、該プロセス中、または該プロセスの後に実行することができる。ポリシー及びＬＣＭＡがブロック６３４のスティッチングプロセスの前に関連付けられる例では、ポリシー（３０３）及びＬＣＭＡ（３０４）を、アプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）内の複数のノードもしくはノードのグループに、並びに、アプリケーションモデル（３１９）全体及びインフラストラクチャトポロジー（３２０）全体に、関連付けることができる。この例では、追加のポリシー（３０３）及びＬＣＭＡ（３０４）を、スティッチングプロセスによって生成されたトポロジー（３０２）に関連付けることができる。別の例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック６３４のスティッチングプロセス後のそれらの処理のパフォーマンスに応じてオプションとすることができる。さらに別の例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック５３４のスティッチングプロセスの前及び後に実行することができる。
【０１５３】
図６に記載されているプロセスは、図３に関連して説明したトポロジー（３０２）と類似の完全に設計されたトポロジー（３０２）を生じる。たとえば、図６の方法によって得られたトポロジー（図４の３０２）を、入力トポロジー（図３の３０２）として使用することができる。さらに、別の例では、図６の方法によって得られたトポロジー（図４の３０２）を、改善（ないし修正）におけるインスタンス化のための入力トポロジー（図３の３０２）として使用することができる。さらにまた、１例では、複数の人が、図６に記載されている方法に参加する。それらの個人は、トポロジー（３０２）の設計、実行、監視、及び改善の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。
【０１５４】
図７は、本開示にしたがうシステム（７００）の１例である。図７は、ファーストデーオペレーションのないセカンドデーオペレーションを含んでいる。たとえば、図７は、実現されたトポロジーを、該トポロジーを以前に提供（プロビジョニング）し及び／又は修正（ないし変更）した手段から分離することを含む。システム（７００）は、本明細書に記載されているように、該システムにおいて、実現されたトポロジーがシステム（６００）によって提供（プロビジョニング）され及び管理されているために該トポロジーを知ることができるだけではなく、該トポロジーが、発見された実現済のトポロジー及び／又は推測された実現済のトポロジーでもありうるところのシステムである。システム（７００）は、クラウドシステムを提供（プロビジョニング）して管理するための種々の要素を含むことができる。
【０１５５】
発見されたトポロジーは、システム（７００）以外の異なるシステムから、該トポロジー（すなわち、メインシステム（７００）から提供（プロビジョニング）されていないか、または、メインシステム（７００）から独立に管理及び修正（ないし変更）された可能性があるトポロジー）に関連する情報を取得する能力を参照する（該能力に問い合わせる）。
【０１５６】
たとえば、該トポロジーを、該トポロジーを提供（プロビジョニング）した別のクラウドコントローラもしくはシステム（たとえば、vCenterのようなＶＭＷareコントローラ、ＳＡのような従来のプロビジョナ、システム（７００）から分離されたシステムなど）からのものとすることができる。別の例では、該トポロジーをリポジトリから推測することができ、この場合、情報は、該トポロジーを設計及び／又は定義した（たとえば、HP Enterprise Map−ＥＭ）、該トポロジーを提供（プロビジョニング）し（たとえばHP UCMDB）及び／又は管理／修正（ないし変更）した、または、システムから提供（プロビジョニング）されたインスタンスを修正（ないし変更）した任意の者または任意のシステムによって格納されている。
【０１５７】
たとえば、推測されたトポロジーを、ＳＡ（サーバーオートメーション）からの設計図及び／又は仕様、または、ＣＭＤＢに格納されている情報とすることができる。推測の場合には、リポジトリからの情報をシステム（７００）にロードして、該情報を、ポリシーと共に（たとえば、異なる要素及び（たとえば、ノードタイプの所定のコンテキスト／データに関連付けられたポリシーから推測されるかもしくは得られる）関連するポリシーに関連付けられたライフサイクル管理アクションを用いて））トポロジーにマッピングすることができる。推測されたトポロジー及び／又は関連付けられたポリシーは、いくつかの実施形態における最良の推測でありうる。推測されたトポロジーは、既知であるもの（たとえば、さらなる管理のためにポリシーまたはＬＣＭに関してシステム（７００）が使用できるもの）を明らかにすることができる。この場合、欠落したトポロジー情報及び／又は推測されたトポロジーに対する修正（たとえば、ＬＣＭの詳細、依存状態／関係、ポリシー）を、トポロジーデザイナーに類似のコンソールを用いて手動で更新することができる。
【０１５８】
実現されたトポロジーが、システム（７００）によってなされた提供（プロビジョニング）、管理（たとえば、改善（ないし修正）以外の管理）、または改善（ないし修正）の結果ではないときも、他のシステムが、該実現されたトポロジーの管理に作用するときにも、システム（７００）は重要でありうる。たとえば、追加のシステムは、実現されたトポロジーの監視、管理、または改善（ないし修正）を独立して行うことができる（たとえばシステム７００はＨＰＣＳＡベースのものである）。いくつかの実施形態では、該ＣＳＡポリシーは、ＣＭＤＢ内の実現されたトポロジーインスタンスを共有することを含むことができる。別の例では、ＨＰＳＡ（サーバーオートメーション）のようなシステムは、（たとえば、動作、使用セキュリティ及び／又はコンプライアンスの）監視、管理、及び／又は改善（ないし修正）を実行するために格納されている情報を使用することができる。いくつかの実施形態では、システム（７００）に関係のない監視、管理、及び／又は改善（ないし修正）を同時に（ないし並行して）行うことができる。したがって、コンプライアンス監視及び／又は改善（ないし修正）は、システム（７００）を使用してはなされない。いくつかの実施形態では、本明細書に記載されているように、または、単に、システム（７００）は、システム（７００）に情報が入れ直されることを知らされもしくは変更について知らされるという理由から、トポロジーを再発見または推測する必要がありうる。したがって、発見システムは、インスタンスに対する変更または通知を追跡し、さらに、それらを（該システムが格納して追跡する）該インスタンスの更新に反映させることができる。すなわち、提供（プロビジョニング）後に、いくつかのステップを外部のシステム（たとえば、システム（７００）以外のシステム）によって実行することができる。この結果、システム（７００）の能力を維持するために、インスタンスの更新をシステム（７００）に反映させることが重要でありうる。したがって、システム（７００）は、インスタンスに対する変更を再発見することができ、または、システム（７００）にそれらの変更（すなわち通知）を知らせることができる。
【０１５９】
いくつかの実施形態では、アプリケーションは、実現されたトポロジーの管理ステップの一部または全てを引き受けるプラットフォームに配置（デプロイ）される。たとえば、アプリケーションは、ＰａａＳ様のＣｌｏｕｄ  Ｆｏｕｎｄｒｙ（クラウドファンドリー）、または、その他の実行及び管理プラットフォームに配置（デプロイ）され、この場合、システム（７００）を用いて、アプリケーション及び／又はＰａａＳ並びにそのコンテキストを配置（デプロイ）することができる（たとえば、インフラストラクチャにおけるＰａａＳデプロイメント、及び、ＰａａＳにおけるマニフェスト生成及びコードデプロイメント）。その後、ＰａａＳは、実現されたトポロジーを管理（たとえばオートスケーリング（auto-scaling））することができる。これが行われるときは、システム（７００）は、実現されたトポロジーに変更を加えないようにすることができる。本明細書に記載されている現在のソリューションは、実現されたトポロジーを管理するのに関わり続けるために必要とされる（たとえば、実現されたトポロジーの更新は、それらの更新を、cloud foundry（クラウドファンドリー）から取り込まれた（または同期した）、実現されたトポロジーの更新として追跡することによって、システム（７００）によって追跡されまたは該システム（７００）に通知される）。
【０１６０】
システム（７００）は、ユーザーインターフェース（７０２）を備えることができる。ユーザーインターフェース（７０２）を用いて、クラウドシステムに関する情報を表示することができる。いくつかの実施形態では、ユーザーインターフェース（７０２）を用いて、クラウドシステムに関するデータを入力することができる。本明細書に記載されているように、システム（７００）を用いて、推測された実現済のトポロジーを視覚化することができる。いくつかの実施形態では、システム（７００）を用いて、推測された実現済みのトポロジーを修正（ないし変更）することができる。たとえば、推測された実現済みのトポロジーを修正（ないし変更）することは、該推測された実現済みのトポロジーを（たとえば、ＬＣＭ、ポリシー（３０３）、及び／又は、該推測された実現済みのトポロジーに関する他の情報を用いて）編集し、訂正し、及び／又は補完することを含むことができる。いくつかの実施形態では、システム（７００）を用いて、他のシステム及び／又は該推測された実現済みのトポロジーのファイルから情報を駆動（または取得）し及び／又はロードすることができる。本明細書に記載されているように、システム（７００）を用いて、あるシステムが実現されているトポロジー及び／又は発見されたトポロジーを管理するのと同じ及び／もしくは類似のやり方で、該推測された実現済みのトポロジーを管理することもできる。さらに、システム（７００）は、ＬＣＭアクションの選択を可能にすることができる。いくつかの実施形態では、それらのトポロジーを補完することは、ポリシー（３０３）をそれらのトポロジーに結合することを含むことができる。たとえば、それらのトポロジーを補完することは、データセンターにおけるポリシーから得られたポリシー（３０３）を、それらのトポロジーの同じ及び／もしくは類似のノードタイプに結合することを含むことができる。すなわち、発見された及び／又は推測されたトポロジーの複数のノードにポリシー（３０３）を結合することによって、該発見された及び／又は推測されたトポロジーを更新することができる。したがって、それらの発見された及び／又は推測されたトポロジーの発見された及び／又は推測されたインスタンスを、システム（７００）によって、規定し及び管理することができる。
【０１６１】
さらに、システム（７００）は、トポロジー、関係、依存状態、及び／又はポリシー（３０３）に対する変更を得るためのオプションを含むことができる。該変更を、システム（７００）によって、実現されたトポロジーに対して実施することができる。たとえば、該変更は、ノードを移動し、トポロジーを複製し、及び／又は、トポロジーを廃棄するための命令を含むことができる。いくつかの実施形態では、システム（７００）は、推奨エンジンによって推奨された改善（ないし修正）を承認することができる。トポロジー、関係、依存状態、及び／又はポリシー（３０３）に対する変更を得るためのオプションはまた、コードを変更すること（すなわち、デザイナーを使用しない）を含むことができる。いくつかの実施形態では、トポロジーがＴＯＳＣＡＹＡＭＬプロファイルで表されているときには、それらの変更をＹＡＭＬによって行うことができる。
【０１６２】
システム（７００）は、カタログ（７０４）を備えることができる。いくつかの実施形態では、カタログ（７０４）は、クラウドシステムに関する情報を格納するために使用することができるコンピューター可読媒体を含むことができる。いくつかの実施形態では、カタログ（７０４）を用いて、クラウドシステムの配置（デプロイ）されたシステムに関する情報を格納することができる。したがって、実現されたトポロジーを、システム（７００）によって最初に提供（プロビジョニング）しなくてもよく、むしろ、システム（７００）以外の異なるシステムによって、ある時点で更新及び／又は管理することができる。
【０１６３】
システム（７００）は、ポリシーベースの実施（フルフィルメント）、調整（オーケストレーション）、及び統合ツール（７０６）を備えることができる。ポリシーベースの実施（フルフィルメント）、調整（オーケストレーション）、及び統合ツール（７０６）は、クラウドシステムにおけるサービスの配置（デプロイ）のために使用することができる複数のポリシー（３０３）を含むことができる。本明細書に記載されているように、ポリシー（３０３）は、いくつかあるポリシー（３０３）の中でも特に、状態及びバージョンポリシー（３０３）、及び／又は、コンプライアンスポリシー（３０３）でありうる。いくつかの実施形態では、ポリシー（３０３）は、システム（７００）によって最初に提供（プロビジョニング）されない実現されたトポロジーに（たとえば、自動的に、または、補完することなどによって）適用される。
【０１６４】
システム（７００）は、サービス及びインスタンスリポジトリ（７０８）を備えることができる。サービス及びインスタンスリポジトリ（７０８）は、クラウドシステムからの複数のサービス及び／又は複数のインスタンスに関する情報を格納するために使用することができるコンピューター可読媒体を含むことができる。システム（７００）は、モデルリポジトリ（７１０）を含むことができる。モデルリポジトリ（７１０）は、クラウドシステムのアプリケーションモデル（３１９）、クラウドシステムのトポロジー（３０２）、クラウドシステムのインスタンス、クラウドシステムの環境、及び／又は、クラウドシステムの所望の環境に関する情報を格納することができるコンピューター可読媒体を含むことができる。
【０１６５】
システム（７００）は、トポロジーの自動化された発見及び／又は手動による発見を開始することができる発見モジュール（７１２）を備えることができる。本明細書に記載されているように、発見モジュール（７１２）は、システム（７００）の実現されているトポロジー及び／又は推測された実現済みのトポロジーを発見することができる。システム（７００）は、報告プラットフォーム（７１４）を備えることができる。報告プラットフォーム（７１４）を用いて、エラーの報告及び／又はクラウドシステムの状態（ステータス）の報告を送ることができる。システム（７００）は、共通のデータウェアハウス（７１６）を備えることができる。共通のデータウェアハウス（７１６）は、報告プラットフォーム（７１４）に関するデータを格納するために使用することができるコンピューター可読媒体を含むことができる。いくつかの実施形態では、発見モジュール（７１２）に、発見すべきアイテムを知らせることができる。たとえば、トポロジーに対する変更がある場合には、発見モジュール（７１２）に、該トポロジーに対して実施された変更であって、該トポロジーを発見するために通知される変更があったことを通知することができる。いくつかの実施形態では、システム（７００）に発見すべきアイテムを知らせて、その後、発見すべきアイテムが何であるかを発見モジュール（７１２）に知らせることもできる。
【０１６６】
いくつかの実施形態では、システム（７００）は、実現されたトポロジーインスタンスから、トポロジー設計、トポロジーモデル、及びトポロジーテンプレートを分離することによってイネーブル（使用可能）にされる。システム（７００）は、実現されたインスタンス（該インスタンスは該インスタンス用のモデル及び／又は設計を有していない）を管理することができる。さらに、システム（７００）は、実現されたトポロジーを、外部のシステムから、取り込み、発見し、及び／又は修正（ないし変更）すること、及び、実現されたトポロジーを管理するために該トポロジーを追跡することを可能にすることができる。
【０１６７】
図８は、本開示にしたがう、図７に示されている構成要素、プラットフォーム、及びモジュールを含むシステム（８００）の１例である。システム（８００）は、本明細書に記載されているクラウドシステムの例示的なアーキテクチャを有している。図８は、管理ブローカー（３００）によって提供（プロビジョニング）されないトポロジーを発見するための例示的な方法にとって有用である。システム（８００）を、システム（７００）と類似のやり方で用いることができる。
【０１６８】
図８に示されているように、システム（８００）は、発見部分（８１０）を備えることができる。発見部分（８１０）は、図７に関して参照された発見モジュール（７１２）を含むことができる。発見部分（８１０）は、実現されたトポロジー及び／又は推測された実現済みのトポロジーを発見するために使用されるシステム（８００）の一部を含むことができる。
【０１６９】
システム（８００）は、セカンドデーオペレーション部分（８２０）を含んでいる。セカンドデーオペレーション部分（８２０）は、構成要素のこのサブセットによってイネーブル（使用可能）にされる。本明細書に記載されているように、セカンドデーオペレーションは、ハードウェア、ソフトウェア、及び／又はロジックの配置（デプロイ）後のクラウドシステムの動作を含むことができる。たとえば、セカンドデーオペレーションは、提供（プロビジョニング）すること、他の管理ツールを用いること、または、図３に関して参照された管理ブローカー（３００）によって管理されることになる別の物によって提供（プロビジョニング）されたトポロジーを発見すること、及び／又は、クラウドシステムを管理することを含むことができる。本明細書に記載されているように、いくつかの実施形態では、システム（８００）は、モデリング部分、設計部分、提供（プロビジョニング）、その後のセカンドデーオペレーション、報告（ただしそれらには限定されない）を含む複数の異なる部分を含むことができる。したがって、トポロジーがシステム（８００）によって提供（プロビジョニング）されない場合であっても、セカンドデーオペレーション（たとえば、システムの提供（プロビジョニング）後に実施されるもの）を、システム（８００）によって実行することができる。
【０１７０】
システム（８００）は、報告部分（８３０）を含むことができる。システム（８００）の報告部分（８３０）は、エラーを報告し、及び／又は、クラウドシステム分析情報を提供するために使用されるシステム（８００）の要素を含むことができる。
【０１７１】
図９は、本開示にしたがうシステム（９００）の１例である。システム（９００）は、モデリング部分（９４０）を含むことができる。モデリング部分（９４０）は、システム（９００）によって表されるクラウドシステムのモデリング（モデル化）に対応する該システムの要素を有する該システムの一部を含むことができる。モデリング部分（９４０）は、サービスリポジトリ及び／又はインスタンスリポジトリ（７０８）、発見モジュール（７１２）、モデルリポジトリ（７１０）、及び／又は、クラウドシステムをモデル化するために使用することができるクラウドシステムの他の要素を含むことができる。
【０１７２】
システム（９００）は、クラウド管理部分（９５０）を含むことができる。クラウド管理部分（９５０）は、図１〜図６に関連して述べたように、クラウドシステムにおいてサービスを提供し、及び／又はクラウドサービスを管理し、及び／又はクラウドサービスを提供（プロビジョニング）するために使用することができる、及び／又は、クラウドシステムのブローカーとして使用することができるシステム（９００）の要素を含むことができる。
【０１７３】
図１０は、本開示にしたがう、構成要素の例示的なプラットフォーム（１０００）を示すブロック図である。プラットフォーム（１０００）は、クラウドシステムを提供（プロビジョニング）し及び管理するために使用することができる複数の構成要素を備えている。プラットフォーム（１０００）は、図１〜図６に関連して述べたように、クラウドシステムのトポロジー（３０２）に関連付けられた構成要素を含むことができる。
【０１７４】
プラットフォーム（１０００）は、ファーストデーオペレーション及び管理のためのクラウド制御及び管理システムを備えることができる。プラットフォーム（１０００）は、一体化されたまたは独立型の開発及び運用システム（１００４）を備えることができる。開発及びアプリケーションリリース自動化システム（１００４）は、ステージ（たとえば、試験、試作、製造などの段階）に応じた適切なインフラストラクチャへのアプリケーションの配置（デプロイ）、並びに、関連する監視及び改善（ないし修正）を容易にすることができる。
【０１７５】
いくつかの実施形態では、複数の管理ソリューションを、プラットフォーム（１０００）におけるアプリケーションとみなすことができる。たとえば、データセンター内で典型的に行われるファーストデーオペレーションなどのアプリケーション、及び、ＣＳＡなどの管理、または、セカンドデーオペレーションなどのアプリケーションを、データセンターとクラウドネットワークとの間で移動させ及び共有することができる。
【０１７６】
プラットフォーム（１０００）は、一体化されたまたは独立型のコンプライアンス及びセカンドデーオペレーションシステム（１００６）を備えることができる。すなわち、セカンドデーアプリケーションを、アプリケーション（１００２）または運用システム（１００４）に統合して、アプリケーション（１００２）または運用システム（１００４）によって生成されなかったインスタンスを管理する能力を提供することができ、または、セカンドデーアプリケーションを、同じプラットフォームに構築してスタンドアローン（独立）モードで使用することができる。本明細書に記載されているように、アプリケーションまたはシステムのコンプライアンスを、複数のポリシー（３０３）に統合することができる。さらに、セカンドデーオペレーションは、ハードウェア及び／又はソフトウェアアプリケーションの配置（デプロイ）後の動作でありうる。
【０１７７】
プラットフォーム（１０００）は、一体化されたまたは独立型の報告システム（１００８）を備えることができる。報告システム（１００８）は、クラウドシステムで起こったエラーを報告することができる。いくつかの実施形態では、報告システム（１００８）は、クラウドシステムの動作及び機能に関する情報を含む報告（レポート）を生成することができる。
【０１７８】
プラットフォーム（１０００）は、一体化されたまたは独立型の監視システム（１０１０）を備えることができる。監視システム（１０１０）を用いて、クラウドシステムの配置（デプロイ）されたサービスの性能及び状態（ステータス）を監視することができる。本明細書に記載されているように、配置（デプロイ）されたサービスは、アプリケーション１００２または異なるシステムによって、提供（プロビジョニング）及び管理され、または改善（ないし修正）されたものであってもよい。本明細書に記載されているように、監視システム（１０１０）を用いて、クラウドシステムの種々の関係を監視することができる。
【０１７９】
プラットフォーム（１０００）は、図１〜図６に関連して述べたようなクラウドシステムを介してサービスを提供するための複数の特徴を含むことができるコアプラットフォーム（１０１２）を備えることができる。コアプラットフォーム（１０１２）は、ユーザーインターフェース（１０１４）を含むことができる。ユーザーインターフェース（１０１４）を用いて、報告システム（１００８）からの報告を表示し、及び／又は、プラットフォーム（１０００）に変更を加えることができる。コアプラットフォーム（１０１２）は、カタログ（１０１６）を含むことができる。カタログ（１０１６）は、クラウド環境において、配置（デプロイ）され、実行され、及び管理される複数のサービス、アプリケーション、プラットフォーム、またはインフラストラクチャ能力から適切に構成されるクラウドサービスなどの個々の設計、提供（プロビジョニング）、配置（デプロイ）及び管理を格納することができるコンピューター可読媒体を含むことができる。この場合、本明細書に記載されているように、それらの設計を注文し、要求し、及び購入することができるユーザーに、それらの設計をカタログ（１０１６）から提供することができる。
【０１８０】
コアプラットフォーム（１０１２）は、複数のポリシー（３０３）を管理し、処理し、及び格納し／結合することができるポリシーサービス（１０１８）を含むことができる。複数のポリシー（３０３）は、管理及び／又は処理及び／又は格納／結合されることができる種々のポリシーの中でも特に、ステージ及びバージョンポリシー、プロバイダー選択ポリシー、セキュリティポリシー、アクセス制御ポリシー、監視ポリシー、イベント処理ポリシー、通知ポリシー、改善ポリシー、及び／又はコンプライアンスポリシーを含むことができる。コアプラットフォーム（１０１２）は、フルフィルメントエンジンサービス（１０２０）を含むことができる。フルフィルメントエンジン（１０２０）は、クラウドシステムの要求を実現し、提供（プロビジョニング）し、及び／又は更新すると共に、適用するポリシーのガイダンスに従うための複数の方法を含むことができる。
【０１８１】
コアプラットフォーム（１０１２）は、通知サービス（１０２２）を含むことができる。通知サービス（１０２２）は、イベントハンドラを含むことができ、インシデントを取り出し、及び、ユーザーに知らせるためにポリシーに応じて該インシデントを送るべくイベントを処理する（たとえば、対応するポリシーでイベントを処理する）ことができる。いくつかの実施形態では、通知サービス（１０２２）は、改善の推奨を知らせることができる。いくつかの実施形態では、通知サービス（１０２２）は、改善するための改善メニューを知らせることができる。いくつかの実施形態では、通知サービス（１０２２）は、改善の推奨を受け入れることの通知、または該推奨とは異なる改善を行うことの通知を送ることができる。さらに、いくつかの実施形態では、通知サービス（１０２２）は、改善（ないし修正）が行われたことをユーザーに知らせることができる。通知サービス（１０２２）は、図１〜図６に関連して述べたような報告システム（１００８）によって生成された通知及び／又は報告を格納するためのコンピューター可読媒体を含むことができる。通知データベース（１０２２）は、実現されたトポロジー（３１４）及び／又は推測された実現済みのトポロジーの論理的システムリポジトリであって、任意の形態のデータリポジトリでありうる。
【０１８２】
コアプラットフォーム（１０１２）は、トポロジーモデル（１０２４）を含むことができる。トポロジーモデル（１０２４）は、複数のトポロジー（３０２）のモデル表現を含むことができる。トポロジーモデル（１０２４）を用いて、クラウドシステムを提供（プロビジョニング）し及び／又は管理することができる。コアプラットフォーム（１０１２）は、モデルリポジトリ（１０２６）を含むことができる。いくつかの実施形態では、モデルリポジトリ（１０２６）は、システムモデル、トポロジー（３０２）、及び／又はインスタンスを格納するためのモデル及びインスタンスリポジトリでありうる。モデルリポジトリ（１０２６）は、複数のシステムモデル及び／又はトポロジー（３０２）を格納するために使用することができるコンピューター可読媒体を含むことができる。
【０１８３】
コアプラットフォーム（１０１２）は、コンテンツリポジトリ（１０２８）を含むことができる。いくつかの実施形態では、コンテンツリポジトリ（１０２８）を用いて、トポロジーサービス及び／又はポリシーを設計することができる。さらに、コンテンツリポジトリ（１０２８）を用いて、リソースプロバイダーまたはＬＣＭＡを実施ないし実装することができる。コンテンツリポジトリ（１０２８）は、クラウドシステムからのコンテンツを格納するために使用することができるコンピューター可読媒体を含むことができる。コアプラットフォーム（１０１２）は、オーケストレーションシステム（１０３０）を含むことができる。オーケストレーションシステム（１０３０）を用いて、図７〜図９に関連して述べたようなクラウドシステムによって供給されたサービスを提供（プロビジョニング）し及び／又は管理することができる。
【０１８４】
コアプラットフォーム（１０１２）は、発見システム（１０３２）を含むことができる。発見システム（１０３２）を用いて、クラウドシステム用のトポロジー（３０２）を発見することができる。さらに、図７〜図９に関連して述べたように、実現されたトポロジー及び／又は推測された実現済みのトポロジー、並びに、既存のインスタンスに対して外部のシステムによって実行される変更を発見する際に、発見システム（１０３２）を利用することができる。コアプラットフォーム（１０１２）は、統合及び実行環境（１０３４）を含むことができる。統合及び実行環境（１０３４）は、クラウドシステムにおいてサービスを実行するために、並びに、プラットフォーム（１０００）内／上で動作するアプリケーション及びサービスを実行するために利用することができる実行プラットフォームを含むことができる。
【０１８５】
プラットフォーム（１０００）は、プロバイダー部分（１０４０）を含むことができる。該プロバイダー部分は、複数のリソースの選択をガイドする、複数のリソースプロバイダーのオファリングに関連付けられた任意のポリシーである、本明細書に記載されているリソースプロバイダーポリシー（３０８−１）を含むことができる。プロバイダー部分（１０４０）は、いくつかあるプロバイダーの中でも特に、リソース（１０４２）、管理（１０４４）、変更制御（または変更管理）（１０４６）、監視（１０４８）、セキュリティ（１０５０）を含むことができる。リソース（１０４２）は、クラウドシステムを介してサービスを提供することができるネットワークリソースを含むことができる。管理（１０４４）を用いて、クラウドシステムにおけるサービスの提供（プロビジョニング）を管理することができる。管理（１０４４）を、図３におけるサードパーティーオファリングによって実行することができる。変更制御（１０４６）を、クラウドシステムに対する手動変更、及び／又は、トポロジー（３０２）に対する手動変更のために用いることができる。監視（１０４８）は、クラウドシステムにおけるリソースの提供（プロビジョニング）及び配置（デプロイ）を監視するためのネットワークモニタを含むことができる。セキュリティ（１０５０）は、種々のセキュリティリスクを回避するために使用することができる独立型またはサードパーティーのネットワークセキュリティ要素を含むことができる。
【０１８６】
本明細書に記載されているシステム及び方法は、別様に提供（プロビジョニング）及び／又は管理されるクラウドサービスを管理することを可能にする。たとえば、本明細書に記載されているシステム及び方法は、ファーストデーオペレーションなしで、セカンドデーオペレーション用のクラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にすることができる。すなわち、本明細書に記載されているシステム及び方法は、アプリケーションがマネージャによって開発されてマネージャによって管理されているときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。さらに、本明細書に記載されているシステム及び方法は、アプリケーションがマネージャによって開発されておらず、及び、トポロジーが、本明細書に記載されているように発見される推測されたトポロジー及び／又は推測された実現済みのトポロジーであるときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。さらに、本明細書に記載されているシステム及び方法は、本明細書で参照されているように、アプリケーションはマネージャによって開発されたが、クラウドサービスは異なる管理ブローカー（３００）によって管理されているときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。
【０１８７】
本明細書で使用されている「ロジック」は、本明細書に記載されている特定のアクション及び／又は機能などを実行するための代替のもしくは追加の処理リソースであり、「ロジック」には、たとえば、メモリに格納されてプロセッサによって実行可能なソフトウェアやファームウェアなどのコンピューター実行可能命令とは対照的に、たとえば、種々の形態のトランジスタロジックや特定用途向け集積回路（ＡＳＩＣ）などのハードウェアが含まれる。さらに、本明細書で使用されている「１つ」または「複数の」物は、１以上のそのような物を意味することができる。たとえば、「複数のウィジェット」は、１以上のウィジェットを意味することができる。
【０１８８】
本明細書、例、及びデータは、本開示の方法及び適用、並びに、本システム及び方法の使用の説明を提供する。本開示のシステム及び方法の思想及び範囲から逸脱することなく多くの例をなすことができるので、本明細書は、多くの可能性のある実施形態の構成及び実施のうちの一部を説明しているに過ぎない。
【図１】
2017534109.tif 000003
【図２】
2017534109.tif 000004
【図３】
2017534109.tif 000005
【図４】
2017534109.tif 000006
【図５】
2017534109.tif 000007
【図６】
2017534109.tif 000008
【図７】
2017534109.tif 000009
【図８】
2017534109.tif 000010
【図９】
2017534109.tif 000011
【図１０】
2017534109.tif 000012
【国際調査報告】
2017534109.tif 000013
2017534109.tif 000014