【22】アーキテクチャーではトレードオフは避けられない

　ソフトウェア・アーキテクトは、すべてを手にすることはできないということがわかっていなければなりません。パフォーマンス、可用性、セキュリティ水準、抽象化の水準をすべて同時に高くすることは不可能です。ソフトウェア・アーキテクトが、クライアントや同僚に考えを伝えるために、覚えておくとよい実話があります。それは、バーサという船の話です。

1620 年代、スウェーデンとポーランドは戦争をしていました。スウェーデン王は、金のかかるこの戦争を早く終わらせるために、バーサという軍艦の建造を命じました。この船に要求されたことは、当時の他の船とはまったく異なるものでした。長さは 200 フィート（60m）以上、2 層の砲列甲板に 64 門の大砲を備え、ポーランドまで 300 中隊の兵士を運べるようにせよというのです。日程厳守、予算はギリギリでした。どこかで聞いたような話ですね。アーキテクトは、そんな船を設計したことがありませんでした。得意分野は、砲列甲板が単層のもっと小さな船だったのです。にもかかわらず、アーキテクトはそれまでの経験の延長線上でバーサを設計し、建造しました。栄えある処女航海の日、バーサは誇らしげに港に入り、祝砲を上げましたが、それから数分後に、突然海の底に沈んだのでした。

　バーサの問題は明らかでしょう。17 世紀の大きな軍艦の散らかった甲板を見たことがある人なら、特に戦闘中にそこが危険だということがわかるはずです。軍艦であるとともに輸送船でもあるような艦船を建造したのは、金をどぶに捨てるような大きな誤りでした。バーサのアーキテクトは、王の希望をすべてかなえようとして、バランスと安定性の悪い船を造ってしまったのです。

　ソフトウェア・アーキテクトは、この話から多くのことを学び、ソフトウェア・アーキテクチャーの設計に応用できるはずです。バーサのように、すべての要求を満足させようとすると、結局何もできない不安定なアーキテクチャーになります。トレードオフのよい例は、SOA（サービス指向アーキテクチャー）とポイントツーポイント接続を両立させるという要求です。そんなことをすれば、SOA アプローチによって得られたさまざまな抽象レベルをバイパスすることになり、近所のイタメシ屋でよくオーダーするあのメニューのようなアーキテクチャーになってしまいます。アーキテクチャーを設計するときに、トレードオフがどのようなものになるかを把握するためのアーキテクト用のツールがいくつかあります。特にポピュラーなのは、ATAM と CBAM の 2 つです。ATAM と CBAM の詳細は、SEI（Software Engineering Institute）のウェブサイト、http://www.sei.cmu.edu/architecture/ata_method.html と http://www.sei.cmu.edu/architecture/cbam.html で学ぶことができます。