SIはデータ中心アプローチ (DOA)を行うことが多いです。正確にはデータ駆動開発（Database Driven Development）が多いです。データ中心アプローチ (DOA)とは、すべてのビジネスロジックがデータベースに融合していることを指します。
Springなどが多くつかわれますが、実際にJavaでは何もしません。ただコントローラを作成し、サービスインターフェイスとサービスの実装物を接続し、DAOを呼び出してXMLにクエリを作成します。複雑なビジネスロジックはプロシージャに書き込みます。
そのため、SIを長く経験しているひと昔前のSEは、プログラム設計の必要性をあまり理解していない方も多いです。（設計書はいらないよというおじさん開発者）データ構造図やE-Rモデルのドキュメントを読んでDBスキーマに合わせてCRUD演算するだけですからね。
このようなデータベース中心のプログラミングを行う理由は、ユーザーの要件が頻繁に変わるからです。要件が変わらないプロジェクトだとしても、昔の頻繁に行われる要件変更を経験したので、このようなスタイルの開発に慣れているからです。
もう少し具体的な話をします。要件が変更されたら高い確率でDBスキーマを変更する必要があります。カラム追加ぐらいで済めばいいですが、外部キー (Foreign Key)で関連付けられた関係 (Relation)を変更が必要な場合、または関係性がないデータを強制的に関連付けする必要がある場合もあります。逆に、関連付けされているデータの関係を切らないといけない場合もあります。ですから、DBスキーマの変更は必須になります。
もし、ビジネスロジックがJavaのソースコードで実現されている場合は、要件が変わる度に、ソースコードも変更しないといけません。DBテーブルと1：1にマッピングされるValue Object（V.O）がある場合は、テーブル構造が変更されるたびにV.Oも変更する必要があります。
修正そのものは難しくなくても、SI業界ではJavaコードが変更されてしまうと、ビルドしてリリースするまでかなり面倒です。
さらにGitのようなバージョン管理システムがなかった時代から開発された方々は、ソースコードのマージ作業を嫌う人もいます。そういう方はソースの修正は極力避けたがります。
時間もないし、変更要素は多い場合は徹夜を避けるために、開発者は「何でも格納できるオブジェクト」を活用します。代表的なものはMapとListです。コントローラから要求を受ける時からサービス、DAO を経て実際のクエリが実行されるまで一貫してMapを使用し、値を返すときは一貫してListタイプで返されるようにプログラムを作成すれば、クエリの変更にプログラムが影響を最小限にで受ける形で開発できます。
さらに、Javaコードで何も処理せずに要求をそのままデータベースに送信し、データベースから受信した応答をそのままViewに送信できる場合は、さらに変更に強いプログラムを作成できるようになります。そうなると開発者はSQLクエリを変更するだけです。
さらに、すべてのビジネスロジックをストアドプロシージャに作成します。表面的な理由はパフォーマンスが悪化しにくいことや、アーキテクチャがシンプルになることですが、本音はJavaコードを一行も書かなくても良いということです。こういった理由で、SI業界ではデータ中心アプローチ (DOA)がおおいです。
