誰が建築家を必要としますか？

免責事項：Martin Fowlerの記事は2003年に発行されました

IEEE Software Magazineで。 ネットワーク（ただしHabréを除く）には、5年前のSergey Teplyakova（ SergeyT ）からのすばらしい翻訳があります。

私は最近、廊下で明らかにイライラしている同僚、デイブ・ライスに会いました。 私の最初の質問は、「履歴書に「建築家」という項目がある候補者を無視する必要がある」という厳しい声明を引き起こしました。 この奇妙なフレーズでは、私たち自身が原則として、デイブを主要な建築家の一人として表しています。



彼の「名誉精神病」の理由は、私たちの業界の基準でも、「建築家」と「建築」という言葉の意味が非常に過大評価されているという事実でした。 多くの人にとって、「ソフトウェアアーキテクト」という用語は、最終シーン「Matrix：Reboot」の独創的で完全に制御されたイメージと完全に一致するようです。 しかし、そのようなディスプレイを非常に軽withしている企業でさえ、やはり同じように、技術的なリーダー、つまり本質的にデイブ自身のようなアーキテクトにとって重要な役割があります。

アーキテクチャとは？

「Patterns of Enterprise Application Architecture」（Addison-Wesley、2002年）という本のタイトルで自分自身を苦しめたとき、各評論家は「architecture」がタイトルに当然含まれていることに同意しました。 しかし、この言葉を定義しようとするのは困難でした。 これが私の本だったので、私はこの概念に対処する義務があると感じました。



あいまいさから逃れるための最初の衝動は、皮肉に陥ることでした。 ある意味で、私はアーキテクチャを、デザインを議論したいときに使用する言葉として定義し、デザインをより重要にしようと試みました。 （はい、同じことが建築家にも適用できます）。 しかし、よくあることですが、皮肉の爆発には真実の一滴が見られます。 Extreme ProgrammingのメーリングリストでRalph Johnsonの投稿を読んだ後、理解が得られました。 通信は非常に良かったので、ここに完全に持っていきます。



前の投稿は言った：

IEEEの定義に基づくRUPは、アーキテクチャを「環境内のシステムの最高レベルの概念」と説明しています。 （所定の時点での）ソフトウェアシステムのアーキテクチャは、各コンポーネントがさらに小さなコンポーネントとインターフェイスから組み立てられるインターフェイスを通じて相互作用する重要なコンポーネントの組織または構造です。

ジョンソンは答えた：

私は、言及されたIEEE標準のレビュアーであり、それが完全にかつ完全に偽の定義であることを証明しました。 システムに関する高レベルの概念はありません。 ユーザーには、開発者が操作するものとは異なる、システムに関する独自のビジョンがあります。 通常、ユーザーは重要なコンポーネントの構造を気にしません。 はい、おそらくアーキテクチャは、環境内のシステムに関する開発者の最高レベルのビューです。 しかし、小さな領域しか理解できない開発者については忘れましょう。 アーキテクチャは、 エキスパート開発者によるシステムの最高レベルの表現です。 特定のコンポーネントが重要な理由は何ですか？ 専門家がそう言ったので重要です。



したがって、最良の定義は次のようになります。「最も成功したソフトウェア開発プロジェクトでは、このプロジェクトに取り組んでいる最も優秀な開発者は、システム設計について同じ理解を持っています。 このような共同理解は「アーキテクチャ」と呼ばれます。 この理解には、システムがどのようにコンポーネントに分割されるか、およびこれらのコンポーネントがインターフェースを介して相互作用する方法が含まれます。 「これらのコンポーネントは通常、小さなパーツで構成されていますが、アーキテクチャには、すべての開発者がすぐに理解できるコンポーネントとインターフェースのみが含まれています。」



そのような定義は、アーキテクチャが社会的な構成要素であることが明らかになるため、より良い可能性があります（そう、ソフトウェア自体もそうですが、アーキテクチャはさらにそうです）。グループのコンセンサスの結果として重要です。



このように、アーキテクチャを定義する別の方法があります。「アーキテクチャとは、プロジェクトの初期段階で行わなければならない一連の決定です。」 また、私はこのオプションを批判し、アーキテクチャは他のどのプロジェクトよりも成功するという事実ではないという事実にもかかわらず、プロジェクトの最初からすぐに決定したいと考えています。



いずれの場合でも、2番目の定義によると、ほとんどのプロジェクトでは、プログラミング言語はアーキテクチャの一部になりますが、最初の定義によると-いいえ。



何かがアーキテクチャの一部であるかどうかは、これが開発者によって重要と見なされるかどうかに完全に依存します。 「企業」アプリケーションを作成する人々は、永続性が重要であると考えています。 アーキテクチャの概要を説明すると、すぐに3つのレベルが得られます。 「Oracleをデータベースとして使用し、独自のストレージレイヤーを作成してその中にオブジェクトを表示する」などのことを述べました。 ただし、医療用画像アプリケーションには、アーキテクチャの観点から考慮せずにOracleテクノロジーを含めることができます。 これは、ストレージの最大の難点はストレージではなく画像の処理だからです。 画像の取得と保存は、アプリケーションのごく一部によってのみ提供され、ほとんどの開発者は単にそれを無視します。



これが、アーキテクチャの記述方法を人々に説明するのを難しくしている理由です。 「ここで重要なことを教えてください。」 アーキテクチャは重要なものです。 それらの下でそれは意味されませんでした。

建築家の役割

そのため、建築が重要なものに関するものである場合、建築家は重要なことを重視する人（またはグループ）です。 そしてここで、「マトリックス：リローデッド」からの建築家の見方と、デイブ・ライスの人に表されているスタイルとの違いの本質に迫ります。



Arkitektus Rilaudus（Architectus Reloadus）は、すべての重要な決定を下すキャラクターです。 建築家がこれを行うのは、概念的に全体的なシステムを確保するために統一されたビューが必要であり、おそらく建築家がそのような決定を下すのに十分な資格があるチームメンバーを考慮していないためです 多くの場合、そのような決定は、他のすべての人が従うことができる計画を持つように、最も早い段階で行わなければなりません。



Arkitektus Orizus（Architectus Oryzus）は別の獣です（推測できない場合は、 archives.nd.edu/latgramm.htmを試してください）。 このタイプのアーキテクトは、プロジェクトで起こっていることに非常に注意を払い、重要な問題を探し、深刻な問題になる前に解決する必要があります。 この種の建築家を観察すると、彼の作品の最も顕著な部分は集中的な協力であることがわかります。 午前中、そのようなアーキテクトは開発者とプログラムを組んで、最も一般的な「ロック」コードを探します。 午後、このアーキテクトは要件定義会議に参加し、要件開発者に、開発コストなどの非技術的な概念を通じて、アイデアのいくつかの技術的な意味を説明するのに役立ちます。



多くの点で、Arkitektus Orizusの最も重要な職業は、チームを指導し、より複雑な問題を解決できるレベルに上げることです。 チームの能力を向上させると、建築家は単独のリーダーの立場からよりもはるかに強力なレバレッジを得ることができ、プロジェクトの建築コルクになる危険を回避するのに役立ちます。 これにより経験則が得られます。アーキテクトの価値は、彼または彼女が下す決定の数に反比例します。



ThoughtWorksの最近のリトリートで、建築家と同僚の何人かと話しました。 Arkitektus Orizusaを念頭に置いて、ポジションの性質についてすぐに共通の意見になったのは面白いように思えましたが、彼の名前を選ぶことはすでに容易ではありませんでした。 Arkitektus Rilaudusは、私たちにとって「建築家」として分類するにはあまりにも馴染みがあり、さらに、不正確なメタファーに基づいています（ こちらを参照）。 マイク・ツー（マイク・ツー）は、私が偶然聞いた人たちの最高の名前を提案しました：登山の意味での指揮者 。 指揮者は経験豊富で熟練したチームのメンバーであり、グループの他のメンバーに自分で危険に対処するように教え、同時に特に難しい場合には常にそこにいます。

ソフトウェアアーキテクチャを取り除く

私は挑発的な見出しを書くのが好きです。この場合のように、最高のものには重要な意味が含まれていますが、必ずしも明白ではありません。 ジョンソンの2番目の定義を思い出してください。「アーキテクチャは、プロジェクトの初期段階でエラーなしに行いたい意思決定です。」 なぜ人々は、プロジェクトの最初の段階でいくつかのポイントを解決する必要があると考えるのでしょうか？ 肝心な点は、これらの要素が明らかに複雑すぎて将来変更できないことです。 つまり 最終的に、アーキテクチャの定義を「人々が将来変更するのが難しいと感じる要素」と言い換えることができます。



たとえば、企業アプリケーションの構築では、データベーススキーマを最初から決定する必要があると考えられています。 特にアプリケーションが既に使用されている場合は、基本スキームを変更するのは本当に難しいからです。 私たちのプロジェクトの1つで、データベース管理者Pramod Sadalageが、問題なくスキームを変更（およびデータを転送）できるシステムを思い付きました（こちらと翻訳をご覧ください）。 これを行った後、彼はアーキテクチャー要素の放出のためにデータベーススキーマを除外しました。 このソリューションは、変化にうまく対応できるので素晴らしいと思います。



エコノミストのエンリコ・ザニノットは、 XP2002カンファレンスでのスピーチで、製造とソフトウェア開発におけるアジャイルのアイデアの背後にある主要なアイデアを発表しました。 私が特に興味深いと思った1つのポイントは、 不可逆性が複雑さをもたらす主要な要因の1つであるという彼のコメントでした。 彼は、業界およびソフトウェア開発業界のアジャイル手法を、混乱を招く他の前提を取り除くこととは対照的に、不可逆性に対処する方法を模索するパラダイムシフトであると考えました。 アーキテクトの主なタスクの1つは、アーキテクチャを取り除くこと、ソフトウェアデザインの不可逆性を防ぐ方法を見つけることだと思います。



そして再び、ジョンソンに戻って、今度は私の手紙に答えます。

建築アーキテクチャとソフトウェアアーキテクチャの違いの1つは、多くの建築決定を変更するのが非常に難しいことです。 まだ可能ですが、最初に戻って地下室を変更することは困難です。



ソフトウェアで変更するのが難しいものを考慮する理論的に正当な理由はありません。 ソフトウェアのいずれか1つの側面を選択した場合、変更は簡単ですが、難点は、すぐにすべてを簡単に修正できるようにする方法がわからないことです。 簡単に変更可能なものを作成しようとすると、システム全体が少し複雑になり、 すべてを変更可能にしようとすると、システム全体が非常に複雑になるという事実につながります。 混乱は、ソフトウェアの変更を複雑にするものです。 これは複製です。



アスペクト指向プログラミングに関する私の発言のポイントは、プログラムの側面を強調するかなり良い方法をすでに持っているが、それを使用していないということです。 本当の問題は、側面を強調するための最良の技術によって解決されるとは思いません。 どの側面を特定すべきか、それらを個別に検討する価値がある場合、そうでない場合はわかりません。



ソフトウェアは、同じ建物のような世界の物理法則に限定されません。 想像力、デザイン、組織によって制限されます。 つまり、世界の特性ではなく、人間の特性によって制限されます。 「私たちは敵に会い、彼は私たちであることが判明しました。」

ThoughtWorksの主任研究員、マーティン・ファウラー