Loading
eCloud研究会
ラ・マンチャ通信
お問い合わせ

R-0015 イノベーションの試行を可能にするスケーラブルなフレームワーク
   2009年9月18日 中島丈夫 投稿
 
 イノベーションをやろう!と、私たちはいとも簡単に言ってのけていますが、実際には大変高いハードルがあるのが理解できます。
仮に事業部門が新しいビジネス・モデルを創案しても、それを支えるITがタイミング良く準備出来るかどうかも甚だ心もとない。
ここでは、クラウド・コンピューティングの活用がイノベーション活性化に大変効果的であることを論じます。
            
GRC: Governance, Risk, Complianse

イノベーションをスムーズに実現するためには、実環境開発 (in vivo development) のフレームワークが必要

 ”in vivo development” の言葉は、創薬の世界での開発手法が出典のようですが、一般的に研究開発や設計におけるイノベーションにおいてはcut & try、すなわち試行錯誤の自由度が重要な位置を占めます。一方で、ITの基幹系システム開発ではwell structuredな上流工程での構想・設計によるトップダウンな流れが当たり前で、手戻りを出来るだけ無くすことが開発プロジェクトト成功の要諦だと考えられています。 
ということで、モバイルのような社会インフラを睨んだ基幹系システムの革新を考えた場合、イノベーションをやろう!と、私たちはいとも簡単に言ってのけていますが、実際には大変高いハードルがあるのが理解できます。ものの作り方に整合性が無いわけですね。
事業部門が新しいビジネス・モデルを創案しても、それを支えるITがタイミング良く準備出来るかどうかは甚だ心もとない。
 先ず伝統的な基幹系システム開発での、要求・要件把握・定義、アーキテクチャ選択・決定、機器選択導入、一連のテスト、カット・オーバーという一直線の流れでは太刀打ちできない。 Web 2.0で提起されたような消費者とのネットワーク型のビジネスでは、ビジネス・モデル自身が先ずやってみて、チューンアップしていくことになることも多いでしょう。そしてモバイルなどのユビキタス環境では、インフラとの接続性やセキュリティ上の強固な施策など、プラットフォーム上の多くの準備が必要です。リアルワールドとの多様なend to end のテスト環境などを考えると、従来のバックエンド主体のソフトウェア開発手法の視界だけでは到底対応できないのが目に見えています。
ダウンサイジング時代には技術のディスラプションに対応して、本プロジェクトと並行した技術のフィージビリティ・スタディ・チームが編成されました。インターネット系システムではカット・オーバーという言葉が消え、常にβバージョンという循環型の対応が常識になりました。
グローバルな広がりの中での熾烈なビジネス戦争を勝ち抜くためには、多様な環境でのビジネスのスタート/ストップを迅速に行うことが必須です。そのためには、ビジネスのフィージビリティ・スタディを強く意識した、ITの実環境開発のフレームワークが必要になると思われます。
テスト・マーケットにしろ売上げが計上されれば会計システムとの連携が必要になるでしょうし、CRMシステムなどとも強い連携が要求されるでしょう。つまりGRCの観点から、迅速性の一方でぜい弱性は絶対ゆるされない。チェンジ&レジリエンスのIT要件です。  

クラウドの、ダイナミックなプロビジョニングと実資源管理による、IT支援の迅速性とスケーラビリティ

 このようなダイナミックな環境への対応が、従来のまま、ハードウェアの選択・導入、OSの選択・導入、ミドルウェアの選択・導入などという一連のプラットフォムの手当てのスピード感覚で可能でしょうか。到底無理ですよね。
クラウド・コンピューティングの第一の属性がこのようなプラットフォーム資源を抽象化して、サービスとして提供してくれるわけです。
テスト環境を少なくとも一時間ぐらいで提供してくれる。クラウド・プラットフォームではサーバー、データ・ストア、ネットワーク環境の実資源を仮想化して要求ベースで供給してくれるわけですから、テストやイノベーションのための試行錯誤にはうってつけの(抽象化された)プラットフォームになります。
一方で、クラウド・プラットフォームがあれば全て解決するのかというと、NOだと考えています。事実、現在見えているクラウド・プラットフォームでシビアな基幹系を全てサポート出来るものはありません。
信頼性にしてもセキュリティにしても、つまり多様できめ細かなNFR充足は、クラウド・プラットフォームだけでは出来ない。すべきではない。
eCloud研究会がクラウド・プラットフォームとその上に乗るIaaSやPaaSなどとを峻別することを強く主張しているのはそこをはっきりさせるためです。eVA (enterprise class Virtual Appliance)やVAC (PaaS)のコンセプトの導入はそのような課題を解決するためです。さらに、不毛なA社、B社仕様のプライベート・クラウドの企業システム囲い込み論の危惧を断ち切る目的も持っています。