企業システムの悩み　第1回

現在の企業システムの悩みは、単一のシステム（いわゆるストーブパイプシステム）において、複数のシステムとデータを連携している点ではないでしょうか。「データ入力の2重化」を防ぐために、他のシステムからデータをもらったり、渡したりします。
このようなケースでよくあるのが、
販売管理システムが、チャネルごとに存在し、配送管理システムが「商材・仕入ルート」ごとに存在するケースです。


今までの場合、このようなデータ連携ではMxN通り（上手に作るとM＋N通り）のバッチプログラムを用意して、夜間バッチ（日次）で連動していました。（M+N通りにするためには一つの標準的なデータ構造を作成し、そのデータ構造に連携元・連携先ともあうように変換するプログラムを用意します。）

多くの企業の場合、ジョブ管理システムを導入しており、ジョブ管理の標準化はおこなえていますが、アーキテクチャ標準や技術標準を明確にしていないため、システムごとにバッチプログラム（アーキテクチャ）を開発しているのが現状です。
もちろん、ジョブ管理システムから呼び出すことができるようにするため、OSのシェルスクリプトやバッチファイルとして実装されている場合がほとんどですが、単純に独自のアーキテクチャを呼び出すための仕組みが共通化されているに過ぎません。
アーキテクチャがばらばらであるため、バッチプログラムの保守性を下げているケースも見受けられます。このようなデータ連携は、

1)連携元がデータ変換をする

1. 連携元DBからデータを抽出して
2. データの変換をおこなってファイルに出力する
3. 連携先DBにデータを格納する

2)連携先がデータ変換をする

1. 連携先DBからデータを抽出してファイルに出力する
2. ファイルを読み込んでデータの変換をおこなって
3. 連携先DBにデータを格納する

3)入出力情報の標準を定義する

1. 連携元DBからデータを抽出して
2. データの変換（標準形）をおこなってファイルに出力する
3. ファイルを読み込んでデータの変換（標準形から特殊な形態）をおこなって
4. 連携先DBにデータを格納する

の3つのパターンに分かれます。いずれの場合も抽出して、変換して、格納するというサイクルを描きます。これらの英語の頭文字をとり、ETL（Extract、Transform、Load）と呼ばれます。

ETLにはいくつかのツールがあるため、OSSによるツールを次回紹介したいと思います。