IBM Rational Change は、スタンドアロン・モードとセントラル・モードの 2 つの操作モードをサポートします。
スタンドアロン・モードでは、変更依頼 (CR) はサーバーに接続した開発データベースに保存されます。 CR をアクセスするには、ユーザーは CR が保存されているデータベースにログオンする必要があります。 CR とタスクの関係付けを確立するには、両者が同じデータベースに存在する必要があります。 利用できるデータベースは、IBM Rational Change が依存している特定の IBM Rational Synergy サーバーに対して利用可能なものに限定されます。 この動作は以前のリリースまでと同じです。
セントラル・モードでは、すべての CR はセントラル CR データベースに保存されます。このセントラル CR データベースは CR 専用のリポジトリーです。 IBM Rational Change は常に暗黙的にセントラル CR データベースに接続していますので、ユーザーはすべての CR にアクセス可能な状態で、セントラル・サーバー・クラスター内の任意のデータベースにログオンできます。 CR とタスクの関係付けは、両者の物理的な存在場所に制約されません。 さらに、セントラル・サーバー・クラスター内のデータベースは、複数の IBM Rational Synergy サーバーにまたがることが可能になり、地理的にも離れた場所に配置できます。
現在、スタンドアロン・サーバーからセントラル・サーバー構成へのアップグレード・パスはありません。 セントラル・サーバー・モードは、新規の配置としてのみサポートされます。
セントラル・モードには、2 つの相補的なサーバー・タイプがあります。セントラルとリモートです。
1 つのセントラル・サーバー・クラスターには、常に 1 つのセントラル・サーバーと 0 個またはそれ以上の数のリモート・サーバーが存在します。 各サーバーは、タイプにかかわらず、複数のデータベースを管理できます。 セントラル・サーバーはセントラル CR データベースと、オプションで、他のデータベースを管理できます。 エンド・ユーザーが直接やり取りをするのは、このサーバーだけです。
リモート・サーバーは、セントラル・サーバーとリモート開発データベースの間で "プロキシー" として振る舞います。 リモート・サーバーが必要になるのは、セントラル・サーバー・クラスターにある別の IBM Rational Synergy サーバーが管理するデータベースにアクセスする必要がある時です。
下図を使って一つの例を考えてみましょう。 ある企業の本社はサンフランシスコ (セントラル Change サーバー) にあり、営業所がマドリッドとベルリン (図の 2 つの地域) にあるとします。 この企業は IBM Rational Synergy データベースを各地域に保持し、それぞれの地域にある IBM Rational Synergy サーバーがそのデータベースを管理します。 セントラル・サーバーとセントラル CR データベースはサンフランシスコにあり、マドリッドとベルリンにあるデータベースとは、各都市にあるリモート・サーバーを通じて通信できます。 このデプロイメントの状態では、1 つのセントラル・サーバーと 2 つのリモート・サーバーが存在します。すべてのユーザーは、リモート・サーバーではなくセントラル・サーバーを通じて IBM Rational Change にアクセスし、タスクの作業のためにログインしているデータベースに関係なく、すべての CR にアクセスできます。