『ソフトウェアとチームの構成は一致する。4つのグループでコンパイラーを作れば4つのコンパイラーができる。』もうちょっと意訳すると「アーキテクチャは組織に依存する」という話ですね。以下の記事ではOSを例に挙げており、なるほどなぁ、と思ったり。Plan9日記3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。逆にアーキテクチャに応じて開発チームを構成すべきとも言われたりします。コンウェイの法則と企業情報システムアーキテクチャよくソフトウェア構成や開発について言及されるのですが、企業情報システムアーキテクチャにおいても同様だと思っています。いうかそういう例をクソほど見てきました。1990年台後半からERPが流行り始め、システム統合が進みました。ERPといえば「ベストプラクティスがー」とか「BPRがー」とか言われますが個人的にはどうでもよくて、アーキテクチャ観点での本質は「組織間のデータの共用化」だと思っています。本来的に企業の組織は相互に影響し合う振る舞いが必要で、これまでバッチでインターフェース連携していたのが、ERPになって、データの連携が自動化・リアルタイム化されて、また、領域をまたいでデータが見られるようになった。最近はSaasやSoEやSoRといった考え方で、部門ごとにシステムを切り出す方向にトレンドが流れている。その流れは止められないのですが、これをIT部門が弱い企業で進めると、かなりカオスになります。(というか、なっています。)システムを分ける、というものの、一度ERPで実現したシステム間の相互連携は必要で、個別システム化にあたってのポリシーがないと、ツギハギだらけの増築を繰り返したいびつな旅館みたいなシステムが出来上がります。利用言語、OS、MW、基盤の乱立、システム間連携のトポロジー複雑化、言われるがままに仕様追加してスパゲッティ化した仕様やコード、再利用なんてとんでもない。企業の場合、アーキテクチャに応じて組織を設計する、というのは難しい話。組織毎のシステム構築の流れが進む今、全体を俯瞰して計画する従来のEAを推進するような役割とアーキテクチャに対する原則やデザインルールなんかを整備できない企業は、気がついたら90年代以前の手がつけられない情報システムの状態の再来を招くことになりそうです。11:44コンウェイの法則と企業情報システムアーキテクチャTweet広告を非表示にする関連記事2018-09-08エンプラITとプロダクト開発の違い弊社内でもアジャイルだ―、とかDevOpsだーとか、何となく言う人...2015-12-312015年、転職してました。»プロフィールid:nyopSAP好きなエンジニアですがSAP以外もやります。思いついたことを適当に書きます。初日ざっくりまとめ仕事上のコミュニケーションで気をつけていること。(2)月別アーカイブはてなブログをはじめよう!nyopさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。