最近、ある方から「ITアーキテクトの視点ってなんですかね？」と質問を受けました。ITアーキテクトが技術、プロダクトやアーキテクチャ・パターンを選択する際に何を見ているのかと。
残念ながら視点はうまく答えられなかったのですが、僕の考えるプロセスを整理してみました。それが1.目的（問題）の設定、2.全体の俯瞰、3.技術の選択という順番です。
アーキテクチャが解決すべき問題
プロセスの話に入る前に前提から。僕が相手にしているのはいわゆる「業務システム」です。この業務システムにおいて、アーキテクチャが解決すべき問題はシステムのスケーラビリティ、スタビリティ、メンテナンスビリティの3つです。
実際に動くロジックそのものというのはアーキテクチャではありません。アーキテクチャは、ロジックが"利用頻度に対して十分な早さを持ち"つつ、"セキュアで安定的に動き"ながら、かつ"複雑さを抑えて変化に対応できる"ようにしてあげるものです。
ですからITアーキテクトの仕事というのはアーキテクチャを構築を通じてロジックを支えることだともいえます。
1.目的（問題）の設定
まずは、達成すべき目的（解決すべき目的）を設定するところからです。先に言えば、これさえできればITアーキテクトの仕事の半分は終わっています。
目的を見つけるのに必要なのは「外圧の発見」です。そのシステムの外部（ユーザーやビジネス環境や技術動向など）から、どんな影響を受けているのでしょうか。
例えば「より良いシステム」という課題があったとして、外的要素から判断してパフォーマンスの向上が最も効果が高いという定義が行われ、そして、「ユーザーレスポンスの30%スピードアップ」という目的が設定されるわけです。
2.全体の俯瞰
さて、目的が決まれば、あとはそれに対応する方法を考えます。そのためにはアーキテクチャ全体を俯瞰して選択肢を洗い出します。
パフォーマンスの問題に対応する方法はネットワーク、ハード、ミドルウェア（OS、Webサーバ、アプリサーバ、DBMS）、ロジックなど、様々なポイントに存在しえます。まずは、広い目でその可能性を見つけるのです。たぶん、それぞれの部位で、それぞれのプロダクトが解を持っていることに気づきます。
あとは情報の流れを追いながら解決すべきポイントを明確にします。ユーザーレスポンスとなると、かなり幅広い部位で対応が可能です。情報のボトルネックがないのか、あるいは集中を軽減することができないのかといったポイントで探します。
すると「HTMLファイルをWebサーバのあたりでキャッシュすればよい」という手段が見出せます。
3.技術の選択
ここまでくればゴールは目前。「Webサーバ+キャッシュ」とかでGoogleするか雑誌を漁るだけです。いくつかのプロダクトが見つかるはずなので性能や運用性を勉強して判断をします。
選択は必ずバランスの問題です。投資対効果や運用性をアプリケーション・ライフサイクルの視点から考えて判断することになります。
ここまで考えれあれば、いつ誰に聞かれてもちゃんと答えることができます。選択が間違っているとすれば、それは「何かを知らなかったから」であるだけです。知らない可能性が怖ければ、もっと知っていそうな人に聞けばいい。それでも選択が間違ったらしかたありません。そういう場合に備えたリスクも考えて選択をしてあれば、何も問題はないのです。
こうしたプロセスは個人的には当たり前だと思っています。ITアーキテクトが何をみているかって別に当たり前のことを見ている気がしました。
