|
| 業務モデルをシステムの核に |
2003年12月12日
株式会社データ総研代表取締役会長 椿 正明
|
 １． 業務モデルとは
これはビジネスユーザの意識する実装独立の業務の構造を、プロセスモデルとデータモデルで表現するもの。これとソフト化標準・ＩＴ環境からソフトすなわちＤＢやプログラムが決まってくる。従来は、ともに独立に激しく変化するこれらの分離が不十分で、必要以上の混乱を招いていた。業務モデルには３レベルの処理、すなわちＬ１：データからデータを作る、Ｌ２：データから製品（画面・帳票）を作る、Ｌ３：製品を届ける、が含まれている。これを生産管理にたとえると、Ｌ１は中間部品製造、Ｌ２は製品製造、Ｌ３は製品物流になる。プログラミングレスなどの試みにおける、Ｌ１とＬ２の分離を提案したい。
２． 業務モデルの表現
人と人とのコミュニケーションを図るものを言語というなら、これには図面言語、テーブル言語、テキスト言語の３種があり、実装独立・ランダムアクセス・関係表現・教育負荷・デバッグいずれの観点からもテキスト言語−日本語、ＣＯＢＯＬ、ＪＡＶＡなど−が最悪である。エンジニアリングでは図面言語とテーブル言語が主役となる。システムの世界にも極力エンジニアリングを取り込みたい。
同じプロジェクトで同じドキュメントを共有した人が同じ文化を持つようになるが、ファイルレイアウト、プログラム仕様書、ソースプログラム、ＩＯレイアウトなどソフトドキュメントの共有でなく、データモデル図、データ定義書、業務フロー図、ＩＯイラストなど、業務モデルの図と表の共有にしたい。データモデル図としては、広辞苑相当のリソースエンティティと新聞記事相当のイベントエンティティを分離し、配置で意味を表現し、結合・要約・抽出などのＬ１、Ｌ２の処理の読める図を提案する。Ｌ３の処理にはＩＰＦチャートを用意している。
３． データインフラ（ＲＲＲ）
メタデータをストアするRepositoryと広辞苑相当のResourceデータは、各アプリの共用するデータインフラであるが、最近話題のダッシュボードと呼ばれるRealtimeデータウエアハウスも共用対象のインフラである。この３つをデータインフラとするＴＨｅＥＤＷの環境を提案したい。
４． ２１世紀の情報システム業務分担イメージ
ユーザ企業の多くは業務モデルを常時維持管理し、これを条件にアウトソースすることにならなければならないであろう。いま話題のＥＡ（Enterprise
Architecture）はこの方向に沿ったものであり、前向きに取り組むべきである。ＤＯＡ＋コンソーシアムで取り組むＤＯＡ＋ＯＯＰはＥＡでの業務モデルとＩＴとの間に横たわる断絶を解消しようとするものである。
５． オブジェクト指向との棲み分け
アプリケーションにはデータ構造に制約される業務アプリケーションと、制約されないシステムアプリケーションの２種類があるのではないか。前者は画面・帳票として要求が与えられ、システムの範囲が事業、企業、企業グループと際限なく拡大される。後者は対象とするハードウエアなどにより自ずと限界がある。したがって前者にはＤＯＡが、後者にはＯＯが適しているように思われるのだが。ＯＯにはオブジェクトの粒度の基準、リポジトリの構造、データベース通信場など、種々の疑問や課題があるかに見える。
|
 |
|
| |
|
