「アーキテクト」と聞くとなんだかハードルが高いコトの様に聞こえる方もいらっしゃるかもしれません。
しかし気付かないうちに関わっていたりすることもあります。
例えば、
　

• どの言語にしようか
• サーバの構成はどうしようか
• ミドルウェアはどうしようか
• ログはどうしようか

　
など、部分部分でのアーキテクチャ選定としてのかかわりです。
ではアーキテクチャの選定に関わる方々皆様が「アーキテクト」なのでしょうか？
私は違うと考えています。
「アーキテクチャの選定に関わる」ことに加えて、「全体像を把握」し、「その選定に責任を持つ」役割が「アーキテクト」なのだと考えているからです

ひとつひとつの要件に対して答えることができるアーキテクチャ選定ができたとしましょう。
しかしそれで問題は無いのでしょうか？
もしかして個別最適な構成になっていく可能性があります。
　
個別最適をしすぎるあまりに1要件として縦軸でのレベルは高くとも、横串で横軸で見た時にレベル感の違いや個別要件のつなぎの部分に隙間が空いていたりして隙間が生まれる(ポテンヒットになっていたりする)ことはないでしょうか？
また、横軸で見るからこそ生まれてくる最適化もあると感じることがあったりします。
そこで目的を見失うことなく。また、全体的にバランスの取れた構成を考えられる視点も必要となります。
個別個別で素敵な絵を描けたとしても、全体的にまとまりがない状態では「ピカソの絵」の様になってしまいイビツな構成になってしまう可能性があったりします。
そうならないためにもアーキテクトには「バランス感覚」も求められることの一つになり得るのではないでしょうか。
　
顧客からの要件が「実現したいことの点」だったりします。
それらの点と点を結んで一つの線にしていく。
そしてその線を結んでいくことで大きなカタチを形成するのだと思います。
アーキテクトはその「点」を見ながらも「大きなカタチ」を意識して、いびつな構成にならない様注意を払いながら選定する必要があります。

そのシステムは作って終わりではありません。
作った先にお客様が業務を行い、我々が保守・運用を行い。新たな機能を実装し。など未来があります。
　
仮に、今流行りの技術があるとします。
エンジニアとしては取り入れたいと思うかもしれません。
しかし「流行っているから」という理由だけでは選定理由にはなりません。
　

• 誰がメンテナンスをするのか
• 他に同様のことを実現するアーキテクチャは存在するのか？(もしも存在しているがまだ流行っていないだけならば、そちらを選定する可能性は無いのか
• 流行っているか特殊な実装をしすぎているために、切り捨てることはできるのか(運命を共にする覚悟はあるか)

　
など検討事項は多岐に渡ると思います。
　
そのシステムや選定したアーキテクチャにどのような未来があるのか。それも考えて行く必要があると思います。
流行っていない枯れた技術だった場合、あとどれくらい延命するのかも検討の一部になり得ると思います。

タイトルにしました【「点と点を線にする」全体像を考えてのアーキテクト】についてイメージいただけたでしょうか？
簡単にまとめると
　

• 顧客からの要求にこたえるための「構成要素のひとつひとつ」が「アーキテクチャ」
• 「アーキテクチャ」を選定することが「アーキテクト」のミッション
• 選定したアーキテクチャに対し責任を持つ
• アーキテクチャを選ぶ際にはいろいろな観点が必要
• 点の意識
• 線の意識
• 全体の意識
• 選定したアーキテクチャの未来やシステムの未来を意識

　
ビジネスロジックとして作りこんでしまってもかまいませんが、作りこむ工数以上にテスト工数がかかってきたりするなど、機能的にはいくつも手段がある中でその方法を選択するが故に膨らんでしまう工数があったりもします。
やはりできる限り工数は押さえておきたいところですので、そうならないようなアーキテクト選定やそれをメンバに伝える義務があったりするのだと思います。