前回は，アーキテクチャのスコープについて述べ，全社的なアーキテクチャ，つまり，都市計画型のアーキテクチャが重要であること，そして，アーキテクチャのスコープを誤ることで問題が発生することが多いと述べた。今回は，この問題をもう少し具体的に見ていくことにしよう。

◆軽視されがちな設計の多様性

　「企業内の情報システムには大きな多様性が存在する」と言うと，メインフレーム，Unixサーバ，PCサーバなどのさまざまなハードウエアとOS，さまざまなDBMSやミドルウエアなどが存在することをまず考えるだろう。確かに，このようなテクノロジの多様性はコストの面で問題であり，解決すべき課題である。その解決策の1つが，テクノロジ・アーキテクチャの設定，要するにプラットフォームの標準化を行うことである。

　しかし，プラットフォームの標準化を完全に実現できたとしても，多様性の問題が完全に解決されるわけではない。企業内のアプリケーション設計，つまり，データ設計やコンポーネント設計が完全に一致していることはないからである。

　例えば，工場系のシステムと，本社系のシステムとで製品コードが異なることがある。さらに，製品属性などのデータになれば，アプリケーション間で共通化ができていないことの方が普通だろう。

　企業にとって真に重要な課題はテクノロジの多様性ではなく，アプリケーション設計の多様性なのである。テクノロジの標準化だけを行い，エンタープライズ・アーキテクチャを作成したと言ってしまうケースもあるが，それだけでは真の問題解決にはほど遠い。

◆アプリケーションの多様性の発生原因

　アプリケーション設計の多様性が生じるにはいくつかの理由がある。

　当然ながら，アプリケーション開発グループが適切にコミュニケーションしないことで設計の不一致が発生する場合がある。このような不一致はできるだけ解消すべきだ。しかし，どうしても回避することができない設計の不一致もある。

　まず，第1にレガシー・システムである。レガシー＝メインフレームと思われがちだが，正確には長期的に使用されているシステムのことを指す。legacy＝遺産であることから，前世代の開発者から引き継いだシステムと考えればよいだろう。その意味では，過去に開発したクライアント／サーバ・システムもレガシーになり得る。

　いずれにせよ，レガシー・システムの設計変更は困難であるし，廃棄して新しい設計に基づいたシステムを1から作り直すことはさらに困難であり，新規開発システムとの設計の不一致は必ず生じてしまう。

　第2にアプリケーション・パッケージの存在である。当然ながら，アプリケーション・パッケージの設計はユーザー独自開発アプリケーションの設計とは異なるし，ユーザーがパッケージの設計をコントロールすることもできない。さらには，アプリケーション・パッケージのデータ設計が公開されていない場合すらある。

　さらに，企業の吸収合併というケースもある。この場合にも，両社のアプリケーションの設計が一致していることはあり得ない。

　これらの設計の不一致は，要するに，アプリケーションの設計の主体が異なるため必然的に生じてしまうものである。トップダウンで共通の設計を行い，それに基づいて全アプリケーションを構築するというのは，教科書の中だけで通用する考え方である。

　全社的アーキテクチャが都市計画のようなものであるという例えは，ここでも生きてくる。都市をすべて1回更地にして，理想の都市計画に基づきすべて再開発できれば苦労はないのだが，そうはできないのと同じように，全社的アーキテクチャにおいても，過去の資産やさまざまなしがらみを考慮して，現実的な妥協案を求めなければならないのである。

◆ツールだけでは解決できない

　アプリケーション設計の多様性はツールの使用だけで解決することはできない。例えば，さまざまなDBMSのデータを自由にアクセスできるデータベース・ゲートウエイと呼ばれるタイプのツールがある。製品カタログだけを見るとこのようなツールを使えば，企業内のデータ統合の問題を容易に解決できるかのように見える。もちろん，このようなツールは便利な場合もあるのだが，決して万能というわけではない。

　例えば，DB2上にある売上げデータとOracle上にある売上げデータをアクセスし集計できたとしても，片方が月末締めの売上げであり，もう片方が20日締めの売上げであったならば，業務的な意味があるとは言えない。言うまでもないことだが，これらのツールはテクノロジの多様性は吸収してくれるが，アプリケーション設計の多様性は吸収してくれないのである。アプリケーション設計の多様性は，業務プロセスを理解した者がビジネス・ロジックを開発しなければ吸収できない。

◆全社的アーキテクチャは無意味なのか？

　上記のように企業内のアプリケーション設計の多様性が不可避である以上，全社的アーキテクチャで定めた設計標準をトップダウンですべてのアプリケーションに適用することはほぼ不可能と言えるだろう。かと言って，アーキテクチャを適用してもしなくてもよいという任意の扱いにしておけば，誰もアーキテクチャに従うものはいなくなる。どちらの場合でもエンタープライズ・アーキテクチャは有名無実化し，棚のこやしとなることになる。

　アーキテクチャ・プロジェクトにおける落とし穴の1つが，都市計画的なアーキテクチャに対して，設計図面的な厳密なアーキテクチャを適用しようと無駄な努力をしてしまうことである。これは，あたかも，都市内のすべての建物の設計を標準化しようとして努力するようなものである。

　ではどうすれば良いのかというと，企業のビジネス・プロセスの真の根幹を支えるシステムであり，きわめて高い品質が要求されるアプリケーションでは，全社的アーキテクチャを厳格に適用し，それ以外のアプリケーションではガイドラインの位置付けに留めておくことが現実的な最適解だろう。

　例えば，銀行で言えば，顧客の口座を直接扱ういわゆる勘定系システムにはアーキテクチャを厳密に適用し，それ以外の領域では柔軟性を重視して，アーキテクチャはガイドライン的存在に留めるというような対応が考えられるだろう。非常におおまかな目安だが，全社アプリケーションの30％程度には厳密なアーキテクチャを適用すべきと，ガートナーは推定している。

　EA（エンタープライズ・アーキテクチャ）というと，1つのアーキテクチャを全社的に強制的に適用しなければならないというイメージがあるが，それは現実的ではないだろう。エンタープライズ・アーキテクチャは，エンタープライズ・システム（全社的基幹系システム）に適用するアーキテクチャと考えた方が，得られるものはおそらく大きいはずだ。