競争が激しく、再編が進む業種・業界ではすでにEAの適用プロジェクトが進められ、成果を挙げている。実例とともに、EAの運営体制のポイントについて解説しよう。
筆者が昨年11月に参加したアリゾナのフェニックスで開催されたEAC(Enterprise Architecture Conference)における事例発表を中心に、トレンドをまとめてみます。この会議の参加者は305人、うち3割がアーキテクトで、組織の名称から約2割にEA担当組織があるとされました。
米国以外は日本、韓国、カナダなどの参加者が多く、ヨーロッパやオーストラリアなどからの参加もあり、国際的なユーザー中心の会議でした。参加者の企業は化学、製薬、自動車、航空機、金融、公共機関が多く、ほかには物流、半導体・コンピュータメーカー、テレコム関連からでした。
日本では政府が中心になって推進していることもあり、官公庁の事例が多いと思われるかもしれませんが、競争が激しい製造業や、合併・統合の続く金融、製薬会社ではすでに大型のEAプロジェクトがスタートしており、情報交換をしている姿は真剣かつ具体的でした。
EAに取り組む目的は、おおむね以下の4項目に分けられます。
EAに対する取り組みの範囲とレベルはさまざまで、まさに「Just enough architecture, just in time」というスローガンのとおり、ザックマン・フレームワーク(Zachman framework)に忠実に全項目にわたって取り組んでいる企業から、情報システムに関する部分に焦点を当てている企業、ビジネスプロセスを中心に行っている企業など、目的と企業レベルに応じてアーキテクチャを整備しています(ザックマン・フレームワークについては第2回参照)。
ここでは、次の2つの事例を紹介します。1つはザックマン・フレームワークのほとんどすべてを整備している化学会社です。情報システム部門の役割としてはEAの整備と維持に専念し、開発そのものはアウトソーシングしています。もう1社は、TO-BEのアーキテクチャとしてサービス指向アーキテクチャを目指している半導体メーカーの事例です。
▼EAの目的
アプリケーション/情報の統合、知識獲得、レガシー・マイグレーション、コスト削減、ビジネスの全体把握、データ共有、全社プロジェクト支援などを目的として挙げています。
▼取り組みの概要
3年前にはバラバラなITソリューションの導入で一貫性がなく、例えばSAPの導入でも既存のCRMシステムとの間でグローバルな顧客データの統合が不十分なため、データの不整合が生じていました。そこで情報システムと、ビジネス戦略/活動を密接に連携させるためにザックマン・フレームワーク全項目を作成し、個別案件のRFPに活用、レビューに利用しています。
▼効果
適用対象は、最初の1事業部門から4事業部門に広げ、以下のような成果を挙げました。
また「EA導入により、将来のIT投資の方向性が明確になり、ガイドラインとなったことも大きい」とのことです。
▼体制
CIO直下に5人程度の「EAオフィス」を設け、EAオフィスがビジネスプロセス、データ、アプリケーション/テクノロジ、組織レディネス/コンテンツマネジメントに関する統合化リーダーの役割を担いました。必要な能力は、強力なプロジェクトマネジメント力とプロセス能力です。EAチームの目標は、全体図の作成、標準/ガイドライン、ツール―プロセス―インターフェイス整備、新しいIT導入メカニズムとレガシー・マイグレーション、シックスシグマと連携した経営マネジメントの確立でした。
▼特徴
EAに関する開発/投資/強化の正しい決定ができる能力(EAガバナンス)を持てるように、ポリシー制定、標準EAプロセス制定、EAパフォーマンスモニタ定義、EA能力/関係力/組織内への浸透力に注力しました。
▼EAの目的
サービスベース・アーキテクチャ(SBA)によるアジャイル企業へと変革し、SBAによって費用削減(再利用、必然性のある開発のみ)、生産性向上、ビジネス駆動によるシステムの柔軟性向上などを目的に掲げました。
▼取り組みの概要
2001年1月CIOが取り組みを開始して、EA第1版は同年8月完成、現実の組織に依存しないSBA第1版は2002年1月に完成しました。EAは、全社横断のデータ保護とプライバシー、デジタル・シックスシグマ、顧客サービス・配送、サプライチェーン最適化などのプロジェクトに適用されました。
▼体制
CIO主導の業務、IT、戦略コンサルの混成チームがEAのコアチーム。情報システム部門はアウトソーシングによって4600人から2000人になりました。
▼効果
▼特徴
図1にあるようにTO-BEの目標アーキテクチャとして、サービス指向アーキテクチャを目指していることが最大の特徴です。
従来、個別のIT製品や情報システムは、互いのデータ関連、機能連携、情報定義といった情報に関する情報(メタ情報:情報に関する上位の抽象的な情報)の定義と管理が不十分だったために、全社に関係するプロジェクトを実施するには大きな障害となっていました。そこで全社のビジネス機能と情報を分析して、144ビジネス機能、300の主要エンティティ、26アプリケーション群と600以上のデータ交換にブレークダウンし、150の主要なビジネスシステムとデータストレージにマッピングしました。
このような体系化に基づいて、図1の上から順に業務支援の画面、ワークフロー、ワークフローで用いる再利用可能なビジネスオブジェクトと、そのビジネスオブジェクトと個別の情報システムとをEAI/EII(Enterprise Application Integration/Enterprise Information Integration)で連携してサービス指向アーキテクチャを実現しました。同社では「このようなSBAがなければ、EAはメタ情報のスパゲティになる」と忠告しています。
(1)EAの開発
表1は、EAの開発計画例です。EAの開発においては、米国会計検査院の「EA管理成熟度フレームワーク」などを参考に、自組織の現在のEAに関するマネジメントの成熟度を診断したうえで適正な目標設定をすることが重要です。というのは、競合企業や他社事例を参考にした場合にどうしても無理な目標設定をしがちだからです。
それから、スモールスタートでインクリメンタルな整備(運用を通して完成度を高める)を開始します。その中で、どのEAフレームワークを採用して、どのアーキテクチャモデルにフォーカスしてやるのか、EAの目的や達成イメージと評価基準を定めていきます。全社に対して「プロジェクト憲章」とでもいうような理念を明示するのもよいでしょう。完成度より、タイムリーな成果物の配布に注力して効果を早く出して継続することが重要です。
|
|||||||||||||||||||
表1 EA開発計画例 |
* 出所:オージス総研
|
(2)EAの運用
EAの運用とは、EAを使って情報化資源の調達を行っていくということです。運用をしながら、一方でEAそのものを改善していくことになります。
表2は、日本政府のEAを利用した情報システムの調達プロセスです。リファレンスとしてEAの各アーキテクチャを参照することが通常の調達と異なるところで、そのほかはITコーディネータのプロセスフローに似ています。
|
|||||||||||||||||||||||||||||||
表2 EA による調達プロセス例 |
* 出所:EA策定ガイドライン
|
(3)EA整備体制
個別の情報システム開発チームに対してEAチームは全体を見る立場にあります。例えば図2のように、CIOから直接任命される形でEAを整備し、原則やガイドラインを個別案件プロジェクトに提供してRFPに反映してもらいます。その後にシステム開発企画が具体化された時点で、EAとの適合度をレビューすることになります。
アーキテクチャ・レビュー・ボードは、EAそのもののレビューとともに、個別案件がEAに適合しているか審査します。設計・開発部門をアウトソーシングしている場合は、このレビュー・ボードが重要になります。実際の情報システム開発で、開発技術や製品知識を体得している場合は問題ありませんが、これらを外部にアウトソーシングしている場合には外部出向や研修、あるいは特別の案件を内部制作するなど戦略的に開発技術ノウハウを残す施策がなければ、技術に対する目利き力がなくなり、管理不能に陥る恐れがあります。
第2回の表1で、UMLがカバーしている範囲を黄色で示しました。これを見ると、企業全体の中で情報システムに関係の深いデータ、機能、ネットワークの部分になっています。また、OMG(Object Management Group)が推進しているMDA(Model Driven Architecture:モデル駆動開発)のCIM(Computation-Independent Model)、PIM(Platform-Independent Model)、PSM(Platform-Specific Model)は、ザックマン・フレームワークにおけるビジネスモデル、システムモデル、技術モデルに対応しています。
OMGが、モデルからコードの自動生成を狙ってUML2.0を制定しているのも、上流から下流への連携強化が目的です。UMLはJavaやC++といった言語との連携が保証されているので、UMLと上流のビジネスモデルが連携すればメリットは大きいといえます。例えば機能の軸におけるビジネスプロセスをUMLのアクティビティ図で定義し、BPEL(Business Process Execution Language)に連携し、ワークフローを自動生成させてWebサービスを作成する製品や実例が出てきています。
経営戦略を定めるフェイズではさまざまな問題解決の手法やツールがあり、これを限定することにはあまり意味はありません。ただし、戦略をブレークダウンして組織内部にある経営資源を割り当て、「誰が」「何を」「どのように」実施するかといった構造を定義するビジネスモデリングや、情報システムを設計するシステム・モデリングの段階ではUMLがその威力を発揮するので、EAにおいても主要な役割を担うと思われます。
EAは定義するのが難しい用語です。というのは、事例でも述べたように各社各様の取り組みがなされているからです。しかし、実はこの「各社各様であること」が、EAの本質なのかもしれなません。
自社にとって理想の情報システムを作り上げるための処方せんであるEAは、ほかから与えられるものでなく、自社で開発して改善し続けるべき性格のものです。ただ16年も前に提案されたザックマン・フレームワークはEAの元祖としていまも君臨しており、EACの基調講演でも大人気であったことは驚きでした。各社各様の取り組みのベースには、やはりザックマン・フレームワークが存在しており、この中から取捨選択している組織が多いようです。筆者が6年前にドイツ製のリポジトリを販売していたころ、メタデータ・スキーマとしてザックマン・フレームワークを日本で紹介したことがありますが、隔世の感があります。次回からはEAの中核部分を担うUMLビジネスモデリングについて解説していきます。
▼EAの開発にあたっては、現在のEAに関するマネジメントの成熟度を診断したうえで適正な目標設定をすること
▼最初はスモールスタートで、改善を継続しながら範囲を広げていく
▼個別の情報システム開発チームを監理する立場としてEAチームを置き、開発プロジェクト全般を通じてレビューを行う
参考文献
ITアソシエイト協議会中間報告
ITアソシエイト協議会報告〜「EA策定ガイドラインVer.1.1」
EAC Conference Proceedings November 4-6,2003
Copyright © ITmedia, Inc. All Rights Reserved.