企業がデプロイ方式に及ぼす影響（Corporate Influences on Deployment Architecture） †
要約 †
マーケテクトがデプロイ方式を検討する際には、単に顧客の要件だけを考えているだけではダメで、
ソリューションを提供する企業についても熟知しておかなければいけない。たとえば以下のようなことだ。
セールスサイクル †
セールスサイクルとは、企業が実際にモノを売り出すまでの時間やステップのこと。
コンシューマ向けの安価なソフトなら短くなるだろうし、
エンタープライズソフトウェアなら長くなるだろう。下手したら年単位になってしまうかも。
セールスサイクルを短くしたければ、たとえばxSP形式を使うのもひとつの手だ。
ただ、顧客からの影響を無視してxSPを採用するのは、あまりうまくない。
たとえば「とりあえずはxSPで試してみて、その後は自分たちの現場に導入したい」「これまで自社に導入していたソフトウェアをxSPに移行したい」など、話が複雑になることもある。
今（2003年）はまだレアケースだけど、きっと今後は増えてくるだろう。
インフラへの投資 †
サービスベースのアプリケーションモデルを採用する企業は決まって、
想定される要件に耐えうるインフラを構築するための費用を甘く見積もりすぎる。
技術的なリソース（ハードウェアやインフラ）と非技術的なリソース（データセンター要員や
サポート要員など）の両方を考慮して費用を見積もる必要がある。
それだけの資金や覚悟がないのなら、xSPやウェブサービスはやめておくことだ。
キャッシュフロー †
複雑なエンタープライズアプリケーションを、最低利用料を定めずにレンタルで提供するMSPを考えてみる。
年間ライセンスの場合（毎年一定額の支払いがある）とは違って、レンタルの場合は年間ライセンスと同程度の支払いがあるとは限らない（いつ解約されるかわからない）。
資金繰りには注意が必要だ。
柔軟性 †
顧客の環境にインストールして使う形式のソフトウェアだと、改良版をすばやく提供ができないこともある。
一度インストールしたソフトウェアをそうやすやすと変更したくはないと思う顧客もいることだろう。
その結果、どうなるかというと、複数のリリースを同時にサポートせざるを得なくなる。
xSPやウェブサービスでソリューションを提供すれば、この問題はクリアできる。
こちらがわで完全にコントロールできるので、アップグレードのスケジュールなども柔軟に設定できるようになるからだ。
地理的な分散 †
グローバル企業への売り込みをかけることを考えてみよう。
彼らは当然、導入にあたって必要となるサポートやサービスを受けられてしかるべきだと考えるだろう。
たとえば電話応対を自国語でやってもらえるかなど。
アプリケーションをxSPで提供する場合は、複数の場所にインストールする必要があるかもしれない。
パフォーマンスや可用性を保証するためだ。
ネットワークの速度は日々向上しているけれど、ローカルに置いたアプリケーションやデータに比べると見劣りする。
価格ではなくサービスで勝負 †
初期のxSPは価格で勝負していた。が、その多くは消えていった。
第二世代、第三世代のxSPは、利便性や信頼性、サポートなどのサービスで勝負するようになった。
その結果、サービスに注力し続けていれば長生きできるようになった。
担当者のつぶやき †
みんなの突っ込み †
