【16】選択肢を 1 つに絞らないための現実的な方法

　システムが 1 つのデータモデル、1 つのメッセージフォーマット、1 つのメッセージトランスポートで作れないことにシステム・アーキテクトはいつまでも悩みます。彼らはコンポーネント、ポリシー、スタンスといったものが 1 つに決まらないだけで、くよくよするのです。もちろん、今後 10 年間で何種類の「顧客」テーブルがシステム構築に影響を与えるか心配するような巨大企業（巨大企業というのがそもそも危険なのですが）なら、最初から大きすぎて 1 つの「顧客」テーブルでは業務をカバーすることはできないでしょう。

　技術的な領域では、1 つに絞ることを強制できます。そうすれば私たちにとってはとても便利です。しかし、ビジネス領域には、一貫性がなく多面的で曖昧でごちゃごちゃした世界が入り込みます。さらに悪いことに、ビジネスが相手にしているのは、「現実世界」でさえありません。現実世界の一側面に対する見方を相手にしているのです。ドメインを技術的に考えて、強権的にソリューションを 1 つに絞るのも、確かに 1 つの方法でしょう。しかし、現実とは「信じることをやめても消えないもの」（フィリップ・K・ディック）ですから、ビジネスが発展すれば整理しきれないものがかならずまた出てきます。実存的不安を静めようとして、貴重な時間をすべて DTD に注ぎこむエンタープライズ・データ・チームのようなものが作られるのもそのためです。しかし、顧客たちは、このようなチームの反応の鈍さに不満を感じることでしょう。

　なぜ、私たちは世界は乱雑だという現実を直視して、一貫性がなく、重なり合う部分もあるような複数の表現、サービス、ソリューションを認めることができないのでしょうか。私たち技術者は、このようなものを見ると、ひるんでしまいます。更新の不整合とか、メンテナンスのオーバーヘッドとか、管理しなければならない依存性がスパゲッティ化してしまうといったぞっとするシナリオを想像してしまうのです。

　しかし、ヒントはデータウェアハウスにあります。データマートのスキーマは、あまり正規化されておらず、個別にインポートされ、値が事前に計算されていることが多く、データはデータベースに格納されているのとはかなり異なるビューで表示されます。そんなことをしても空が落ちてこないのは、データマートの非機能的な性質に理由があります。ETL 処理は、トランザクション処理と分析処理というまったく異なる 2 つの世界をつなぎます。両者の間では、更新や検索の頻度、スループット、設計変更の大きく異なり、おそらくデータ量も大きく異なります。ポイントはここです。非機能的な性質が十分に異なるサブシステム同士では、データ表現の不一致も扱えるのです。

　おもしろ半分にデータ表現やトランスポートを複数にするようなことをしてはいけませんが、非機能的なパラメーターによってシステムを分割することができることを常に頭に置いておきましょう。そうすれば、顧客の利益のために、多様なソリューションを共存させるチャンスが見つかるでしょう。