Becoming a Salesforce Certified Technical Architect
Tameem Bahri (著)
https://www.amazon.co.jp/dp/4621066048
https://learning.oreilly.com/library/view/becoming-a-salesforce/9781800568754/
Technical Architect資格取得に必要な知識を体系化した書籍の要約
Google翻訳なので変な日本語なのはご容赦を
目次
1章 CTAとしての旅の開始
2章 コアアーキテクチャの概念-データ-
3章 コアアーキテクチャの概念-統合と暗号化-
4章 コアアーキテクチャの概念-IDおよびアクセス管理-
5章 スケーラブルなシステムアーキテクチャの開発
6章 Salesforceでの安全なアーキテクチャの策定
7章 スケーラブルなSalesforceデータアーキテクチャの設計
8章 リーンソリューションアーキテクチャの作成
9章 統合ソリューションの構築
10章 開発ライフサイクルと展開計画
11章 ソリューションの伝達と社会化
12～15章 レビューボードのモック
付録 ヒントとコツ、そして今後の方向性
1章 CTAとしての旅の開始
概要
CTAとはどのようなものか？
レビューボードについて
CTAになるためのトレーニング方法
ポイント
テクニカルアーキテクトは現在と将来の潜在的な要件を満たすソリューションを選ぶ役割を担っている
レビューボードでは複数の図を組み合わせてプレゼンテーションを行う
プレゼンテーションで作成する図は関係者とコミュニケーションするためのツールである
詳細
Salesforce認定テクニカルアーキテクトの役割を理解する
Salesforceの経済圏は急速に成長している
アーキテクトやアーキテクト関連のスキルはこれまで以上に求められている
テクニカルアーキテクトはビジネスの課題を深く掘り下げ、特定の要件の背後にある実際のビジネス価値を明らかにするための難しい質問を行うことができる
彼らは物事の根底に到達し、現在及び将来の潜在的な要件を満たすソリューションを選択するために尽力する
また、開発チームとの会話に飛び込んでガイダンスやベストプラクティスを提示し、プロジェクト管理チームと協力してステークホルダーに対してプレゼンテーションも行う
CTAとして、Salesforceの可能性を最大化するとともに複数のテクノロジーを組み合わせて安全かつ高性能なシステムを設計することが期待されている
CTAレビューボードの構造と形式
試験の前提条件：Salesforce認定アプリケーションアーキテクト資格とSalesforce認定システムアーキテクト資格
形式：候補者は架空のシナリオを確認して3人の審査員に対してプレゼンテーションを行う
その後、審査員との質疑応答が行われる
割り当てられた時間：シナリオのレビューとソリューション準備（180分）、
シナリオプレゼンテーション（45分）、質疑応答（45分）
試験から実生活におけるCTAになるためのトレーニング方法
重要なキャリアアップに加えて、CTAで期待されているのと同じ方法で、Salesforce Platform上でセキュアで高性能な技術的ソリューションを設計する方法を学ぶ理由はいくつかある
試験に合格するために必要な活動と考えるのではなく、価値を提供し、実装リスクの少ないソリューションを作成するために、設計者が従うことが期待されるベストプラクティスと考えるべきである
必要なすべてのドメイン知識を実際に体験する最善の方法は、次の簡単な手順を実行することである
1.この本で説明している方法論を日々の活動に適用する
2.ソリューションを構成する様々な要素やテクノロジーの実践経験を得る（手を動かす）
シングルサインオンのフローがどのように機能するのかを調査するときは、読むだけでなくPlayground環境で設定してみること
3.複数のソリューションについて、各オプションの長所と短所を文書化する構造化された方法を理解しておく
利害関係者に各オプションを明確に伝えることができる
ざまなアプローチ、トレードオフ、妥協、リスクを特定し、特定のソリューションを合理的に正当化するという原則は、レビューボードでまさに期待されるものである
これらを日々の日課の一部とすることでレビューボードの準備もできていく
生成する必要があるものの種類とその理由
Salesforce Architectは、常にすべての必要な機能を満たす安全でスケーラブルなソリューションを作成し、利害関係者と効果的にコミュニケーションできるように文書化することを目指している
これはレビュー委員会の間、そして現実の実装プロジェクトに取り組む間に適用される
アーキテクチャ図は、アーキテクチャの一部である一連の概念をグラフィカルに表したものである
これらはソフトウェアアーキテクチャで頻繁に使用され、効果的に使用されると、ソリューションを文書化して伝達するための共通言語になる
レビューボードで必要となる図
アクターとライセンス図
各アクターのユースケースを特定する
ライセンス決定に役立つ
ソリューション内の各アクターの役割を明確にする
図では3つの異なるペルソナに関するアクティビティ/ユースケースと、それぞれに必要なライセンスを示している
データモデル図
ソリューションで使用されているカスタムオブジェクトと標準オブジェクトを特定する
カスタムオブジェクトにはライセンスによってアクセスできる数や種類に対する考慮事項がある
LDV（Large Data Volume）オブジェクトを識別する
LDVは問題が発生する可能性が高い場所と、データがより急速に増加する場所を特定するのに役立つ
データの共有と可視性の要件を識別する
レポートに必要なデータがどこから来ているかが分かる
統合戦略の策定に役立つ
システムランドスケープアーキテクチャ図
ランドスケープアーキテクチャに関係するすべてのシステム（AppExchange製品や外部システムなどのサードパーティを含む）を表示する
廃止予定のシステムを含める
追加または保持したい他のシステムと区別する
図はSalesforceがレガシーCRMに取って代わるランドスケープに関係するシステムを示している
統合インターフェース表
データのIN/OUT、統合パターン
統合インターフェースを表示する
統合パターンや接続の保護方法、認証方法などの情報を含める
SSO（Single Sign On）インターフェースを含める
モバイルデバイスやモバイルアプリの種類（Salesforce Mobile、ネイティブカスタムアプリ、ハイブリッドアプリ）を追加する
ロール階層
データセキュリティと可視性の戦略を説明する
少なくとも1つの支店の完全なロール階層を作成する（すべての州の支店のロール階層は不要）
パートナーのロールも記載する
アクターとライセンス図を参考にライセンスタイプの制限も考慮する
図は米国に基づく会社の階層を示している
ビジネスプロセスフロー図
特定のプロセスの対象となるユーザを伝えるのに役立つ
以下の内容を記載する
開始アクションとアクター
各段階に含まれるアクティビティ、自動・手動どちらか？
あるステップから別のステップへ、またシステム間の移動を制御するロジック
システム間で交換されたデータ
図はパートナーのオンボーディングプロセスを示している
コンテキストSSOフロー図
SSO要件の図は、対象ユーザとなるユーザエクスペリエンスの詳細を説明するのに役立つ
記載方法はシーケンス図を推奨する
以下の点を考慮する
各フローを完全に描画する方法と必要なすべての詳細を知っておくこと
SAML IDP-initiated、ディープリンクによるSAML SP-initiated、OAuth2.0/OpenId Connect Webサーバー/認証コード、
OAuth2.0/OpenId Connect ユーザーエージェント、OAuth2.0/OpenId Connect 更新トークン、
OAuth2.0/OpenId Connect JWTフロー、OAuth2.0アセットトークンフロー
これらをいつ使用するかを理解しておく
統合アーキテクチャ（Salesforceで認証する外部システムなど）やモバイルアーキテクチャ（Salesforceで認証するネイティブアプリなど）の
一部としてユースケースを含める場合、特に注意する
ソーシャルサインオンにも説明できるようにしておく
シーケンス図の各ステップで交換されるデータに関する情報を含めることを推奨する
図はSAML IDP-initiatedの処理の流れを示している