大企業のソフトウェアアーキテクトが直面する重要課題の多数が、テクノロジーとしての組織と大いに関係がある。Dan Greenblogは以下の問いに答えようと、最近のブログで、ソフトウェアアーキテクチャの裏にある原則と効果的な組織構造の間の類似点を指摘している(リンク)。
ソフトウェアのような構造になっている企業はどうでしょうか。また、企業とソフトウェアの設計でどういったベストプラクティスを共有できるでしょうか。
Greenblogがこの題目に対し、状況によって変化する具体的な観点から、専門的な方向性をもってアプローチしているのは明らかで、そのため、この論文はソフトウェアアーキテクトにとって一層有用なものとなっている。Greenblogの主題文は次のとおりである。
首尾良く組織された企業は、さながら上手に構築されたソフトウェアのように、職務上の要素から構成されるモジュールのグループに分割することができ、すべてのグループには構築前に定義された、きちんと文書化された個々の役割が割り当てられており、相互に合意済みのユニバーサルなプロトコルを使ってすべてのグループがコミュニケート可能で、全グループが常に監視、維持、更新され、必要とあればリファクタリングもしくは段階的に廃止されます。
読者は一読して、自分の組織がこの説明と同じくらい明確に定義され、効率的であったならいいのに、とただただ願うだろう。しかし、この比較練習はとても役立つのである。なぜなら、大部分のソフトウェアアーキテクトが怖じ気づくような「組織管理」というトピックを取り上げて、すでにアーキテクトの手中にある多数のツールを使えば、上手な組織管理に役立つという事実を教えてくれるからである。主要点は4つあるが、Greenblogはまずモジュール性から言及する。
モジュール化は、企業あるいはソフトウェアにとっておそらく最も重要な特性でしょう。各ノード、つまりソフトウェアであればモジュール、企業であれば従業員のチームには、ソフトウェア全体あるいは企業全体を考慮した非常に明確に限定された仕事を行う任務があり、全ノードがお互い協調して働いていると、エンティティーが全体として機能するのです。
続いてGreenblogは、契約による設計（DbC）の原則と要件管理について説明する。
ソフトウェア開発でプログラマーは、特定のソフトウェア構成要素の役割を決めるために、事前条件と事後条件を書きます。こうした境界を設計時に明確に定義しておけば、まったく予定していなかった機能性を、プログラマーがこっそりコードに追加しようと試みる可能性は低くなります。組織でも同じことが当てはまります。チームの任務がはっきりと定義され、チームメンバーの技能と適切にマッチしているなら、チームはおそらく任務を上手に果たすでしょう。チームの任務に変更があれば、新しい定義の下でチームが今までどおり適切に義務を果たすことを確実にするために、審査が必要です。
そしてもちろん、メッセージングパターンも取り上げている。
コードを書き始める前に、コミュニケーション・パラダイムを綿密に計画し、アプリケーション全体を通して一貫性があれば、モジュールが追加されるたびに新規のメッセージ一式を作成するという手間を、プログラマーは省略することができます。
ここでいうコミュニケーションという概念は、モジュール間、チーム間の両方に当てはまり、モジュールやチームはおそらく常に相互作用し、相互作用には明確なAPIが必要であり、そしてより非同時性が強く、割り込み駆動型のメッセージの場合は、イベント駆動型の通知システムで処理した方がいいかもしれません。
その後Greenblogは、ソフトウェアと組織の両方をリファクタリングする必要性について、無情だが偽りのない意見を述べている。
企業であっても、ソフトウェアであっても、あらゆる生物と同じ生き残りのルール「順応か絶滅か」が適用されます。絶え間なく変化する市場において、トップに留まる唯一の方法は、沈滞を回避し、変化を受け入れることです。
大規模組織のソフトウェアアーキテクトがソリューションアーキテクチャ開発時に視野を広げ、ソフトウェア側で使用するのと同じ原則を用いることにより、組織の変化管理エンジニアリングを盛り込むことができたなら、システム全体（アプリケーションとユーザの両方）で、より高いレベルの成功を達成することができるだろう。
原文はこちらです：