「なぜこのアーキテクチャーにするの？」。ITアーキテクトはこの問いに、明快に答えられなければならない。
実績あるアーキテクチャー（システムの基本的な構造）の“焼き直し”で要件を満たせるなら、話は早い。「よく似たxxプロジェクトで成功したから」という答えになる。ただし、そう判断を下す際は、前提条件が異なると、同じ実現手法を用いても結果が異なってくることに注意する必要がある。
既存アーキテクチャーの“焼き直し”で済まないときには、「yyやzzにまつわるトレードオフのバランスが適切に取れており、かつ将来も通用する解だから」などと答えるだろう。アーキテクチャーの決定において大事なのは、今ある要件を満たせるだけでなく、未知の要件への備えまでできていることだ。それが大切なのは、次の理由による。
「変化への構え」を盛り込む
プロジェクトマネージャー（あるいは、サブシステムごとのリーダー）は、QCD（品質、コスト、納期）のプレッシャーが高まる中で、持てるエネルギーのほぼすべてを、機能要求を満たした上でプロジェクトを完遂することに注ぐ。視線はプロジェクト完了報告書作成までの期間に向けられ、その先にどのような課題が生じるのかにまで踏み込んで考慮する余裕はなく、またそれが重要との意識も働きにくい。
一方、ITアーキテクトはシステム構造や設計方針、実装方式などを決めて、開発に関わるすべての人に理解してもらう役目を担う。と同時に、システム構築における全体の整合性や長期的な変化対応への責任を負う（図1）。従って、将来顕在化する課題を見据え、対処できるように「変化への構え」を盛り込んだ上で、適切なグランドデザインを描かなければならない。変化への構えの良しあしが、アーキテクチャーの是非を分けることになるのだ。
以下では、ITアーキテクトの行動原則を七つ示していく。いずれもが、これまで約25年にわたって、アプリとインフラ、開発と運用が隔てなく一つのシステムとなるよう手探りで設計し続けてきた筆者が、いくつもの失敗を伴う経験の末にたどり着いた経験則（筆者にとっての不変の真理）でもある。
原則1 見えにくいところを可視化
データの一貫性と鮮度の問題を議論する
利用部門（システム利用者の集合）は、直接目にする画面や帳票、および画面を通して見える業務機能に強い関心を抱く。しかし、「（業務機能についての）機能要求が満たされる」＝「（ユーザー部門が）欲している業務機能を手に入れられる」わけではないことに注意してほしい。機能要求に加えて、レスポンスよく情報を引き出せる性能要求や、安定して使える可用性要求など、いわゆる非機能要求も併せて満たされる必要がある。
ITアーキテクトは、システムの全体設計をする際に機能要求を機能要件、非機能要求を非機能要件に落とし込み、それらを両立させる必要がある。非機能要件には、機能要件と違って、直接目にしにくい面がある。そこで、見えにくいところに意図的に意識を振り向け、視覚化することがポイントになる。そうした視覚化をすることが、一つめの行動原則だ。
