School」を、ご本人の許可を得て翻訳したものです。*1その他の記事についても許可をいただいていますので、順次翻訳を掲載していきます。School)に触発されたので、私としては(まだ)101個も主張するものは無いけれども、ITアーキテクチャ・スクールで学ぶべきであったものとして、10個くらいは挙げてみることにする。最高のアーキテクチャは、パターンに満ちている。Boochからの言葉である。アーキテクチャにおける革新の必要性が増加している一方で、過去のものからも学ぶ必要がある。試され、テストされたパターンをアーキテクチャのベースとすることは、これを行うための1つの方法である。ITシステムを開発するプロジェクトは、技術的な理由で失敗することはめったにない。このレポートで、ITプロジェクトの失敗理由について言及されているが、そのほとんど全てが、実際の技術的な問題というよりは、人間(コミュニケーション)に関するものであった。学ぶべき点:有能なITアーキテクトはハード(技術)スキルのみならず、ソフト(対人)スキルを持たなければならない。これに関する私の考えについては、ここを参照のこと。最高のアーキテクチャ文書は、複数のビューポイントを含む。アーキテクチャを十分に記述できる、単一のビューポイントなどは存在しない。慎重なアーキテクトはこのことを認識しており、これら複数のビューポイントを組織化し、カテゴライズするためにビューポイントのフレームワークを使用する。このペーパーは、私とIBMの同僚が少し前に書いた、そのようなビューポイントのフレームワークに関するものである。Elesと執筆した書籍*2でも、この点について知ることができるだろう。全てのアーキテクチャはデザインであるが、全てのデザインがアーキテクチャであるわけではない。これもまた、Gradyからの言葉である。これは、微妙な点を含んでおり、”アーキテクチャとは何か”、”デザインとは何か”という、争点の多い問題をほのめかす。ポイントは、デザインに関するベスト・プラクティス(関心事の分離や、契約によるデザイン、明確なコンポーネントの責務の特定など)は、開発対象のシステムの全体像を推進する重要な要素へ、どうアーキテクチャが焦点を当てるのかという点では、よいアーキテクチャに関するプラクティスでもあるということである。更なる議論については、は、ここを参照。システム・コンテキスト図が存在しないプロジェクトは失敗する運命にある。非常に単純にいうと、システムコンテキストは、開発対象となる1つのシステム(または複数のシステム)の境界を定め、何がスコープ内であり、何がスコープ外であるかを示す。初期にこれをやっておかなければ、後になって膨大な時間をこの議論に費やすことになるだろう。システムコンテキストを早いうちに描き、承認をもらい、少なくともA2サイズの紙に印刷してよく見えるところに貼っておくこと。これに関する更なる議論は、ここを参照。複合(Complex)システムは複雑(complicated)かもしれないが、複雑なシステムは必ずしも複合システムではない。このトピックに関する更なる議論については、この記事を参照。システムを構築するためにはアーキテクチャの青写真を使い、システムに関するコミュニケーションには、アーキテクチャのスケッチ(drawings)を使用する。青写真は、それがどうあるべきかの公式な仕様である。作成する際には、UMLやArchimateなどの正式のモデリング言語を使用するのが最適である。これと同様に、我々はアーキテクチャについて、全くITの知識がない、またはかろうじてITのことがわかる人々(そしてしばしば財布を持っている人)とコミュニケーションを行う必要がある。そのようなコミュニケーションには、モデリングツールではなく、描画ツールによるスケッチを使うのがよい。各々の違いと、いつ使うかについて知っておくことは有用である。プロセスをプロジェクトに適用させること。Life-Cycle)を持つことには全く賛成である。それをプロジェクトで使用する際に最初にすることは、自分自身の目的に合うようにカスタマイズすることである。ソフトウェア開発においても、紳士服と同様に、”これ1つで全てのサイズにフィットする”というものは存在しない。販売するイギリスの小売事業者)で、あなたに完全にフィットするようなスーツを見つけることができないように。同様に、あなたのプロジェクトに完全にフィットするような標準仕様のSDLCを手に入れることはできない。フィットするように、必ずカスタマイズすること。成功とは失敗より多くの問題を生み出すものである。Surplus”からである。このトピックに関するClayのプレゼンテーションは、TEDのこのリンクで見ることができる。ここでも、組織がなぜ成功からより失敗から学ばなければならないかを見ることができる。ここでのポイントは、あなたはいくらでも問題を分析しつづけることができるけれど、そんなことをしていたら、あなたがすべてを把握できたと思うまで、前に進むことができないだろう、ということである。あなたはどんな時でも、予想もしていなかったような問題を見つけるだろうから。最初のうちは、事前の分析を徹底的には行わないことによって、多くの問題に対処することになるかもしれない。長い目で見ると、そのようなやり方は、より良い状態へと到達することとなるだろう。早期に出荷し、実際のユーザー体験から恩恵を受けることは、必然的に多くの問題を持つことを意味するだろう。完全なソリューションを作り上げようとするが、何も出荷できなくなってしまうというリスクを冒すよりも、より多くのことを学べる。アーキテクチャのプレゼン方法を知ることは、それを作る方法を知ることと同じくらい大切である。これは最後の項目であるが、多分あなたが学ぶであろうことで一番重要かもしれない。適切なステークホルダーをターゲットとした、アーキテクチャを記述する良いプレゼンテーションを作ることは、アーキテクチャそのものと同じくらい重要である。更なる議論については、ここを参照。*1:原文公開日:2010年8月27日。*2:日本語版は、「システムアーキテクチャ構築の実践手法」として出版されている。コメントをキャンセルメールアドレスが公開されることはありません。ThemeHall.。