トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
作者 Mark Little, 翻訳者 編集部 投稿日 2007年11月5日 午前6時56分
最近Joe MacKendrick氏(source)は”大企業の”SOAが終わりに近づいているかどうかという興味深い記事(source)を出している。Joeが提示しているように、SOAに対するより現実的なやり方が前に進む方法であるという見解もある(source)。SOAがブロガー、アナリスト、カンファレンス、メディアそれぞれにおいて、その問題がエンタープライズレベルで表面化していなかったためSOAがどのように成功していないかというディスカッションがくり広げられてきた。代わりにSOAは部門、単一のビジネスユニットセットにおいて主に見受けられてきた。ZapthinkはSOAと彼らの呼ぶPrgramatic SOAへのアプローチに関して長年にわたって論議してきた。以前の記事で報告したように、
SOAでの成功はほとんど包括的な変更を必要としない。代わりに慎重にSOAバトルを選択するアーキテクトは、制限されたスコープのプロジェクトを通してSOAの約束をビジネスに提供することができるのである。この要点を見逃すアーキテクトは、SOAの成功のハードルを自ら高く設定しすぎてしまうのだ。同じような論議がほとんど全ての新たなテクノロジーにも当てはめられる。いくつかの例外はあるが、採用への進化的なアプローチが革新的なアプローチよりも成功率が高いのにはたくさんの理由がある。その組織が大きいほど、そしてあり得るデプロイメントの機会のスケールが大きいほど、必要な時間内で必要な変更に対する同意を得られるチャンスが少ないのである。JoeはZapthinkが下記のように言っているところ、"ゲリラ SOA"のエコーをどのように聞くかということに関して論議を続けている。
...特定のビジネス問題を提示するための目標の定められた軽量の取り組み VS たくさんのベンダー達に援助された大規模なSOAアプローチだしかしながらJeff Schneider氏はJoe氏に同意していない(source)。
「Joe」は真実と呼ぶのにはほど遠い、SOAが衰えていくということを暗に意味しています。私はそういう悪い情報は、SOAを知らない、または使わない人々から来ると信じています。そしていくつかのケースではSOAが処理してくれる混乱を逆に引き起こすのです。また彼は"Guerilla SOA"に関してJoeと他の人たちに反対している。
”ゲリラSOA”を叫びながら走り回る愚か者たちを黙らせなければいけません。こういう人たちはまず初めにサイロ指向の考え方に責任がある人たちなのです。私たちがコーディングとリリースを始めるのに十分な条件を捕らえたところで、小さなAgileプロジェクトを提案するのです。それでどうなると思いますか?このスタイルの開発は共有サービスの概念と相反しているのです。それはもはやソリューションではなくて問題になってしまうのです。更にMikoが提示しているように(source)エンタープライズSOAは大変なものなので(エンタープライズJava、エンタープライズCORBA、エンタープライズ XYZと同様に)、だからこの時点で成功例に限界があるのは不思議ではないのである。でも少し時間を与えて様子を見てみたい。
だからエンタープライズ(銀河系間の)の偶然性に注目することは、私たちにとって有益なことであるかもしれないのです。今の時点で”惑星間の”SOAを始めるのには十分なのです。Development MartiansをService Lifecycle GovernanceについてIT Operations Venusiansに話しをさせましょう。Joeは両者に正しい点があることには同意しているが、彼はSOAの圏内で事は全て良好ではないという意見を支持している。
要はプロセスをリフォーム、再形成するためにSOAを一番必要としている組織は、SOAを一番採用しない組織であるということである。このような組織のほとんどにとってサービス指向はムラがあり不均一、無益でエンタープライズのサポートが全然無いか、もしくはサポートが全くないものになってしまうだろう。一度に成功するプロセスを構築しながら、それを独力で行わなければならなSOA支持者達はたくさんいるのである。ゲリラ戦略は前へ進むためのただ一つの道なのかもしれない。しかしそれに対する同意がまったく無いわけでもない。”ゲリラSOA”かそれとも実際的なSOAであっても、どちらにしろJoeは、彼が携わってきた成功するエンタープライズSOAデプロイメントは、デプロイメントスペースのパーティショニングを伴っているが全体的な図は未だ実現されていないと言及している。
全てを全体的なエンタープライズのためには行わないのです。というのもそれは”エンタープライズSOA"の意味するところではないのです。代わりに彼らは彼らのエンタープライズをコミュニティに分けて、たいていの場合平行に攻撃するのです。Joeの返答に対して、
多分私たちはSOAとなると小さく考えすぎなのだと思います。多分私たちは大きく考え始めなければならないのです。人生において何でも拘束されて制限された考え方は中途半端に終わりかねません。大きく夢見ることは新しい可能性、アイディア、イノベーションへの世界へと導きます。長い目で見て、SOAは単なる標準化されたインターフェースかもしくは能率化されたプロセス以上のものなのです。SOAは、企業家達の連合と経済圏の中にいる誰にとっても、新たな可能性を開く仲介されたサービスに組織を整理しなおす可能性を持ち合わせているのです。原文はこちらです:http://www.infoq.com/news/2007/11/soa-long
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
12/16 ~野村総合研究所が提案~ 「不況を乗り切る!効果的なIT投資を考えるセミナー」
12/5 CSQ会員限定技術情報交換会にてJCP議長が標準化について語る
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。
筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。
エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。
この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。
No comments
返信