月刊ビジネスコミュニケーションによるエキスパートブログ
HOME | ABOUT |
atom rss2.0

« previous next »

機能追加型開発(その2)

2007.03.17|プロジェクトマネージメント このエントリーをはてなブックマークに追加Yahoo!ブックマークに登録この記事をクリップ!BuzzurlにブックマークBuzzurlにブックマーク

できるだけ母体に影響を与えず機能追加したい。デグレード試験を最小化したい。その潮流がSOA(Service Oriented Architecture)やマッシュアップ(Mash Up)につながっている。

既存システム同士を接続する。接続を変更する。一部を更改する。このようなパターンについては、極力プログラム改造を避け、SOAで対応する。さらに、複数の既存システム機能を組み合わせて新しいユーザインタフェースを作るのがマッシュアップだ。元々は音楽用語で、ジャンルを越えたコラボレーションとか、クロスオーバーを指す。強固に完成してしまっているミドルウェアと、それをベースにした既存システムに手を入れるのは危険で、大変なので、外側に新たに機能追加するパターンである。ITシステム間を直接つなぐより、ユーザが複数のシステムにアクセスして、協調利用する方が容易である。ただし、それぞれシステム固有のユーザインタフェースが異なっているので、Web化し、マッシュアップしてしまう。あたかも新しい1つのWebに見えるが、実際に裏側では複数の既存システムをアクセスしている。

マッシュアップの事例が電話時代にもあった。プッシュホンである。「ピポパ」という音によってダイヤル信号を伝えることで、ユーザインタフェースはプッシュホン電話機の1つだが、信号を受信するシステムは複数あって構わない。たとえば、電話予約する場合、予約センタに電話する最初のダイヤリングは交換機が受信する。センタにつながると、「日付を入力ください」などと応答が来る。この「ピポパ」はセンタが受信する。途中の交換機は全く関知しない。新サービスを交換機に追加するのではなく、センタに追加することで、交換機のデグレード試験は全く必要のない方式である。

プッシュホンでは「ピポパ」という音声信号を標準化することによってマッシュアップが可能となったが、Web時代はもっと複雑だ。マッシュアップしやすいインタフェースを提供できたミドルやDBが生き残ることになる。

トラックバック

このエントリーのトラックバックURL:
http://www.bcm.co.jp/mt/mt-tb.cgi/495

コメントを投稿

(投稿頂いたコメントは内容を確認させて頂くので、公開まで時間がかかります。また、適切でないと思われるコメントは公開されない場合があるので、予めご了承下さい。)

Latest