DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回のテーマは前回に引き続き「ＸＸＸＸの誤解」シリーズを連載することにしたい。本ブログでは近年の大規模システム再構築案件で時々目にする“インターフェース標準に関する誤解について話してみたい。前回同様に、この誤解は箸にも棒にも掛からないというものではなく、それを解消すれば企業システムのさらなる生産性と品質向上が狙えるというものである。そしてこれらの共通点は、ベンダーの製品戦略を安直に受け入れ、EAにおけるTA層が先行するあまり、上位層（特にDA層）がおろそかになるという現象である。

大規模システムの再構築で必ずと言って良いほど問題となるのが、当該システムの内外に存在するおびただしい数のシステム（サブシステム）間インターフェースである。長年のシステム増改築でデータを無秩序に連携した結果、見事なまでの超大盛りスパゲッティーが出来上がっている。現行システムの分析段階で、数百～数千のインターフェースが出現した際には、とても解読する気にはならない。この膨大なインターフェース資料は、再構築においてDAやAAを変えずにTA（プラットフォーム）のみを移行するストレートコンバージョンでこそ役立つが、新築に建て替える“通常の再構築”では、あるべき姿のDB設計に基づいて再定義されるので、そのままでは活用できない。

ところで、近年の大規模開発プロジェクトでは、何らかの開発方法論に則って、基本設計以降のアウトソーシングに備えて各種の設計開発標準を定めることが一般的である。そして数ある標準の一つとして“インターフェース標準”も定義することになるのだが、残念なことに、実装するツール類の選定に話題が移って行く。“実装環境の選定”を標準化と錯覚してしまうのだ。HULFT、MQ、DATASPIDER、POWERCENTER、DATASTAGE、等々の製品を選定する作業にいそしむことになる。また、この作業のモチベーションにはベンダーも一役買っている。

上記のツール類はEA的観点からみるとTA層に属することは誰でもお解りいただけるだろう。DA、AA層（とりわけDA）についての標準化はいったい何処に行ってしまったのだろうか。DA層におけるインターフェース標準とは、システム間で受け渡される“伝文フォーマット”の標準に他ならない。このきわめて重要な標準が抜け落ちてしまうのだ。ではなぜレコードレイアウトの標準化に至らなかったのだろうか？POA（Process Oriented Approach;造語）型開発手法では、DB設計は開発後半のフェーズ（詳細設計）で固まるので、本標準化作業段階では、あるべき姿のDBが描けていないからである。DB設計が先行していなければならない理由はここにもあるのだ。

話は少しそれるが、石油化学業界では1980年代後半にはEDIフォーマットが既に規定されて電子商取引が行われていた。企業毎にバラバラなフォーマットで取引情報をやりとりしていたのでは非効率との事で、早くから協会が音頭をとって標準化がなされている。製薬メーカーと卸の受発注をとりもつJD-NETもしかりである。これを企業内のデータ交換（インターフェース）に置き換えても同様にフォーマットの標準化が可能である。いや寧ろ、1企業の中での標準化の方が折衝の相手も少ないので簡単なはずである。

このように、異なるシステム（サブシステム）間インターフェースのレコ－ドフォーマットは、同類のものを集約して数百から数十までに減少することが可能なはずである。しかし、少なくとも上記の業界VANのように誰かに統一しようという”意思”が必要である。そしてDA層の統一はさらに上位のBA層についての知識抜きにはなし得ない。EAの各層の設計はBA⇒DA⇒AA⇒TAの順に確定されなければならない。進化の著しいTA層は実装直前に最も新しいものを選定すれば良い。

よくよく考えれば、システム間インターフェースとは、データのやりとりである。その同期タイミングの分類としては、リアルタイム、準リアル、遅延型バッチ等がある。また、伝文の蓄積形態としては、揮発性メッセージ、一時蓄積メッセージ、ファイル蓄積、DB蓄積等が挙げられる。これらいずれのパターンでもレコードレイアウトは存在し、それらの出来る限りの統一を図る事がエンタープライズレベルでのスラム極少化に寄与する。そして本ブログに度々登場するデータHUBはこれらのインターフェース標準の実装である。

まとめると、インターフェース設計はシステム設計の起点にあり、結果としての妥協の産物ではないと言える。そして、データ中心はデータベース中心よりも明らかに広い事を意味する。また、プロセス中心はこの正反対であり、サービス提供側ベンダーのモデルと言える。