プログラマの思索

Enterprise Architectureに関する記事が面白かったのでメモ。
あくまでも感想なので、ラフなメモ書き。
おかしな所があれば後で直す。

EAコラム(1)　みなさん元気にEAやってますか？ | ARIS BPM Community

EAコラム(2)　EAが巻き起こした悲劇 ① | ARIS BPM Community

EAコラム(3)　EAが巻き起こした悲劇 ② | ARIS BPM Community

EAコラム(4)　EAが巻き起こした悲劇 ③ | ARIS BPM Community

EAコラム(5)　EA来襲　その時歴史は動かなかった ① | ARIS BPM Community

EAコラム(6)　EA来襲　その時歴史は動かなかった ② | ARIS BPM Community

Enterprise Architectureと言えば、全体最適化のためのITシステム戦略のイメージだが、バズワードに近いと思う。
上記の記事にも書かれているが、複数の個別システムの全体最適と言いながら、中身は下記のドキュメントをキングファイルでまとめるだけに過ぎないと勘違いしやすい。

　・業務説明書
　・機能構成図（DMM）
　・機能情報関連図（DFD）
　・業務流れ図（WFA）
　・情報体系整理図（UMLクラス図）
　・実体関連ダイアグラム（ERD）
　・データ定義表
　・情報システム関連図
　・情報システム機能構成図
　・ネットワーク構成図
　・ソフトウエア構成図
　・ハードウエア構成図

システムの整合性やデータの整合性、システムと運用のバランスを考える所まで頭が回らず、ひたすらドキュメントを作るだけで終わってしまうのがオチなのだろう。

おそらく、EAはDOAの観点で、各システムに散らばったマスタデータを一元化し、各システムのトランザクションデータを外部接続で連携して、各システムのデータを一つのビューで分析できるような仕組みにスべきだろうと思う。

でも、サイロのようにバラバラに散在している業務システムをシステム間連携するだけでも大変なのに、目的を定めて本来の用途に使えるように開発するのは並大抵の作業ではないだろう。
おそらく、メインフレームという余りにも古いシステム、何十年も運用して蓄積された膨大な固定長データという古いデータ構造だろうから、コード変換処理という無駄な変換プログラムがたくさん作られるのだろう。

アジャイル開発が最近注目を浴びているのは、恐竜のように肥大化して身動きの取れないシステム開発よりも、哺乳類のように小回りがきいてすぐに変化に対応しやすい開発スタイルの方が、システムの価値が得られやすいからだろうと思う。
そんなことを考えると、業務システム開発をDOAの観点でアーキテクチャ設計する場合、本来のゴールは何なのか、というマネジメントの部分がクローズアップされてくるように思える。
単にアジャイル開発すれば全ての問題が解決するわけではなく、顧客やベンダー、開発者などの利害関係者の間で根回しして調整して、システムの本来の価値を考えようとする仕組みが必要になってくる。

多分、それが要求開発のこたつモデルであり、ソフトウェアプロダクトラインにおいてアーキテクトが調停者の役割を持つという意味につながるのだろうと思っている。