BT

アジャイルなビジネスアーキテクトに関する混乱

| 作者: Richard Seroter フォローする 5 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2011年7月28日. 推定読書時間: 8 分 |

原文(投稿日:2011/07/18)へのリンク

組織はなんとかしてビジネスアーキテクトの役割を特定しようとするが、結果、IT部門に配属してしまうという失敗を続けている。Tetradian Consulting社のエンタープライズアーキテクトであるTom Graves氏この問題について指摘し、アーキテクトは現状を受け入れるのではなく、状況を改善しようとするべきだと主張する。

CIO Magazineは“IT業界の6の最も熱い職種”を挙げている。そして、“ビジネスアーキテクト”がトップに挙げられているが、氏はブログでビジネスアーキテクトはITの仕事ではなく企業の構造に従事する職だと説明しこの記事に注意を促している。この問題について考えているのは氏だけではない。このエンタープライズアーキテクトとビジネスアーキテクトを巡る問題はLinkedInのアーキテクチャフォーラムでもa href="http://lnkd.in/mFyB7Q">取り上げられている。例えば、EAをIT部門に配属すべきでない6の理由という議論では、140ものコメントが集まり、EAとビジネスアーキテクトの配属方法について議論が交わされた。

InfoQはこの混乱の影響について、また、この状況をどのように改善するかについて詳しい話を聞いた。

InfoQ: あなたはブログでビジネスアーキテクトとIT関連のアーキテクトをひとまとめにすることの弊害を説明していますね。この弊害はどのような結果を生み出しますか。どこに(悪い)影響が出るのでしょうか。

Graves:真の問題はビジネスアーキテクチャとビジネスアーキテクトがビジネス上のすべての信頼を失うということです。 私は常に'タームハイジャック'のような現象を警戒しています。つまり、あるドメインの‘自然な言葉’がそのドメインのサブセットを説明するための言葉でハイジャックされてしまうことです。ビジネスアーキテクチャの'自然'な意味は 'ビジネスのアーキテクチャ'ということです。つまり、ビジネスモデルやビジネスモデルと組織の能力とリソースの関連が関心事になります。しかし、TOGAFのようなフレームワークは、 'ビジネスアーキテクチャ'を'ITに影響がありそうなITでないもの'が入っている福袋のように扱い、ITのメインストリームとは直接関係無い部分は無視します。つまり、一部の例ですが、人と人とのコミュニケーションや、ブランディング、市場での位置、小売店や倉庫の場所というようなことが無視されてしまいます。

ビジネスアーキテクチャはビジネスのアーキテクチャであり、ITに影響を与えるのは明らかです。しかし、現実にはITはビジネスの比較的小さな部分でしかありません。普通は組織の3%から5%を占めるだけです。 'ビジネスアーキテクチャ'をITとビジネスの他の部分との関連としてのみ考えるとすれば、私たちにはビジネスの他の部分があらゆる物事とどのように関連しているかを説明できません。これは、IT指向のアーキテクチャの信頼性、ひいてはITそのものの信頼性の問題に発展するとても深刻な問題です。

InfoQ: (公式な)エンタープライズアーキテクチャを練り上げようとしている組織にとって、理想的な組織図はどのようなものだと思いますか。様々なアーキテクチャの原則をどのように配置するのが最適でしょうか。

Graves:私はいつもアーキテクチャはひとつのとても単純なアイディアに帰着すると言っています。それは、アーキテクチャが上手く動作するのは、アーキテクチャが協調して動作したときだ、ということです。したがって組織では、それぞれのドメインにそれぞれのアーキテクチャ上の原則を設定し、それが協調して動作するようにしむける必要があります。

まず、スコープ内のアーキテクチャのタイプを専門性のレベルやドメインの観点からはっきりと捉える必要があると思います。これは、組織によって異なるでしょう。しかし最も巨大な組織では、インフラやアプリケーション、データなどのITアーキテクトだけではなく、(ITの領域を越えた活動をする)セキュリティアーキテクト、(BPMとして知られている)プロセス/ワークフローアーキテクト、(物理的な流れを構築する)ファシリティ/ロジスティックアーキテクト、(組織図などを作る)組織アーキテクト、 (ビジネスモデルを作る)ビジネスアーキテクト、(取引、口座、財務の構造など)ファイナンシャルアーキテクトなどたくさんのアーキテクトが必要です。

これらのアーキテクトはそれぞれ違ったスコープ、違った水準で活動します。この分野で'必読'なのはOpen GroupのLen Fehskens氏による'Enterprise Architecture's Quest for Its Identity'です。この記事はそれぞれのアーキテクトの重要な違いについて書いてあります。

  • ソリューションアーキテクト。個々のプロジェクトで活動する。個別のソリューションを組み合わせて問題なく動作することを保証する(Zachmanレイヤの4から5、'物理的'から'詳細')。
  • ドメインアーキテクト。複数のプロジェクトを横断した活動し、そのドメインが問題なく動作することを保証する(Zachmanレイヤの3から4、'論理的'から'物理的')
  • 企業レベルのドメインアーキテクト。ドメイン間を結びつける(いわゆる'T字型'スキルセット、つまりひとつのドメインを深く知りつつ、他のドメインもある程度知っている。ドメインをまたがった会話が可能) (Zachmanの3、'論理的'で必要に応じて'上がった'り'下がったり'できる)。
  • エンタープライズアーキテクト。企業全体の結びつきや一貫性を導く。(Zachmanの1から3、'概念的'で'文脈的'から'論理的'、必要に応じて'深く潜る'ことができる)。

ここでのエンタープライズアーキテクトとビジネスアーキテクトの明確な違いに注意する必要があります。ビジネスアーキテクチャは企業全体の中のひとつのドメインのアーキテクチャであり、'ビジネスのためのビジネス'が中心です。一方でエンタープライズアーキテクチャは各ドメインを横断的に結びつけ、すべてが'中心'であるかのようにバランスを取る必要あります。

また、上述した枠組みは組織のどこにどのタイプのアーキテクトを配置するべきかを示します。ソリューションアーキテクトはプロジェクトチームに配属され、プロジェクトの構築や開発、成果の提供とプロジェクトの解散などを実行し、リーダーやさらに上のマネジメント部門に報告を行います。ドメインアーキテクトは企画やポートフォリオの作成を行いますが、各ドメインを管理するそれぞれの部門に対して報告を行います。

企業レベルのドメインアーキテクトは'親'ドメインに対して報告を行います。普通はすぐ上の幹部レベルです。例えば、エンタープライズITアーキテクトはCIOやCTOへ報告を行います。しかし、同時に他のドメインとも強固かつ明示的に結びつきを持ちます。エンタープライズアーキテクトは企業全体を見なければ成りません。そして、経営層に直接報告する戦略部門のような部門と連携して働くのが理想的です。このような配置を行わないと(例えば金融やITのような部門に配属してしまう)ドメインはゆがみ、配属によって解決する課題よりも多くの問題を生み出してしまいます。

InfoQ: "モデルはアーキテクチャではない"というのは広く知れ渡った原則ですが、戦略や能力、ビジネスプロセスに関するアーキテクチャを理解する最も優れた方法は何でしょうか。

Graves:私の考えでは、人と話すことが最良の方法です。互いに助け合いながら組織や自分が働く領域に対する自分自身の見方を構築するのです。アーキテクトはこのような会話をやってみせて、学ぶことと同じくらい'教える'ことがある、ということを見せなければなりません。一方的にアーキテクトが誰彼かまわず押し付ける'未来の状態'を発信するのではなく、このような形継続的に共有し学習するプロセスを構築する必要があります。

とりわけ巨大な分散組織では人と人が実際に話をするのは難しいです。しかし、これが私たちが常に目指している理想です。そして、このような会話の場でこそモデルやダイアグラムを使い、コミュニケーションギャップを埋める余地があるのです。確かにモデルはアーキテクチャではないということは常に覚えておかなければなりません。モデルを使った会話やそこから生まれた意思決定が真のアーキテクチャなのです。

このような会話に特に役立つダイアグラムを3つ紹介します。

  1. ひとつ目は"なぜそれをやるのか"ダイアグラムです。Alex Osterwalder氏のビジネスモデルカンバスはとても優れた例です。政府の部門がリザルトロジックダイアグラムを利用していたのをみたことがありますが、これも便利です。
  2. 次は'ビックピクチャ'ダイアグラムです。これは広い文脈の中に組織とビジネスを配置します。DoDAFの'オーバービュー'はこれの優れた例です。
  3. 最後に勧めるのは'やること'や'どうやってやるか'に着目したダイアグラムです。これは機能的ビジネスモデルや能力マップ、ハイレベルサービスモデルなど多くの形があり、様々な名前がついています。DoDAFバージョン2の能力オーバービューのそのひとつです。通信アーキテクチャフレームワークのeTOMもそうです。しかし、とても便利なのですが、これらはかなりハイレベルで、最低でも3層目まで行かなければなりません。

ここでは'企業がなにをすべきか'を1ページで簡単に概括しただけです(このa Visioテンプレートを見ればこのタイプのシンプルな3層構造の描き方がわかります)。よりよく一緒に働けるよう、人々がしっかりコミュニケーションするようにしむけるのが大事です。そういう意味ではアーキテクチャとは会話です。モデルは会話が上手く行くようにするための道具なのです。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT