Salesforce のアーキテクトが絵を見た時に考えていること

何を考えてるのか的な話と考慮点については過去にまとめているので、考え方自体はこの辺を参考にしてみてください。

では、実際に頭の中で何をやっているのか、絵を見た瞬間に何をしているのかを説明します。

システム構成図には、よくこういった抽象画が描かれます。

わたしも担当する相手が業務部門だったり、上位の CxO などにはこういった図をよく出します。あまり細かい絵をかいた所で仕方ないですからね。

ただ、アーキテクトとしてこの繋がりの実現可能性はきちんと検証済みであることは必須事項です。当然です。

なので、お客さまからの要求事項だろうが、営業の理想図だろうが、これを見た時に必要最低限の具象化から考え始めます。写実主義的な具象画というか、Salesforce での実現可能性検証的にはキュビズムというか半具象画がちょうどいいです。何を言っているのか、書いている方がよく分かりません。伝わっているとも考えていません。

要するにこの程度の論理図です。

実際に利用される具体的な機能と、そのプロダクトが明確な構造となって、経路が判明できるレベルでの具象化を行います。そして、この図に辿り着くまでにはたくさんの確認事項があります。このレベルへ落としていくために、いろいろな問いを考えます。

ここにあることで全てとは限りません。セキュリティ要求によって、より安全な経路や接続方法などの要求もあります。例えば閉域接続の方法だったり、特定の Salesforce の組織とだけしかやり取りできないようにする方法だったり。IPアドレスでのアクセス制限ではどうにもならないことも多いですから、Salesforce の持つ mTLS (相互認証の証明書) での実装を計画することもあります。

こういった細かい積み重ねの上、ようやく抽象画が描かれています。

我々ITアーキテクトは何となく抽象画を描いているわけではなく、過去に多くの写実的な具象画のデッサンを行ってきた経験を元にして抽象画を描く能力へと昇華させてきました。なんの訓練もなく抽象画を描いている人とは違って、きちんと内部構造まで理解してデッサンしてきたからこそ、同じ一本の線だとしても、その一本で表現される線の情報量は大違いなわけです。

何故、ITアーキテクトは自信を持ってこの抽象画を提示できるのかと言えば、その背後にはきちんとデッサンされた具象画があるからこそなのです。論理図のみならず、イメージ的には物理レベルの詳細まで落とし込んでいるからこそ、なぜこの抽象画が正確なのかを説明できるわけです。

ただ、やみくもに理想的な絵を描いているわけじゃないんです。

この抽象と具象を行ったり来たりできるエンジニアが ITアーキテクトなのです。