GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Steven Robbins , 翻訳者 編集部 投稿日 2008年5月27日
組織のITへの投資が(買い取りや借用、構築などにより)増加し続け、ビジネスプロセス管理(BPM)やサービス指向アーキテクチャ(SOA)などのコンセプトがいっそう普及するにつれ、エンタープライズアーキテクチャ(EA)という任務はいっそうありふれたものになった。David Linthicum(source)、Mike Kavis(source)、Alan Inglis(source)の三氏は最近、業界内のEAに関する見解をそれぞれ語った。
Linthicum氏の問いはこうである—我々はEAに投資し続けるべきか(source)。氏が指摘するところによると、グローバル2000企業に見られるエンタープライズアーキテクチャへの典型的なアプローチは以下のとおりである。
Linthicum氏は、この特定の問題に関してアーキテクト自身を非難しているわけではないと指摘している。その代わりに、真の戦略(すなわち、エンタープライズアーキテクチャ)に専心するとは口先だけで、ITの戦術的なプロジェクトに的を絞り続ける組織こそが、EAの現状をもたらしていると述べた。こういった環境ではあるが、エンタープライズアーキテクトが生み出すものに関しては、アーキテクト自身に責任があると考えている(source)。Linthicum氏が言うには、この役割におけるアーキテクトの主な問題は2つあり、それは、組織が現在抱えている問題を測定、つまり数量化できないことと、アーキテクトの多くが変化を恐れていることである。エンタープライズ・アーキテクトに必要な測定には、インフラにおける費用非効率、数量化可能な技術再利用の値、組織の機敏性の値が挙げられる。ほとんどのグローバル2000企業には、アーキテクトが1人とスタッフが2〜3人いますが、予算的にも命令的にも何ら権限を持たないため、さっぱり成果を上げません。成功へ続く道を自分で「支配する」こともできず、アーキテクチャの中核をなす原則にも従わない者は厳しく統制する必要があります…これがガバナンスというものです。ITやビジネスに何の価値も加えず、目に見える結果を出さなくてもよい人々の集まりが高給取りになっているのです。
人々はWIIFM(what's in it for me=自分にとってのメリット)を知る必要があります。変化に対して抵抗があれば、どんなプロジェクトもダメになる可能性があります。あなたのイニシアチブには、多大な影響力を持つ擁護者がいなくてはなりません。指導部や主要技術者、プロジェクトマネージャー、プロジェクトで皆の目につく人々の全員が、プラスの力となり、ビジョンと未来の姿を常に推進しなければなりません。…人間は、イニシアチブをリードしている人たちの態度に視線を注ぐのです。抵抗には正面から立ち向かい、危機を脱するには人々の助けが必要と呼びかけなければなりません。呼びかけを受けつけず、障害となる人々は、追い出してください!
Mike Walker氏はKavis氏のリストについて意見を述べ、リストにもう1項目追加してLinthicum氏の議論「プロセスにおける権威」を繰り返した。すなわち、権威をもって原則を実施するガバナンスが、企業には必要ということである。権威が伴わなければ、ガバナンスは組織がしなければならないことではなく、した方が良いことのリストに成り下がるのである。
Alan Inglis氏はヨーロッパにおけるEAの状況を米国と比較して(source)意見を述べた。ITに価値を加えずに「高給を取る」というLinthicum氏の考えに共鳴し、米国で最近EAの取り組みに対する資金提供が急増していることが、EAの取り組みの妨げになっているのかもしれないと仮説を立てた。
何百万ドルももらい、実現まで何年もかけてよいのなら、実践的になる圧力は存在しないのではないでしょうか。つまり、エンタープライズアーキテクチャへの主なアプローチが、大規模アーキテクチャを前面に押し出したアプローチであることを意味します。アーキテクチャに対する受け入れ度合いが低く、資金も少ないような場合は、目標達成のために代わりの方法を展開する必要がありました(source)。手持ちの資金で(source)さらに推し進めるには、創造的なアプローチの展開が必要だったのです。
Inglis氏は、ヨーロッパのEAの取り組みは、資金が原因で戦術的に実行する必要があるため、戦略的に成功していると指摘しているように思われた。「豊富にあることが災い(source)」となってIT全体に影響を与えるように思われる。
原文はこちらです:http://www.infoq.com/news/2008/05/state-of-ea
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信