えー、やっぱり僕には回数とか流れを考えるのは無理です（ｗ。言葉にすることが重要だと思うので、感じるままに書いてみますね。
アーキテクトの発想では、システムはどう捉えるべきでしょうか？僕が感じるのは環境と呼べるような存在です。
「右に行ってください」
ある人に右に行って欲しいとします。どうすべきか。
まず思いつくのは「右に行ってください」とお願いすること。
悪くない方法です。しかし、その右とはどの方向なのでしょうか？あるいは、たまたま聞き取りにくかったら？その人に起因する要素によって動きは大きく変化してくるでしょう。特に、その行為が本人にとって意識的にせよ、無意識的にせよ苦痛を伴う場合には問題が大きくなるはずです。
右に行けるようにする
では、ITアーキテクトはいかに考えるべきか。
それは、右にしかいけないように壁を作り「道なりに進んでください」とお願いすること。
言い換えれば"右に行けるようにする"。これが環境によって主体を操作することです。あとはコストバランスと確実性、そしてアイデアのクールさにおいて実現方法が変わってくるだけです。
たとえば、床にテープを貼って「この線の通りに進んでください」とお願いするのもよいでしょう。既に存在する環境にアダプトするのであれば矢印を書いた紙を貼り「矢印の通りに進んでください」とお願いすればよい。
モノを作るのは仕事の一端に過ぎない
近視眼的にはITアーキテクトは壁やテープといったモノの設計をしているようにしか見えないかもしれません。しかし、それが本質的な作業ではありません。
ITアーキテクトが作るものには、必ず「人が使う」という視点があります。使われて何ぼ、使われているという行為そのものがITアーキテクトがみるべきゴールであり、システムの実体なのです。
クラスとインスタンスの関係
動いているときが重要である、という点においてクラスとインスタンスの関係にも似ています。われわれが作るのは静的なクラスです。しかし、我々がまさにオブジェクトとして、そのクラスの実体として感じるのは動的なインスタンスです。
そして、そのクラスの役割を考えるというのは、「インスタンスとして他者からの呼び出しに対していかに振舞うのか」ということなのです。
ですから、クラスとインスタンスの概念を理解できるかがITアーキテクト的発想ができるかの1つの分かれ目です（オブジェクト指向プログラミングの理解と、ほぼ同意です）。クラスにコードを設計書通りに書いているだけでは絶対にプログラミングは上達しません。コードによって、ありありとインスタンスが動く様子が想像できなくてはならないのです。
ITアーキテクトの発想
まとめるとITアーキテクトの発想は以下のようになるはずです。
１．主体となる対象を、いかに環境によって誘導するか
２．その環境の現実的な実現手段とは何か
実は2というのは、1がうまく定義できれば自然にわかるものです。先ほどの例であれば、１の時点で以下のような発想が可能です。
A：「右に向かう道を作り、進むようにお願いする」
B：「右に誘導するアイテムを置いて、進むようにお願いする」
もう、この時点でAとBの実現手段は大きく異なるはずです。Aは壁やロープなどによって囲うことによって実現し、Bは矢印や床のガイドテープのようなもので実現するでしょう（他にもいっぱいありますね）。
もちろん、どちらが良いかというのは一概に言えません。これは状況によって変わってくるものだからです。Aは確実ですがコストがかかり、Bは危険性はありますがコストが安くすみますのではないでしょうか。一方で、ロープや矢印という手段は非常にアダプティブです。
設計はITアーキテクトの仕事の半分にしか過ぎません。なんのために設計すべきか、という点までを包括してこそITアーキテクトといえるのです。
