DOA（Data Oriented Approach：データ中心アプローチ）のモデリング技法である DFD（Data Flow Diagram）の簡単な例が次のような図になります。

この例に「プロセス-E」を追加してみます。「プロセス-E」は「データストア-X」と「データストア-Y」を参照します。

果たして、このような「プロセス-E」は最適な方法なのでしょうか？

DFD 上のプロセスから見ると、データストアは、プロセス間のインターフェースになっているともいえます。このような考え方ですべてを進めてしまうと、DBMS への負荷が高くなることが予想されます。また、データストアが別々のデータベースである場合や別々のネットワークである場合、対応が複雑になることが予想されます。

条件にもよりますが、たとえば次のようなアプローチも自然に発想できそうです。

SOA（Service Oriented Architecuture：サービス志向アーキテクチャ）の重要技術のひとつに ESB（Enterprise Service Bus）があります。異種システム間などでサービスをつなぐ中継技術など、あるいはそれらを実装するミドルウェアにあたります。

この ESB との比較によく用いられているのが EAI（Enterprise Application Integration）です。

ESB は、バス型で分散処理であり、疎結合であることに対して、EAI は、ハブ・アンド・スポーク型で集中処理であり、密結合であることがいわれます。

EAI は、ベンダーの独自技術によって実現されているともいわれます。この EAI をベースにした SOA 製品も登場しています。

サービス志向アーキテクチャ（SOA：Service Oriented Architecuture）について、わたしが注目する３つの基本ポイントをあげてみます。

SOA の１つめの基本ポイントは、SOAP（Simple Object Access Protocol）。SOAP は、XML と HTTP を利用してオブジェクト間の通信を行うプロトコル。SOAP を利用することにより、異種システム間の連携がやり易くなるであろうこと。また、SOAP が HTTP プロトコルを利用しているため、ファイアウォールを通過できる点も重要なポイントだとわかります。

SOA の２つめの基本ポイントは、訳のままですが、「サービス志向アーキテクチャ」。「サービス」（のオブジェクト）を提供し、そして、その「サービス」（のオブジェクト）を利用するための共通フレームワークであること。Web サービスが例にあげられますが、企業システムにおいては、イントラネット Web サービスが中心となりそうです。当然ながら、インターネット Web サービスもターゲットとなりえます。

SOA の３つめの基本ポイントは、「サービス志向」であること。「サービス」（というオブジェクト）は、ビジネス業務における一連の機能を提供します。企業システムの構築や連携について、SOA では、この「サービス」の視点で切り込んでいくことになります。このことに関連して、BPMN（Business Process Modeling Notation：業務処理プロセスを記述する表記法）、BPEL（Business Process Execution Language：業務処理プロセスを記述する言語）というキーワードが登場します。また、ESB（Enterprise Service Bus：異種システム間などでサービスをつなぐ中継技術など）も重要なキーワードです。

データ中心アプローチ（DOA：Data Oriented Approach）は、「データの構造」や「データの流れ」に着目して情報システム分析・構築を進める方式です。わたしの知るところでは、ＩＢＭ社系列において特に推進されてきた方式です。また、経済産業省のホームページの公表資料によると、エンタープライズアーキテクチャ（EA）の成果物には、機能情報関連図（DFD）があげられています。

この DOA でのモデリング技法に、DFD（Data Flow Diagram）や ER 図（Entity Relationship Diagram）がよく知られています。

DFD を構成する要素は、４つ。「外部実体/ターミネータ」、「プロセス」、「データストア」、「データフロー」。

あるいは、「データの源泉／吸収」、「処理（プロセス／バブル）」、「蓄積（データストア／ファイル）」、「データの流れ（データフロー）」とも。情報処理技術者試験問題ではこちらがよく使われています。

DFD の構成要素が単純であることから、システム全体（のデータの動き）について展望のよいフローを書くことができます。しかし、まじめに細かく「データフロー」線を書いてしまうと、「データフロー」線が多くなり、逆に見づらくなるという面もあります。よって、「フロー」線について網羅・詳細な表現には不向きとも感じられます。

企業に導入される情報処理システムの構築費用の算出に使われることがいまでも多い「人月」。関係者の中には、この「人月」に疑問を感じてる方も多くいます。

一般に、雇用契約や委任契約、請負契約は、労務供給契約になります。人の労務について対価が支払われることになります。このようにみると、「人月」による算出については、ある程度合理性があるようにも思えます。また、この業界では下請負の使用が常にあるといえますので、このような事情も「人月」による算出と関連しているように思われます。

なお、請負契約は、仕事の完成を目的とする契約で、完成義務があります。請負人がこの完成義務を履行することによって、注文者にはその仕事の結果に対して報酬支払義務が生じます。

仕事の完成が目的で、それに対する報酬となるので、その報酬からは、労務供給契約でありながら、実際の人の労務内容との関係性において希薄になりがちと感じられます。

情報処理システムの構築費用として、ハードウェアや商用ソフトウェアなど、価格があらかじめ定まっている製品の導入が前提となることがほとんどでしょう。ただ、これらの製品自体の設定やチューニング作業は、人の労務になります。

また、ビジネスプロセス／ビジネスルール／ビジネスロジックや、ユーザビリティ、そしてそれらに合わせた前提製品とのインターフェース、などなど、作り込み作業がある場合も、人の労務になります。

このような作業の定量化／定型化、人の技量の考慮、作らない技術、などなど、「人月」という算出方法についての疑問を解消できそうな、いくつかの方法があげられます。