アーキテクチャ vs. デザイン

この記事は、Peter Cripps氏による、「Architecture vs. Design」を、ご本人の許可を得て翻訳したものです。*1


そう、これは古くからある厄介な問題だ!

Hugh MacLeodは、gapingvoid.comで、 オーバーラップしている関心事を表すために、ベン図を使うのを好んでいる。以下は、最近私が行っているアーキクテチャ・シンキングのクラスでの多くの討論を源とした、アーキテクチャとデザインに関する永遠の議論を扱うために、その方法を使ってみたものである。

f:id:GOLEM-XIV:20110416171934j:image

私が覚えている限り討論は以下のようなものであった。

  • 生徒:それで、アーキテクチャとデザインの違いは何なのですか?先生が言っていることは、ただ規模の問題のように聞こえますが。
  • 私:確かにアーキテクチャが詳細というよりは、主なコンポーネントについて扱うということは正しいけれど、それだけじゃない。アーキテクチャは”what”(要求)と”how”(デザイン)の架け橋なんだ。
  • 生徒:ええ、でもそれは私たちがいつも”ハイレベルなデザイン”といっているものじゃないんですか?
  • 私:そうじゃない。Grady Boochは「全てのアーキテクチャはデザインだが、全てのデザインがアーキテクチャなわけではない」と言っている。(後でこの引用をちゃんと調べたところ、Boochはさらに続けて「アーキテクチャはシステムを形作る重要なデザインの決定を表し、そこでは重要度は変更のコストによって測定される」と言っている。)私の経験上、ハイレベルなデザインは、1ページで表現された、完全なシステムのビューにすぎない。
  • 生徒:まだ何が本当に違うのか、わかりません。
  • 私:オーケー、これが私にとっての本当の違いだ(ここで、私は上のベン図をフリップチャートに描いてみせる)。システムの構造を定義するのはもちろんのこと、アーキテクチャはまたその構造の中に、”what”と”how”を包含しなければならない。ここでいう”what”は、要件(機能的なものと非機能的なもの)であり、よって、アーキテクチャはそれらしばしば矛盾する要件の論拠と、解決を含むことになる。アーキテクチャとは、”how”(デザイン)を推進(または制約)するような、アーキテクチャ上重要なそれらの要件(”what”)を扱うものである。

今、もしこの図を再び描くことがあるのであれば(そしておそらく次回はそうするであろうが)、”why”とラベルのついた、3つ目のオーバーラップする円を描いただろう。これは、なぜ私たちがそのような(アーキテクチャの)決定を行ったかの、論理的根拠をつかまえるところである。

ありがとうHugh、これは物事を説明するすっきりしたやり方だ!


(翻訳者のコメント)

アーキテクチャとデザインの違い、はっきり言って完全にしっくりきた訳ではないのですが…

ベン図にあるとおり、アーキテクチャはhow(デザイン)の部分集合なので、「アーキテクチャはデザインである」は正しい言明です。しかしながら、その逆である「デザインはアーキテクチャである」は成り立ちません。つまり、デザインでありながら、what(要件)も包含するもの、それが「アーキテクチャ」であるということなのだと思います。それを、上の記事では「howとwhatをつなぐ架け橋」と表現しています。

ほかにも、例えばここでも同じようなトピックを扱っています。この記事では、「What distinguishes architecture from other design is significance as expressed by difficulty or cost of change.」つまり、アーキテクチャをその他のデザインから区別するものは、変更の難しさやコストで表現される重要度である、と言うような説明があります。

ちなみに、Boochさんの「全てのアーキテクチャはデザインだが、全てのデザインがアーキテクチャなわけではない」は、この記事 (www.booch.comにアクセスできないため、Web Archiveのサイト)に登場するようです。

*1:原文公開日:2010年5月17日。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です