Salesforce のアーキテクトは何を考えて構成を考えているか
Salesforce の Pre-sales で (ほぼ唯一の) Technical Architect しょっさんです(ｴｯﾍﾝ
本日 12/23 は、Perfume かしゆかの誕生日です。また Salesforce Advent Calendar の 23日目でもあります。ともかく。ゆかちゃん、誕生日おめでとう。今度の週末は逢えるね 🥰
さて。そんな Certified Principal, Technical Architect のしょっさんが、Salesforce の各種プロダクトと既存のシステムを組み合わせてシステム構成を考える時、一体、何に気をつけて実現可能性の高いアーキテクチャを検討しているか。なかなかそんなところに着目していないだろう、Salesforce の資格と併せて説明します。資格を取る時の参考にしてください。
なお、しょっさんは、アプリケーションアーキテクトとシステムアーキテクトの資格を持っています。したがって、Salesforce アーキテクト資格の最高峰であるテクニカルアーキテクトの受験資格を持っています。受ける気はありません。
さて。具体的な紹介にあたりカテゴリを紹介します。今回はTOGAF に代表される Enterprise Architecture のフレームワークと合わせてカテゴライズしました。
わたしの役割は Technical Architect なので、ビジネスアーキテクチャが完成したところからの検討が主です。できなくもないだろうけど、特定のビジネスドメインしか担当できないので、そこはビジネスが得意な人に任せています。
ビジネスアーキテクチャが何なのかよく分からんって場合には、実装したいシステムや企業規模でビジネス要件が定まってる、程度の理解で今日は許します。ゆかちゃんの誕生日なので。
技術的要素でのカテゴリは、データ、アプリケーション、テクノロジの3つがあります。TOGAF では、データアーキテクチャ、のように「アーキテクチャ」を含めて分類しています。本来はアーキテクチャの要素を含めて検討が必要ですが、今回は「実現可能性の高いシステム構成の考え方」であってアーキテクチャ成分はほぼ含まれていないので、「アーキテクチャ」を外して分類軸としました。
それぞれのカテゴリで、わたしが特に気をつけているポイントについて紹介します。これで全てではありませんが、これで大抵どうにかなります。多分。
データ
まずはじめに。対象のデータは Salesforce で保管すべきかどうかから考えます。
以前は Sales/Service Cloud の稼働する Platform しかなかったので、考慮事項は Salesforce へ入れる・入れないで済んでいたものです。今では、Marketing Cloud 系の Engagement から EC サイトを実現する B2C Commerce、そして何よりも Data Cloud があります。データをどこに配置すべきか、の考慮が重要なキーポイントです。
アーキテクトとして Salesforce の各プロダクトへ保管すべきデータを理解しておくべきです。例えば、マーケティングに必要なデータは Engagement に入るべきですし、EC の商品カタログは Commerce です。そして CRM に必要な顧客情報は Sales/Service の稼働する Platform になければなりません。ただし、その顧客情報および、まつわるデータは Data Cloud へ配置するケースもあるでしょう。各プロダクトで必要なデータや配置すべきデータについて、プロダクトの特性と合わせて、きちんと理解すべきです。
次に、データの流れです。
それらのデータが生まれる源泉はどこか。またどこで利用されるのか。データの誕生からなくなるまでのデータライフを元に、データフローを考えましょう。
対象のデータは、どこのシステムで必要となって、最終的にどこにあれば良いのか。マスタデータとして整合性を担保し管理するのはどこか、正確な最新のデータ(SSOT = Single Source of Truth)はどこにあるのか。データフローが正しく紡がれていないと、マスタデータとSSOTを明確に区別して表現・配置することはできません。
最適と思われるデータの配置場所が明確になったら「ホントにそこに配置して処理ができるのか」を確認しましょう。
考慮する必要がある箇所に関しては Salesforce Platform で処理し切れるかどうか、が主です。元々私の作ったこちらのガイドが役に立ちます。大量データの配置と検索、実装の仕方がある程度分かります。
Salesforce Platform 以外のプロダクトの場合は、ここまで考慮しなくとも良いケースがほとんどです。Platform 上に配置するビジネスデータを何にするか、どの程度の期間保管するのかが重要なポイントです。
オススメの資格 Data Architect
アプリケーション
アプリケーションは機能と読みかえても良いでしょう。データをどのようにどこで処理するかを決めるターンです。
実はアーキテクトとしてはそこまで深く考えていません。
スクラッチ開発ではないので、ある程度、実装の見込みが立て易いことがその理由です。特に Sales Cloud や Service Cloud、Commerce Cloud などのようにプロダクト ≒ ビジネスケイパビリティを指していますから、営業管理 = Sales Cloud 、コールセンター = Service Cloud と当たりがつけやすいことが SaaS の特徴です。
後は、そのケイパビリティに必要な機能群が「スクラッチ開発(=プロコード = Apex)かローコード(フローなど)か」のおおまかな Fit&Gap ができていれば実現性はすぐに把握できます。
一般的に、プロコード開発20%、ローコード開発80%程度の割合までがおさまりの良い基準といわれています。プロコード開発が 50%になるようであれば、要件の見直しや Salesforce 以外の製品選定も視野に入れます。Salesforce は営業管理の為のプロダクトではありますが、全ての状況において、おさまりが良いとは限りません。開発の少ない要件でおさまることが SaaS 採用の条件でもあります。
オススメの資格 アプリケーションアーキテクト(複合資格)
テクノロジ
いっちばん重要な要素です。ぶっちゃけ、上記二つは、開発者と運用者によってどうにかなります。ただし、テクノロジ部分はノックアウトファクターがありますから、回避できずに実装できないケースも出てきます。アーキテクトが試される領域です。
まずはじめに、そもそもネットワークが繋がるかどうかです。
それは物理的に繋がることは当然ながら、論理的に繋がるかどうかも考慮が必要です。TCP/IP のパケットの気持ちになれないとダメです。とにかく、SaaS はお客様のネットワークと安全に正しく、帯域も確保されて繋がるかどうかが重要なポイントです。使い方によって、帯域も重要なんですよ。バッチ処理好きですからね、日本人。
ネットワークに関しては、とにかくみっちりみりみり確認します。特に金融系は。閉域じゃないとダメとなった時の選択肢は異常に少ないんです。しかも、Hyperforce の場合は選択肢などありません。現時点では一択です。
ネットワークが繋がるとなったら、ひとまずはおめでとうございます。次に相互接続したいシステムの総ざらいです。システム間連携はとても難しいのに「連携ソフトがあれば繋がるんでしょ」と軽く言い放ってしまう人の多いこと。そんな簡単に繋がるなら私の役割は不要です。例えば弊社のプロダクトで言えば MuleSoft があれば、どのシステムとも繋がる、なんて信じてる人は多いです。
そんなものは儚い夢です。
言い切りますが、日本人の大好きな HULFT とはどうやっても繋がりません。どっかでプロトコル変換が必要です。珍しいトコで言えば全銀手順とかめっちゃ困ります。特定のベンダーしか対処できません。
他にもイロイロありますが、次のポイントを考慮しつつ、Salesforce Platform だけでいけるか、MuleSoft を始めとする ETL/EAI ツールでもいけるか。この辺の肌感覚を持っていないと地獄に堕ちます。
プロトコル
TCP/IP かどうか(インターネット・トランスポート層) オンプレの SNA ってコトはないはずだけど
HTTPS か否か (アプリケーション層) → REST or SOAP のみ標準ではサポート
文字コード
UTF-8 じゃなかったらどうするか
えっ、外字あるんですか
フォーマット
JSON, XML
CSV などは手動ならうまくいくけど、自動化の場合には考慮しないとね
連携頻度
リアルタイム (同期/非同期)
バッチ (時間帯とデータ量)
この辺は別にSalesforceに関係なく、クラウドサービスだと容易にノックアウトする部分なので、きちんと把握することが必要です。未だに ISDN の EDI って一部で提供されてるからね。
ここで、ちょっとだけ気をつけてほしいことがあります。リアルタイム通信が発生する場合、Change Data Capture のような機能を使わないと原則として開発が発生します。API をキックするシステム側は、キックする為の何らかの手段が必要です。Salesforce であれば、少なくともフローでの実装が必須です。ものによっては Apex や Lightning でのプロコード開発も必要でしょう。MuleSoft のようなリアルタイム連携ツールがあれば、それだけで済むと勘違いしているエンジニアが未だにたくさんいるんですが、そんな事はあり得ません。ネットワーク通信を行う手段と方法については、きちんと理解しておきましょう。頼むよマジで。
この辺がクリアできたら後少し。認証と開発手法が想定している構成に適合するかどうか。
Experience Cloud や Commerce など B2C 系のプロダクトを利用する時、認証をどうするかは必ず発生する課題です。統合認証サービスがすでにある場合に、そこの傘下に入れるかどうか。これは SSO(SAML/OIDC) で認証可能なのか、それとも OAuth で認可の連携をするのか。サービスのあり方と合わせて、実装できるかどうかをきちんと考えておかないと、あとで認証サービスまみれになってユーザが使いずらい将来がやってきたりします。
尚、代理認証だけは使わないようにしましょう。
それと開発手法。DevOps Center や Salesforce DX のおかげで git を始めとするバージョン管理との相性も良くなってきました。とは言え、Salesforce の開発、テスト環境は常設ではない Sandbox の利用が多いでしょうから、開発プロセスの仕組みから変わってくる場合もあります。複数の事業が一つの Salesforce 組織の開発を行う場合のガバナンスの利かせ方も考慮が必要です。
こういった開発プロセスや、運用時のデータ管理は企業の組織に連動するので、まとめ切れないことも多々あります。こういった企業の組織構造自体が、Salesforce の組織に影響を及ぼすことも少なくありません。企業組織と文化、開発プロセスも考慮しながら Salesforce 組織の設計も必要となるわけです。
オススメの資格 システムアーキテクト (複合資格)
まとめ
さて、いろいろ書きましたが、注目する箇所は次の通り。
データの配置
Fit to Standard と機能
連携システムとの接続性
企業組織と Salesforce 組織
ただ、これらの良し悪しについては、現時点で AI でもきちんと回答してくれるレベルにはありません。
多分、Salesforce のアップデートがすさまじく、学習が追いついていない可能性があるのでしょう。あとはこういった知見自体がまだまだ少ない気がします。アーキテクチャパターンなんてものはいくらでもありますが、ただのリファレンスであって、最適解ではありません。
一番は、日本企業の製品のAPIが非公開なものが多すぎるからだと思う。
いいなと思ったら応援しよう！
