JP2009534773A - プロセス符号化 - Google Patents

Abstract

説明されるのは、プロセスの符号化を含むポータブルなパッケージである。これらのパッケージは、ポータブルであり、技術スタックとは異なる。これらのパッケージは、技術スタックを構成するための宣言コードの形態であることが可能であり、技術スタックが、これらのパッケージを実行して、パッケージによって符号化されたプロセスを自動化することを可能にするように技術スタックにプラグインされることが可能である。やはり説明されるのが、パッケージ、パッケージを実行するための技術スタック、パッケージをロードし（「プラグインし」）、場合により、パッケージの実行を制御するためのアプリケーションを作成するための方法である。

Description

いくつかの異なるエンティティが、ＩＴ（情報技術）管理プロセスに関する案内書を編集している。例えば、ＩＢＭは、Ｒｅｄｂｏｏｋシリーズを発行する。英国のＩＴＩＬ（ＩＴ Ｉｎｆｏｒｍａｔｉｏｎ Ｌｉｂｒａｒｙ）は、ＩＴサービスを管理するための、ベンダ独立の好ましい慣行について説明する。本件特許出願人は、ＩＴＩＬガイドラインを特定のソフトウェア製品に適用するＭＯＦ（Ｍｉｃｒｏｓｏｆｔ Ｏｐｅｒａｔｉｏｎｓ Ｆｒａｍｅｗｏｒｋ）を提供する。いくつかの組織は、しばしば人間のアクティビティと自動化をともに含む、独自のカスタムのＩＴ慣行およびＩＴ手続きを有する可能性がある。一般に、ＩＴシステムおよびＩＴサービスを管理するための多くの異なる好ましい慣行が存在する。これらの慣行のいくつかは、例えば、ＩＴシステムの変更を管理すること、ＩＴインシデントを報告し、ＩＴインシデントに対応することなどと関係する。

多くのＩＴ部門は、形式的なＩＴ管理プロセスを実施に移すことに問題を抱えてきた。一部のＩＴ部門は、ＩＴＩＬプロセスを実施することに数年を費やす可能性がある。プロセス自動化をサポートするのに必要なインフラストラクチャの欠如などの、技術的な問題がある可能性がある。ＣＭＤＢ（構成管理データベース）が、必要とされる可能性があり、あるいは新たなアプリケーションが、ユーザーのコンピュータ上で展開される必要がある可能性がある。また、新たなプロセスについて学習すること、スタッフを再教育すること、情報を普及させること、実施の詳細を決定することなどの人的問題が存在する可能性もある。一般に、これらの種類の問題は、ＩＴ業界では、好ましい、または形式的なＩＴ管理慣行を採用する、または自動化することが、なぜ遅れているかを部分的に説明する可能性がある。

もちろん、これらの同じ問題に、多くの異なる会社または組織のＩＴ部門が直面する可能性がある。作業の相当な重複が存在する可能性がある。例えば、異なる２つのＩＴ部門が、それぞれのＩＴシステム上で同一のビジネスプロセスまたはＩＴ管理プロセスを実施することを望むシナリオを考慮されたい。これらの部門は、獲得プロセス（例えば、経理の詳細、承認系統、通信など）について学び、理解すること、その新たなプロセスに対応するように、これらの部門の技術を構成すること、そのプロセスが、どのように実施されるかについての知識をＩＴユーザーおよびＩＴ管理者に提供することなどのほぼ同一のステップを行わなければならない。現在、ＩＴ部門が、好ましいＩＴ管理プロセスを効率的に、または自動的に実施する方法は、全く存在しない。さらに、ＩＴプロセスまたはビジネスプロセスの符号化を、そのようなプロセスを自動化するための基礎をなす技術とは切り離された仕方で人々が共有する方法は、全く存在しない。

以下の概要は、単に、後段の詳細な説明において説明されるいくつかの概念について概説するために含められる。この概要は、包括的ではなく、添付の特許請求の範囲によって示される保護可能な主題の範囲を線引きすることは意図していない。

説明されるのは、プロセスの符号化を含むポータブルなパッケージである。これらのパッケージは、ポータブルであり、技術スタックとは異なる。これらのパッケージは、技術スタックを構成するための宣言コードの形態であることが可能であり、技術スタックにプラグインされて、技術スタックが、これらのパッケージを実行して、これらのパッケージによって符号化されたプロセスを自動化することを可能にすることが可能である。やはり説明されるのが、パッケージ、パッケージを実行するための技術スタック、パッケージをロードする（「プラグインする」）ため、さらに、場合により、パッケージの実行を制御するためのアプリケーションを作成するための方法である。

付随する特徴の多くは、添付の図面と併せて考慮される以下の詳細な説明を参照することによって、より容易に理解されよう。

添付の図面における同様の部分を示すのに、同様の符号が使用される。

（概略）
以下の説明は、通常のＩＴシステムの説明、およびこのＩＴシステム上で利用可能なソフトウェアサービスまたはソフトウェア構成要素のスタックの簡単な説明から始まる。そのような説明の後に、プロセスパッケージ、ならびに、どのようにプロセスパッケージが、技術スタック上で「実行される」、つまり、ＩＴインフラストラクチャ上のビジネスプロセスまたはＩＴプロセスを自動化するのに使用されることが可能であるかの説明が続く。その後、ソフトウェアサービススタックの構成要素、およびこれらの構成要素の特性が、より詳細に説明される。その後、パッケージの他の態様が、説明される。

（ＩＴシステムまたはＩＴインフラストラクチャ）
ＩＴ（情報技術）という用語は、特に大きい組織における技術に広くかかわり、特に、情報を管理し、処理する態様にかかわる。ＩＴには、情報を格納し、処理し、伝送し、取得するコンピュータおよびコンピュータソフトウェアの使用がかかわる。組織のＩＴインフラストラクチャまたはＩＴシステムとは、その組織に提供される資産、主にＩＴサービス、ならびにその組織にＩＴサービスを提供するのに使用されるハードウェアおよびソフトウェア（アーティファクト）を指す。通常、大きいＩＴインフラストラクチャは、専門のスタッフまたは専門の部門によって管理される。

図１は、例示的なＩＴシステム１００を示す。ＩＴシステム１００は、いくつかのハードウェアアーティファクトおよびソフトウェアアーティファクト１０２を有する。ハードウェアアーティファクトの例は、サーバ、ルータ、ブリッジ、バックボーン、ケーブルなどのネットワーク機器、ワークステーション、移動デバイス、ＰＣ、プリンタなどの周辺デバイス、場合により、電話機器、および列挙するには多過ぎるその他である。ソフトウェアアーティファクトの例は、データベースサーバ、デスクトップアプリケーション、ウェブサーバ、ウェブポータル、ファイルサーバ、電子メールサーバ、ＩＴ管理ソフトウェア、生産性スイート、経理パッケージ、ならびにＩＴ部門によってしばしば、展開され、管理されるほとんど限りのない様々な他のソフトウェアサービスである。

また、図１は、例示的な技術スタック１０４も示す。技術スタックは、緩くリンクされ、互いに協働して、または通信して、全体的なＩＴサービスを提供し、全体的なＩＴサービスを管理して、維持することができるＩＴインフラストラクチャにおけるソフトウェアサービスまたはソフトウェア製品と考えられることが可能である。つまり、技術スタックは、ＩＴインフラストラクチャにおけるユーティリティおよび機能を提供する。図１に示される例示的な技術スタック１０４において、技術スタック１０４は、ＩＴインフラストラクチャ１００全体にわたって分散された、いくつかの構成要素１０６〜１１６を有する。重要度の順ではなく、これらの構成要素が、後段で全体的に説明され、さらに後段で、より詳細に説明される（「技術スタック」という題名のセクションを参照）。

例示的な技術スタック１０４は、組織の従業員が、エンタープライズ情報およびエンタープライズアプリケーションにアクセスする開始点、つまり、ゲートウェイの役割を通常、果たすセルフサービスポータル１０６を有する。ウェブポータルとして通常、実施されるものの、セルフサービスポータル１０６は、他の形態をとることも可能である。セルフサービスポータル１０６は、様々なソフトウェアベンダのいずれかからの製品を使用して実現されることが可能である。例えば、本件特許出願人のＳｈａｒｅＰｏｉｎｔ Ｐｏｒｔａｌ Ｓｅｒｖｅｒの現在のバージョン、または将来のバージョンが、コアポータル機能のために使用されることが可能である。ＳＱＬサーバなどの他の製品が、報告サービスなどを供給するのに使用されることが可能である。ＩＢＭ社のＷｅｂＳｐｈｅｒｅ Ｐｏｒｔａｌが、セルフサービスポータル１０６のために使用されることが可能な製品の別の例である。

また、技術スタック１０４は、フォームフレームワーク１０８も含む。フォームフレームワーク１０８は、ＩＴシステム１００全体にわたって広く利用可能な何らかのフレームワークである。名前が暗示するとおり、フォームフレームワーク１０８は、フォーム様の仕方で、アーティファクト、タスクなどの何らかの作業アイテムについての情報を記入することを目的とする。全く基本的なフォームは、通常、フィールドを有し、場合により、サイズ設定されて、型付けされ、フォームフィールドを格納するため、またはバックファイルするための何らかのバックエンドデータソースに結合されることが可能である。また、フォームフレームワーク１０８におけるフォームは、対話型であることも可能であり、つまり、フィールドフォームを単に埋めることに留まらないことを含むことが可能である。また、データ完全性の軽量ロジックまたは軽量規則が、フォームに存在することも可能である。多種多様な既製の製品が、フォームフレームワーク１０８を実施するのに使用されることが可能である。例えば、本件特許出願人からのＯｆｆｉｃｅ １２、またはＩＢＭ社のＷｏｒｋｐｌａｃｅ Ｆｏｒｍｓその他が、使用されることが可能である。好ましくは、フォームフレームワーク１０８は、フォームが、様々な仕方で表示されることを可能にし、例えば、フォームは、直接ユーザーインタフェース（例えば、ＳｈａｒｅＰｏｉｎｔフォームまたはＩｎｆｏＰａｔｈフォーム）であることが可能であり、あるいはフォームは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋなどのアプリケーションにおいて、ワードプロセッサにおいてなど、ポップアップされることが可能である。フォームフレームワーク１０８を介してユーザーによって入力されたデータは、場合により、１つまたは複数のデータベースの中に、または専用アーティファクトストア１１０（後段で説明される）の中で、通常、永続させられる。フォームフレームワーク１０８におけるフォームは、技術スタック１０４における他の構成要素によって駆動されることが可能であり、フォームフレームワーク１０８を介して入力されたデータは、技術スタック１０４における他の構成要素に影響を与えることが可能である。

また、技術スタック１０４は、知識ソース、知識リポジトリ、または知識フレームワーク１１２を有することも可能である。知識フレームワーク１１２は、知識を管理するのに使用されるサービスまたはアプリケーションセットである。知識フレームワーク１１２は、項目および文書を格納し、索引付けを行うこと、知識を探索すること、関連する文書を相互参照すること、またはリンクすること、メタデータタグ付け、カタログ作成などの機能を提供することが可能である。知識フレームワーク１１２は、組織の知識を継続的にキャプチャし、そのような知識に継続的にアクセスすることを可能にするシステムと考えられることが可能である。好ましくは、ユーザーは、構造化された情報であることも、構造化されていない情報であることも可能な格納された知識を照会し、ブラウズすることができる。知識のアドレス指定可能な部分が、望ましい可能性がある（例えば、文書のＵＲＩ）。トラブルシューティング案内書、項目、白書、ユーザーマニュアル、手続き文書などが、知識フレーム１１２の中で見つかることが可能な、いくつかのタイプの知識の例である。知識フレームワーク１１２のために使用されることが可能な製品の例には、本件特許出願人のＯｆｆｉｃｅ １２、Ｆａｃｔｉｖａ、Ｉｎｔｅｒｗｏｖｅｎ社のＷｏｒｋｓｉｔｅスイート、その他が含まれる。

また、ワークフローエンジンまたはワークフローフレームワーク１１４も、ＩＴシステム１００の技術スタック１０４の一部である。ワークフローフレームワーク１１４は、自動化されたワークフローの作成、実行、および監視を可能にする。ほとんどのワークフロー製品に関して、ワークフローは、様々な別々のアクティビティの間の、場合により、条件付きのフローから成る。アクティビティの過程は、条件付きイベントに依存することが可能である。ワークフローは、自動化を扱う単純なインシデントから、ユーザーによって定義された長期継続の複雑なワークフローにまで及ぶことが可能である。ワークフローは、通常、何がワークフローの或る特定のインスタンスをトリガするか、作業がどのように流れるか、およびワークフローを実行するアクティビティの何らかの記述である。後段で詳細に説明されるとおり、ワークフローは、別の接続されたシステムまたは技術スタック構成要素における状態変化イベントによってトリガされることが可能である。さらに、アーティファクトは、リンクフレームワーク１１６（後段で説明される）によって提供されるリンクによってリンクされることが可能であるため、ワークフローアクティビティ（ワークフローにおける「ノード」）は、インタフェース、例えば、ウェブサービスを介して、それらのアーティファクトを操作する、またはそれらのアーティファクトにアクセスすることができる。このことにより、ＩＴインシデントのライフサイクルを扱うインシデントワークフローを作成するＩＴ管理システム警報などのシナリオが可能になり得る。

ワークフローフレームワーク１１４のために使用されることが可能な、多数の市販の製品が存在する。例えば、ＷＷＦ（Ｗｉｎｄｏｗｓ（登録商標） Ｗｏｒｋｆｌｏｗ Ｆｏｕｎｄａｔｉｏｎ）は、ワークフローを実行するためのＷｉｎｄｏｗｓ（登録商標）ベースのワークフローエンジンを提供し、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（Ｖｉｓｉｏ）は、ワークフローのグラフィカルな構築を可能にする。Ｓｋｅｌｔａ社が、．ＮＥＴベースのワークフローフレームワークを販売する。また、Ｊａｖａ（登録商標）ベースのオープンソースワークフローエンジンが使用されることも可能であり、ＪＢｏｓｓ ｊＢＰＭを参照されたい。

例示的な技術スタック１０４における別の構成要素が、リンクサービスまたはリンクフレームワーク１１６である。リンクフレームワーク１１６は、技術スタック１０４における様々な構成要素を一緒に結び付けるのに役立つ。リンクフレームワーク１１６は、アーティファクトのリンク、交換、または同期、およびマッピングを可能にする。例えば、リンクフレームワーク１１６は、ＭＯＭ（Ｍｉｃｒｏｓｏｆｔ Ｏｐｅｒａｔｉｏｎｓ Ｍａｎａｇｅｍｅｎｔ）またはＳＭＳ（Ｓｙｓｔｅｍｓ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）などのＩＴ管理プラットフォームを使用して開発プラットフォームをリンクすることができる。リンクフレームワーク１１６におけるリンクは、自動化されたワークフローがトリガされることを可能にし、リンクされたシステムにおける関連するアーティファクトを操作する。使用されることが可能なリンク付け製品の一例が、本件特許出願人のＴＦＳ（Ｔｅａｍ Ｆｏｕｎｄａｔｉｏｎ Ｓｅｒｖｅｒ）であり、ＴＦＳは、スタック構成要素が、それらの構成要素のアーティファクトおよび関係をリンクサーバに登録することを可能にする。ＴＦＳが使用される場合、ウェブサービスを介して利用可能なアーティファクトが、例えば、これらのアーティファクトの関係およびロケーションを保持することが可能なリンクフレームワーク１１６によって使用されることが可能である。

技術スタック１０４は、好ましくは、通常、ＣＭＤＢ（構成管理データベース）であるアーティファクトストア１１０を含む。ＣＭＤＢは、ＩＴアイテムのレコードを保持する機能を主に果たし、ＩＴアイテムの、相互の関係を追跡する。ほとんどのＩＴ管理アクティビティは、ＩＴシステム１００における物事について決定を行うため、およびそのような物事について情報共有するために、アーティファクトストア１１０について推論する。好ましくは、アーティファクトストア１１０は、ＳＤＭ（システム定義モデル）言語に基づき、ＳＤＭ言語は、アーティファクトのタイプ、およびアーティファクトの間の関係をモデル化することを円滑にし、さらに、ＭＯＭやＳＭＳなどの他のＳＤＭベースの構成要素との対話も円滑にする。ＣＭＤＢタイプのアーティファクトストア１１０については、後段でより詳細に説明する。

技術スタック１０４は、ＩＴシステムが有する可能性がある１つの可能な技術スタックの例に過ぎない。他のＩＴシステムは、異なる構成要素セットを有する可能性がある。さらに、これらの構成要素は、任意のベンダからの任意の様々な市販のソフトウェア製品を使用して実現されることが可能である。これらの構成要素は、ＩＴシステムにおける多くの異なるコンピュータにわたって分散されることが可能である（例えば、フォームフレームワーク１０８、セルフサービスポータル１０６など）。一部の構成要素は、１つのコンピュータまたはサーバにインストールされて、そのコンピュータ上、またはそのサーバ上で実行されることが可能である（例えば、知識フレームワーク１１２、アーティファクトストア１１０など）。一部の構成要素は、同一のサーバ上でホストされることが可能である。インストール構成は、重要ではない。むしろ、関係があるのは、様々な技術構成要素の入手のしやすさ、およびそれらの技術の、互いに通信する能力である。さらに、これらの構成要素は、それぞれの機能に関して自律的動作ができる可能性がある。つまり、例えば、ワークフローフレームワーク１１４は、技術スタック１０４における他の構成要素を要求することなしに、ユーザーにワークフロー機能を提供することができる。あるいは、フォームフレームワーク１０８が、他の構成要素とは別個に存在し、動作するフォームを有することが可能である一方で、同時に、後段で説明されるとおり、他の技術スタック１０４構成要素と相互運用されるフォームを有することが可能である。技術スタック１０４は、緩い連合または相互運用が可能である（場合により、間接的に、またはリンクフレームワーク１１６によって円滑にされて）が、スタンドアロンの機能も提供する自律的構成要素のコレクションである。

（パッケージ）
図２は、パッケージ１３０を示す。例示的な技術スタック１０４などの任意の技術スタックを所与として、パッケージ１３０は、その技術スタックを制御するのに使用されることが可能である。パッケージ１３０は、技術スタックの構成の、好ましくは、宣言型の、符号化を含み、つまり、パッケージは、技術スタックによって解釈され、技術スタックを制御する。より具体的には、パッケージ１３０は、プロセスの符号化であり、そのプロセスを実施するのにスタックによって使用されるメタデータなどの関連する情報を含む。パッケージ１３０は、事実上、技術スタックに「プラグインされ」、技術スタックによって「実行される」ことが可能である。パッケージ１３０は、おおまかにＤＶＤに類似し、つまり、パッケージ１３０は、プレーヤ（技術スタック）にプラグインされることが可能であり、パッケージ１３０のプロセスが、技術スタックによって実行されることが可能である。

背景技術において説明されるとおり、紙の知識、または人間の知識からＩＴプロセスまたはビジネスプロセスを解釈することは、誤りが生じやすい可能性があり、プロセスが既存の管理ツールで機能するようにプロセスを自動化することは、あまりにも複雑である可能性があり、実施するのに数年かかる可能性があり、保守するのに費用がかさむ可能性がある。パッケージ１３０は、技術中立のＩＴプロセスまたはビジネスプロセスが、ポータブルな、マシンによって使用可能である、拡張可能な形態に符号化されることを可能にする。このため、異なるＩＴシステム（およびそれぞれの異なる技術スタック）が、同一のパッケージを有する場合、そのパッケージの中の符号化されたプロセスは、それらの異なるＩＴシステムにおいて実施される（自動化される）ことが可能である。このパッケージアプローチは、パッケージのプロセスを実行するように技術スタックを構成するパッケージの中の情報から、（プロセスを実施する）技術スタックを切り離すことを可能にする。後段で説明されるとおり、このパッケージは、好ましくは、プロセスを協働して実行するようにスタック構成要素を構成し、制御する宣言情報を含む。例えば、パッケージは、以下を含む可能性がある。すなわち、パッケージのプロセスにおける様々な人的ステップ、または自動化されたステップを定義するワークフロー情報、アーティファクトストア１１０にプラグインするためのアーティファクトスキーマおよび関係タイプ、知識フレームワーク１１２の中に格納されることが可能である、プロセスに関与する人々に向けられた知識項目または知識命令、役割定義、ビュー、フォーム、およびレポート、サービス、資産、ユーザー、ロケーション、組織などのオブジェクトを表す構成アイテムである。

パッケージ１３０の内容は、好ましくは、宣言構成情報およびメタデータであり、この情報およびメタデータのいくつかの部分は、技術スタック１０４における様々な対応する構成要素に向けられ、それらの構成要素によって解釈されることが可能である（図５参照）。パッケージ１３０の内容の形態にかかわらず、プログラムまたはアプリケーション１３２は、パッケージ１３０を読み取り、パッケージ１３０を技術スタック１０４にプラグインする。プラグインが行われると（図２の下側部分）、技術スタックは、パッケージ１３０の中に符号化されたビジネスプロセスまたはＩＴプロセスを自動化する、すなわち、パッケージを「実行する」ことを開始することができる。

図３は、どのようにパッケージが、プロセスを共有するのに使用されることが可能であるかを示す。いくつかの異なる組織、個人、またはエンティティ１５０ａ、１５０ｂ、１５０ｃが、プロセス１５２ａ、１５２ｂ、１５２ｃをパッケージ１５４ａ、１５４ｂ、１５４ｃに符号化することができる。エンティティ１５０ａ、１５０ｂ、１５０ｃは、ビジネスプロセスまたはＩＴプロセスを自動化することを専門とする会社であることが可能である。エンティティは、ＩＴ部門、またはこの部門のためにＩＴ管理プロセスを符号化していることが可能な、この部門のスタッフであることが可能である。プロセス１５２ａなどの１つのプロセスは、プロセスの大部分が、１名または複数名の個人の個人的知識である、またはプロセスの別の部分が、おおまかに文書化されている可能性がある、非公式に理解された、または部分的に文書化されたプロセスであることが可能である。プロセス１５２ｂなどの別のプロセスは、ＩＴＩＬ、ＭＯＦ、ＩＢＭ Ｒｅｄｂｏｏｋシリーズ、ＩＴ部門ドキュメンテーションなどにおいて通常、見られるタイプの文書化されたプロセスであることが可能である。別のそのようなプロセス１５２ｃは、そのようなプロセス１５２ｃをパッケージ１５２ｃの中に符号化しながら、準備なしに開発される、または設計されることが可能である。いずれにしても、パッケージ１５４ａ、１５４ｂ、１５４ｃは、異なる組織の間で共有されることが可能なプロセスまたは手続きの、好ましくは、宣言型の、ポータブルな符号化である。

また、図３は、異なる組織、ビジネス、会社などに、場合により、対応する２つの別々の、自立的なＩＴシステム１５６ａ、１５６ｂも示す。各ＩＴシステム１５６ａ、１５６ｂは、対応する技術スタック１５８ａ、１５８ｂを有する。技術スタック１５８ａ、１５８ｂは、前述した技術スタック１０４と同様であるが、異なる構成要素セット、および、場合により、同様な機能を実行する、またはそれらの様々なスタック構成要素の代わりを務める異なる製品を有することが可能である。例えば、技術スタック１５８ａは、ワークフロー管理のために本件特許出願人のＷＷＦを使用する可能性があり、技術スタック１５８ｂは、オープンソースのワークフローエンジンを使用する可能性がある。

図３に示されるとおり、パッケージ１５４ａ、１５４ｂ、１５４ｃは、異なるＩＴシステム１５６ａ、１５６ｂにおいて分散され、共有され、実行されて、技術スタック１５８ａ、１５８ｂが、プロセス１５２ａ、１５２ｂ、１５２ｃを実行するのを可能にすることが可能である。パッケージ１５４ａ、１５４ｂ、１５４ｃは、ネットワーク伝送によって電子的に分配される、物理記憶媒体の分散によって物理的に分散される、またはＩＴ管理システムの一環としてあらかじめインストールされることなどが可能である。いずれにしても、パッケージが受け取られると、そのパッケージは、受け取り側の技術スタックにプラグインされ、この技術スタック上で実行されて、対応するプロセスを自動化することが可能である。図３の例では、技術スタック１５８ａが、パッケージ１５４ａ、１５４ｂ、および１５４ｃを実行している。技術スタック１５８ｂは、パッケージ１５４ｂ、１５４ｃを実行している。異なるプロセスが、１つのエンティティによって符号化されるが、それでも、多くの異なるエンティティによって効率的に共有され、自動化される（「実行される」）ことが可能であることを見て取ることができる。さらに、図４に関連して後段で説明されるとおり、必要とされる場合、パッケージ１５４ａ、１５４ｂ、１５４ｃの任意のパッケージが、その他のパッケージ１５４ａ、１５４ｂ、１５４ｃの任意のパッケージを参照することが可能であり、したがって、相互参照されるパッケージから導き出された作業アイテム、またはクラス、またはデータファイル（例えば、知識項目）、または任意の情報を使用することができる。

各ＩＴシステム１５６ａ、１５６ｂは、任意のパッケージを、そのＩＴシステム１５６ａ、１５６ｂのそれぞれの技術スタック１５８ａ、１５８ｂにプラグインする能力を有するはずであることに留意されたい。アプリケーション１３２などのスタンドアロンのプログラムが、使用されることが可能であるものの、同様の機能が、技術スタック１５８ａ、１５８ｂの構成要素の一部として提供されることも可能である。ＣＳＤ（統合されたサービスデスク）が、そのような機能を提供するための理想的なロケーションである。実際、アプリケーション１３２は、ＣＳＤアプリケーションであることが可能である。

図４は、例示的なパッケージ１７０を示す。一実施形態では、パッケージ１７０は、技術スタックにおけるそれぞれの構成要素に対応するコード部分１７２ａ〜１７２ｆを有する。例えば、コード部分１７２ａ〜１７２ｆは、技術スタック１０４における構成要素１０６〜１１６（図２）に対応することも可能である。しかし、パッケージは、そのようなパッケージによって符号化されたプロセスによって使用されるスタック構成要素のサブセットだけに対応するコード部分を有することが可能であり、つまり、パッケージは、技術スタックにおける各構成要素を使用しなくてもよいことに留意されたい。より複雑な、構造化されたプロセスは、より多くのスタック構成要素に及ぶ傾向がある符号化パッケージを有する。例示的なパッケージ１７０が、技術スタック１０４に向けられるものと想定すると、各コード部分１７２ａ〜１７２ｆは、対応する技術スタック構成要素にプラグインされることが可能なコードを有する。パッケージ１７０の中に符号化されたプロセスが、例えば、ＩＴアセット獲得プロセスである場合、コード部分１７２ａは、要求のステータスを調べるため、または要求を開始するためのセルフサービスポータルオブジェクトの型／クラスおよびインスタンスを宣言することが可能である。コード部分１７２ｂは、ユーザーが、要求と関係するデータを入力するフォーム、例えば、要求を承認するための承認フォームを宣言的に記述することが可能である。コード部分１７２ｃは、アーティファクトストア１１０に関して、インスタンスがアーティファクトストア１１０の中に格納される可能性がある要求と関係するオブジェクトのクラスを定義することが可能である。例えば、作業アイテムまたは作業順序、要求されているアーティファクト（例えば、ソフトウェアパッケージ、コンピュータなど）、または「要求者」、「承認者」、「経理部門」などの役割。コード部分１７２ｄは、パッケージ１７０に付加されたいくらかの知識１７４を含めることを命令することが可能である。知識１７４は、電子文書、教育用のビデオなどのメディア、あるいは知識１７４に対する新たなハイパーリンク、新たなテキスト、または他の類似した情報などの、知識フレームワーク１１２の中の既存の文書の変更または更新さえ含む可能性がある。

例示的なパッケージ１７０の中で、コード部分１７２ｅは、プロセスに関する全体的なワークフロー、例えば、資産獲得ワークフローを定義する。コード部分１７２ｅは、アクティビティ、アクティビティ間のフローに関するイベントおよび／または条件を宣言する。コード部分１７２ｆは、リンク付けフレームワーク１１６に追加されるべきリンクを宣言する。例えば、コード部分１７２ｆは、ＩＴ管理システム（例えば、ＭＯＭ）からの警報が、アーティファクトストア１１０の中に格納された問題またはアーティファクトにリンクされることを宣言することが可能である。任意のスタック構成要素の中の任意のデータが、別のスタック構成要素の中の別のデータアイテムに潜在的にリンクされることが可能である。

図４に破線１７６で示されるとおり、コード部分１７２ａ〜１７２ｆのいずれも、別の部分１７２ａ〜１７２ｆの中で宣言されるクラスもしくはオブジェクト、または他の情報に対するリファレンスを有することが可能である。前述したとおり、コード部分は、知識１７４などの、パッケージ１７０に付加された、または含められたいくらかのビットまたはハードデータに対するリンクまたはリファレンス１７７を有することも可能である。また、そのようなハードデータには、ソフトウェアライブラリ、コード部分１７２ａ〜１７２ｆの１つに補足的なロジックを追加するソースコードまたは「ｃｏｄｅ−ｂｅｓｉｄｅ」、あるいはパッケージ１７０または１つまたは複数のコード部分１７２ａ〜１７２ｆと互換性があるように技術スタック構成要素をアップグレードするためのアップグレードパックさえ含まれることも可能である。

パッケージ１７０などのパッケージは、好ましくは、グローバルデータまたはパッケージデータ１７８と呼ばれる、パッケージ１７０全体に適用可能ないくらかの情報を含む。パッケージデータ１７８は、パッケージ１５４ａ、１５４ｂ、１５４ｃおよびパッケージ１７０などのパッケージのフォーマットを定義するマスタスキーマまたはコンテナスキーマを示すことが可能である。パッケージデータ１７８は、名前またはグローバル一意識別子または他のＩＤ情報を提供することによって、パッケージ１７０を識別することが可能である。パッケージデータ１７８は、パッケージ１７０に関する名前空間を定義し、パッケージ１７０のバージョンを識別し、パッケージの発行者または作成者を識別し、真正性情報および完全性情報（例えば、暗号化されたチェックサム、公開鍵または真正性証明書など）、またはグローバルな性質の他の情報を含むことが可能である。また、パッケージデータ１７８は、別のパッケージ１８０に対する依存関係１７９、要求されるプラットフォーム、必要とされるスタック構成要素、およびそれらの構成要素のバージョンなどの依存関係情報を含むことも可能である。また、パッケージデータ１７８は、配信データ１８１またはインストールデータ１８２などのパッケージ１７０のマニフェストリスト部分の役割をすることも可能である。一実施形態では、パッケージ１７０は、オプションとして、キャビネットファイル（すなわち、ＣＡＢファイル）、ＭＳＩ（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｉｎｓｔａｌｌｅｒ）パッケージ、または他の何らかの配信パッケージフォーマットとして形成されることが可能である。

一実施形態では、パッケージ１７０は、ＸＭＬスキーマ定義ファイル（ＸＳＤファイル）、または他の何らかのタイプのスキーマファイルであることが可能なパッケージスキーマ１８４に従ってフォーマットされた、構造化された文書である。前述したとおり、パッケージスキーマ１８４は、パッケージ１７０に付加される、またはパッケージ１７０を包むようにされることが可能であるが、そうすることは、必須ではない。ＸＭＬベースの実施形態では、コード部分１７２ａ〜１７２ｆおよびパッケージデータ１７８は、パッケージスキーマ１８４に従ってフォーマットされ、構成されたＸＭＬマークアップまたはＸＭＬタグ１８５から成る。この実施形態では、コード部分１７２ａ〜１７２ｆは、ロードアプリケーション１３２によって構成要素特有のコードに変換されることが可能である。

別の実施形態において、パッケージ１７０は、やはり、パッケージスキーマ１８２に従ってフォーマットされた構造化された文書である。しかし、コード部分１７２ａ〜１７２ｆは、対応する技術スタック構成要素に特有のコードのスニペットであり、変換される必要はなく、ただし、マクロ拡張（すなわち、コンパイラ様の前処理）が、パラメータ、マクロ、名前付きオブジェクトなどが、パッケージ１７０、またはパッケージ１７０が実行される技術スタックに特有であることを確実にするのに役立つ可能性がある。

いずれの実施形態においても、パッケージは、ＸＭＬ（拡張マークアップ言語）、またはＸＭＬから派生した言語、またはその他の言語などの言語を使用して実施されることが可能である。いくつかの部分は、ＳＤＭ（システム定義モデル化言語）、例えば、アーティファクトストアの中に格納されるべきアーティファクトの定義を使用して実施されることが可能である。技術スタック構成要素が、宣言コードを介してアクセス可能であるＡＰＩおよび／またはオブジェクトモデルを有する場合、パッケージのコード部分は、対応するスタック構成要素に直接にプラグインされることが可能である。技術スタックが、標準化された宣言型アクセスを提供しない構成要素（例えば、構成要素特有のＸＭＬスキーマ）を有する場合、その構成要素に関するパッケージコードは、その構成要素のために特別に書かれることが可能であり、あるいはモデル化言語（例えば、ＳＤＭ）、または、パッケージスキーマ１８４によって定義される可能性がある別の言語で書かれることが可能である。そのようなコードは、アプリケーション１３２によって、対応する構成要素に特有のコードに変換されることが可能である。

パッケージの中でキャプチャされる情報の性質に関して、多くのタイプのプロセスが、パッケージの中に符号化されることが可能であることに留意されたい。構造化されていないプロセス（例えば、単一のアクティビティ、または順序付けられていないアクティビティを有するプロセス）、例えば、通信プロセスおよび協力プロセス、知識および訓練の使用、格付け、および更新、診断アプリケーションおよびデバッグアプリケーションのブラウズ、ＩＴ問題を解決しながらのエンドユーザーとチャットすること、ウェブベースのセルフサービス、報告、ＩＴインシデント、およびＩＴインシデントのサービスステータスを調べること、ＩＴシステム変更の通知、調査票に記入すること、使用、利用可能性、およびＳＬＡ（サービスレベル契約）の遵守に関するレポートを発行すること、およびその他が符号化されることが可能である。また、長期の状態持続（例えば、数日、数週間、数ヶ月、数年さえもの）を有し、場合より、アクティビティの合間の長い間隔、およびアクティビティ間の非常に構造化されたフローを有する構造化されたプロセスが、符号化されることも可能である。構造化されたプロセスの例には、ルーティングおよびエスカレーション（ｅｓｃａｌａｔｉｏｎ）などの作業アイテムライフサイクル、場合により、経理アクティビティを含む許可および承認、受領、試験、展開、および撤収などの資産ライフサイクルプロセス、変更管理ライフサイクルプロセス、知識ライフサイクル、およびその他が含まれる。ＩＴ管理プロセスは、様々なＩＴリソースが利用可能であるという想定で、しばしば、設計されるため、パッケージ化によく適しているが、他の非ＩＴプロセスが、パッケージ化されることも可能である。経理プロセス、保険金請求処理プロセス、およびその他のビジネスプロセスが、パッケージ化されることも可能である。

（ローダー／コントローラーアプリケーション）
図２に関連して前述したとおり、アプリケーション１３２を使用して、パッケージが、そのパッケージを実行する技術スタックにロードされることが可能である。図５は、アプリケーション１３２が、パッケージ２０２を技術スタック２０４にロードするのを実行することが可能なプロセス２００を示す。最初に、アプリケーション１３２が、パッケージ２０２を読み取り（２０６）、グローバルデータまたはパッケージデータ（例えば、パッケージデータ１７８）を調べる。パッケージデータに基づき、アプリケーション１３２は、パッケージ２０２の依存関係が満たされているかどうかを判定することができる。例えば、アプリケーション１３２は、技術スタック構成要素が存在し、さらに／または十分なバージョンレベルであることを検証することができる。また、アプリケーション１３２は、相互参照されるパッケージが、技術スタック２０４にインストールされている、またはインストールされるように利用可能であるかを調べて検証することもできる。また、初期読み取り（２０６）時に、アプリケーションは、必要なスキーマをロードし、名前空間を調べ、または他の仕方で、パッケージ２０２をプラグインする準備をすることも可能である。

グローバルパッケージデータが読み取られ（２０６）、処理された後、アプリケーション１３２は、技術スタック構成要素に向けられたパッケージ２０２の部分を識別する（２０８）。例えば、アプリケーション１３２は、パッケージ２０２を解析する際、或るコード部分、例えばコード部分１７２ａ〜１７２ｆの１つを識別する、または区別するタグを読み取ることが可能である。必要な場合、そのように識別された（２０８）ノード、要素、またはコード部分が、そのコード部分が向けられたスタック構成要素によって規定されたフォーマットまたは言語に変換される（２１０）ことが可能である。前述したとおり、標準の宣言型言語（例えば、ＳＤＭ、ＸＡＭＬなど）を使用して直接にプログラミング／構成されることが可能な技術スタックの場合、そのようなスタックのためのパッケージのコード部分は、対応するスタック構成要素に直接にプラグインされることが可能である。いずれにしても、次に、識別され（２０８）、場合により、変換された（２１０）コード部分を使用して、適切な技術スタック構成要素が構成される（２１２）。つまり、パッケージ２０２のその部分が、技術スタック構成要素にプラグインされる。例えば、識別された（２０８）部分が、ワークフロー定義であった場合、ワークフローフレームワーク１１４が、そのワークフロー定義で構成される（２１２）。識別された（２０８）部分が、アーティファクトストア１１０に関し、オブジェクトのクラスおよび／またはインスタンスを定義する場合、アーティファクトストアが、その部分で構成されると（２１２）、定義されたクラスまたは型のオブジェクトを格納することができるようになることが可能である。識別された（２０８）部分が、パッケージ２０２に関するポータルを定義するポータル情報２１４であった場合、ポータル構成要素２１６が構成されて（２１２）、定義されたポータルを提供することが可能である。さらに、コード部分のいくつかの部分が、複数の構成要素にプラグインされて、例えば、それらの構成要素を、必要なタイプのオブジェクトクラス、作業アイテム、リンク、またはその他のデータで構成することが可能である。

識別し（２０８）、場合により、変換し（２１０）、構成する（２１２）プロセスは、パッケージ全体２０２が解析されるまで、繰り返される（２１８）。パッケージ２０２が、致命的な誤りなしにロードされた、またはプラグインされたものと想定すると、アプリケーション１３２は、技術スタック２０４上でパッケージ２０２を起動する（２２０）ことによって、パッケージ１３２の「実行」を開始することができる。そうすることには、パッケージ２０２またはコード部分がすべて、ロードされることに成功して、ワークフローフレームワークが、パッケージ２０２によって定義されたワークフローのインスタンスを扱うことを始め、さらに、場合により、スタック構成要素の再スタート、再設定、または再起動をシグナルすることを可能にしていることを検証することがかかわる可能性がある。

流れ図で示されていないものの、アプリケーション１３２は、他の主要な機能を有することも可能である。例えば、アプリケーション１３２は、パッケージのワークフローを無効にすることによって、または有効にするコードをスタック構成要素からアンロードすることによって、パッケージの「実行」を「停止する」こともできる。また、アプリケーション１３２は、様々なスタック構成要素の誤りメッセージまたは誤りログを分析することによって、パッケージのステータスを監視することもできる。この場合も、例示的なアプリケーション１３２の機能は、任意の場所に存在することも可能であり、専用のプログラムに委任されなくてもよい。また、アプリケーション１３２は、一般的な統合されたサービスデスクアプリケーションの役割をすることも可能である。

図６は、パッケージをプラグインするための別のプロセスを示す。いずれかの任意のソースからのいずれかの任意のパッケージが、受け取られる（２３０）。このパッケージの中に、別個にインストールされる、またはプラグインされる（２３４）、受け取られた（２３２）パッケージに組み込まれる、または技術スタック上で、現在、「実行されている」と検証されることが可能な他のパッケージに対するリファレンスがないか探される（２３２）。次に、パッケージは、起動され（２３６）、その後、スタック構成要素が、パッケージからの内容のそれぞれの部分を実行し（２３８）、必要に応じて、相互動作を行う。

（技術スタック）
パッケージで構成されると、技術スタックは、そのパッケージによって符号化されたプロセスを自動化すること、すなわち、そのパッケージをプレイする、つまり、実行することを始める。技術スタックの自律的な構成要素は、これらの構成要素の通常の機能を実行するが、これらの構成要素は、今や、それらの機能が、パッケージによって符号化されたプロセスを一緒に自動化するように構成されている。構成要素は、他の構成要素を認識していなくてもよい。例えば、ワークフローエンジンは、或る特定のワークフローが、例えば、フォームフレームワークにおけるフォームによる影響を受けることを知らなくてもよい。

単純なプロセス、または構造化されていないプロセスに関して、最小限の量のアクティビティが、技術スタック構成要素上で行われることが可能である。例えば、ＩＴシステムの変更についてユーザーに通知する単純なパッケージによって符号化されたプロセスには、ユーザーが、セルフサービスポータルにおいて変更通知を開始し、このことによって、そのポータルに関するデータソースであるバックエンドデータベースサーバにおけるトリガが呼び出されることが可能であるという程度のことしか、かかわらないことが可能である。トリガは、そのポータルイベントが、アーティファクトストアの中の作業アイテムにリンクされていることを特定することが可能なリンク付けフレームワークに向かうことが可能である。その結果、リンクサーバが、変更通知に関する作業アイテムを格納するようにアーティファクトストアにメッセージを送ることが可能であり、さらに、新たな変更通知ワークフローを開始するようにフォームフレームワークにメッセージを送ることが可能である。次に、ワークフローエンジンは、作業アイテム（変更通知の詳細）を記入するためのフォームをユーザーに送信することによって、ワークフローの初期アクティビティを実行することが可能である。ユーザーは、このフォームを受信し、このフォームに記入し、変更通知に記入することができる。変更通知に記入することにより、アーティファクトストアが、変更通知が更新されたことをリンクフレームワークに通知することが可能である。次に、リンクサーバが、ワークフローエンジンにメッセージを送り、変更通知プロセスが完了するまで、以下同様である。見て取ることができるとおり、スタック構成要素は、それぞれが、その他のスタック構成要素とは独立にインストールされ、使用されることが可能であるスタンドアロンの、または自律的な構成要素である可能性があるものの、まとまりのある単位としてパッケージをプレイする、つまり、実行する。

図７は、技術スタックが例示的なパッケージを実行する際の技術スタックの例示的なプロセスフローを示す。パッケージが実行される、または起動されると（２５０）、ユーザーアクティビティまたはシステムイベントが、例えば、作業アイテム、または他のアーティファクト表現を生成する（２５２）ことが可能である。ユーザーアクティビティのいくつかの例は、パッケージによって構成された電子メールアドレスに電子メールを送信すること、ポータルページにアクセスすること、またはフォーム（場合により、パッケージによって定義された）に入力されたデータをサブミットすることなどである。システムアクティビティの例は、ＭＯＭまたはＳＭＳなどの管理システムからの警報、またはワークフローアクティビティによって生成されたメッセージ、またはＩＴシステムの技術スタックによって受け取られる、または認識されるＩＴシステム上の他の自動化された出来事である。作業アイテムの生成（２５２）は、その作業アイテムが、ＣＭＤＢまたは他のアーティファクトストアの中に格納される（２５４）ことをもたらす。技術スタックにおける構成要素が、ワークフローアクティベーションを生成する。次に、ワークフローエンジンが、トリガする作業アイテムに応じて、リンクされたワークフローインスタンスにおけるアクティビティを実行する。これらは、技術スタックにおける様々な構成要素が、パッケージで構成されると、どのように協働して、パッケージによって符号化されたプロセスを実行することができるかのいくつかの例に過ぎない。

図８は、ＣＭＤＢ（構成管理データベース）２８０を示す。前述したとおり、ＣＭＤＢは、アーティファクトストア１１０の役割をするための好ましい（ただし、必須ではない）タイプのデータベースである。ＣＭＤＢは、構成アイテム、つまり、ＣＩ（便宜のため、ＣＩの表現とＣＩ自体は、互いに区別なく使用される）の表現を格納する。ＣＩは、通常、ＩＴ構成管理制御を受ける何らかのＩＴ構成要素である。ＩＴＩＬの下で、ＣＩは、いくつかの例を挙げると、サービス、資産、ユーザー、ロケーション、および組織のようなオブジェクトを表す。ＣＩのライフサイクルは、しばしば、変更オーダ（次のセクションにおいて説明される）によって駆動される。ボックス外アーティファクトテンプレートが、作成者に提供されて、作成者が、コンピュータやアプリケーションなどの一般的なアーティファクトのためのＣＩを使用するパッケージを書くことを容易にすることが可能である。作成者は、新たなタイプを追加する、または既存のタイプを拡張することができる。

また、関係は、ＣＭＤＢの中でも、通常、見られる。作業アイテムとＣＩは、包含、所有、サービス依存関係、因果関係などの様々なタイプの関係によって互いに、または作業アイテムおよびＣＩそれぞれの間で関連することが可能である。ＣＭＤＢの中で、ＣＩは、他のＣＩから成ることが可能である。ＣＩは、複雑度とタイプが多種多様であることが可能であり、システム全体（ハードウェア、ソフトウェア、およびドキュメンテーションを含む）から単一のソフトウェアモジュール、またはそれほど重要でないハードウェア構成要素にまで及ぶことが可能である。ＣＩは、ＣＩの名前、記述、ロケーション、詳細な技術的構成設定、オプションなどの属性を有することが可能である。要するに、ＣＭＤＢは、各ＣＩの適切な詳細、およびＣＩ間の関係の詳細を含むデータベースである。このデータベースは、いくつかを挙げると、ＣＩのコピーおよび通し番号、カテゴリ、ステータス、バージョン、モデル、ロケーション、責任、またはアイテムについての履歴情報などの、ＣＩについての情報を含むことが可能である。

ＣＭＤＢが、好ましい可能性があるのは、多くのＩＴプロセスが、ＣＭＤＢの中に都合よく格納されるＩＴアーティファクトおよび関係を扱うためである。図８で見られるとおり、インシデント管理、変更管理、リリース管理などのＩＴ管理機能２８２が、ＩＴインフラストラクチャ２８４を管理しながら、情報交換および情報永続のポイントとしてＣＭＤＢ２８０を使用することが可能である。さらに、ＩＴ管理機能２８２におけるほとんどの意思決定は、これらのアーティファクトおよび関係について推論され、プロセスの自動化は、通常、これらのアーティファクトおよび関係の表現を操作する。また、ＣＭＤＢは、ポータブルであるとともに拡張可能である明確に定義されたベースラインシステムモデルを提供することも可能である。さらに、やがて、より多くの管理製品が、他の製品またはスタック構成要素との相互接続性を容易にすることが可能なＣＭＤＢ、特に、ＳＤＭベースのＣＭＤＢを使用しはじめる。

ＣＭＤＢが使用されるか否かにかかわらず、アーティファクトストア１１０は、好ましくは、いくつかの特性を有する。好ましくは、ＣＭＤＢは、オブジェクト関係型でなければならない。つまり、クラス、関係、合成、グループ化、および制約の概念が、有益である。さらに、パッケージが、事実上、既存の技術スタックを拡張することから、アーティファクトストア１１０が、拡張性および継承を可能にすれば役立つ。したがって、新たなパッケージの作成者は、場合により、他のパッケージ、または他のテンプレートの中で定義されたクラスおよび関係タイプを基礎にして、引き続き新たなクラスおよび関係タイプを定義することができる。また、ＣＩ（構成アイテム）、管理されたエンティティ、サービス、資産、およびネットワークデバイス、またはクライアント−サーバのような関係タイプのような事前定義された抽象クラスからのサブクラス化（ｓｕｂ−ｃｌａｓｓｉｎｇ）により、パッケージを作成するのに必要とされる作業が減らされることが可能である。

図９は、例示的なワークフローエンジン３００を示す。前述したとおり、ワークフローフレームワーク１１４は、様々な既存のワークフローエンジンのいずれかを使用して実現されることが可能である。図９におけるワークフローエンジン３００は、一部のワークフローエンジンが、どのように構成され、機能するかの例を与えることだけを意図している。ワークフローエンジン３００は、新たなワークフロー定義３０４を解析するパーサ３０２を有する。コントローラー３０６は、ワークフロー３０４のインスタンスを実行するユニットである。コントローラー３０６は、ワークフローの主題を管理し、ワークフローのアクティビティを実行し、リスナーを呼び出し、イベントをリッスンし、タイムアウトを扱い、ログ記録を実行するといったことを行う。リスナー３０８は、同期的なアクティビティとして実施されることが可能であり、前提条件が満たされた際にコントローラー３０６によって呼び出される。リスナー３０８は、ワークフローの入ってくるイベントをリッスンする。ローダー３１０が、ワークフローの主題を、ｉｄにより、ＣＭＤＢ２８０などの永続ストアからロードする。

図１０は、インシデントを扱うための例示的なワークフロー３３０を示す。ワークフロー３３０は、パッケージを使用して実施されることが可能な構造化されたプロセスのタイプの典型である。アクティビティ３３２（パッケージのワークフロー部分において定義される）は、ワークフロー３３０のノードである。ワークフロー３３０の主題は、作業アイテム、ユーザー、電子メールなどを含む。アクティビティ３３２のいずれも、技術スタックの他の何らかの構成要素によってトリガされることが可能である。他のタイプのアクティビティには、タスクを送ること、サービスを呼び出すこと、人々に通知を送信すること、アーティファクトを操作すること、またはリンクサーバ（アーティファクトに対するリファレンスを有する可能性がある）を経由することによって別のスタック構成要素のアーティファクトを操作することが含まれることが可能である。また、パッケージのワークフローコード部分は、そのワークフローの或る特定のインスタンスを何がトリガするかを定義する、または記述する情報を含むことも可能である。また、パッケージのワークフローコード部分は、フローロジック、すなわち、アクティビティの間のフローに関するパスおよび条件も記述しなければならない。ワークフローが、他のスタック構成要素とどのように対話することが可能であるかのいくつかの例を考慮されたい。ワークフローが、ＣＭＤＢの中の作業アイテムおよびアーティファクトを取得する、作成する、更新する、または削除することが可能である。ワークフローは、リンク付けフレームワークを介して外部システムと対話することができ、例えば、管理構成要素（例えば、ＭＯＭ）によって監視されるサービス上のタスクを実行することができる。また、ワークフローは、通知を電子メール送信する、または他の手段によって送ることも可能である。ワークフローは、特定の情報で知識項目に注釈を付けることさえできる。

前述したとおり、パッケージは、パッケージの中で記述されるワークフローが、自動的に作成され、実行され、監視されることが可能なように、ワークフローエンジンを構成することができなければならない。ワークフローには、自動化を扱う単純なインシデントから、ユーザーによって定義される長期継続の複雑なワークフローまで任意の物事がかかわることが可能である。次のセクションにおいて説明されるとおり、パッケージ作成者は、変更許可、エスカレーション、通知、インシデント処理、資産ライフサイクル管理などのＩＴプロセスに関するワークフローを定義することができる。ベースラインパッケージまたは標準パッケージ（作成されるほとんどのパッケージによって使用される）が、例えば、ＭＯＦにおいて見られる標準の動作に基づくテンプレートを提供することができる。

やはり前述したとおり、ＷＷＦが、ワークフローフレームワークとして使用されることが可能である。しかし、コードを書かなければならないことを避けるのに、作成は、Ｖｉｓｕａｌ Ｓｔｕｄｉｏワークフローデザイナにおいて実行されることが可能である。ワークフロータイプは、作業アイテムまたはアーティファクトの状態変化イベントに結び付けられることが可能である。特定の状態変化、例えば、或る問題の状態を「解決済み」に設定することにより、問題解決を扱うワークフローの新たなインスタンスが開始されることが可能である。ワークフローのコンテキストは、作業アイテムを含むことが可能であり、したがって、ワークフローにおけるロジックは、その作業アイテムの特性、または関連するアーティファクトの特性、例えば、その問題による影響を受けるサービスの所有者の電子メールアドレスにアクセスすることができる。解決−インシデント、エスカレート−インシデント、更新−インシデント、更新−ＣＭＤＢなどのようなアクティビティを含む、ボックス外の標準ワークフローアクティビティのライブラリが、アーティファクトを操作するのに提供されることが可能である。標準ワークフローアクティビティのパレットが、ＷＷＦデザイナにおいて提供されることが可能である。これらのアクティビティには、電子メールを送信すること、バグをエスカレートさせること、あるいはＭＯＳ、ＳＭＳ、Ｅｘｃｈａｎｇｅ、ＳｈａｒｅＰｏｉｎｔ、またはＴＦＳのようなリンクされた製品を呼び出すことによってソフトウェアを展開することが含まれることが可能である。このアプローチでは、パッケージ作成者は、コードを必ずしも書かなければならないことなしに、アクティビティをドラッグアンドドロップすることによって、事前定義されたプロセスを作成することができる。

図１１は、ワークフローを宣言的に定義するためのマークアップ３５０を示す。この例におけるマークアップ３５０は、ＸＡＭＬ（拡張アプリケーションマークアップ言語）で書かれる。マークアップ３５０は、パッケージから抽出され、ワークフローフレームワークにプラグインされるコード部分であることが可能なタイプのコードの例である。

前述したとおり、技術スタックは、パッケージが、関連する知識でプロセスを補足するのに使用することができる知識フレームワークを含むことが可能である。知識フレームワークは、理想的には、文書のコレクションを超えたものであり、むしろ、知識フレームワークは、索引を作成すること、探索を許すこと、関係する項目を関連付けることなどの知識管理機能を有さなければならない。項目間の関係を追い、或る特定のパッケージのコンテキストなどの所与のコンテキストにおいて、いずれの項目が所与の項目と関係しているかを知る能力が、存在しなければならない。バグレポート、インシデント、または問題のような作業アイテムは、目的またはコンテキストを示す分類を有することが可能である。例えば、作業アイテムは、作業アイテムがパスワードリセットを求める要求であることを示すフィールドを有することが可能である。何らかの関連する知識が存在することを示すいくらかの情報が、作業アイテムのパッケージの中に存在することが可能である。その情報は、作業アイテムを分類にリンクするリンクであることが可能である。ユーザーが、パスワード変更をどのように要求すべきかについて知る必要がある場合、ユーザーは、例えば、パスワードを要求する際に、電子メールがユーザーのマネージャーに送信される必要があること、または符号化されたプロセスに従って、何であれステップが行われる必要があることを示す知識を獲得することができる。知識集約型の使用シナリオにおいて、知識のライフサイクルを定義するワークフローまたはパッケージが存在することが可能であり、例えば、何らかの個人または役割が、或るトピックに関する項目の必要性が存在することを決定し、何らかの個人または役割が、原案を書き、誰かが、この原案を点検し、誰かが、この原案を生産に移すといったことなどである。知識フレームワークは、Ｍｉｃｒｏｓｏｆｔ ＳｈａｒｅＰｏｉｎｔ、ウェブフロントエンドを有するデータベース、Ｆａｃｔｉｖａ、ＡｓｋＭｅ、ＳｉｔｅＳｃａｐｅなどの市販の製品を使用して実施されることが可能である。

図１２は、リンクサーバまたはリンク付けフレームワークによってリンクされることが可能な作業アイテム、アーティファクト、警報およびその他の物事の例３７０を示す。リンク付けフレームワークは、新たなデータ型、または新たなデータクラスの間で新たなコネクタを作成するのに使用されることが可能である。ソリューション空間に依存して、他の外部ストアが、接続される、またはリンクされることが可能である。また、リンク付けは、スタック構成要素の上にウェブサービスが置かれている場合にも可能であり得る。この場合、リンクされたアイテムの間で何らかのリンク付けおよび変換を宣言的に表現することが容易である可能性がある。つまり、リンク付けフレームワークは、１つの構成要素に対応するアーティファクトを、別の構成要素（またはＭＯＭまたはＳＭＳなどのＩＴ管理プラットフォーム）に対応するアーティファクトに対してリンクし、交換／同期し、さらにマップする能力を提供することが可能である。ＴＦＳリンク付け−ルーティングサーバ（前述された）を使用して、システムが接続されることが可能である。アーティファクト、およびアーティファクトの関係は、リンク付けサーバにおいて登録される。一実施形態では、これらのアーティファクトが、ウェブサービスを介して利用可能である場合、リンクサーバは、これらのアーティファクトの関係およびロケーションを保持することができる。ＭＯＭ接続性、ＳＭＳ接続性、およびＴＳＦ接続性のためのコネクタは、標準のテンプレートライブラリの中で提供されるとおり作成される、または使用されることが可能である。単純な実施形態では、リンクは、第１のオブジェクト／アーティファクトに関する第１の一意識別子と、第２のオブジェクト／アーティファクトに関する第２の一意識別子との間の関連付けであることが可能である。この実施形態において、例３７０の間のリンクは、例３７０に対応する一意識別子のペアの間の関連付けセットである。

前述したとおり、一実施形態では、技術スタックは、拡張可能である。このため、新たなパッケージが、新たなクラス、新たなアーティファクト、新たなタイプのアクティビティ、アーティファクト間のリンク、新たなワークフローなどを定義する場合、スタック構成要素は、この新たな情報を学習し、この新たな情報に適応することができる。スタック構成要素は、パッケージからの新たな情報に従って再構成される、または拡張される。スタック構成要素は、好ましくは、スタック構成要素の機能を拡張するのに使用されることが可能である拡張可能なＡＰＩまたは抽象化層を有する。技術スタックのこれらの特徴は、パッケージが、プロセスを自動化する技術スタックから、プロセスの定義がきれいに切り離されることを可能にするプロセス、および関連するメタデータの自立型の符号化の役割をすることを、より容易にすることができる。

（プロセスのパッケージフィーチャおよび例）
パッケージは、動作環境または技術スタックにプラグインされることが可能なプロセスの外部表現またはモデルの役割をすることが可能であり、つまり、技術スタックと、作成環境と、パッケージ自体との間の区別が存在することに留意されたい。同一のパッケージが、様々なＩＴシステムの様々な技術スタックにプラグインされることが可能である。パッケージは、新たなリンク、スタックにおける様々な箇所で行われる作業を有する新たなワークフロー、新たな文書、およびそれらの新たな文書に対するリンク、および新たなフォームを持ち込むことが可能である。さらに、この情報は、宣言的な仕方で符号化されることが可能である。つまり、作成者は、パッケージの中で、フォームを宣言する、例えば、ブログにおけるドロップダウンメニューの配置を定義する、別の箇所でテキストフィールドを定義する、別の箇所でボックスを定義する、ドロップダウンが、宣言された選択肢リストから選択されたデータソースに付加されることを宣言する、インタフェース要素が、選択肢に応じてインタフェース要素が何を表示するかを制限することを宣言するといったことなどである。このタイプの情報は、このタイプの情報を実行するスタックまたは動作環境において表現されることが可能である。同様に、レポートが、ハードコードされるのではなく、抽象で宣言されることが可能である。

一部の実施形態では、パッケージは、メタデータによって駆動されるソリューションである。ソリューションが開発されるべき技術スタックを所与として、新たなデータ型をスタック構成要素に追加することが可能であり得る。しかし、今やワークフローが、例えば、正しいデータ型を有さないために機能しない可能性があるため、そのステップだけでは、実際的ではない可能性があり、つまり、作成者は、既存のワークフローに入り込み、例えば、追加された新たな属性について知るように新たなデータ型を扱うことができるようにワークフローのデータを変更しなければならない可能性がある。同様に、既存のフォームは、フォーム作成者が、属性について知ってさえいなかったために、直ちにそのデータ型を「実行する」ことができない可能性がある。このため、これらの物事をパッケージの中で一緒に関連させることにより、パッケージは、プロセスの自立型の符号化となることが可能であり、つまり、パッケージは、技術スタックの中に投入されることが可能であり、パッケージが記述する機能およびデータが、その技術スタック全体にわたってアクティブになる。このことは、技術スタックのいくつかの部分が、パッケージの中のメタデータ言語を理解し、したがって、パッケージをまとまりのある単位として一緒に「実行する」ことができる場合、特に実現可能である。さらに説明すると、パッケージは、新たな属性を有する新たな物事が存在することなどをスタックに知らせることができ、パッケージは、それらの新たな物事を、システムの様々な部分における他の物事にリンクすることができる。次に、スタックレベルで、パッケージは、それらのリンク可能な新たな物事が、技術スタック全体にわたって操作可能であるという想定の下で作成されることが可能である。例えば、アクティビティを有する新たなワークフローは、それらの新たな物事を操作することができ、あるいは、新たな物事が或る仕方で変更された際に、構成要素におけるトリガが呼び出されることが可能である。

さらに説明すると、アーティファクトストア（例えば、オブジェクト指向データベース、ＣＭＤＢなど）、フォームフレームワーク（例えば、Ｏｆｆｉｃｅ １２）、ワークフローエンジン（例えば、ＷＷＦ）、情報労働者生産性スイート、および前述した他の製品などの、様々なソフトウェア製品が利用可能であるものと考慮されたい。これらの種類の製品（スタック構成要素）は、いくつかの仕方で収斂している。例えば、多くは、ＳＤＭベースの、または他のＸＭＬベースのモデル化言語などの宣言コードを使用して拡張されることが可能なオブジェクトモデルおよび機能である、またはそのようなオブジェクトモデルおよび機能を有することになる。つまり、これらの種類の製品は、異なる構成要素に関して同一の言語になっていることが可能な宣言コードによって構成されることが可能である。しかし、組織の技術スタックのこれらの異なる構成要素は、まとまりのある単位として前もってプログラミング（構成）または拡張されていない。本明細書で説明される一部の実施形態によれば、今や、ポータブルなパッケージを使用して、標準であれ、非標準であれ、ＸＭＬ、ＳＤＭ、または他の言語などのモデル化言語を使用して、オブジェクトモデルを宣言的に拡張させるパッケージの一般的な能力を利用することによって、これらの構成要素が「一緒につなげられる（ｗｉｒｅ ｔｏｇｅｔｈｅｒ）」ことが可能である。

プログラミング言語が、標準ライブラリのセットを有するのと同様に、技術スタックは、他のパッケージが参照し、使用する、または拡張することができる標準パッケージのセットを有することが可能である。これらの標準パッケージは、特定のシナリオに的を絞っていることが可能であり、後段で説明される、そのようなシナリオに関係する基本アーティファクト、アクティビティ、リンクなどを定義する。

ＩＴ管理の分野において、サービス管理シナリオが、パッケージ化されたポータブルソリューションを使用して自動化されることが可能である。多くのスタック構成要素に関係することが可能なコール管理のためのプロセスが、符号化されることが可能であり、つまり、電話、チャット、電子メール、またはウェブさえ介する着信「コール」が、コールキュー管理、ＣＴＩ（コンピュータ電話統合）、ＩＶＲ（インテリジェント音声応答）、監査、自動フォームポピュレーション、およびプレゼンスと一体化されることが可能である。また、インシデント管理シナリオ、例えば、インシデントのライフサイクルを通じたインシデントの状態遷移および所有権を管理することがかかわるインシデント追跡が、符号化されることも可能である。インシデント管理プロセスには、分類の自動ポピュレーション、知識の問題および可視性に対するサービスおよび資産の関連付け、資産データの事前発見、および変更履歴が含まれることが可能である。また、要求管理プロセスが、パッケージの中に符号化されることも可能である。情報、およびハードウェアアップグレードまたはソフトウェアアップグレードを求める要求を扱うことを含むことが可能なプロセス。サービス管理プロセスパッケージは、例えば、ＭＯＭなどのイベント管理システムもしくはパフォーマンス管理システム、または外部サービスデスクからインシデントを自動的に生成することによって、サービス監視プロセスと一体化されることが可能である。また、問題管理ソリューションが、自動化されることも可能である。そのようなパッケージは、基礎をなす問題の徴候としてインシデントを認識して、インシデント間の構成、トポロジ、知識、および共通性の可視性をもたらして、パッケージが問題を解決するのを助けることを含むことが可能である。別のタイプのサービス管理プロセスが、根本的原因分析である。これらのタイプのプロセスは、ＣＭＤＢの中の相互関係マップ、ならびにサービスおよび資産の現在の状態を使用して、基礎をなす真性の問題を自動的に認識する。サービスレベル管理プロセスが、パッケージの中に符号化されることが可能である。これらは、インシデント優先順位付け、エスカレーション、場合によりＳＬＡ（サービスレベル契約）に結び付けられた通知、またはサービスおよび問題タイプによるきめ細かいＳＬＡの設定を自動化することが可能である。通知ソリューションおよび簿記ソリューションが、パッケージの中に格納されることが可能である。例えば、そのようなパッケージは、インシデントを扱う際に記録を取り、適切な時点で利害関係者に要求される通知を送信するプロセスを自動化することができる。別の例が、バグエスカレーションであり、この場合、バグであると考えられる問題が、ＴＦＳなどのバグ追跡システムを介してエスカレートされる。サービス管理タイプのソリューションパッケージの別のタイプは、インシデント分類および事前収集された構成データに基づいて、場合により、知識ベースの中のランク付けに基づく、適切な対応する知識がアナリストに提示される、知識使用および知識維持と関係する。より上層のアナリストは、知識を定期的に更新して、大量の問題を食い止めることができる。

変更管理は、パッケージの中に符号化されることが可能なプロセスを有する別の領域である。誤った管理をされたＩＴ変更は、ＩＴシステムにおけるインシデントおよびダウンタイムの大きな原因である。変更管理プロセスは、ダウンタイムを最小限に抑えるように制御された仕方で変更を導入するプロセスである。変更の基本アイテムは、しばしば、変更オーダと呼ばれ、変更を通じて追跡されるアイテムの基本単位は、構成アイテム、つまり、ＣＩ（前述した）と呼ばれる。ＣＩは、モデルベースの管理アプローチの部分である、管理されたエンティティ、または関係であることが可能である。しかし、ＣＩは、ポリシー、ユーザーグループ、または連絡先および関連する関係であることも可能である。いくつかの特定の符号化可能な変更管理シナリオまたは変更管理プロセスには、以下が含まれる。変更オーダの作成から完了までワークフローを駆動して、利害関係者（例えば、リスク管理者、予算管理者、スケジューラ、サービス所有者、およびエンドユーザー）から必要な許可および承認を確保するものとして構造化されることが可能な変更許可および変更承認。変更管理のためのプロセスは、作成される、またはカスタマイズされることが可能である。影響を受ける関係者に、電子メール、ポータルなどを介して、差し迫った変更について常に知らせておくことが可能な変更通知プロセスが、作成されることが可能である。リスク管理者が、１つまたは複数のサービスにわたる、要求された変更を行うことの影響（またはリスク）を評価することを助ける影響分析プロセスが、符号化されることが可能である。そのようなプロセスは、ＣＭＤＢの中の関係を利用することによって自動化されることが可能である。スケジューラが、場合により、変更窓、サービススケジュール、および要求されるスタッフの利用可能性に基づいて、最も少ない悪影響を伴って変更を行う適切な機会を見つけ出すのを助けることを含むことが可能な変更スケジューリングプロセスが、作成されることが可能である。また、構成監査プロセスが、パッケージ化されることも可能であり、そのようなプロセスは、例えば、構成情報を、ＳＭＳ ＤＣＭ（Ｄｅｓｉｒｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）ツールおよび物理的インベントリツールを使用してスキャンされた現実世界の情報と比較することを含むことが可能である。

また、パフォーマンス管理およびセキュリティ管理のためのプロセスが、プロセスパッケージの中に捕捉されることも可能である。セキュリティ管理プロセスの例には、調査アクティビティおよび通知アクティビティと組み合わされた警報、推奨される知識が管理者に提供されることにつながる自動化された分析、およびその他が含まれる。

また、資産管理と関係するプロセスが、ポータブルなスタックにプラグイン可能なパッケージの中に捕捉されることも可能である。資本設備決定は、しばしば、サービス情報を考慮に入れるＴＣＰ（総所有コスト）レポートに基づく。そのような決定は、変更管理を介する変更を駆動することが可能である。より具体的には、資産−構成追跡プロセスを使用して、サービス、資産、ユーザー、構成、ポリシー、および以上の、互いに対する関連付けなどのＣＩが、時間を通じて追跡されることが可能である。このことにより、資産の所有権、資産がどこに設置されるか、いずれのサービスに資産が関与するか、または資産が壊れた場合、誰が呼び出されるべきかに関して問い合わせることなどの、付加的なプロセスが可能になる可能性がある。変更オーダの自動化された実行は、好ましくは、エンタープライズアーティファクトストアの中で、このデータを最新に保つ。別の符号化可能な資産管理プロセスが、環境におけるソフトウェアの存在および使用に関する自動化された検査を含み、費用および使用許可リスクを低減する措置をとるソフトウェアライセンス遵守管理である。ＴＣＯ追跡プロセスが、或る特定のサービス、または資産に関して、時間を通じたサービス費用および変更費用を報告することができる。この情報は、料金請求、アウトソーシング、資本財およびベンダの選択にまつわる決定を行うのに使用されることが可能である。

（結論）
要約すると、１つまたは複数の実施形態において、単一のプラグアンドプレイパッケージ（他のプラグアンドプレイパッケージを参照し、そのため、そのようなパッケージを論理的に含むことが可能な）が、他の接続された製品上で（スタックの外部で）人々および自動化がかかわる完全なＩＴ／ビジネスプロセスの編成を首尾一貫した仕方で提供するように、構成要素のスタックを駆動する能力を有することが可能である。スタックの構成要素は、それらの構成要素の性質を所与として、互いに直接に通信しても、しなくてもよい。しかし、関係のある構成要素のすべてが、協働することができる。とりわけ、スタック構成要素（例えば、フォーム、ワークフロー、アーティファクトのクラス）の宣言型構成が、基礎をなす宣言型構成の知識のために、例えば、スキーマおよびワークフローアクティビティが、同一のプラグアンドプレイパッケージの中に入っているため、スキーマおよびワークフローアクティビティの知識のために、基礎をなす構成要素（例えば、ＣＭＤＢまたはワークフローエンジン）の振舞いの知識で表現されることが可能である。

プログラム命令を格納するのに使用される記憶デバイスは、ネットワーク全体にわたって分散されることが可能であることが、当業者には認識されよう。例えば、リモートコンピュータが、ソフトウェアとして説明されたプロセスの例を格納することができる。ローカルコンピュータまたは端末コンピュータが、リモートコンピュータにアクセスして、プログラムを実行すべきソフトウェアの一部分または全部をダウンロードすることができる。代替として、ローカルコンピュータは、必要に応じて、ソフトウェアの部分をダウンロードする、または一部のソフトウェア命令をローカル端末装置において実行し、一部のソフトウェア命令をリモートコンピュータ（またはコンピュータネットワーク）において実行することによって、分散処理を行うことも可能である。また、当業者に知られている従来の技術を利用することによって、ソフトウェア命令のすべて、または一部分が、ＤＳＰ、プログラマブルロジックアレイなどの専用回路によって実行されてもよいことが、当業者には認識されよう。

前述した実施形態および特徴のすべては、揮発性および／または不揮発性のコンピュータ可読媒体またはデバイス可読媒体の中に格納された情報の形態で実現されることが可能である。この媒体には、前述した様々な実施形態を実行するようにコンピューティングデバイスに能力を与える、またはそのようにコンピュータを構成するのに使用されることが可能なマシン実行可能命令、またはソースコード、または他の任意の情報を（実行前に、実行中に、または実行前と実行中の両方で）格納するＣＤ−ＲＯＭ、磁気媒体、フラッシュＲＯＭなどが少なくとも含まれるものと考えられる。また、この媒体には、実施形態を実行するプログラムの実行中にＣＰＵ命令などの情報を格納するＲＡＭなどの揮発性メモリが、少なくとも含まれるものとも考えられる。

例示的なＩＴシステムを示す図である。 パッケージを示す図である。 どのようにパッケージが、プロセスを共有するのに使用されるかを示す図である。 例示的なパッケージを示す図である。 パッケージを技術スタックにロードするのにアプリケーションが実行することが可能なプロセスを示す図である。 パッケージをプラグインするための別のプロセスを示す図である。 技術スタックが例示的なパッケージを実行する際の技術スタックの例示的なプロセスフローを示す図である。 ＣＭＤＢ（構成管理データベース）を示す図である。 例示的なワークフローエンジンを示す図である。 インシデントを処理するための例示的なワークフローを示す図である。 ワークフローを宣言的に定義するためのマークアップを示す図である。 リンクサーバまたはリンク付けフレームワークによってリンクされることが可能な作業アイテム、アーティファクト、警報、およびその他の物事の例を示す図である。

Claims (34)

1. パッケージを格納する１つまたは複数の揮発性コンピュータ可読媒体および／または１つまたは複数の不揮発性コンピュータ可読媒体であって、
   前記パッケージは、拡張可能なアーティファクトストア、拡張可能なワークフローエンジン、および拡張可能なフォームフレームワークを含むエンタープライズ技術スタックのディスクリートの構成要素を、前記パッケージによって定義されるビジネスプロセスを協力的に自動化するように構成するための構成情報を含み、
   前記構成情報は、
   前記パッケージのビジネスプロセスに関与する人的役割のタイプ、および前記パッケージのビジネスプロセスに関与するコンピューティングデバイスおよび／またはソフトウェアサービスのタイプを少なくとも含む、前記パッケージのビジネスプロセスの一部である１つまたは複数のタイプのエンタープライズアーティファクトを定義するアーティファクト定義情報と、
   前記パッケージのビジネスプロセスと関係する情報を入力するため、および／または閲覧するための１つまたは複数の対話型フォームを定義するフォーム定義情報と、
   前記アーティファクト定義情報によって定義される前記タイプのエンタープライズアーティファクトに対するリファレンスまたはリンク、および前記フォーム定義情報によって定義される前記１つまたは複数のフォームに対するリンクまたはリファレンスを含む、前記パッケージのビジネスプロセスの１つまたは複数のワークフローを定義するワークフロー定義情報とを含むことを特徴とする媒体。
2. 前記アーティファクト定義情報は、前記アーティファクト情報によって定義される前記１つまたは複数のタイプのエンタープライズアーティファクトの表現をインスタンス化し、格納するように前記アーティファクトストアを構成するのに使用されることが可能であることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
3. 前記ワークフロー定義情報は、前記ワークフローエンジンが、前記ワークフロー情報によって定義される前記ワークフローのワークフローインスタンスをインスタンス化することができるようにするのに使用されることが可能であることを特徴とする請求項２に記載の１つまたは複数のコンピュータ可読媒体。
4. 前記フォーム定義情報は、エンタープライズ全体にわたるディスプレイが、情報を入力するため、および閲覧するための対話型フォームを表示することができるようにするのに使用されることが可能であることを特徴とする請求項３に記載の１つまたは複数のコンピュータ可読媒体。
5. 前記構成情報の少なくとも一部分は、ＳＤＭ（システム定義モデル化）言語の形態である、またはＳＤＭ言語からコンパイルされることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
6. 前記ＳＤＭ言語は、標準のマークアップ言語に基づくことを特徴とする請求項５に記載の１つまたは複数のコンピュータ可読媒体。
7. 前記標準のマークアップ言語は、ＸＭＬを含むことを特徴とする請求項６に記載の１つまたは複数のコンピュータ可読媒体。
8. 前記パッケージは、異なるアプリケーションが、前記パッケージを使用して、前記パッケージによって定義される前記ビジネスプロセスを実行するようにエンタープライズ技術スタックの異なるインスタンスを構成することができるようにポータブルであることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
9. 前記パッケージは、他の１つまたは複数のパッケージに対する１つまたは複数のリファレンスをさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
10. 前記構成情報は、宣言コードを含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
11. 前記宣言コードは、ＸＭＬベースの言語を含むことを特徴とする請求項１０に記載の１つまたは複数のコンピュータ可読媒体。
12. 前記パッケージによって定義される前記ビジネスプロセスは、ＩＴ（情報技術）管理プロセスを含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
13. 前記ＩＴ管理プロセスは、変更管理プロセスを含むことを特徴とする請求項１２に記載の１つまたは複数のコンピュータ可読媒体。
14. 前記ＩＴ管理プロセスは、インシデント管理プロセスを含むことを特徴とする請求項１２に記載の１つまたは複数のコンピュータ可読媒体。
15. 前記ＩＴ管理プロセスは、リリース管理プロセスを含むことを特徴とする請求項１２に記載の１つまたは複数のコンピュータ可読媒体。
16. 前記プロセスは、ＩＴＩＬ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｌｉｂｒａｒｙ）の中で定義されるプロセスに対応することを特徴とする請求項１０に記載の１つまたは複数のコンピュータ可読媒体。
17. 前記パッケージは、前記パッケージのプロバイダを認証するのに使用されることが可能な前記パッケージのデジタルシグネチャをさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
18. 前記パッケージは、前記パッケージのバージョンを示すバージョン情報をさらに含むことを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
19. プロセスを記述するパッケージを生成するための方法であって、
    ワークフローエンジンにプラグインされた場合、前記ワークフローエンジンが、ワークフローのインスタンスをインスタンス化して、実行することができるようにする、前記プロセスに対応する前記ワークフローを定義するワークフロー定義情報と、
    フォームフレームワークにプラグインされた場合、前記フォームフレームワークが、フォームをユーザーに表示することができるようにする、フォームと、前記ワークフロー定義情報によって定義された前記ワークフローに前記フォームをリンクする情報とを定義するフォーム定義情報と、
    アーティファクトストアにプラグインされた場合、前記アーティファクトストアが、アーティファクト定義情報によって定義されたタイプのアーティファクトを格納することができるようにする、１つまたは複数のクラスのアーティファクトと、前記ワークフロー定義に前記アーティファクトをリンクする情報とを定義する前記アーティファクト定義情報とを含むプロセス定義情報をポータブルなパッケージの中に格納することを含むことを特徴とする方法。
20. 前記格納することは、前記パッケージの中に、前記パッケージの作成者を識別する情報、別のパッケージに対する前記パッケージの依存関係、および前記パッケージが準拠するパッケージ化スキーマを含むパッケージ情報を格納することをさらに含むことを特徴とする請求項１９に記載の方法。
21. リンク付けフレームワークにプラグインされた場合、前記リンク付けフレームが、前記ワークフローエンジン、前記フォームフレームワーク、または前記アーティファクトストアのいずれか１つの中のアイテムを、前記ワークフローエンジン、前記フォームフレームワーク、または前記アーティファクトストアの別の１つの中のアイテムにリンクすることができるようにするリンク付け情報を、前記パッケージの中に格納することをさらに含むことを特徴とする請求項１９に記載の方法。
22. 前記プロセス定義情報を前記格納することは、前記プロセス定義情報を宣言コードとして形成することを含み、前記ワークフロー定義情報、前記フォーム定義情報、および前記アーティファクト定義情報は、それぞれ、前記ワークフローエンジン、前記フォームフレームワーク、および前記アーティファクトストアによって実施される言語におけるコードのそれぞれの部分を含むことを特徴とする請求項１９に記載の方法。
23. 他のプロセス定義情報を含む別のパッケージに対するリファレンスを、前記パッケージの中に格納することをさらに含むことを特徴とする請求項２２に記載の方法。
24. 前記プロセス定義情報は、リンク付けフレームワークにプラグインされた場合、前記リンク付けフレームワークが、前記ワークフローエンジン、前記フォームフレームワーク、および前記アーティファクトストア異なる物の上に格納された前記プロセス定義情報の異なる部分によって定義された異なるアイテムをリンクすることができるようにするリンク情報をさらに含むことを特徴とする請求項１９に記載の方法。
25. 前記プロセス定義情報は、ポータルフレームワークにプラグインされた場合、前記ポータルフレームワークが、前記プロセス定義情報によって定義される前記プロセスの一部であるポータルを表示することができるようにするポータル情報をさらに含むことを特徴とする請求項１９に記載の方法。
26. 前記プロセス定義情報は、知識フレームワークにプラグインされた場合、前記知識フレームワークが、前記プロセス定義情報によって定義される前記プロセスと関係する知識をユーザーに提供することができるようにする知識情報をさらに含むことを特徴とする請求項２５に記載の方法。
27. パッケージを格納する１つまたは複数の揮発性コンピュータ可読媒体または１つまたは複数の不揮発性コンピュータ可読媒体であって、
    前記パッケージは、
    ＩＴ（情報技術）スタックにプラグインされて、前記ＩＴスタックが、宣言コードによって定義されるプロセスを実行することができるようにすることが可能である、前記プロセスのワークフロー、前記プロセスのアーティファクトのタイプ、および前記プロセスの形態を含むビジネスプロセスまたはＩＴ管理プロセスを定義する前記宣言コードと、
    前記パッケージを識別するパッケージ識別情報と、
    前記パッケージがフォーマットされるスキーマ、またはスキーマに対するリファレンスを含むスキーマ情報とを含むことを特徴とする媒体。
28. 前記パッケージ識別情報は、前記パッケージの製造者または作成者、前記パッケージのバージョン番号、前記パッケージが依存する別のパッケージ、または前記パッケージを認証するためのセキュリティ証明書の２つ以上を含むことを特徴とする請求項２７に記載の１つまたは複数のコンピュータ可読媒体。
29. 前記宣言コードは、システム定義モデル化言語に準拠することを特徴とする請求項２７に記載の１つまたは複数のコンピュータ可読媒体。
30. 前記ビジネスプロセスまたはＩＴ管理プロセスを定義する宣言コードは、前記ＩＴスタックにおいてワークフローフレームワークによって使用されることが可能な部分、前記ＩＴスタックにおいてフォームフレームワークによって使用されることが可能な部分、および前記ＩＴスタックにおいてアーティファクトストアによって使用されることが可能な部分を含むことを特徴とする請求項２７に記載の１つまたは複数のコンピュータ可読媒体。
31. 前記ワークフローフレームワーク、前記フォームフレームワーク、および前記アーティファクトストアは、その他の構成要素とは無関係にインストールされて、使用されることが可能な前記ＩＴスタックの別々の自律的な構成要素であることを特徴とする請求項３０に記載の１つまたは複数のコンピュータ可読媒体。
32. 前記アーティファクトストアは、構成アイテム、および前記構成アイテム間の関係を格納することを特徴とする請求項３１に記載の１つまたは複数のコンピュータ可読媒体。
33. 前記アーティファクトストアは、ＣＭＤＢ（構成管理データベース）を含むことを特徴とする請求項３２に記載の１つまたは複数のコンピュータ可読媒体。
34. 前記ビジネスプロセスまたは前記ＩＴプロセスを定義する前記宣言コードは、前記プロセスに関与する人々または役割、前記ＩＴスタックを介する、前記人々または前記役割へのアクティビティフロー、および／または前記人々または前記役割からのアクティビティフローを定義することを特徴とする請求項２７に記載の１つまたは複数のコンピュータ可読媒体。

Images