部品化と再利用

工業製品では、標準化した部品を用いることにより、故障した部品だけを取り換えればよいし、改良された部品と取り換えるたけで性能を向上させることができます。このように、ソフトウェアを部品化すれば、保守・改訂が容易になります。

サブルーチン

例えばあるロジックを変更しようとしたとき、それを個々のプログラムで記述されているならば、それに関係しているすべてのプログラムを改訂しなければなりません。それを欠落なしに探すのは大変な作業になります。それにたいして、ロジックを個々のプログラムで独自に記述するのではなく、そのロジックを一つのサブルーチンにしておき、それだけを改訂すればよいようにしておけば間違いがなく簡単に改訂できます。

標準パターン

事務処理では、ソート、照合、集計など、似たような処理が多くあります。個々のシステムでそれらの処理を個別に作成するのではなく、汎用的に使えるプログラムを作成しておき、それを多くの箇所で利用すれば開発が容易になります。しかも、その部分は十分なチェックがなされているのであるから、改訂のときは独自に開発した部分だけを考えればよいことになります。

非手続き型言語

修正個所を発見するには、プログラムのステップ数が短いほうが容易です。ＣＯＢＯＬのような手続き型言語に比べてＳＱＬのような非手続き言語を用いれば、ステップ数は非常に少なくなります。非手続き型言語は、標準パターンを言語化して汎用性を高めたものだと解釈することもできます。

データベースとデータ中心アプローチ

プログラムだけでなく、データの部品化を図ることが必要です。たとえば、商品コードと商品名の対応表などは、多くのシステムで利用するのですから、それを商品マスタとして整備すれば、多くのシステムでそれが使えるようになります。
　このような方法の利点に「ロジックの外だし」があります。例えば、○○、△△、□□の得意先に関して特別な処理をするとき、それをプログラムで記述するならば、
　　　if （(得意先=○○) || (得意先=△△) || (得意先=□□)) { ...... }
のようなコードを、該当する多数のプログラムで記述しなければなりません。
　新しく☆☆の得意先もこれに加えようとするとき、該当プログラムをすべて確認するのは大変な作業になります。
　それに対して、得意先マスタに得意先区分というフィールドを設けて、該当する得意先のレコードのこのフィールドの値を１としておけば、プログラムは、
　　　if (得意先区分=1) { ...... }
とするだけでよいし、☆☆を追加するときは、得意先マスタを変更するだけでよく、プログラムを修正する必要がなくなります。
　販売システムでは商品や得意先があり、商品は商品系列に分類され、得意先にはいくつかの納入先があり・・・といったデータの構造は、通常の経営環境の変化にはあまり影響を受けません。このようにデータ構造に着目したシステム設計の方法をデータ中心アプローチ（ＤＯＡ：Data Oriented Approach）といいます。

オブジェクト指向アプローチ

データ中心アプローチがデータの部品化だとすれば、データだけでなく処理（メソッドという）までも部品化したのが>オブジェクト指向アプローチです。たとえば、得意先を追加するとか在庫を更新するなどの処理をオブジェクトとすることによって、プログラマはデータやメソッドの内容を知る必要がなくなります。
　また、データ中心アプローチではリレーショナルデータベース（ＲＤＢ）を対象としていました。ＲＤＢでは、たとえば乗用車とトラックを取り扱うとき、それぞれに必要なフィールドが異なるので、一つのデータベースにすると無駄が生じるし、別のデータベースに分けると、それらにまたがる処理をするのには複雑なロジックを作らなければなりません。
　それにたいしてオブジェクト指向アプローチでは、共通するフィールドやメソッドを自動車というスーパークラスで定義しておけば、乗用車やトラックのサブクラスでは、個別のものだけを定義すればよく、上記のような問題が解決されます。さらに、新規にオートバイを加える場合でも、オートバイ特有の事項だけを定義すればよいのです。

ＳＯＡ

さらに部品を大きくしたのがＳＯＡ（Service Oriented Architecture：サービス指向アーキテクチャ）です。ここでサービスとは、受注とか在庫確認など、業務として意味のある単位の機能を指します。プログラマは、これらのサービスの部品を組み合わせることだけで、販売システムのようなシステムを構築できるのです。
　しかもＳＯＡでは、個々のアプリケーションの開発言語や動作環境などを限定せず、共通のメッセージ交換インターフェースに対応していればよいという利点もあります。
　従来のＥＲＰパッケージの機能をサービスレベルに分解して、柔軟な対応ができるようにしたものだと解釈することもできます。
　なお、これらのサービスの部品を、ユーザが必要な機能だけを必要なときにオンデマンドで利用できるようにした利用形態をＳａａＳ（Software as a Service）といいます。