情報システムを設計するとき、何に着目して構想するかを開発アプローチといいます。歴史的にみると、環境変化による情報システムへの影響を少なくし、情報システムの改訂を局所化することにより、改訂を容易にできるアプローチへと変化してきました。
プログラム指向アプローチ
新入社員や転入者に業務を説明するとき、担当者について、他の業務から受け取る帳票、参照する資料、作成する文書を示し、その加工方法（仕事の内容）を説明するでしょう。
情報システムでは、加工方法がプログラムであり、帳票・資料・文書がデータ（ファイル）であると認識すればわかりやすいでしょう。すなわち、プログラムが中心で、プログラム間をデータが動くことにより処理が行われるという認識です。
昔は、このようなアプローチが当然だと思われていたので、あえて名称をつける必要はありませんでした。ここでは、他のアプローチと区別するために、ＰＯＡ（Program Oriented Approach：プログラム中心アプローチ）とします。
ＰＯＡは、理解しやすいアプローチですが、業務の手順を中心に設計されるため、データの有効活用や保守・改訂の観点から、多くの欠点があります。
- 縦割りシステムになる
各部門での実際の仕事に従ってシステム化されるので、他のシステムとの連携をしにくい、いわゆる「縦割りシステム」になりがちです。情報システムには、販売システム、生産システム、経理システムなど多くのシステムがあります。経営的な観点からは、それらを互いに関連づけて情報を活用することが重要です。販売システムでの商品コードと生産システムでの製品コードが違うというように、互いに関連のとれない縦割りのシステムになるのでは困るのです。 - 環境変化の影響が大きい
組織変更や業務の変化などが発生すると、仕事の仕方が変わります。それに伴いプログラムを変更する必要が生じ、それに応じてデータファイルも変更しなければなりません。しかもファイルの項目が変わると、それを用いる他のプログラムも変更しなければなりません。
ＰＯＡでは、保守・改訂が頻繁に発生するし、しかも、大幅な変更になってしまいます。 - 冗長が多く大規模になる
どの業務では似たようなパターンがありますが、それぞれ別途に構築されることが多くなります。データも同じような内容のファイルが多数存在するようになります。冗長が多く大規模になるだけでなく、管理も困難になります。
データ中心アプローチ
１９８０年代になりデータベースが発展すると、対象業務で用いるデータをデータベースとして保管し、それをプログラムで創生・更新・参照するのだという概念に変わってきました。すなわち、データが中心になったのです。それをＤＯＡ（Data Oriented Approach：データ指向アプローチ）といいます。
- 全体的整合性
ＤＯＡは「最も重要な情報資源はデータである」という理念に立脚しています。
ＤＯＡでは、「自社において必要な情報は何か」という経営的な観点で、データベースを構築しデータベースから情報を得ることを中心としてシステムを設計します。個々の業務ではなく、全社的な立場からトップダウンで設計するので、論理的に整合性のあるシステムを構築しやすくなります。いうなれば、ＤＯＡはＰＯＡにくらべて、よりしっかりしたインフラの上に個々のシステムを構築するのだともいえます。それにより、個々のシステムがバラバラにならず、全体的に整合性のあるシステムにすることができるのです。 - データの部品化
ＤＯＡは、見方を変えればデータの再利用、部品化であるともいえます。販売システムとして作成した得意先マスタや商品マスタは、流通システムや経理システムとしても利用できます。逆にいえば、これらのマスタは、きっかけとなった販売業務だけではなく、流通業務や経理業務などの全社的な観点から設計しなければ効果が少ないのです。すなわち、ＤＯＡを採用しようとすれば、全社的なデータの整備をする必要があるのです。 - システムの安定性
経営環境がかなり変化しても、得意先と店舗は１：Ｎの関係にあるというようなＥＲモデルで記述されるデータ構造はあまり変化はしません。すなわち、ＤＯＡによるシステムは、環境変化に対して安定しているので、システム改訂の必要性が少なくなります。すなわち、ＤＯＡは安定した基盤の上にシステムを構築しているといえます。そのために、経営環境が変化しても、システムへの影響が比較的小さいのです。 - 改訂作業の容易性
たとえば、○○得意先と××得意先については例外処理を行うとき、プログラムの中で
ＩＦ 得意先＝○○ ＯＲ 得意先＝×× ・・・
と記述していたのでは、後で△△得意先も例外の対象となったときには、上のような処理をしているすべてのプログラムを探さなければなりません。それにたいして、得意先マスタに例外処理という属性項目を作っておき、プログラムでは
ＩＦ 例外処理＝１ ・・・
としておくのであれば、変更があったときには、得意先マスタの△△得意先のレコードについて例外処理項目の値を１に修正するだけで、すべての修正が行えることになります。
さらに、ＤＯＡでは、必然的に得意先マスタは全社で一つのファイルしか存在しないので、１か所だけを修正すればよいのです。このようにデータの一元管理をすることは、保守・改訂を容易にするために重要なことなのです。 - 情報検索系システムとの連携
情報検索系システムでは、任意の切り口で検索加工することが必要です。すなわちデータベースが中心となるＤＯＡと合致しています。
オブジェクト指向アプローチ
ＤＯＡはＰＯＡと比較して多くの利点がありますが、ＤＯＡの限界もあります。
- 処理の部品化ができない
ＤＯＡでは、データベースの更新や参照などの処理はプログラマに任されています。これでは処理の部品化にはなりません。プログラムのエラーによりデータベースの信頼性が損なわれることがあります。 - データの構造が制限される
ＤＯＡでのデータベースは、ＲＤＢ（リレーショナルデータベース）を前提としています。ＲＤＢは２次元表（縦横表）になるデータを扱うのには便利ですが、それ以外の構造になるデータを扱うのには不便です。
このような欠陥を回避するために、ＯＯＡ（Object Oriented Approach：オブジェクト指向アプローチ）が注目されるようになりました。現在では、ＪａｖａやＣ＋＋などのオブジェクト指向言語が主流になってきました。
- オブジェクトの概念
ＯＯＡでは、データベースとそれを処理するプログラム（メソッドという）を一体化したものをオブジェクトといいます。例えば、売上データベースにデータを追加するとき、誤データ入力を防ぐためのチェック機能を組み込んだメソッド（売上）を作り、プログラマにはデータベースの保管形式も処理方法も見せず、売上メソッドを実行するためのインタフェースだけを公開します。プログラマは、
売上（年月日、得意先、商品、個数、金額）
というようなデータ（メッセージという）を与えるだけでよいのです。 - 多様なデータ構造
ＯＯＡでは、プログラマはデータベースの処理方法を知る必要がないので、データベースをどのような構造にしてもかまいません。ＲＤＢの限界が解消されます。 - 継承の概念
ＯＯＡの特徴の一つに継承（インヘリタンス）という概念があります。既存のデータベースやメソッドに新しい機能を追加するとき、既存のものと違う部分だけを追加すればよいのです。
例えば、自動車というデータベースに乗用車とトラックのデータベースがあるとき、それらに共通する項目とそれぞれに異なる項目があります。それにバスを追加したいときは、バスに特有な項目だけを追加すれば、共通部分が継承されます。
メソッドでは、売上の特殊なケースとして、サンプル売上という機能を付け加えたいときは、売上メソッドと異なる部分（金額＝０）だけを定義したメソッドを作ればよのです。
function サンプル売上 {
金額＝０；
売上（年月日、得意先、商品、個数、金額）；
}
ＳＯＡ
最近はＳＯＡ（Service Oriented Architecture）が注目されています。
情報システムを構築する観点では、ＯＯＡのオブジェクトは、プログラムの部分的な部品に過ぎません。それを体系化して発展させれば、「受注」「在庫確認」「出荷」のような業務レベルの部品にすることができます。その部品のことを「サービス」といいます。
これらのサービスを自社仕様で開発することもできますが、ベンダが標準的なものを提供するようになりました。これはＥＲＰパッケージが持っている機能を独立させて部品化したのだということもできます。
ＳＯＡでは、システムを構築することは、これらのサービスを組み合わせることになります。ここまでのレベルで部品化すれば、システム開発・改訂が飛躍的に容易になります。
情報システム構築の変化
このようなアプローチの変化に伴い、情報システム構築の概念が大きく変わってきました。
以前は、処理の仕方を細かく記述するのがプログラミングでした。情報システムを構築するには膨大な作業がかかり、プログラミングが情報システム構築の大部分を占めていました。短いプログラムで記述する能力があること、プログラミングの生産能力が高いことが、プログラマの評価基準でした。
ところが、部品化が進むと、プログラミング作業のウエイトが小さくなります。プログラマの評価基準は、
適切な部品を知っており適切に用いる能力、部品を作ることができる能力が重要になります。
部品化をするには、業務の標準化、しかも情報システムに合わせた標準化すら必要になります。
データ中心アプローチになると、用語・概念の統一が重要にあり、しかも企業全体での統一が必要になってきます。オブジェクト指向アプローチになると、さらに業務の仕方の統一が求められるようになります。ＳＯＡで標準的なサービスを活用するには、そのサービスの機能に合わせて業務の仕方を変える、靴に足を合わせることすら求められます。