アーキテクチャリングとアーキテクト

モデリングと違った意味で、アーキテクチャリングという言葉を使うケースが増えた。モデリングって言葉は皆使うだろうけど、アーキテクチャリングって、あまり聞かない。で、たまたまある人が言っているのを聞いて、これは自分の思うイメージに近いと感じて使うようにしている。
モデリングは、どちらかというと、オブジェクトとその関係性に着目する。クラス図や概念データモデルなどがそうだけど、もちろん、それだけではなく、シーケンス図やアクティビティ図もある。だから、そういう静的な状態を示すものだけではないし、モデリングの本質は抽象化だから、特に何かにこだわる必要はない。でも、モデリングが抽象化するってことだとすると、それは対象物をいかにとらえるか、というところに特徴がある。
なので、モデリングから何かを生み出す、いや，創造していく感じではなく、あくまで捉えるところに着目している感じを受ける。
これに対して、アーキテクチャリングとは、ある目的を達成するために実施するもので、そのための構成要素と要素間を関連付けるという意味で、能動的なイメージとして捉えている。構成要素は、今あるものを明らかにするというよりも、何が必要なのかを明らかにする。最終的に出来上がったアーキテクチャは、何か目的を達成するための方針であったり、思想であったり、構造であったりする。
実際の対象を整理するものと、実際の対象を含め、何を加えるべきか、関係させるべきか、そのあたりに着目する点で、モデリングとアーキテクチャリングを使い分けている。
アーキテクチャは、構成要素とその関係性で表され、役割を個々の要素に設定する。個々の要素は、いろいろな使い方があるかもしれないが、ある文脈において果たすべき役割を定義することが必要になる。こういったアーキテクチャリングを実施していく上で重要なことは、制約を意識することだ。
モデリングでは、どちらかというと、制約を取り払うイメージがある。制約ではなく、普遍的なものを目指している気がする。（本来は、そうでないだろうけど、モデル化する上で、前提や制約を明示しながらやっているケースにあまりお目にかかったことがないからか）

さて、アーキテクチャリングによって導き出すアーキテクチャは、ある制約下で創造されるとして、それを実現（システムとして実装）するには、さらに、制約と要素が増える。時間やコスト、そして、メンテナンスビリティなどである。システムアーキテクチャを考える上で重要なのは、制約を踏まえた上でトレードオフを明らかにし、今取るべき選択肢が何なのかを考えることだ。理想的な構造や仕掛け、さらにいえば、きれいな構造といったものは、もちろん目指すべきであり、特にメンテナンスビリティや耐障害性などを考える上では、よりシンプルに保っておくことが重要なのは承知している。しかし、現実取るべきものは違ったものになる可能性がある。十分に検討をしておくことは重要で、その上で、取るべき手段は、なぜ、そうだったのかを明らかにしておく必要がある。
これを実際にできるのが、アーキテクトの役割だ。

ITスキル標準のITアーキテクトの行動様式においては、こういったアーキテクトのとるべき行動を示唆している。
特に気に入っているのが決断力と説明責任だ。
個人的には、スペシャリストとの違いはここにあると考えている。

トレードオフ要件を常に意識し、トレードオフを選択する。
苦渋の決断になるケースもある。自分の好みだけではいけない。
今向かうべきゴールに対して、今選択できる最適なもの。それをいかに導ききるか、

そのためには、知的体力と粘り強さが重要。

そして、アーキテクトになるには、アーキテクチャに詳しいだけではいけない。