システムの構造化といっても、やりかたはプログラムとよく似ている。個々のサブシステムの機能を出来るだけ単純化し、共通化できるものは共通化する。でも、これは言うほど単純ではない。もともとスパゲティーなシステムは、そのプログラムから見直していく必要がある。
特定のデータの検索や登録・変更などの基本的な処理と、そのバリエーションや表現や使い手の利便性を向上させるための処理は可能な限り分離する。たとえば、品物の見積もりを依頼された場合、在庫を調べ、在庫があれば「即納可」として、必要数量を仮押さえ（予約）する。在庫がなければ、標準納期を検索するか、仕入先に問い合わせて在庫と納期を確認する。それから、単価、顧客ごとの仕切り率などを検索して、それらの情報から見積もり書を作成し、内容を確認してから上司のハンコをもらって・・・・。という手順だとしよう。
ここで在庫の検索、標準納期の検索、品物の予約、単価や仕切り率の検索などは、基本的な処理であり、他の作業でも利用される。一方、見積書の作成、印刷もしくはその承認という作業は見積もり作成に固有の作業だ。（もちろん承認などの統制過程は汎用的なワークフローにできるが、その際も、見積もり固有の業務フローは基本ロジックからは分離しておく）
ＤＢＭＳの多くにはストアードプロシジャー呼び出しという機能が用意されている。こうした基本処理をサーバ側に手続きとして用意しておき、それを呼び出すというのが綺麗な形だ。こうした汎用的な手続きをデータベースサーバ側に用意しておくことで、アプリケーションの処理はかなり綺麗なものになるはずだ。
しかし、依然として問題は残る。たとえば、そのような方法で作られた２つのシステムを統合することを考えてみる。企業の合併などの場合だ。しばらくは２システムの並行運用は必要になるが、最終的には統合したい。その際に、既存のシステムのパーツを利用したい。だが、同種の機能をたばねたくても、インターフェイスがまったくことなっているため、アプリケーション側にはそれぞれの異なる呼び出しを実装しなければいけない。まして、こういう整理すらされていないシステムの統合は、ほぼ不可能に近い。
経済状況の変化でＭ＆Ａなどが急激に増加し、また、その規模も大きくなってきた今日、こうしたシステム統合の問題は経営からのプレッシャーも強く、ＩＴ部門関係者の地獄絵図をもたらしがちだ。これをなんとか解決できるアーキテクチャはないだろうか。
（続く）
コメントする