日経SYSTEMS 6月号のコラムは「自転車の購入で気付いた優れたアーキテクチャ」です。
IEEE-Std-1471-2000では、アーキテクチャを
「コンポーネント」、コンポーネント間および「環境」との「関係」、またその設計と進化の指針となる原理に体現された「システム」の基本「構造」である
と、定義しています。なにやら難しそうですが、ようは、部品の特性、部品の組み合わせの特性、そして、全体としての特性という3つについて考えるということです。
自転車にはシティサイクル、クロスバイク 、ロードバイク 、マウンテンバイク 、最近じゃBMXなんてのもあります。これらの自転車は、それぞれ特性があり、用途ごとに分類されます。
一方で、部品というのはフレーム、タイヤ、ハンドル、チェーンなどなど。自転車の用途が変わっても、これらの部品が必要ということは変わりません。その代り、それぞれの部品の特性は大きく変わります。たとえばタイヤでいえば、チューブラー、クリンチャー、 チューブレスといった構造によって特性が違いますし、そこにタイヤの大きさ、太さ、表面の加工、それから色なんて要素もあります。
さらに部品同士の組み合わせに特性があります。いかに個々の特性が優れていても、部品の組み合わせでバランスが取れていなければ意味がありません。
Wikipedia 自転車
Wikipedia 自転車用タイヤ
このように自転車というやつも、自転車全体としての特性だけでなく、個別部品の特性や、それら部品の組み合わせによる特性まで考えて組む必要があります。ということは、それらの特性について判断するアーキテクトがいるということになります。
では、その自転車屋のアーキテクトが優秀の条件とは何でしょうか。それは、部品に詳しいとか、自転車の知識があるといったことは前提として、「その顧客に合った自転車を選択する力」だと思います。これはIT業界でも同じです。
ITアーキテクトも，まったく同じである。ハードウエアやソフトウエア，各種パターンなど，システムの要素に関する知識があるだけでは良いアーキテクチャを設計することはできない。システムの品質は各種要素のバランスに左右されるので，セキュリティ，保守性，性能といった多くの要素を考えなくてはいけない。また，技術的に難しすぎてエンジニアが実装できない，あるいは，機能が複雑すぎてユーザーが使いこなせない，といったことであれば，アーキテクチャとしては失敗である。
ITアーキテクトにとって知識とは必要条件でしかありません（そもそも、すべてを網羅的に知るなんて不可能だし）。それよりも「顧客に必要なことを見抜き、そのパラメタを調整しつつ、まとめる力」が不可欠なのです。
