3. コンポーネントの抽出
開発者は、レガシーシステムからどのコンポーネントを抽出すべきかを判断しなければならない。サービスコンポーネントの抽出を容易に行えるかどうかは、次の5つの要因で決まる。
- ソースコードが最初から、どれだけきちんと書いてあったか。
- ソースコードに対して、バグ修正のためのパッチ適用や再適用がどれだけ頻繁に行われてきたか。
- レガシーシステムの文書が定期的に更新されてきたかどうか。
- その開発者の技術的スキル（例えば、レガシーシステムの元の開発者はもはや社内にいない可能性がある）。
- サービスコンポーネントの依存関係の複雑さ。
4. 抽出したコンポーネントの採用または不採用の決定
開発者は、依存関係の問題を解決してしまえば、それらを採用または不採用にすることができる。依存関係を採用することは、サービスコンポーネントを現状通りで採用することと、必ずしも同じではない。開発者は、新たなビジネス要件を満たせるように、サービスコンポーネントを再構築する必要があるかもしれない。依存関係を組み合わせた結果、重複、あるいは類似するサービス機能を取り除くことで、サービスコンポーネントの数を減らすことになる可能性がある。開発者は、採用したサービスコンポーネント全てを、SaaSアプリを作成した時に使用するリポジトリに格納する。
SaaSアプリの作成とインストール
PaaS上でSaaSアプリを作成する場合、開発者は以下について判断しなければならない。
- ユーザー、開発者、システム管理者、ビジネスアナリストらが、SaaSアプリに何を期待しているのかを判断した上で、SaaSアプリを稼動させるクラウドサービスの種類を、プライベートクラウド、パブリッククラウド、ハイブリッドクラウドの中から選ぶ。
- 採用したサービスコンポーネントのどれを使用してアプリを作成するのか、ユーザーや開発者、システム開発者、ビジネスアナリストらの期待に基づいて決定する。
- そのサービスコンポーネントをまとめて、ゆるく統合されたSaaSアプリ（ユーザーの反応を待ちつつ、他の部分は動作できるアプリ）にするために、最も費用効果が高い方法を判断し、そのアプリの結果が期待に沿うものかどうかテストする。
開発者はアプリのインストール後に、そのSaaSアプリのパフォーマンスだけでなく、ビジネス要件の変化も注意深く見守るべきである。アプリのサービスコンポーネントのアップデートや再構築が必要になる可能性があるためだ。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
