新鮮

頑張らないために頑張る

EA の功罪(3) 「順番」を定義したところは素晴らしいと思う

f:id:hiizumix:20180220123444j:plain  

先日、"EA"(Enterprise Architecture) というシステム開発方法論を述べた。そして砂上楼閣な計画が何故か実施まで進んでしまい、その結果どうなったかまでをお話した。

今回は逆に「EA の素晴らしいところ」を考えたいと思う。

f:id:hiizumix:20180220163024j:plain

え!あれだけ「EA はゴミ」って言ってて良いところがあるの?

f:id:hiizumix:20180220173410j:plain

結局、使い所次第だよね

EA を構成する 4 つのレイヤ

前回までで、こと日本企業においては組織力学が働くことから、EA がその効果を発揮するのは難しいとお話した。しかしながら、やはり信じられないくらい聡明な天才たちが考え抜いた結晶だけあって、EA の考え方には有用な部分が多数ある。そこで、Yes/No の二元論ではなく、取り入れできる点は取り入れていくスタンスが良いかと思う。

もしあなたが SE さんであれば、とりわけ知って損がないのは EA フレームワークだ。EA では最上位のフレームワークとして「企業およびシステム」を 4 つのレイヤで表現する。各レイヤの詳細な内容や具体的な成果物は書籍をみていただくなりググっていただければと思うが、端的には以下のとおりである。

  1. ビジネスアーキテクチャ(BA) : 業務目的・目標, 業務フロー
  2. データアーキテクチャ(DA) : ERD, CRUD, データディクショナリ, コード表
  3. アプリケーションアーキテクチャ(AA) : 機能要件, システム間連携
  4. テクノロジーアーキテクチャ(TA) : 非機能要件, プロダクト標準

ん?

普通の整理では?と思うかもしれないが、実はこの「順番」がとても重要なのだ。「業務とシステム」という複雑系を 4 つのレイヤでシンプルに表現し、さらにその関係性から「順番」を規定した。そこは EA の素晴らしいところだ。

EA フレームと RFP 項目の対比

順番?

そう、順番が大事なのだ。

順番の前に、一般的に RFP(提案依頼書) で提示される項目と対比してみよう。RFP では保守要件、プロジェクト要件(納期含む)、見積もり前提条件なども書かれているがそこは一旦割愛しよう。

  1. BA : N/A
  2. DA : N/A
  3. AA : 機能要件、外部IF仕様
  4. TA : 非機能要件、設計制約

ここで面白いのは RFP には BA, DA に該当する項目がないのだ。もちろん RFP 冒頭には施策目的などは記載されるし、ユースケース図があればアクタが描かれている。しかし業務ミッションや詳細業務フローや作業手順まで書かれることは極めて稀だ。また用語集はあっても、データディクショナリがでてくることもほぼ無いだろう。もしこれらが出てきているなら、それは素晴らしいお客様なので懇意にした方がいい。

これはなぜかというと、丸投げする範囲は AA, TA だからである。SIer さんに提供いただきたいのは機能と非機能であって、業務とデータはあくまでユーザ企業の領分になる。そのため敢えてユーザ企業から出すこともしなければ、SIer さんから要求することもないのが一般的だと思う。

f:id:hiizumix:20180220172150j:plain

機能要件や非機能要件がでてこなかったらやめたほうがいいよ

 

実はここに仕様変更のカラクリがある。この辺りが見えると、もしかしたら仕様変更をプロアクティブに防ぐことができるかもしれない。

ま、長くなったので別エントリでお話しようと思う。

 

おわり

図解入門よくわかる最新エンタープライズ・アーキテクチャの基本と仕組み (How‐nual Visual Guide Book)

図解入門よくわかる最新エンタープライズ・アーキテクチャの基本と仕組み (How‐nual Visual Guide Book)