エンタープライズ・マッシュアップ

「マッシュアップ」というキーワード、ボクはこのキーワードが大好き。
でも、無理はしないでほしい。

マッシュアップが「システムの断絶」を解消する

エンタープライズ・マッシュアップ。なんだそりゃ。
言葉としては随分と以前から存在していることは、ググると明らか。
しっかし、SOAやらSaaSやらと、何が違うんだろう。結局、言いたいこと、やりたいことは方向性として全部同じなんだろうけど。
それが内部サービスの組み合わせなのか、外部のサービスも含めた組み合わせなのか、というとことが違うだけで。

で、ボクが「無理はしないでほしい」というのは、「エンタープライズ」という言葉がつくとセキュリティやシステムトラブルの際、必ず「責任分解点はどこか？」という問題が出てくるから。
AというサービスとBというサービスをCというエンタープライズマッシュアップのフレームワーク（？）で構築してそれを利用している際、セキュリティ上の問題やトラブルが発生した際に「何が悪いのか」を簡単には特定しにくくなる。
Aが悪いのか、Bが悪いのか、Cが悪いのか、AとCの組み合わせが悪いのか、BとCの・・・
最初にきちんと想定されるリスクとその責任分解点を把握し、それをサービス提供者、利用者などのステークホルダーが互いにグリップできていなければ、こんな話になるのが目に見えている。

ボク個人の感覚としては、マッシュアップはもっと気軽に扱われるべきで、「エンタープライズ」なんて言葉はつけなくていいと思っている。
「あれとあれ、組み合わせたらちょっと便利そう」ぐらいの語感を保った言葉であり続けてほしい。
＃ここで、サラっと「こんな感じ」ってサンプルをJavaWebStartとかで見せれると、このエントリーにも説得力が出るんだけどなぁ…(:_;)
作りたいと思いつつ、企画がFixせず放置しっぱなし。


さてこのマッシュアップ、技術的な観点から見ると「サーバ側で組み合わせてクライアントへ提供する」というのが常識のようだけど、クライアント上で組み合わせてもいいと思う。
というか、利用しているサービスがクライアントで動いていようがサーバで動いていようが、それがどこで組み合わさっていようが関係ない（気にしない）環境が良い。
そしてこれをやろうと思うと、前述のように「エンタープライズ」という冠は重過ぎる。

最初に紹介した記事で、「電子メールを中心に」というのは大いに納得した内容だが、そこからさらにユーザが繋ぎたい基幹システムを選んで利用できるかというと、そこはまだクリアすべき課題が山積み。
いずれ技術的に、あるいはビジネスの仕組み的に解決されるときは来るだろうけど。