Steve Truckingの全体像

🌐 ほかに 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)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール6／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。 前へ：組織戦略は全体像の判断である · 次へ：次の章、データの品質とガバナンス

このモジュールが答える問い： 何かを設計する前に、現実の全体像は何を教えてくれるのか？

この章ではずっとカメラを引いてきました。多くのシステムの一つとしてのSalesforce、データの種類、Salesforceを取り巻くシステム、全体像の描き方、そして組織戦略。では、それをSteve Truckingでまとめましょう。ただし、まだ何も直しません。それが規律です。存在するものを描き、すべての矢印をたどり、全体像が何を教えてくれるかを見る。

わかっていることから始める

Steve Truckingは米国で一つのSalesforce組織を使っています。Service Cloudが受取人と小売パートナーからのケースを扱い、Field Serviceが予約、クルー、モバイルアプリを動かし、Experience Cloudが小売パートナーにポータルを提供し（現在はクレームとレポートにだけ使われています）、Sales Cloudがパートナーとの契約と新しい物流センターの入札を管理しています。ですからSalesforceを中央に置きます。

左には人々がいます。小売パートナーの物流センターの中で働く45人の配車コーディネーター、330台のトラックに乗る約700人のクルーメンバー、60人のカスタマーケア担当者、40人のオペレーション・財務・営業スタッフ、そして約300人の小売パートナーのユーザー。それだけでもう何かがわかります。これは一部門のCRMではありません。ビジネスの大部分のための業務プラットフォームです。それでも箱は一つです。では、何がそれを取り巻いているかを見ましょう。

Click to enlarge

今日のSteve Trucking、適切な実装の前。すべての積荷目録はRouteDeskに届き、コーディネーターがルートをSalesforceに、完了した停車地をRouteDeskに、手で再入力しています。FleetLinkは接続が欠けています。

問題に印を付ける

これは適切な実装の前の現状であり、私は図の上にそう書きます。そしてパレットを広げます。完成したシステムの全体像では赤を使いませんが、現状では使います。赤は悪い、あるいは不適切なプロセス、破線は手作業で行われていること、赤い点線は欠けている接続を示します。矢印を描かないことも、何かを語っています。どれも飾りではありません。すべての赤い線は、書かれるのを待っている要件です。

3社のパートナー、3つの連携

3社の小売パートナーはそれぞれ違う方法で積荷目録を送ってくるので、一つずつ別々に描きましょう。

Keystoneは毎日午後、2日後の配送分のCSVの積荷目録をSFTPサーバーに置き、毎晩ステータスファイルを返してほしいと言います。矢印は2本。積荷目録はファイルで入り、接続を開くのはKeystone。ステータスはファイルで出ていき、接続を開くのはRouteDesk。非同期で、タイミングの幅は広い。

RedrockはREST APIで積荷目録を送り、ステータスの更新は起きたときにWebhookで受け取りたいと言います。矢印は2本、仕組みも2つ。RedrockがAPIを通じて積荷目録を持って呼び出してきて、RouteDeskがWebhookを通じてステータスを持って外へ呼び出します。ニアリアルタイムです。

Brightwaveはサードパーティのネットワークを通じてEDIファイルを送り、EDIのステータスメッセージが返ってくることを期待しています。別の形式、別の仕組みです。

同じビジネス概念（積荷目録、配送、ステータス）に、まったく違う3つの連携。一貫していてほしいからといって、図を単純化しないでください。一貫していないのです。それが現状です。

そしてたどりましょう。Keystone：SFTPの接続はどう認証するのか、ファイルはどこに着き、何がそれを拾い、ファイル全体が処理されたことをどうやって知り、不正な行はどうなり、今夜のファイルより前の変更をKeystoneはどうやって知るのか？　Redrock：APIはどう認証するのか、どちらかが止まっていたら何が起きるのか、何をもってWebhookの成功とするのか、同じステータスが2回届いたら？　Brightwave：EDIネットワークは誰が運営していて、変換はどこで行われ、どんな受領通知が返ってくるのか？　何も設計し直してはいません。問いを発見しているのです。それが全体像の仕事です。

RouteDeskはまだそこにある

RouteDeskは、各物流センターのコーディネーターが積荷目録をルートにするために使っている、従来のデスクトップの配車・ルート作成ツールです。8年分の配送履歴を持ち、引退が予定されています。それでも描きましょう。よくある間違いは、「なくす予定の」システムを図から外すことです。いつなくすのか？　答えが18か月後だとしましょう。それなら少なくとも18か月はアーキテクチャの一部であり、その8年分の履歴、約500万件の配送は、アプリケーションが消えても消えません。そして全体像があらわにするものを見てください。RouteDeskとSalesforceはつながっていません。クルーはSalesforceのField Serviceアプリで停車地をこなしますが、ルートはRouteDeskで作られるので、コーディネーターは毎晩それをSalesforceに再入力し、さらにRouteDeskがパートナーにステータスを送れるように、完了した停車地をRouteDeskに再入力しています。1日約3,300か所の停車地を2回、手で。図の上では赤い破線です。それはまた、Redrockの「起きたときに」のWebhookが、実際には起きたときではないことも教えてくれます。今日RouteDeskは何を所有しているのか？　何がそれに依存しているのか？　どの履歴がそれより長く生き残らなければならず、それはどこにか。Salesforce、ウェアハウス、アーカイブ？　まだ答えはしません。全体像が問いをあらわにしただけです。

FleetLinkは孤島である

テレマティクスのプラットフォームであるFleetLinkは、すべてのトラックからGPSを受け取っています。1日約20万件の読み取り値、すべてのトラックから、走っている間は毎分。そして何ともつながっていません。コーディネーターは別の画面でそれを見ています。ですからFleetLinkは矢印なしで描きます。あるべきだと思うからといって、魔法の連携の線は引きません。

そしてゼロを数えましょう。1日20万件は年7,000万件を超えます。それは「GPSデータがあります」ではありません。Salesforceの体験の外にある、ゼロの多いストリーミングの源です。Salesforceは年7,000万件の読み取り値を必要とするでしょうか？　おそらく全部は必要ありません。それは後で扱う設計の問いです。

財務には独自の真実がある

財務ERPは、配送、設置、引き取りごとに各小売パートナーに請求し、クルーにインセンティブを支払っています。そして配送の件数は毎月のスプレッドシートで届きます。スプレッドシートを描きましょう。私たちはアーキテクトでもっとよい方法を知っているからといって、すっきりしたAPIの矢印に置き換えないでください。それは現在のアーキテクチャの一部です。そして描けば、問いが出てきます。誰がどのシステムからそれを作り、誰が確認し、送った後で配送が変わったらどうなり、誰の数字が勝つのか？　その答えにはお金がかかっています。

Snowflakeには毎週エクスポートが届く

Snowflakeは、毎週のエクスポートで供給されるオペレーションと財務の分析を持っています。Snowflakeが自分でそれをするわけではありません。間にある何か、つまりSalesforceの外で動くスケジュールされたエクスポートジョブが、Bulk APIを通じて取り出し、Snowflakeに読み込みます。分析の置き場所はデータの置き場所に従い、Snowflakeはすでに分析の居場所です。しかし、タイミングもまた何かを教えてくれます。「先月何が起きたか？」なら毎週のフィードで十分です。「この配送は今どこにあるか？」なら、私はSnowflakeからは始めません。同じ企業、違うワークロード、違う鮮度、違う答えです。

IDはすべての人に同じようには届かない

会社のIDプロバイダーはSalesforceの上に置きます。オフィスのスタッフはシングルサインオンを使います。しかしコーディネーターとクルーはSalesforceの認証情報でログインしています。ですから、IdPからSalesforceへの1本の信頼の線は、話の半分を隠してしまいます。本当の問いはどのユーザーがどの経路でサインインするのかであり、それは全体像に属します。

受取人の体験には穴がある

SMSとメールのプロバイダーは、RouteDeskから受取人に「配送は明日です」という汎用のメッセージを送ります。追跡リンクはありません。一方、年に約18万件のケースがあり、その約60%が「荷物はどこ？」です。同じ質問をする年およそ10万8,000件のケース。 それをFleetLinkの隣に置いてみてください。会社は自分のトラックがどこにいるかを知っています。受取人は電話をかけて尋ね続けています。そして知っているシステムは、答えているシステムとつながっていません。まだ解決策を設計する必要はありません。全体像がすでに物語を語っています。

一覧表にゼロを書き込む

では、何が動くのかを数えましょう。モジュール4と同じく、ゼロは矢印の上には書きません。絵の背後の一覧表に書き、設計するときにそこで仕組みを決めます。年に約100万件の配送、1日約3,300件、年30%で成長。1件あたり約1.6の明細。1件あたり約8回のステータス更新なので、今日で年800万件のステータス更新。年に400万〜500万枚の写真が、今はクルー自身の電話の中にあります。1日約20万件のGPSの読み取り値。年に約18万件のケース。「配送ステータス」とラベルの付いた矢印は、たまに来るメッセージではありません。箱は何が存在するかを教えてくれます。矢印は何が動くかを教えてくれます。ゼロは、あなたの前提が現実に耐えられるかどうかを教えてくれます。

Click to enlarge

Steve Truckingの全体像の背後の一覧表：ボリュームが、それが決めることになる仕組みの隣に並んでいます。

目指すアーキテクチャはまだありませんが、重要なデータがどこにあり、どんな種類で、どれくらい速く動き、システムがそれをどうやりとりしているかが、もう見えています。

試験の先へ：AIが変えること。 Steve Truckingが、受取人の「荷物はどこ？」に答えるエージェントを作るとしましょう。どのシステムに尋ねるべきでしょうか？　Salesforceは予約を知っていて、FleetLinkはトラックの位置を知っていて、パートナーの積荷目録が配送を定義しました。現在の全体像はエージェントの地図です。エージェントが安全に答えられるようになる前に、アーキテクトは、それぞれの事実についてどのシステムが権威を持ち、それがどれくらい新しいかを知っていなければなりません。エージェントを間違った源に向ければ、古いデータが自信満々の答えになります。

痛みを読む。まだ直さない

一歩下がってみましょう。3社のパートナー、3つの連携スタイル。8年分の履歴を持つ従来の配車ツールと、1日3,300か所の停車地をSalesforceに、そしてまた元に再入力するコーディネーター。1日20万件の読み取り値を持つ、つながっていないテレマティクスのプラットフォーム。毎月のスプレッドシートで配送を数える財務。1週間遅れの分析。一部のユーザーにはシングルサインオンがあり、ほかのユーザーにはない。追跡リンクがなく、配送がどこにあるかを尋ねる年10万8,000件のケース。そのすべてが年30%で成長している。

一枚の絵から、これだけのアーキテクチャが見えます。直し始めたくなります。やめましょう。まだです。現状の図を醜いままにしておくことに慣れてほしいのです。現状は醜いことがあるからです。目的は、きれいな図で誰かを感心させることではなく、現実についての共通理解です。記録しながら設計し直せば、基準を失います。後で私はこう言いたいのです。これが存在していたもの、これが解いた問題、これが変えたもの、そしてその理由。第6章で所有と識別についての判断を下し始め、チェックポイント1で第1部をまとめます。パートナーとの流れは、Integration Architectのコースで深く設計します。

ここでアーキテクトが決めること

この段階では、アーキテクトは目指すアーキテクチャを決めているのではありません。決めているのは、現状を、目指す姿を設計できるほど十分に理解しているかどうかです。

• 今日実際に存在するシステム、ユーザーの集団、データストア、外部パートナーはどれか。
• 重要な境界のそれぞれを、どのデータが、どの方向に、どれくらいの頻度で、どんな仕組みで越えているか。
• 業務、分析、ストリーミング、履歴、非構造化のデータが、今どこにあるか。
• どの流れが最も多くのボリュームを運んでいて、早めに注意を向けるべきか。
• どの抜け、手作業、つながっていないシステム、不明確な権威、一貫しないパターンが、明示的な設計上の問いになるか。

この章は一つの考えから始まりました。組織を設計する前に全体像を描く。 もしSteve Truckingのデータモデルから始めていたら、FleetLinkが1日20万件の読み取り値とともに外にあり、RouteDeskが8年分の履歴を持ち、3社のパートナーが3つの言葉を話し、財務がスプレッドシートを使い、年10万件のケースが配送はどこかと尋ねている間、私はオブジェクトとリレーションに何時間も費やしていたかもしれません。それらはオブジェクトモデルの問いではありません。企業データの問いです。醜い連携を、スプレッドシートを、引退させるはずのシステムを描きましょう。ゼロを書き留めましょう。すべての矢印をたどりましょう。そうすれば、それを変える準備ができます。

さらに学ぶ

• Steve Truckingの概要資料、セクション2〜4と、その全体像の図（英語）。