"ソフトウェアアーキテクチャ" は1990 年ごろまで正式に科学として研究されてこなかった。それ以来、この用語はファッショナブルなものとなり、現在ではたくさんのソフトウェア専門家が自分の名刺の肩書きにいろんな形式で "アーキテクト" と書いてはしゃいでいる。エンタープライズアーキテクト、ソリューションアーキテクト、アプリケーションアーキテクト、他にも豆粒のように転がっている。だがもっと重要なのは、ソフトウェアアーキテクチャのプラクティスが技術的に不可欠なものとなり、組織的な競争上の優位を保つために重要なイネーブラとなったことだ。

ソフトウェアアーキテクチャとはなんだろう？様々な定義がある。驚くほどではないが、私たちはこれが一番気に入っている。

システムのソフトウェアアーキテクチャとは、システムのニーズを充たすための構成物の集合であり、ソフトウェアの要素、要素間の関係性、そしてその両方を兼ね備えたものだ。

この定義は、システムの"早期に"または"主要な"設計判断をすることについて言及するその他多数の定義とは対照的だ。ほとんどのアーキテクチャ上の決定は早期に行われるが、それがすべてではない。ほとんどの決定は早期に為されるが、それはアーキテクチャに限ったことではないのだ。そして決定したことだけを見てそれが "主要" なことであるかどうかを区別するのは困難だ。だから私たちは構造や関係性や性質に注意を向けることのほうを選ぶのだ。

これはアーキテクチャが抽象化であることを意味している。アーキテクチャはソフトウェア要素とその関連性から成り立っている。私たちの定義における抽象化（構造と性質）を強調することで、アーキテクチャが特定の詳細を選び他を抑制することを明確にする。

• システムを推測するのに有用でない要素に関する情報を除外する。
• 単一要素の設計と実装の他になんの影響も無い情報を除外する。
• ソフトウェア要素の詳細を隠蔽する。詳細には内部実装が単独でやるべきことが含まれる。

私たち人間の認知能力は有限だ。つまり私たちには一度に大量の詳細を頭の中に入れておくことはできないのだ。だがシステムに物理的な限界が無いことを知っている。それは容易に複雑なものとなり、それを理解することは私たちの能力をあっさりと上回るだろう。（"理解" の意味がシステムの全ての詳細について把握することだとしたら）。したがって抽象化はアーキテクチャの複雑性を手なづけるために不可欠なのだ。私たちはもう単純に不可能だし、やりたくもないし、どんな複雑さにも対処したくないのだ！さらに抽象化に集中することで、膨大なリソースをコードへ費やす前に、かなりのリソースを計画、設計、分析に充てることができる。これは他の成熟した工学分野とまったく変わらない。例えば、土木技師は基礎を掘り、コンクリートを流しこみ、梁を組み上げる前に青写真を設計する。これはただの常識的な感性なのだ。

システムの複雑性の増加に伴い、システム・オブ・システムズは日々私たちの生活に広まっている。アーキテクチャはより中心的な役割を果たすようになってきているのだ。Software Architecture in Practice の第二版が出版されてからほぼ10年になる。その間ソフトウェアが対象とする領域や社会への影響はますます成長してきた。ソフトウェアの爆発的な成長と同時に、ソフトウェアアーキテクチャの焦点は主として内部指向、技術指向だった（複雑なソフトウェアシステムの設計、評価、ドキュメントをどうするかという問題への対処だった）のが、外部への影響を考慮するまでに広まってきた。それはあなたのビジネスと目標に影響を及ぼす。人々に、彼らが何をするのかに、どう訓練するのかに影響を及ぼしているのだ。場合によっては広範囲な技術的環境にも影響を及ぼす。そしてごくまれに社会にも巨大な影響を与える。（例えばモバイルアプリケーションやP2Pネットワーク、ソーシャルネットワーク、サービスコンピューティングはどれだけの社会に影響を与えているだろうか。）アーキテクチャはあなたの組織の目標や同僚たち、ソフトウェア開発のサイクル、プロジェクトの管理方法にまで大きな影響力を持つことができるのだ。

過去10年の間に製造されるシステムの形態は劇的に変化してきた。そしてアーキテクトが直面する懸念も同じように変化してきた。大規模データ、ソーシャルメディア、クラウドがほぼ全ての領域であり、これらは10年前は未発達だったが、現在では成熟しただけでなく非常に影響力を持っている。ソフトウェアは普遍的なものとなっている。コンピューターだけでなくスマートフォン、おもちゃ、ツール、冷蔵庫、炊飯器、車、温度計、電気カミソリなど…実際には、ソフトウェアが完全に普遍的になったわけではないが、これらのドメインのすべて（まあ、カミソリは違うだろうが）において不可欠になってきているし、ビジネスの成功にも不可欠となっている。モダンな自動車の広告を見れば、ソフトウェアによって実現された機能が過剰なまでに強調されているのが分かると思う。アンチロックブレーキ、適応型クルーズコントロール、GPS、ブルートゥース、盗難防止装置、パーキングセンサー…延々と続く。このような機能が無いシンプルな自動車には、今日の市場における競争力が無いのだ。競合に先じるためにこういった機能を提供することは、非常に大きな利点になる。ソフトウェアアーキテクチャは全ての中心である。その成果物がビジネス目標とそこから得られる成果の間を仲介するのだ。ソフトウェアは私たちの生活の中心である。ソーシャルネットワーク、電子メール、電話、インスタントメッセージは私たちを結びつける。B2B の電子データ交換はサプライチェーンを動かし続ける。信号は道路や空港、鉄道や電気供給網の操作と協調を保っている。繰り返すが、ソフトウェアアーキテクチャはあらゆるものの中心なのだ。これらのシステムはアドホックなやり方で設計されるにはあまりにも複雑すぎるし、ビジネス的に重要すぎるし、生命的に重要すぎる。

近年のアーキテクチャが果たしている役割の好例は、それが先進的なシステムの構築における中心となっていることだ。先進的なシステムはユーザの成功において必要不可欠だ。ウィキペディア、Facebook、YouTube、Craigslist、Twitter、Flickr、Pinterest について考えてみてほしい。YouTubeは一日に約10億もの動画を配信している。Twitterはユーザーのつぶやきが1日あたり50万におよぶことを誇っている。Facebookでは10億人以上のユーザーが毎月約30億ものコンテンツを提供していると言われている。Flickrは6億枚もの写真がユーザによってアップロードされたことを発表した。先進的なシステムは公開コンテンツシステムに限ったものではない。オープンソースソフトウェアには "クラウド" と全く変わらない自由な貢献というモデルがある。そして世界中で最も重要なソフトウェアに、私たちのビジネスと情報技術インフラの中核となったのだ。Linux と Apache は世界中の2/3のWebサーバとして動いている。Android OS は他のすべての OS の合計よりも多くのスマートフォンで動いている。MySQL、Eclipse、JBoss、Joomla、PHP、Firefox、FileZilla、OpenOffice、Hadoop、Wordpress、Twiki…重要なオープンソースソフトウェアのリストは長大で印象的であり、私たち個人や企業を取り巻いて動いている。

なぜこの級（クラス）のシステムに注意を払うのか？こういったシステムのアーキテクチャには、あなたが過去に構築したことなる従来型のシステムのアーキテクチャとは決定的な違いがあるからだ。ソフトウェアアーキテクチャの分野では、伝統的な建築とのアナロジーが好まれている。ソフトウェアの複雑な部分の設計には、建物の設計と多くの共通点があるのだ。対照的にこの新たな級（クラス）のシステムは "メトロポリス" システムと呼ばれる。単独の建物よりは都市のほうが似ているからだ。そこには数百万のステークホルダーがいて、継続的に変化しており、相反する要件があり、計画に権限を持つ唯一の人は存在しない。

メトロポリス級の先進的なシステムにおけるアーキテクチャ上の重要な選択は、中核と末端を区別することだ。そしてそういったシステムが失敗しないためのアーキテクチャは次のように分類される。

• 小さな一致団結したチームがコアの（もしくはカーネルの）インフラストラクチャを設計し、基本構造や品質特性、トレードオフを定義する。そうして作られたコードは大抵の場合高度にモジュール化されているし、変化しにくく頑健である。
• コアに構築された周辺機能やサービスの集合。これらは大部分の機能とエンドユーザの価値を提供するし相対的に早く変化する。そしてこれらの周辺機能は大抵の場合相互に独立している。

コア（しばしばプラットフォームと呼ばれる）は普通サービスの集合として実装される。複雑なプラットフォームには数百のコアがある。周辺機能やサービスは数千からそれ以上に及ぶだろう。（Android アプリケーションや Firefox のプラグイン、Linux のアプリケーションやドライバの数を考えてみるといい）主たるアーキテクチャ構造がなければこれらのシステムが際限なく（一見）成長することはできなかっただろう。

私たちの身近なソフトウェア開発ライフサイクル（ウォーターフォール、アジャイル、反復、プロトタイピングベース）は先進的でクラウド化された世界ではどれも崩れ去った。これらのモデルは要件を理解できるようになることを前提としているのだ。ソフトウェアが開発されテストされ、計画されたインクリメントがリリースされる。プロジェクトは有限のリソースを捧げ、マネジメントはそのリソースを "管理" することができる。どんな条件もメトロポリスでは真ではないのだ。要件はクラウドから湧き出す。ソフトウェアは絶え間なく変化し一時も安定した状態に留まることはない。プロジェクトのリソースは気まぐれにクラウドを出入りし、マネジメントは貢献者に影響を与えることはできるが管理することはできない。

アーキテクチャのテクノロジーとして近年重要性を増しており、今後数年間は主導権を握るように見えるのがクラウドベースシステムだ。クラウドは仮想マシン・仮想ネットワーク・仮想ファイルシステムを利用することで柔軟なリソース集合を提供する。クラウドベースのアーキテクチャは多くの企業にとって大規模な経済性を提供する。クラウドはある意味では新しいものではない。私たちは仮想化されたリソースとして提供された時分割コンピューティングを1960年台から使用している。だがクラウドベースのシステムはインターネットを介してユビキタスに（かつ安価に！）サービスを提供する。そして今日のソフトウェアアーキテクトのために様々なサービスモデル（SaaS、PaaS、IaaS）と配置の選択肢（プライベート・クラウド、パブリック・クラウド、ハイブリッド・クラウド、コミュニティ・クラウド）が設計に新たな選択肢を（そしてトレードオフを）もたらす。

これらの例にはポイントが二つある。1）アーキテクチャが変化し続けるならあなたは最先端のテクノロジーを追い続けてアーキテクチャの基盤とあなたの組織が離れ離れにならないようにしなければならない。2）アーキテクチャとはアーキテクチャのアーキテクチャである（ガートルード・スタイン氏には申し訳ない）。私たちは自ら矛盾しているのだろうか？クラウドのようなテクノロジーや先進的なシステムが変化ととてつもない結果をもたらす一方でそのテクノロジーの背景は 変わらない ということが言いたいのだ。素晴らしいニュースだ！アーキテクチャ設計の基本要素を理解し、あなたが作ることのできるドキュメントや計画のような成果物を分析することで、重要なスキルを習得することができる。アーキテクトでいこう！