システム全体像を描く
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール4／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。 前へ：Salesforceを取り巻くシステム · 次へ：組織戦略は全体像の判断である
このモジュールが答える問い： データがどこへ行くのかを示す全体像は、どう描けばよいのか？
新しいシナリオと真っ白なホワイトボードを渡されたら、私が最初に描くものの一つがシステム全体像です。美しくなくていいし、すべてのAPIも、まだデータモデルも要りません。企業全体を見たいのです。ユーザーは誰か、どのシステムが関わっているか、Salesforceはどこにあるか、何がそれを取り巻いているか、データはどこから来てどこへ行くか。そして矢印をたどりたいのです。よい全体像は箱の絵ではありません。アーキテクチャ上の判断をあらわにする方法です。
真っ白なキャンバスから始める
Section titled “真っ白なキャンバスから始める ”私はCTAの候補者にこれを練習させます。シナリオを読み、それから描き始める。頭の中で全部解けるまで待たないでください。描くことが解く助けになります。だから初日の後の宿題は、データモデルに挑戦する前に全体像を描き始めることなのです。データモデルを先に描けば、何がSalesforceに属するかをもう決めつけています。全体像を先に描けば、その判断を形づくるべきシステムが見えます。
高いところから始めて、掘り下げていきましょう。まず企業全体、それから重要なところの細部へ。
ステップ1／6：真っ白なキャンバス。ゾーンだけです。
スティーブの全体像レイアウト
Section titled “スティーブの全体像レイアウト ”システム全体像の描き方はたくさんあります。これは私のやり方にすぎません。長年かけて磨いてきたもので、全体像をすばやく組み立てる方法を見てもらうために紹介します。私はすべてのSalesforceの全体像にこれを使っていて、それは一つの文のように読めます。左の人々が中央のSalesforceにアクセスし、上のシステムを通じて信頼され、下のチャネルを通じてサービスを受け、右のバックオフィスとつながる。
左に人々。上から順に、社内ユーザー、パートナー、顧客。 まだすべてのペルソナではありません。**誰がこのアーキテクチャにたどり着こうとしているのか？**に答えられる程度で十分です。それぞれのグループは、自分が入ってくる場所を指します。社内ユーザーはSalesforceへ、パートナーはパートナーコミュニティへ、顧客は顧客コミュニティへ。システムはそれだけで存在しているのではありません。誰か、あるいは何かがそれを使おうとしているのです。
ステップ2／6：誰がこのアーキテクチャにたどり着こうとしているのか？
中央にSalesforce。 飾りのない箱が一つ。Salesforceが企業の中心だからではありません（そうではないと3つのモジュールで言ってきました）。それが、私がその周りを設計しているシステムだからです。それが錨なのです。
そのすぐ下に、接するようにコミュニティ。 パートナーコミュニティと顧客コミュニティは別々のエンドポイントなので、それぞれ自分の箱を持ちます。しかし、Salesforceにぴったり接して置きます。同じ組織の中で動いているので、たどり着くのに連携は何も要らないからです。
ステップ3／6：中央にSalesforce、そのすぐ下にコミュニティ。
上にID。 開発者が忘れがちなIDプロバイダーを一番上に置きます。社内ユーザー用に一つ、パートナー用にもう一つあるかもしれません。AppExchangeパッケージもそこに置き、右に寄せます。それらは組織とデータをやりとりするバックオフィスシステムではなく、組織に持ち込まれる機能だからです。公開Webサイトは左上に置きます。
ステップ4／6：上にID。開発者が忘れる箱です。
右に連携、その先にバックオフィス。 連携層、つまりESBやiPaaS（名前が挙がっているならMuleSoft）は、Salesforceのすぐ右にある縦長のバーです。社内システムはその後ろに置きます。ERP、財務、注文管理、従来システム、ウェアハウス。これでページは左から右へ読めます。人々、Salesforce、連携、バックオフィス。
ステップ5／6：連携、その先にバックオフィス。
下にチャネル。 顧客と直接つながるものなら何でも。メール-to-ケース、Web-to-リード、電話、メッセージング。
右下にデータの入出力。 外部のデータソース、アーカイブ、データロード。
Data 360は右側、連携層の下に。 ユーザーが接続することはなく、そのテナントは多くのバックエンドシステムに接続するので、配管と一緒に、それらの線が短くなる場所に置きます。社内システム、ウェアハウス、右下のデータのそばです。データチームはその画面を開きますが、その画面は組織の中にあります。Data 360はニアコア、つまりコア上で管理され、コアの外でホストされています（モジュール1）。Salesforceに戻る1本の線が、誰がそれを管理しているかを示します。箱をどこに置くかが、それが何をするのかを物語るべきです。
この配置のどれも神聖なものではありません。決まりごとの価値は、毎回視覚的な言語を発明し直さなくて済むことと、私の図を一度見た人なら次の図をもっと速く読めることにあります。
ステップ6／6：レイアウト全体。まだ矢印はありません。以降の全体像はすべてこの位置を保ちます。
ゾーンの中のカード
Section titled “ゾーンの中のカード ”表記はシンプルに保ちましょう。すべてのシステムはカードです。名前、役割、そしてそれがどんな種類のものかを示す小さなアイコン。ERP、データベース、IDプロバイダー、人々のグループ。いま説明した領域は、ラベル付きの薄いゾーンとして描くので、レイアウトそのものが見えます。下部の凡例が、すべてのアイコンと線の意味を示します。
箱の中に詰め込みすぎないでください。Salesforceをその部品に開いて描く（組織の中にSales CloudとService Cloudを置き、その間に矢印を引く）のは、非常に複雑な全体像のときだけです。そして、それぞれが読み手に何かを伝えるのでない限り、15種類もの図形を発明しないでください。誰かが全体像を30秒見て、アーキテクチャを理解し始められるようにしたいのです。凝っていても役に立ちません。役に立つのは明快さです。
一覧表にゼロを書き込む
Section titled “一覧表にゼロを書き込む ”ボリュームを考えるのに詳細設計を待たないでください。一晩に500件の製品を運ぶ矢印と、1日に20万件のGPSの読み取り値を運ぶ矢印は、全体像の上ではまったく同じに見えることがあります。同じ問題ではありません。ですから、矢印を1本でも描く前に、何が動くのかを数えましょう。絵の背後の一覧表を、件数から始めます。重要なデータセットごとに1行、そのボリュームとともに。ゼロは矢印の上には決して現れないかもしれませんが、大きな数に入るのがいつなのかは知っておく必要があります。1時間に数千件や数百万件、数十万件のトランザクション、さらには1秒に数十から数百件のトランザクション。
その数字が仕組みを決めます。一晩に数百件のレコードならバッチです。誰かが待っている呼び出しは、ボリュームが許すなら同期にできます。1秒に数十から数百件なら、レコードごとの呼び出しではなく、プラットフォームイベントのようなイベントが必要かもしれません。矢印は同じに見えます。何がそれを運ぶかを決めるのはボリュームです。だから、仕組みを選ぶ場所である一覧表に記録しましょう。
仕組みは矢印の向きさえ変えることがあります。1分に数件のレコードを送るなら、Salesforceは単純に外部を呼び出せます。矢印はSalesforceから始まります。はるかに多く送るなら、Salesforceは代わりにイベントバスにイベントを発行するかもしれません。外部システムがそれを購読し、取りに呼び出してくるので、今度は矢印が反対側から始まります。さらに大きく、たとえば数百万件のレコードの夜間同期なら、それはバッチ処理です。ですから、仕組みを設計し始めるときには、早めに件数を知っておきましょう。件数は矢印を描き直させることがあるからです。
ボリュームが重要になる場所は2つあり、理由も2つです。データモデルでは、大量データに目を光らせ、アーカイブを計画するために必要です。第2部で深く扱います。システム全体像では、一覧表の大きな数字が、連携パターンと仕組みの選択を決めます。モジュール6では、Steve Truckingの全体像とその一覧表に本物のゼロを書き込みます。件数が手に入ったら、矢印を描きましょう。
矢印を描く
Section titled “矢印を描く ”システムが配置できたら、それらをつなぎましょう。そこで全体像はアーキテクチャになります。箱はシステムであり、矢印は誰が接続を始めるかを示します。 矢印は接続を開くシステムから始まり、それが呼び出す相手を指します。クライアントからサーバーへ。ラベルが、何がどちらの向きに動くかを示します。
この決まりは、システム同士が話をしているシステム全体像のためのものです。データフロー図では、予想どおり矢印はデータに従います。全体像の決まりをほかの図に持ち込まないでください。混乱を増やすだけです。
矢印を加えました。どの箱も元の場所のままです。それぞれの矢印は接続を開くシステムから始まり、そのラベルが何がどちらの向きに動くかを示します。
ですから、連携層がSalesforceに製品を送り込むなら、矢印は連携層からSalesforceへ向かい、ラベルは入ってくる製品です。Salesforceが取りに外部を呼び出すなら、矢印はSalesforceから始まりますが、ラベルはやはり入ってくる製品です。同じデータでも会話が違い、その違いが、誰が認証情報を必要とし、誰が失敗を処理しなければならないかを教えてくれます。Salesforceは連携層を通じて注文を送ります。出ていく注文です。ERPの出荷情報が返ってきます。入ってくる注文ステータスです。これで、誰がそれぞれの会話を始めるのか、データがどこでSalesforceに入り、どこで出ていくか、どの流れが境界を越えるか、所有がおそらくどこにあるか、どこでさらに問う必要があるかが見えます。
そしてモジュール1を思い出してください。流れが一つしか見えないと、私は心配になります。高いレベルでは、出ていく注文の矢印は、逆向きの流れに依存しています。入ってくる顧客、入ってくる製品、価格。さらに深く見れば、帰りの道があります。受け付け、拒否、ステータス、請求書番号、キャンセル。矢印が、異を唱えるための具体的なものを与えてくれます。
すべての矢印には仕組みが必要
Section titled “すべての矢印には仕組みが必要 ”ここで全体像はPowerPointのアートではなくなります。レビューボードでは、どの矢印にも3つの問いが投げかけられ得るので、答えを持っていてほしいのです。
- どう認証するのか？ OAuth、証明書、指定ログイン情報、それとも別の何か？
- 同期か非同期か？ SalesforceはERPを待つのか、それとも発行して先に進むのか？ ビジネスはどれくらい速く結果を必要としているか？
- 仕組みは何か？ REST呼び出し、イベント、ファイル、メッセージキュー。MuleSoftを通るのか、直接か？
そして、相手側が止まっていたら何が起きるのか？ すべての矢印には仕組みが必要です。 説明できないなら、その線は飾りです。
そして「投げっぱなし」は答えではありません。たいていは「投げた後に何が起きるかを設計していない」という意味です。届いたのか？ 受け付けられたのか？ 失敗したのか？ 再試行するのか？ 詰まっていることを誰が知るのか？ 同じメッセージが2回届いたら？ そのどれも全体像には載せません。載せたら読めなくなります。しかし矢印は、そうした問いが存在することをあなたに気づかせるべきです。
どれか1本の矢印を拡大すると、そこにはクライアントとサーバーがあり、それぞれが自分の半分を所有しています。クライアントは接続を開きます。エンドポイントとポートを必要とし、まず認証サーバーからトークンを取得し、サーバーが定義するプロトコルと契約で呼び出し、待つかどうかを選びます。往復の全体が見えるのはクライアントだけなので、再試行できるのもクライアントだけです。サーバーは待ち受け、プロトコル、契約、ペイロードを定義し、入ってくるものを検証し、自分の部分だけを見ます。矢印を描くとき、私はどちらの端がどちらかをすでに知っていて、それがこれらの問いのそれぞれを誰が所有するかを教えてくれます。
1本の矢印を拡大：クライアントが扱い、サーバーが定義する。これは全体像には載りませんが、すべての矢印が持っています。
では矢印を逆向きにしましょう。ERPがSalesforceを呼び出すとき、Salesforceがサーバーです。APIを定義し、自身の認可サーバーを動かし、外部クライアントアプリケーションと連携ユーザーを通じて、呼び出し元が何をしてよいかを決めます。同じ問いで、反対の側です。
サーバーとしてのSalesforce：同じ問いで、サーバー側の半分にSalesforceが答えます。
全体像には矢印、会話はスイムレーンに
Section titled “全体像には矢印、会話はスイムレーンに ”アーキテクトがよい図を台無しにするのはここです。一つの成果物ですべてに答えさせようとするのです。全体像にAPI名、ペイロード、再試行、エラーキュー、変換、すべてのコールバックが載り、やがて誰も読めなくなります。やめましょう。全体像は大きな絵です。システムと、その間の重要な流れです。
やりとりを説明する必要があるときは、2枚目の図を描きます。ただし、すべての連携についてではありません。システムAがBに何かを送る、あるいは問い合わせて答えをもらうだけなら、ラベルの付いた矢印で十分です。スイムレーンがほしいのは、プロセスが会話になるときです。AがBを呼び出し、BがCに確認し、Cが答え、Bが何かを作ってAにコールバックし、人が承認し、別のシステムが続きを引き受ける。私の目安はこうです。やりとりが1、2回を超えるなら、その手順には独自のスイムレーンを。 全体像には矢印、会話はスイムレーンに。
そして、そこでは矢印の意味が違うことに気づいてください。全体像では、矢印は接続です。誰がそれを開き、何が動くか。スイムレーンでは、それぞれの矢印は会話の中の一つのメッセージで、順番に読みます。要求が一方へ行き、応答が反対へ返り、次のステップが続きます。
全体像には3本の矢印、スイムレーンには6つのステップ。全体像では矢印は接続であり、スイムレーンではそれぞれの矢印が、順番に並んだ一つのメッセージです。
すべての矢印をたどる
Section titled “すべての矢印をたどる ”全体像がほぼできたように見えたら、矢印を一本ずつたどりましょう。ERPからSalesforce：何が動いているのか、誰が所有しているのか、どう認証するのか、仕組みは何か、同期か非同期か、どれくらい新しくなければならないか？ そして次の矢印、さらに次の矢印。ここで抜けが現れます。「あ、パートナーが実際にそれをどう送ってくるのか、詰めていなかった」「ERPに注文は送っているけれど、拒否されたものがどう戻ってくるかは設計していない」。いいことです。本番ではなく、ホワイトボードの上で見つけたのですから。
絵の背後に一覧表を置く
Section titled “絵の背後に一覧表を置く ”絵は読みやすく保たなければならないので、詳細はその背後の一覧表に置きます。件数から始めましたね。ここでそれを仕上げましょう。重要なデータセットや流れごとに1行です。
| 列 | 知りたいこと |
|---|---|
| データセット | 顧客、製品、注文、配送、請求書 |
| 種類 | マスター、参照、トランザクション、分析、非構造化 |
| 所有者 | その意味とライフサイクルを誰が所有しているか？ |
| 記録システム | 権威あるバージョンはどこにあるか？ |
| ワークロード | 業務、分析、ストリーミング |
| ボリューム | ゼロの数 |
| 組織 | 複数あるなら、どのSalesforce組織か？ |
| 認証 | 接続はどう信頼を確立するか？ |
| 仕組みとタイミング | API、イベント、ファイル、フェデレーション。同期、非同期、バッチ |
| アプローチ | コピーするか、参照するか、フェデレーションするか？ |
これで成果物が2つになりました。全体像でアーキテクチャを見ることができ、一覧表でそれを問いただすことができます。
ED-D42の背後の一覧表。全体像の上では矢印はどれも似て見えます。それぞれを何が運ぶかを決めるのはボリュームです。
全体像は問いに答える
Section titled “全体像は問いに答える ”だから私はこの成果物が好きなのです。考える助けになるからです。「SalesforceとERPをまたいでどうレポートするのか？」モジュール3の問いです。私の図のうち、どれがこれを見事に解いてくれるか？ 全体像です。すべてがコアにあるなら標準レポート。データがERPとウェアハウスにあるなら、すぐに見えます。「この顧客の属性はどこでマスター管理すべきか？」それを使っているシステムと、すでに顧客を所有しているシステムを見ましょう。「SalesforceはすべてのGPSの読み取り値を必要とするのか？」誰が生み出し、誰が使い、ワークロードは何か？ Salesforceには現在の位置が必要で、別のプラットフォームが履歴を持つのかもしれません。全体像は答えを手渡してはくれません。問題を正しく見る視点を与えてくれるのです。
直す前に現状を描く
Section titled “直す前に現状を描く ”もう一つの規律です。既存の企業では、こうあってほしいものではなく、存在するものを描きましょう。毎週金曜日にメールで送られるスプレッドシート：描きましょう。SFTPサーバーに置かれるパートナーのCSV：描きましょう。歴史的な理由でESBを迂回している連携：描きましょう。2つのシステムの間で人がデータを打ち直している：示しましょう。記録している最中に現実をきれいにしないでください。目指す全体像を設計する前に、現在の全体像が必要です。それがモジュール6でSteve Truckingについて行うことです。
試験の先へ：AIが変えること。 全体像はエージェントの地図になりつつあります。エージェントが「荷物はどこ？」に答えるなら、全体像は、その答えがSalesforce、パートナーのシステム、テレマティクス、ERP、あるいはその組み合わせのどこから来るのかを示さなければなりません。エージェントはシステムの境界をなくしません。どのシステムが権威を持ち、そこに安全にどうたどり着くのかを知ることを、さらに重要にするのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- どのシステムとユーザーの集団が全体像に属するか、そしてその配置がその役割をどう示すか。
- どの流れがシステムの境界を越え、どの方向に動き、何が返ってくるか。
- すべての接続がどう認証し、どんな仕組みがそれを運び、それが同期か、非同期か、バッチか、フェデレーションか。
- ラベル付きの矢印で十分なのはいつで、やりとりに独自のスイムレーンが必要なのはいつか。
- 絵の背後の一覧表に何を記録するか：所有者、ワークロード、ボリューム、組織、タイミング、認証、そしてコピーか、参照か、フェデレーションか。
全体像は、アーキテクチャができあがった後に描くものではありません。アーキテクチャを見つける方法です。そして完成したと思ったら、眺めて感心しないでください。たどりましょう。まだ説明できない矢印の一本一本が、仕事がどこにあるかを教えてくれます。
さらに学ぶ
Section titled “さらに学ぶ ”- さらに読むなら：Salesforce Architectsは独自の図のガイダンス、How to Build Salesforce Diagrams (opens in a new tab)とSystem Landscape (opens in a new tab)（英語）を公開しています。CTAのレビューボードを目指すなら知っておく価値があります。