|
[2012 年 8 月号] |
［技術講座］
サービス指向アーキテクチャ(Service-Oriented Architecture:SOA)とマスターデータ管理(Master Data Management)は，企業情報システムの全体最適を考えたときに，登場するキーワードです．どちらの考え方も企業情報システムの全体最適化を目指していますが，両者にどのような共通性，関連性があるのか明確な定義はありません．
一見，独立したテーマに見える，"SOA"と"MDM"には深い関連があり，両者の考え方を組み合わせることで，企業情報システムの全体最適化へのアプローチがより効果的なものになります．本稿では"SOAとMDMの組み合わせによる全体最適化へのアプローチ"について説明します．
本稿が対象とする読者は次のような人になります．
この章ではSOAの目的や中心的な概念である「サービス」，そして実現のためのプロセスについて簡単に説明します．
SOAは「業務に対応したソフトウェアコンポーネントをサービスと呼び，それらを組み合わせてシステムを構築するアーキテクチャ」(*1)です．SOAはオブジェクト指向やコンポーネント指向と同じ「ソフトウェアの部品化」の考え方の1つです．SOAの目的は様々ありますが，ソフトウェアの部品を「サービス」という単位で共通利用することが根本にあります．オブジェクト指向やコンポーネント指向と異なる点は，「ビジネス環境の変化に情報システムが対応できていない」といったビジネス面のニーズに応える手段になりうる概念であるというところです．
サービスは他のソフトウェアから利用できるように，汎用的なインターフェースを備えていなければなりません．このとき，Webサービスの技術を利用することが一般的です．サービスの数が多くなってくると，比例して連携が多くなり，サービス連携のスパゲッティ化が起こる可能性があります．そこで，連携が疎結合になるように ESB(Enterprise Service Bus) を利用したアーキテクチャにします．SOA を実現したときの模式図は次のようになります．
図1.SOA実現の例
サービスは「業務に対応したソフトウェアコンポーネント」と定義されます．例えば「顧客情報を登録する」業務があったとします．この「顧客情報を登録する」業務に対応するソフトウェアコンポーネントが「顧客情報登録サービス」になります．
サービスは役割や粒度によって分類され，階層構造になります．サービスの階層構造を用いることによって，ソフトウェアの実装技術を隠蔽し，変化しにくい再利用性の高いサービスを構築することができます．
図2.サービスの階層構造
プロセスサービスでは他のサービスの呼び出し順序を制御したり，複数のサービスを組み合わせて1つの機能を実現します．ビジネスプロセスに直接関係したサービスであるため，業務の変化に合わせて変更される可能性が高いサービスです．BPM(Business Process Management)エンジンなどを利用して実装されます． 例えば，受注プロセスに対応した受注プロセスサービスなどがこの層のサービスになります．
ビジネスサービスはプロセスサービスとは異なりプロセスではなく業務のアクティビティそのものを実現するための機能を提供します．ビジネスサービスは業務で利用するデータに関係の深いサービスです．このサービスはプロセスサービスに比べて再利用性が高くなります． 例えば，受注プロセスのアクティビティである「受注登録」を実現するための「受注登録サービス」が，ビジネスサービスにあたります．
基本サービスは，単体では業務のアクティビティを実現しません．より上位のサービスから共通利用される機能を提供します．この点がビジネスサービスと異なる点です．一般的にビジネスサービスより再利用性が高くなります． 認証を行う「認証サービス」などが基本サービスの一例になります．
SOA実現のためのプロセスは次の図に表されるように開発，運用，ガバナンスのそれぞれのアクティビティから構成されます．SOAの開発では「サービス」と「SOA基盤アーキテクチャ」の構築が重要になります．ユーザインターフェースやデータベースの構築は，図には登場していませんが，SOA構築作業と並行して行う必要があります． SOAの実現は一度のシステム開発では達成することはできません．新たなサービスの追加や，サービスを再利用したシステム構築など，SOAの適用範囲を広げていく取り組みが必要です．SOA適用ポリシーやサービス運用ポリシーなどのSOAガバナンスを定義し，実際に運用していかなければなりません．
図3.SOA実現のためのプロセス
次の表に各アクティビティの詳細を記述しています．
表1: SOA 実現のためのアクティビティ概要
| アクティビティ | 種類 | 概要 |
| 要件定義/ビジネスモデリング | 開発 | 対象となる業務の仕様を明らかにし，システム化の範囲と機能を明確化する． |
| SOA適用ポリシーの定義と維持 | ガバナンス | SOAの適用のロードマップおよびサービス化対象を定義し，維持を行う． |
| サービスの抽出 | 開発 | サービス候補の抽出を行う． |
| サービスの分析 | 開発 | SOAの観点からサービス候補を分析し，サービスを洗練させる． |
| サービスの設計/実装 | 開発 | 分析されたサービスの具体的な実現方法を検討し，実装する． |
| SOA基盤アーキテクチャ設計 | 開発 | サービスを実行するための基盤の実現方法を具体化する． |
| SOA基盤アーキテクチャ構築 | 開発 | SOA基盤アーキテクチャを構築する． |
| サービス運用ポリシーの定義と維持 | ガバナンス | サービスの各ライフサイクルと各ライフサイクルに何をするべきかを定義し，維持する． |
| サービスの追加と変更 | 運用 | 運用ポリシーに基づいて，サービスの追加と変更を行う． |
| サービスの利用 | 運用 | 運用ポリシーに基づいて，サービスの利用を促進する． |
この章ではMDMの目的と中心的な概念である「マスターデータ」，そして実現のためのプロセスについて，基本的な考え方を説明します．
企業のデータの中には，複数のシステムにまたがって共通的に利用されるデータがあります．顧客情報などは共通的に利用されるマスターデータの代表です．しかし，多くのシステムは個別に同じようなデータを保持しており，作成，参照，変更，削除をそれぞれのシステムが独自に実行している場合があります．そのような状況では，データの不整合が発生し，正しいデータが不明になってしまいます．このような状況にならないように，信頼性の高いマスターデータの形成を目的とした活動が MDM です．最も信頼性の高いデータをゴールドレコードと呼びます．MDM ではゴールドレコード作成(もしくは特定)を行い，常にゴールドレコードが正しいデータであるように維持していく必要があります．
DMBOK (*2) では「MDM(マスターデータ管理)は流行語に過ぎず，すぐに別の新しい流行語にとって代わられると考えるものもいる．しかし，高品質なリファレンスデータとマスターデータに対するニーズは時代を超越しており，リファレンスデータとマスターデータ管理の技法と活動は，今後も長年にわたり有用なものであると考えられる」と述べており，MDM が一過性の言葉だったとしてもMDM実現のために行われる活動は，普遍的な中身になっているとしています．
図4.MDM実現の例
マスターデータはビジネスエンティティに関係するデータです．企業によってマスターデータと呼ばれるデータの内容は異なります．一般的な企業におけるマスターデータの種類は以下の3つに分類することができます．
パーティマスターデータは，個人や組織に関係するデータです．一般的な企業では顧客，公的部門では国民や市民，医療では患者，教育においては生徒が中心的なデータとなります．これらのデータ管理は多くの企業で課題として挙げられており，MDM の対象の第一候補になります．顧客データの MDM は顧客関係管理(Customer Relationship Management:CRM)の一部として語られることがあります．CRM の方が概念として広く，顧客データの分析や，ダイレクトメールやコールセンターなど顧客接点の分野も含んでいます．
パーティマスターデータは，個人や組織の関連や役割が非常に複雑であり，また多面的な役割を果たすデータであるため，MDM の実現が非常に困難です．しかし，MDM の実現が一番求められている領域でもあります．
製品マスターデータには物品だけでなく組織が提供している無形のサービスも含まれます．サービス産業では顧客に提供するサービスが，商品/製品となります．製品マスターデータには，製品が構成されている部品，材料，使用法，価格設定，値引き条件，画像，などの情報によって構成されています．
製品マスターデータは，その製品の開発，製造，販売，納品，廃棄を通して，製品やサービスのライフサイクル管理が求められます．このライフサイクル管理は Product Lifecycle Management:PLM と呼ばれます．過去の製品情報から製品の改善や，PLMは新たな製品開発の短縮などに利用されています．
財務マスターデータには，予算，計画，コストセンター，プロフィットセンター，総勘定元帳，などが含まれます．一般的には 企業資源計画(Enterprise Resource Planning:ERP) システムが財務マスターデータを管理する役割として機能します．
MDM 実現のためのプロセスは以下の図に示すように開発，運用，ガバナンスのアクティビティから構成されます．開発のプロセスは，要件定義から実現方法の検討，MDM ソリューションの実施まで，一連の MDM 環境構築の流れです．MDM の実現は，一度構築して完了するわけではありません．マスターデータを維持管理するためのルールや仕組みづくり(ガバナンス)，そのルールを継続的に運用していかなければなりません．このガバナンスと運用のアクティビティが適切に実施されなければMDMを実現することができません．
図5.MDM実現のためのプロセス
次の表に各アクティビティの詳細を記述しています．
表2 実現のためのアクティビティ概要
| アクティビティ | 種類 | 概要 |
| MDM の要件定義 | 開発 | 様々なステークホルダー間の MDM に対する要求を明らかにする． |
| ドメインモデルの確立 | 開発 | MDM の対象としている業務領域の概念を，抽象化する． |
| データリソースの把握 | 開発 | データのライフサイクル，流れを追跡しデータの場所，格納先，管理組織などを明確にする． |
| マッチングルールの定義と維持 | ガバナンス | データ照合とマージに関するルールを定義し，維持する．ゴールドレコード確立に関係する． |
| ゴールドレコードの確立 | 開発 | アプリケーションを横断した信頼性の高いデータを定義する． |
| データ統合アーキテクチャの策定 | 開発 | MDM に対する要求や，対象領域を考慮し，データ統合アーキテクチャを策定し，利用製品を選定する． |
| MDM ソリューションの実現 | 開発 | 策定されたデータ統合アーキテクチャに基づいて MDM ソリューションを実現する |
| マスターデータ運用ルール/ポリシーの定義と維持 | ガバナンス | マスターデータのライフサイクル管理，複製やアクセス方法などのルール/ポリシーを定義し，維持する． |
| マスターデータの変更と管理 | 運用 | 運用ルール/ポリシーに基づき，マスターデータの変更，作成，削除などの管理を行う． |
| マスターデータの複製と配布 | 運用 | 運用ルール / ポリシーに基づき，マスターデータの複製(コピー)，配布を行う． |
SOA と MDM は全社視点からの企業情報システム最適化を目指している概念です．SOA はサービス(アプリケーション機能)に焦点を当て，MDM はデータに焦点を当てています．この章では，2つの概念の関連と，具体的な全体最適化へのアプローチの方法を説明します．
Enterprise Architecture : EA は企業全体の業務とシステムのモデル化および改善のフレームワーク(*3)です．EA では業務プロセスやシステムを，業務体系(Business Architecture:BA)，データ体系(Data Architecture:DA)，アプリケーション体系(Application Architecture:AA)，技術体系(Technology Architecture:TA) へと階層化し，現状(AsIs)と理想(ToBe)のモデルを定義します．それに加え，AsIsからToBeへの改善プロセスを定めていきます．
MDM と SOA は，この EA における ToBe に向かって改善するための具体的な方法になります．MDM は データ体系(Data Architecture:DA)，SOA は アプリケーション体系(Application Architecture:AA) にそれぞれ対応します．
図6.MDMとSOAのEAにおける位置づけ
EA では BA の実現のために全体の整合性の取れた，DA，AA，TAを構築することが重要です．EA では，トップダウンで BA を構築し，そこからDA, AA, TA を整備するアプローチが理想的であるといわれています．
一方で，データやアプリケーションの複雑化によって，先行して MDM や SOA の実現を求めているケースは少なくありません．これから紹介する全体最適化のアプローチは後者のケースになります．
サービス構築を行う際，必ず2つのテーマが議論になります．「サービス粒度」と「サービスインターフェースにおけるデータ」です．
SOA における設計の重要な要素がサービスの粒度になります．サービス粒度は，提供する機能の抽象度によって決まります．例えば，顧客情報登録機能と顧客コード採番機能は，登録機能の方が粒度が大きく，採番機能の方が粒度が小さくなります． サービスの粒度が大きいと以下のような問題が発生することがあります．
逆に，サービスの粒度が小さいと次のような問題が発生することがあります．
どちらも一長一短であり，適切な粒度を決定するのがサービス構築のキモになります．
顧客情報登録を例に，サービスインターフェースにおけるデータを考えてみます．
この機能のインターフェースは「顧客情報」をインプットに，顧客情報を登録します．この機能は，いくつかのシステムで重複している機能であり，サービス化することによって共通利用することが期待されています．では，この「顧客情報」が意味する具体的なデータ項目はいったいどのようなものなのでしょうか．顧客情報とひとくくりにいわれていたデータは，システムごとに意味とデータ項目が異なっています．
こういったケースは，SOA実現の現場で少なくありません．
この2つの問題を解決する1つの手段として，MDMの「ドメインモデルの確立」が重要になります．対象領域の抽象的なデータモデルをサービスの粒度やインターフェースのデータの基準とすることで，再利用性の高いサービスを構築することができます．なぜなら，マスターデータは，複数のシステムで共通に利用されるビジネスデータであるため，マスターデータに対応するサービスは，再利用性が高いサービスになるからです．
Allen Dreibelbis らは SOA アプローチによるマスターデータ管理の手法(*4)を提唱しています．これは，マスターデータ管理システムをサービス化し，マスターデータのアクセスをサービスを介して行う仕組みです．このようにマスターデータ管理システムをサービス化することで，共通のインターフェースで，参照・登録・更新を行うことができるようになります．SOA アプローチによる MDM 実現のアーキテクチャ例は以下のようになります．
図7.SOAアプローチによるMDM実現のアーキテクチャ例
SOAアプローチによるMDMの実現は3つの特徴があります．
SOA を実現する標準技術(HTTP，SOAP，XML，JSONなど)は，巨大なデータを一度に処理することに向いていません．これは Web サービスの技術が，少量データの大量アクセスをどのように処理するかをテーマに発展してきたからです．このため，マスターデータを別のデータベースに全てコピーするような処理をサービス化すると，パフォーマンスの劣化や思わぬエラーを引き起こすことがあります．大量データを扱うサービスを作成する場合は，パフォーマンスを考慮して，慎重に設計する必要があります．また，サービス化を行わず別の手段で実現することも選択肢の1つになります．
SOA ではサービスを，MDM ではデータを組織横断的に共通利用します．数多くのステークホルダーが関係し，時にはステークホルダーの利害が対立する場合もあります．組織横断的な取り組みであるために責任の所在が曖昧になり，重要な意思決定ができずに SOA/MDM 自体が雲散霧消してしまうことも考えられます．
こうした問題は組織や企業文化に起因するため画期的な解決策はありません．長期的な取り組みとして，従来の組織を横断した推進体制やトップの強いリーダーシップなどが必要になります．
SOA/MDM は，一度システムを構築したからといって完了する取り組みではありません．SOA であればサービスを，MDM であればデータを正しく利用し，更新していかなければなりません．維持・管理の仕組みを整えておかないと似たようなサービスの乱立，無秩序なデータの利用が行われてしまいます．SOA/MDM どちらも維持管理を行うことが非常に重要です． 維持管理の活動範囲はそれぞれ異なっておりますが，次のような項目になります．
表3:維持管理の項目
| SOA | MDM | |
|---|---|---|
| ポリシー/ルール | サービスの開発/利用に関するポリシー/ルール | データの作成，利用，更新，削除に関するポリシー/ルール データマッチングルール |
| 標準およびアーキテクチャ | システムアーキテクチャの策定． | データアーキテクチャの策定． |
| モニタリング | サービス利用状況の監視 | データ利用状況の監視 |
| 適用支援 | 新規プロジェクトのSOA適用支援． | 新規プロジェクトのマスターデータの利用の支援．ポリシー/ルール遵守の監督 |
当社では「オープンソースのESB、Mule ESBを活用した連携ソリューション」を提供しています。
もしクラウド連携や企業システム連携でお困りの方は当社までご相談下さい。
| © 2012 OGIS-RI Co., Ltd. |
|
