システム分析アプローチを後輩と話した件
後輩とシステム分析アプローチについて話す機会があったので、ちょっとだけ。
システム分析アプローチ
システム開発を行う中で欠かせないのが、システムをどのように構築するのか分析するためのシステム分析アプローチです。
それぞれのイメージを書くと以下のとおり。
POA（Program Oriented Approach：プログラム指向アプローチ）
業務フローなど、対象となるシステムモデルをベースに、事務手続きなどの「プロセス」をプログラムに落としこんでシステムを構築する技法。
- 小規模のバッチを中心としたシステムではわかりやすく作りやすい強力な設計技法。
- でも、規模が大きくなるとスパゲッティなシステムとなってしまう。。。一個一個のアプリをどんなにきれいなプログラミングしても、システム全体がスパゲッティとなると破綻してしまう。。。アプリケーションの影響範囲を探るのは大変。
- SOAとかでも、サービス内部ではこの手法を利用して設計することもある
DOA（Data Oriented Approach：データ指向アプローチ）
帳票や伝票といった業務で利用する「データ」を中心に、各事務手続きをデータの更新を行う機能とみなしてシステムを設計する技法。
- POAと異なり、データは比較的変更が少ないため、業務改修に強い。特に、オンラインが必要なシステムでは役立つ
- でも、細かい改修には強いが、データ構造を変えるような変更があった場合はやっぱり改修はそれなりに必要。システム改修時の影響調査は、POAよりはるかにやりやすい。
- 中規模でもわりかしシステム構築しやすい
SOA（Service Oriented Architecture：サービス指向アーキテクチャ）
対象となる業務をいくつかの業務機能をベースとした「サービス」を中心に構築し、ユーザからのインタフェースは共通のまま、内部のサービスを複数組み合わせることでシステムを構築する技法。
- サービスの単位で外部とやりとりするアプリケーションインタフェースをもたせ、サービス内部にデータを持たせる。一種のオブジェクト指向設計。設計フォーカスが絞りやすく、影響も極小化しやすいので大規模システムでも構築しやすい。
- 業務単位に分割したサービスを構築するので、外部設計工程から設計を行わなくてはならない。内部設計からでは間に合わない。
- 従来のサブシステム分割と似ている。たまに間違える。単純なサブシステム分割と異なり、情報伝達バスの共通化など、基盤共通化をきちっとやっておかないと効率的な設計はできない。
- 設計、開発、修正と言った個々のシステム単位では構築しやすいけど、システム全体が見通しづらくなり、個別最適化しやすい。人によっては開発効率が落ちるという人も。
適当ですけど、こんな感じ。
まとめ
- システム分析アプローチの選択は、生産性に大きく影響をあたえるので十分注意が必要。小規模なシステムでSOAを使っても生産性は上がらないし、大規模システムでPOAだと保守がままならない
- 大規模システムほど保守性が命となる。複数の業務システムが必要となった段階でSOAを検討したほうが良い。
- SOAが真の意味で価値が生まれてくるのは、スクラッチ開発ではなくパッケージやSaasと組み合わせたとき。てか、スクラッチだとよっぽど規模が大きくなければあまり嬉しくない気も。「パッケージを使って標準的な業務を導入する」という思想で語られることが多いけど、「パッケージを標準パーツとして利用し安価でスピーディなシステム導入を行う」を目指すべき
とりあえず。こんな感じ。
続きを書きました
以上
