SOAはアーキテクチャであり,設計の前提となるポリシーとも言える側面も持ち合わせる。そのため,極端な話メインフレームやCOBOLなど使用するテクノロジーがまったく古いままでも,“SOA的なアーキテクチャ”は実現しうる。システム全体の整合性や変更の柔軟性,局所化に耐えうる設計の重要性を理解しているユーザー企業は,実は自覚がなくてもSOAに基づいたアーキテクチャの適用を実践し,移行しているのだ。
古いテクノロジーでもSOA的なアーキテクチャは実現しうる
ある保険会社は,100%SOAとは言えないが,“SOA的”なシステム・アーキテクチャを整備している。例えばこの保険会社では,データアクセス・レイヤーと業務ロジック・レイヤー,そしてプレゼンテーション・レイヤーを明確に分けている。以前説明したアーキテクチャ・パーティショニングと同様のことを実施しているわけである。この企業では、業務ロジック・レイヤーを,さらに業務のフロー(流れ)と業務ロジックを切り分ける設計を採用。変更の局所化を図り,モジュール化を徹底している。ここまで明確に分離した企業は少ない。使用しているテクノロジーはメインフレームで言語はCOBOLだが,別にテクノロジーが古くても構わない。アーキテクチャの優秀さがその会社を支えているのである。
業務ロジックと業務フローを分離するメリットは大きい。保険会社に限らず,商品やサービスの料金を顧客や条件によって変えることはしばしば行われている。ロジックとフローを分離すれば,条件によってロジックとフローの関係を組み替えるようなルール・エンジンを組み込むことが容易になる。
一般的には,業務ロジックと業務フローを一体にしたアーキテクチャにするケースが多い。システムの実装で表現すると,ロジックとフローを一体化したプログラムになっている。これだとフローが変わったときに,論理的には変える必要のないロジックの部分にも手を入れる必要が出てきてしまうため,システム作業の効率化という面から見ると望ましくない。
業務ロジックと業務フローを分離し,ルール・エンジンをソフトウエアで自動化すれば,一歩進んだ業務効率化が実現できる。またBPM(ビジネス・プロセス・モデリング)ツールがより進化すれば,ロジックとフローの関係をGUIで指定・実行することがいっそうスムーズに実現できるだろう。そうすれば,システム担当者の手を煩わせることなく,ロジックとフローを組み替えられる。これこそ「俊敏な企業」に相応しい姿と言える。
もちろんBPMやルール・エンジン分野のソフト技術や製品はまだ発展途上である。しかし,この領域の技術はいま急速に発達している。現状,業務ロジックと業務フローの関係を人手で制御せざるを得ないとしても,アーキテクチャを整えておけば,将来その恩恵をいち早く受けられる。最新テクノロジを導入するために既存システムを部分的に変更したり,時には全面的な再構築を強いられていた姿は,過去のものになるはずだ。
テクノロジを最大限に活用するという意味でも,アーキテクチャは重要である。アーキテクチャを適切に構築しておけば,既存システムがテクノロジの進化の足かせにならないのである。
少しSOAの議論とはずれるが,アーキテクチャ・レベルでロジックとフローを分離するメリットは,テクノロジ面にとどまらない。業務プロセスを可視化する際に,ロジックとフローの関係をディシジョン・テーブルとして表現しやすくなる。つまり,ロジックとフローの間にあるさまざまな条件を見える形で記述できるということだ。アーキテクチャを適切に作ることで,「ロジックとフローの間に隠れていたルールを可視化する」という,一歩進んだ「見える化」を可能にするのだ。
設計が優れていれば,自覚せずともSOAに移行
厳密な意味ではSOAとは異なるが,あるクレジットカード会社は,自社のシステム群を競争力の切り口で区分した。他社と共通化しても問題ないシステム,競争力を維持・向上するために自社で開発するべきシステム,という形で区分し,さらにそれぞれを業務単位に整理。来るべき再構築や,他社とのシステム共同化や合併などの異変に備えている。自社システムのあり方を明確にする,という意味では,これもSOA的と言える。ちなみにこの会社もメインフレームを使い続けている。
SOA先進企業と言われるユーザー企業を訪問すると,「別にSOAに基づいたシステムにしようと考えていたわけではない」と言う。しかし私たちのような第三者から見ると,見事にSOAを実践している。テクノロジーに引っ張られないアーキテクチャの大切さを示す,象徴的なコメントである。
逆説的なようだが,良いアーキテクチャやポリシーを作り上げていれば,それは別にSOAでなくてもよいのだ。いずれにせよ,易きに流れるとうまくいかないのがSOAである。
長期の設計思想としてSOAをとらえると,ITは良い方向に行く。短期の生産性ばかりに落とし込んでしまうと,SOAのメリットはなかなか得にくいかもしれない。
(次回に続く)
|