InfoQ

News

エンタープライズアーキテクチャの状況

作者 Steven Robbins , 翻訳者 編集部 投稿日 2008年5月27日 午後12時47分

コミュニティ
Architecture
トピック
Funding,
エンタープライズアーキテクチャ,
リーダーシップ
タグ
Best Practices,
ビジネス/ITアライメント,
Culture Change,
Organizational Patterns

組織のITへの投資が(買い取りや借用、構築などにより)増加し続け、ビジネスプロセス管理(BPM)やサービス指向アーキテクチャ(SOA)などのコンセプトがいっそう普及するにつれ、エンタープライズアーキテクチャ(EA)という任務はいっそうありふれたものになった。David Linthicum(source)、Mike Kavis(source)、Alan Inglis(source)の三氏は最近、業界内のEAに関する見解をそれぞれ語った。

Linthicum氏の問いはこうである—我々はEAに投資し続けるべきか(source)。氏が指摘するところによると、グローバル2000企業に見られるエンタープライズアーキテクチャへの典型的なアプローチは以下のとおりである。

ほとんどのグローバル2000企業には、アーキテクトが1人とスタッフが2〜3人いますが、予算的にも命令的にも何ら権限を持たないため、さっぱり成果を上げません。成功へ続く道を自分で「支配する」こともできず、アーキテクチャの中核をなす原則にも従わない者は厳しく統制する必要があります…これがガバナンスというものです。ITやビジネスに何の価値も加えず、目に見える結果を出さなくてもよい人々の集まりが高給取りになっているのです。


Linthicum氏は、この特定の問題に関してアーキテクト自身を非難しているわけではないと指摘している。その代わりに、真の戦略(すなわち、エンタープライズアーキテクチャ)に専心するとは口先だけで、ITの戦術的なプロジェクトに的を絞り続ける組織こそが、EAの現状をもたらしていると述べた。こういった環境ではあるが、エンタープライズアーキテクトが生み出すものに関しては、アーキテクト自身に責任があると考えている(source)。Linthicum氏が言うには、この役割におけるアーキテクトの主な問題は2つあり、それは、組織が現在抱えている問題を測定、つまり数量化できないことと、アーキテクトの多くが変化を恐れていることである。エンタープライズ・アーキテクトに必要な測定には、インフラにおける費用非効率、数量化可能な技術再利用の値、組織の機敏性の値が挙げられる。
 

Linthicum氏は次のように自らの疑問に答えている。「エンタープライズアーキテクチャの取り組みに効果がないなら、その取り組みに投資し続けるなと言いますね。つまり、エンタープライズアーキテクチャに真剣になり、ビジネスへの価値を慎重に測定することを厭わなくなるまでは、投資をやめなさい、ということです」。

Mike Kavis氏は、エンタープライズアーキテクチャの価値に関して、自身の組織の経営者向けに行ったプレゼンから、情報をシェアしてくれた(source)。プレゼンの重要点は、EAの定義、主任アーキテクトの役割、EAおよびEAグループを有することの価値、であった。氏はEAチームが焦点を当てるべき事柄について、スライドを使って説明した。
  1. ビジョンを考案すること
  2. 方向性を示し、監督すること
  3.  ビジネスプロセス/サービス、エンタープライズ・メタデータ、インフラ、セキュリティの重要分野を見極めること
  4. 財政責任を負うこと
  5. 研究開発を行って先端技術を利用すること
Kavis氏はプレゼンでEA内部のグッド・プラクティスを指摘している。最近では、企業のイニシアチブが失敗する10の理由を説明することにより(source)、EAのマイナス面についても話をしている。氏が挙げた10の理由のうち、技術に関連するものは「技術的知識の欠如」の1つだけである。残りは組織および人間の問題に集中している。そのうちの最も大きな問題の1つに、「変化を過小評価すること、あるいは変化による影響を無視すること」がある。
人々は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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Agile Japan 2009

2009年4月22日、東京千代田区にある放送会館で「アジャイルジャパン2009」が開催されました。本イベントは「ソフトウェア開発の次世代リーダーをつくる」ことを合い言葉に、200人以上の参加者を集めてスタートしました。

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumboというコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。