トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
作者 Boris Lublinsky, 翻訳者 編集部 投稿日 2008年7月31日 午後11時53分
SOAは人気上昇中で、常に技術の改良も進んでいるが、BurtonグループのAnne Thomas ManesによるSOA調査(リンク)では次のことがわかっている。
…20社を徹底的に調査したところ、50%が完全に失敗しており、成功とも完全な失敗とも言えなかったのが30%でした。…多くの企業が複数のプロジェクトで成功を収めましたが、そうしたプロジェクトのほとんどが単一の統合問題を対象としたものでした。それはちょうどWebサービスの寄せ集めのようでした。…アプリケーション1つのためだけにサービスを構築し、そのサービスを再び使うことはないのです
この調査結果はニュース掲載サイトでも取り上げられ、たとえば、Joe McKendrick(リンク)とMichael Meehan(リンク)は共に、Manesの次の主張に同意している -- 失敗の主な原因は実行の仕方が技術的にまずかったからではなく、SOAにおけるビジネスやアーキテクチャのビジョンが欠落していたからで、具体的には以下とおりである。
- 明確なサービスモデルの欠如
- インフラの焦点
- SOAPベースのシステムだけを対象としたガバナンス
- ランタイム・ガバナンスを適所で活用できない開発者の不手際
- イニシアチブはアプリケーション開発グループ主導で、参画するのもこのグループのみ
- 特定性を欠いたロードマップ
- ROIの測定不能
- プロジェクト中心の文化
- 「自分は特別」という考え方
Burtonグループの(リンク)アプリケーションプラットフォーム戦略・データ管理戦略担当副社長のChris Haddadは次のように述べている。
失敗したSOAプロジェクトでは、結果よりも手段に焦点を合わせ過ぎていました。ビジネスの目標に焦点を合わせられないのは問題で、この目標に焦点を合わせることが解決になるのです。SOAの投資対効果検討書を作成する際、「なぜサービスを構築すべきなのか」、「結局のところは何を意味するのか」という最も基本的な質問をし損なってしまうことが時々あります。…SOAを目指すビジネス上の一要因として、経費削減とROIの達成が挙げられますが、SOAにしてみればROIは未だにつかまえどころのない目標であるのに、ことROIに関しては、盲信的になるSOAのプロジェクトリーダーが頻繁に見られます
BurtonグループがSOA成功例で発見した共通の特徴は以下のとおりである。
- ビジネスとITの再編成。通常は新しい最高情報責任者の着任に伴って実施
- Cレベル、つまり理事会による財政援助
- アジャイル/反復による開発方法論の導入
- プロジェクトの連携先となり、プロジェクトの測定規準となるのは、IT要因ではなく、ビジネス目標
- サービス提供者とサービス消費者のニーズのバランスを保つ、明確に定義した資金調達・維持管理モデル
- 高品質のデータへのアクセスと管理を容易にする、簡略化されたアーキテクチャ
- ビジネスとIT間で相互信頼する文化
Burtonのレポートは次のように述べている。
問題は技術ではありません。SOAは現在企業の中に存在するわけですから、SOAで何の具合が悪いかというと、その核心にあるのは人とプロセスなのです
David Linthicumは投稿メッセージで次のように述べ、この結論を支持している。
私たちがITを行う方法の核心を組織的に変更するのがSOAであり、これがSOAの課題であり続けるのです。誰もが変化を概念的には受け入れるようですが、誰かの雇用保障の一部になっているシステムを実際に変えるとなると、瞬く間にやっかいな状況になるのです。さらに、企業内にSOAを推進する責務を負った人たちに、資金はなく、変化を推進するための権限がないこともあります。資金も力もないのに、「納得させ」て「影響を与える」よう、要求されるのです。これでは決してうまくいきません。必要とするスピードで変化を推進するためには、予算をコントロールし、こうした人々をクビにできるようでなければならないのです。
さらにLinthicumは投稿メッセージの中で、SOAの質を向上させる簡単な方法を提案している。
- 投資対効果検討書を明確に定義します。できない場合は、SOAに手を出さないことです。
- SOAに必要な組織的な変更を推進する人々に権限を与えますが、一般には事を成すための資金と職権を与えます。さもなければ、わざわざSOAをする必要もないでしょう。妥当な期間内にうまくいくようにするためには、資金のコントロールと人員を解雇できる権限が必要です。そうしないと、アジリティや再利用向けのアーキテクチャ再構築を議題に入れていない人たちと、永遠に会議する羽目になります。
- 短期的・戦術的ではなく、長期的かつ戦略的に物事を考えましょう。反応的から積極的に流儀を変えたくらいで事態が崩壊するわけありませんから、安心してください。実際、企業はこの方法で市場を勝ち取っているのです。
- 小さなところから始めますが、勢いは失わないようにしましょう。小規模の戦いを複数行うことで、戦争に勝てるのであり、常に前進を続ければ、少しずつアーキテクチャはよくなっていくのです。
こうしてみると、SOAを成功させるための重要要素は以下であることが再確認できる。
原文はこちらです:http://www.infoq.com/news/2008/07/Only1
InfoQ Japanはコンポーネントスクエアが運営しています
セキュアなIT基盤と付帯運用サービス”SecureOnline”
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
この記事では、私達がどのようにして大規模(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
返信