エンタープライズアーキテクチャとは何か

作者 Boris Lublinsky , 翻訳者 吉田 英人 投稿日 2011年4月24日

セクション

エンタープライズ・アーキテクチャ

トピック

エンタープライズアーキテクチャ ,

Architecture ,

Emergent Architecture

共有 |

原文(投稿日：2011/04/19)へのリンク

Jason Bloomberg 氏が最新の記事で，次のように問いかけている。"なぜエンタープライズアーキテクチャは実践されないのだろうか？" 氏はこう書いている。

ソリューションアーキテクトは，ソリューションを実施する前にソリューションを設計します。Java や .NET のアーキテクトは，プログラマよりも先に自身の仕事をします。どちらも作ってから設計するのではありません，設計してから作るのです ... ところがエンタープライズアーキテクチャは，すでに存在している企業 (エンタープライズ) が常に開始点です ... 今日のエンタープライズアーキテクトの役割は，本質的には既存の企業を調査し，修正することです。そう，それだけではない場合もあるでしょうが，ある意味での発展形に過ぎません。今日のこの情けない状況を脱して，いつの日か涅槃の境地へと到達し，事態を改善しようではありませんか。

Bloomberg 氏の意見では，既存の企業を改善することは非常に重要かつ高尚な命題ではあるが，それはエンタープライズアーキテクチャの行うべき仕事ではない。

アーキテクチャとはものごとを改善することではありません。何かを設計する上で最善の実践アプローチを確立することなのです。

だから真のエンタープライズアーキテクトは存在しない，というのが氏の意見だ。企業は成長するものである。

どんな起業家も，この基本的ポイントは理解しています。新しいベンチャのビジネスプラン作成に着手しようという時に，最初からエンタープライズと呼ぶのに十分な規模の組織を計画するような，そんな思い上がった起業家は存在しません。未知な部分が多すぎます。その代わりに彼らは，成長のためのフレームワークを確立するのです。種を植え，水を撒きます。草取りをして，時には肥料も与えます。多少の幸運があれば，数年後，すばらしく健全な成長企業があなたの手に入るでしょう。でもそれは多分，最初の計画とはまったく違ったものでしょうけれど。

さらに氏は，これはエンタープライズアーキテクチャ – 望ましい最終状態に到達するための一連のベストプラクティスの定義と達成，とはまったく違うものだ，としている。問題となるのは次の点だ。

発展するビジネスには ... ある特定の最終状態というものは存在しない，ということです。生物の成長に最終状態が存在しないのと同じです。ドングリは自分が樫の木になるであろうことを知っていますが，樫の木には，自分が将来どのようになるか，という具体的計画はありません。ドングリの DNA が成長に関する基本的なパラメータを与えて，それ以外のことはむしろ起こるに任せているのです。このような現象は複雑系システム – 部分的にではなく，システム全体としての偶発的特性を備えたシステム – に特有のものです。そして生物の成長に偶発性が必要であるのと同様に，組織の成長にも偶発性が必要なのです。

氏は，エンタープライズアーキテクチャに再現性がないことは理にかなったものだ，と認めた上で，それに代わる新たな規律を提案する。

偶発的アーキテクチャのベストプラクティス確立を求める，という考え方自体は，おそらく合理的なものでしょう。結局のところ，従来型のシステムが構築可能なのですから，複雑なシステムが構築できないと考える理由はありません ... 本当にエンタープライズを構築する方法を考え出したいと願うならば，結局はエンタープライズシステムに対して複雑系システムのアプローチを取らざるを得ないでしょう。ただし，実際にその方法でエンタープライズシステムが構築可能であるかは，結果を見ないことには何とも言えません。

氏の記事に対して JP Morgenthal 氏は，エンタープライズシステムの原則に問題があるのではなく，その用語が問題を発生させているのだ，と 指摘している。

... エンタープライズアーキテクチャよりも，多次元アーキテクチャ (multi-dimensional architecture) という名称の方が適切でしょう。アクティビティをより的確に捉えていますし，特定のスコープ – これはミッション達成のために大きくも小さくもなり得ます – に拘束されることもありません。ビジネスは常に多次元アーキテクチャに直面している，と私は思っています。彼らはビジネスプロセスやワークフロー，アプリケーション，ユーザ・エクスペリエンス，ネットワークコネクティビティ，フェールオーバとリカバリなどを備えたソリューションを設計しますが，それら以上に重視するのは，システムのある一面が残り部分全体に与える影響です。私にとってはそれこそが，黎明期の不完全な造語である「エンタープライズアーキテクチャ」という用語の示すものなのです。

エンタープライズアーキテクチャという用語の可否を議論することはできるだろうが，現実に受け入れられているものを今さら変える，というのはよい考えとは言えない。さらに混乱と議論を引き起こすだけだ。IEEE 標準 1471-2000 ソフトウェア利用システムのアーキテクチャ記述に関する推奨案 の定義によれば，

アーキテクチャとは，そのコンポーネント，相互関連性，環境において具現化されたシステムの基本構造であり，その設計と発展を導くための原則である。

定義の中に最終状態に関する言及は見当たらない – システムを改良・発展させる上での原則を示している，という点で，Bloomberg 氏と Morgenthal 氏の定義に非常に近いものだ。さらに，この定義によれば，適切なアーキテクチャ上の原則に従うべく企業を修正し，発展させるものが アーキテクチャ なのである。