SIerにおける多層アーキテクチャパターンの一考察

ソフトウェアアーキテクチャやシステムアーキテクチャにパターンがあるように、SIerの~~多重下請構造~~多層アーキテクチャにもパターンがあると考えられます。本稿では、プログラマ35歳定年説等を考察するにあたって基礎となるパターンを提案します。

筆者が提案するパターンの一つを下図に示します。

お客様サイド: スポンサーです。お客様サイドは業態によりアーキテクチャが大きく異なり、しばしば仲間割れがあったり、下位レイヤをバラバラに統制することもあります。
営業: ユースケースの起点となるレイヤです*1。トランザクションの開始や終了に重要な役割を果たしますが、意外と社内政治力を持ち合わせていないこともあります。ただの見積屋にならないよう注意が必要です。
アプリ屋: 本アーキテクチャを構成する最大勢力です。といっても本レイヤにロジックはほとんど含まれていないため、下位レイヤへの~~丸投げ~~委譲によりトランザクションを実行します。世間ではスーツと呼ばれています。
インフラ屋: 堅牢なアーキテクチャを実現する要となるレイヤですが、一方でしばしばリファクタリングを阻害する要因にもなります。特に~~頭の固い~~deprecatedなメソッドが多用されている場合はコストが大きく膨れあがります。
ソリューション屋: 様々なユーティリティ群から構成されます。上位レイヤとの関係は多岐に渡ります。世の中のテクノロジに触れる機会が多いため脱藩しやすいと考えられますが、一方でただの~~代理店~~プロキシになっていることも多いので注意が必要です。
火消し: 必要な時に生成されるワーカーです。ガベージコレクタにより回収され、別の案件に手配されます。優秀な人材が埋もれてしまう危険性があります。
n次請け: 上位レイヤからのトランザクションを受け付けて処理します。レイヤ間のインタフェースは暗黙に定義されていることがほとんどで、しばしば~~無茶ぶり~~適切な例外処理が必要となります。