記事:エンタープライズ・アーキテクチャの10の落とし穴

ガートナーの記事からエンタープライズアーキテクチャを構築する上での注意点と、それに対する若干のコメント。

要約



エンタープライズアーキテクチャの10の落とし穴
http://www.gartner.com/it/page.jsp?id=1159617


  1. 適切でないアーキテクトリーダ
    • 技術はあるけれどもリーダーシップがない人がリーダをやっている。
    • 思い入れとコミュニケーション能力があり、尊敬されている戦略指向のある人に変えた方がいい。
  2. ステークホルダの理解とサポートの不足
    • EAチームに入っていない従業員が参加していなかったり、作ったコンテンツが使われなかったり、経営者が価値を疑問視している場合に起こる。
    • 設計する前にまず「セールス」をすること。
  3. ビジネス側の人を巻き込んでいない
    • ITとビジネスの目標が合致していないと、技術を知らない人が技術的な決定をしなければならなくなるし、アーキテクトは保守的になったり視野がせまくなったりする。
    • アーキテクトはビジネスにも深く関わるべき。
  4. 技術的な領域レベルのアーキテクチャしか作っていない
    • この時代遅れのものをいまだに見かける。
    • EAはビジネス・情報・ソリューションといったもっと広い領域を包括するべき。
  5. まず現状にあったアーキテクチャを作ってしまう
    • まずビジネスのコンテキストを構築し、将来のあるべき姿に焦点を当てるべき。
  6. EAグループがほとんどのアーキテクチャ設計を行う
    • ビジネス側からの情報がなければ的外れになってしまう。
    • アーキテクトの仕事はEAを主導することであって、押し付けることではない。
  7. 影響について評価もコミュニケーションもしない
    • EAの価値は組織の全ての人に取って明らかである訳ではない。
    • アーキテクトはEAの価値をスライドを作って示すべき。
  8. 「箱」だけしか設計しない
    • 重要なのはビジネスのアジリティと統合であって、各ビジネスの単位を標準化することではない。
    • 「箱」同士のつながりにむしろ焦点を当てるべき。
  9. 効果的なEAガバナンスを初期のうちに設立しない
    • 中身とガバナンスは平行させるべき。
  10. コミュニケーションに充分な時間を割かない
    • IT/ビジネスの両者にわかる言葉で進めることが大事

コメント

「ソフトウェアを作ることに関する複雑さは、それが扱っているビジネスの複雑さである」という度々繰り返されるテーゼはここでもやはり反復されているようです。「ITとビジネス」という区別を認めた上で、「技術的な観点だけではうまくいきませんよ」という話も、特にEAという仰々しいものに限ったことではないですね。ただし、5.の指摘は重要だと思います。本文の最後にあるBittler氏のコメントを引用します:


The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future.

エンタープライズ・アーキテクトにとって重要なのは、とりあえずの現状にとって完璧な、あるいはもっともエレガントなアーキテクチャを作ることではなく、将来のために最も適応力のあるアーキテクチャを作ることです。

また、8.の「箱」の標準化より「箱」同士のつながりが大事という指摘も看過できません。基本的には分割統治をセオリーとし、システム/サブシステム/機能と分解した上でそれぞれをやっつけるというのが良くあるパターンで、ビジネス/技術を含めた全体の統合を考えるというのは、言うほど簡単ではないような気がします。