Salesforce के आसपास के सिस्टम

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 3 (कुल 6 में से) — अध्याय एंटरप्राइज़ डेटा को समझना, Data Architect कोर्स का अध्याय 4। हर मॉड्यूल अपने आप में पूरा है। पिछला: एंटरप्राइज़ डेटा के प्रकार · अगला: सिस्टम लैंडस्केप बनाएँ

यह मॉड्यूल किस सवाल का जवाब देता है: Salesforce के आसपास क्या है, और हर सिस्टम की भूमिका क्या है?

पिछले मॉड्यूल ने डेटा को छाँटा। अब मैं उसे कहीं रखना चाहता हूँ, और यहीं Salesforce आर्किटेक्ट मुश्किल में पड़ते हैं। हम Salesforce जानते हैं, तो ग्राहक डेटा मतलब Account, ऑर्डर डेटा मतलब Order, दस्तावेज़ मतलब Files, एनालिटिक्स मतलब Reports। लेकिन एंटरप्राइज़ ने Salesforce अपनी बाकी हर चीज़ की जगह लेने के लिए नहीं ख़रीदा। वहाँ फ़ाइनेंस और fulfillment चलाने वाला एक ERP हो सकता है, सालों के इतिहास वाला एक warehouse, एक इंटीग्रेशन प्लेटफ़ॉर्म, एक identity provider, पार्टनर सिस्टम, एक event प्लेटफ़ॉर्म, एक MDM प्लेटफ़ॉर्म, और इनमें से कई को जोड़ता Data 360। काम तकनीकें रटना नहीं है। काम यह समझना है कि हर सिस्टम का काम क्या है।

प्रोडक्ट के नाम से शुरू न करें

“हमारे पास SAP है” मुझे काफ़ी नहीं बताता। न Snowflake, न MuleSoft, न Tableau, न Data 360। मैं जानना चाहता हूँ कि वह सिस्टम इस आर्किटेक्चर में क्या करता है: वह किस डेटा का मालिक है, क्या पढ़ता है, क्या बदलता है, उसे कौन इस्तेमाल करता है, उस पर क्या निर्भर है, और उसके बंद होने पर क्या होता है। दो कंपनियों के पास बिल्कुल एक जैसे प्रोडक्ट हो सकते हैं और आर्किटेक्चर बिल्कुल अलग।

इसलिए मैं सिस्टमों पर भूमिका का लेबल लगाता हूँ। चार भूमिकाएँ ज़्यादातर चीज़ें कवर कर लेती हैं:

• System of record (रिकॉर्ड का सिस्टम): जहाँ किसी चीज़ का आधिकारिक संस्करण रखा जाता है।
• System of engagement: जहाँ लोग काम करते हैं।
• System of reference: जहाँ कोई सिस्टम ऐसी जानकारी के लिए जाता है जो उसे चाहिए, लेकिन जिसका वह मालिक नहीं है।
• System of insight: जहाँ डेटा मापने, विश्लेषण करने और अनुमान लगाने के लिए एक साथ आता है।

एक प्लेटफ़ॉर्म कई भूमिकाएँ निभा सकता है, और भूमिकाएँ डेटा के हिसाब से बदलती हैं। Salesforce cases के लिए system of record हो सकता है, सर्विस एजेंटों के लिए system of engagement, और ERP के स्वामित्व वाले प्रोडक्ट डेटा का उपभोक्ता। इसलिए जब कोई कहे “Salesforce हमारा system of record है,” तो वाक्य पूरा करें: किस चीज़ का system of record?

ERP: बैक ऑफ़िस का अपना गुरुत्व होता है

ERP वह सिस्टम है जो आपको Salesforce के बगल में सबसे ज़्यादा मिलेगा, फ़ाइनेंस, इन्वेंटरी, ख़रीद, fulfillment और बिलिंग चलाता हुआ। मॉड्यूल 1 के पैटर्न (ग्राहक और प्रोडक्ट अंदर, ऑर्डर बाहर) का मतलब है कि प्रोडक्ट का मालिक ERP है, लेकिन सेल्स वालों को फिर भी वे Salesforce में चाहिए। ठीक है: उन्हें अंदर लाएँ। लेकिन डेटा कॉपी करने से स्वामित्व नहीं बदलता। कॉपी अधिकार नहीं है।

मेरी राय: ERP के स्वामित्व वाला डेटा स्थानीय रूप से पढ़ा जाता है और नियंत्रण में लिखा जाता है। Salesforce यूज़र्स को डेटा वहीं मिलता है जहाँ वे काम करते हैं, लेकिन Salesforce को वह बदलने की इजाज़त नहीं जिसका मालिक ERP है। और मैं इसे स्कीमा में दिखाता हूँ: ERP के फ़ील्ड पर erp_ prefix होता है, जैसे erp_Product_Number__c, ताकि ऑब्जेक्ट पढ़ने वाला हर व्यक्ति जाने कि हर फ़ील्ड का मालिक कौन है और उसे बदलते समय सावधान रहे। prefix कुछ लागू नहीं करता; यह काम permissions, validation और इंटीग्रेशन पैटर्न करते हैं। यह इरादा बताता है, और यह अधिकार-मानचित्र (authority map) को दिखने लायक बना देता है।

Warehouse, lake और lakehouse

ऑपरेशनल सिस्टम बिज़नेस चलाते हैं; एनालिटिकल सिस्टम उसे समझने में मदद करते हैं। “मेरी खुली opportunities दिखाओ” एक Salesforce रिपोर्ट है। “हर चैनल में पाँच साल की बिक्री, fulfillment, returns, cases, इन्वेंटरी और फ़ाइनेंस दिखाओ” एक अलग समस्या है।

आपको तीन तरह के एनालिटिकल स्टोर मिलेंगे। Data warehouse विश्लेषण के लिए तैयार किया गया स्ट्रक्चर्ड डेटा रखता है। Data lake कहीं ज़्यादा डेटा, ज़्यादा रूपों में रखता है, अक्सर कच्चा। Lakehouse दोनों को मिलाता है: lake जैसा स्टोरेज और warehouse जैसा विश्लेषण। इन्हें जानें, क्योंकि ये लैंडस्केप पर आते हैं। लेकिन मेरा अनुभव है कि Salesforce प्रोजेक्टों पर lakehouse और data mesh अब भी गिने-चुने हैं। आम लैंडस्केप में CRM, ERP, एक warehouse और एक इंटीग्रेशन लेयर होती है, और बाकी प्लेटफ़ॉर्म वहीं जहाँ बिज़नेस को सच में उनकी ज़रूरत हो। आर्किटेक्चर सीखें; शब्दावली के पीछे न भागें।

एनालिटिक्स वहीं रहता है जहाँ डेटा रहता है

यह मेरी सबसे पक्की रायों में से एक है: एनालिटिक्स वहीं रहता है जहाँ डेटा रहता है। अगर रिपोर्ट को सिर्फ़ accounts, opportunities और सेल्स वाले चाहिए, तो सब कुछ core पर है: स्टैंडर्ड रिपोर्ट और डैशबोर्ड। फिर बिज़नेस ERP के इनवॉइस जोड़ने को कहता है। फिर प्रोडक्ट की लागत। फिर warehouse से पाँच साल के ऑर्डर। फिर वेबसाइट की गतिविधि। किसी मोड़ पर, सिर्फ़ रिपोर्ट बनाने के लिए यह सब ऑपरेशनल CRM में घसीट लाना बेतुका हो जाता है। जैसे ही दूसरे डेटा स्टोर शामिल होते हैं, एक एनालिटिक्स प्लेटफ़ॉर्म ज़रूरी हो जाता है: Tableau (जिसमें Data 360 पर बना Tableau Next भी शामिल है), या CRM Analytics जहाँ वह पहले से इस्तेमाल हो रहा हो। जब Salesforce डेटा को किसी warehouse के साथ मिलाया जाता है, तो यह अनिवार्य है। ज़रूरत सिर्फ़ ज़्यादा पेचीदा नहीं हुई; लैंडस्केप ने बदल दिया कि सवाल का जवाब कहाँ दिया जाना चाहिए। इसलिए मैं कभी “कौन-सा एनालिटिक्स टूल?” से शुरू नहीं करता। मैं शुरू करता हूँ डेटा कहाँ है? से।

मैं CTA उम्मीदवारों से भी यही पूछता हूँ: “मेरा कौन-सा डायग्राम इसे बेहतरीन ढंग से हल करता है? लैंडस्केप।” अगर सब कुछ core पर है, तो रिपोर्ट इस्तेमाल करें। अगर डेटा दूसरे भंडारों में है, तो मुझे एक एनालिटिक्स प्लेटफ़ॉर्म दिखना चाहिए। कोई रिपोर्ट बिल्डर खोले, उससे पहले ही लैंडस्केप रिपोर्टिंग के सवाल का जवाब दे देता है। (प्रोडक्ट के नाम बदलते रहते हैं; Data 360 वाला अध्याय बताता है कि Salesforce का एनालिटिक्स आज कहाँ खड़ा है।)

MDM: यह ग्राहक असल में कौन है?

अब मान लीजिए ग्राहक की जानकारी Salesforce, ERP, ई-कॉमर्स, एक लॉयल्टी प्लेटफ़ॉर्म और एक पार्टनर सिस्टम में रहती है, और हर एक सोचता है कि वह जानता है कि ग्राहक कौन है। यहीं मास्टर डेटा मैनेजमेंट (master data management) आता है: सिस्टमों के बीच अहम डेटा की आधिकारिक पहचान तय करना और उसका गवर्नेंस करना। लेकिन MDM “एक मास्टर ग्राहक डेटाबेस” नहीं है। कठिन सवाल ये हैं कि कौन-सा सिस्टम ग्राहक बना सकता है, हर सिस्टम किन एट्रिब्यूट का मालिक है, डुप्लिकेट कैसे ढूँढे जाते हैं, कौन-सा पहचानकर्ता (identifier) बचता है, और जब सिस्टम असहमत हों तो क्या होता है। अध्याय 6 पूरा इसी के बारे में है। यहाँ, भूमिका पहचानें: अगर कोई MDM प्लेटफ़ॉर्म मौजूद है, तो वह Salesforce और बाकी एंटरप्राइज़ के बीच एक अहम अधिकार हो सकता है।

इंटीग्रेशन लेयर और events

हर सिस्टम को सीधे हर दूसरे सिस्टम से जोड़ दें, और लैंडस्केप जल्दी ही नूडल्स की प्लेट बन जाता है। इसीलिए एंटरप्राइज़ के पास एक इंटीग्रेशन लेयर होती है: एक ESB (enterprise service bus) या iPaaS (integration platform as a service)। Salesforce लैंडस्केप में आपको सबसे ज़्यादा MuleSoft मिलेगा। यह बीच में मध्यस्थ बनता है, ताकि हर एप्लिकेशन को हर दूसरे को समझना न पड़े।

लेकिन बीच में MuleSoft का एक बॉक्स रख देने से इंटीग्रेशन अच्छा नहीं हो जाता। मैं फिर भी जानना चाहता हूँ कि उससे क्या गुज़रता है और क्या नहीं, डेटा को कौन बदलता (transform करता) है, कॉन्ट्रैक्ट का मालिक कौन है, गंतव्य बंद हो तो क्या होता है, यह synchronous है या asynchronous, और हमें कैसे पता चलता है कि कोई संदेश सफल हुआ। Integration Architect कोर्स इसमें गहराई से जाता है; यहाँ, इसे एक अलग भूमिका के रूप में पहचानें।

और हर इंटीग्रेशन सिस्टम A का सिस्टम B को कॉल करना नहीं होता। कभी-कभी कुछ होता है (एक ऑर्डर बनता है, किसी डिलीवरी का स्टेटस बदलता है, कोई ट्रक किसी क्षेत्र में दाख़िल होता है), एक event प्रकाशित होता है, और जिसकी भी दिलचस्पी हो वह प्रतिक्रिया देता है। चलते हुए events का भी अपना इन्फ़्रास्ट्रक्चर होता है: Salesforce की अपनी event क्षमताएँ, एक एंटरप्राइज़ event bus, दूसरी मैसेजिंग। सिर्फ़ डेटाबेस नहीं, डेटा ले जाने वाली व्यवस्थाएँ भी बनाएँ।

वह सिस्टम जिसे डेवलपर भूल जाते हैं: पहचान (identity)

एक बॉक्स है जो मैं हमेशा लैंडस्केप पर चाहता हूँ और जिसके बारे में डेवलपर शायद ही कभी सोचते हैं: identity provider। डेवलपर अपने sandbox में सीधे username और password से लॉग इन करते हैं, इसलिए बिल्ड के दौरान identity दिखती ही नहीं। फिर UAT या production आता है, और अचानक कर्मचारियों के लिए कंपनी का single sign-on है, शायद पार्टनर्स के लिए दूसरा provider, ग्राहकों के लिए social sign-on। identity हमेशा से आर्किटेक्चर का हिस्सा थी। बस डेवलपर ने उसे अभी तक देखा नहीं था।

Identity provider (IdP) वह सिस्टम है जो किसी यूज़र को ऑथेंटिकेट करता है और वह पहचान स्थापित करता है जिस पर Salesforce भरोसा करता है। यह पहले दिन से लैंडस्केप पर होना चाहिए, भले ही release pipeline में इसे बाद में कॉन्फ़िगर किया जाए, क्योंकि कौन अंदर आ सकता है, यही तय करता है कि कौन डेटा तक पहुँच सकता है।

एक व्यावहारिक पेच भी है: identity कॉन्फ़िगरेशन डिप्लॉय किया जा सकता है, लेकिन पूरी तरह नहीं। SAML single sign-on कॉन्फ़िगरेशन और authentication providers Metadata API टाइप हैं, इसलिए वे pipeline से होकर जाते हैं (SamlSsoConfig (opens in a new tab))। लेकिन authentication provider के consumer secrets अब Metadata API के जवाबों में नहीं लौटाए जाते (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), और सर्टिफ़िकेट आमतौर पर हर environment में अलग होते हैं। जो हिस्से साथ जाते हैं और जो नहीं जाते, दोनों की योजना बनाएँ।

Click to enlarge

लैंडस्केप को लोगो की तरह नहीं, भूमिकाओं की तरह पढ़ें: हर सिस्टम किस चीज़ का मालिक है, क्या पढ़ता है, या क्या तय करता है।

Data 360 कहाँ बैठता है?

Data 360 डायग्राम बनाने का एक बढ़िया सवाल खड़ा करता है। मैं इसे दाईं ओर, ESB या MuleSoft के नीचे रखता हूँ। वजह इसके कनेक्शन हैं: यूज़र कभी इससे सीधे नहीं जुड़ते, जबकि यह बहुत-से back-end सिस्टमों से सीधे जुड़ता है। इसलिए इसकी जगह डेटा की plumbing के साथ है, जहाँ वे लाइनें छोटी रहती हैं, यूज़र्स के पास बाहर नहीं। इसे किसी और स्क्रीन की तरह बनाएँ जिसमें लोग लॉग इन करते हैं, तो आप गलत कहानी सुना रहे हैं।

एडमिन और डेटा टीमें Data 360 की स्क्रीनें खोलती तो हैं, लेकिन वे स्क्रीनें org में हैं, core पर। काम करने वाला tenant, उसका डेटा और उसकी प्रोसेसिंग, core से बाहर चलते हैं। इसीलिए मैं इसे near-core कहता हूँ: core पर मैनेज, core से बाहर होस्ट (मॉड्यूल 1 ये शब्द समझाता है)। डायग्राम tenant के पीछे चलता है: वह plumbing के साथ बैठता है, और उसे मैनेज करने वाले org तक एक लाइन वापस जाती है।

यह क्या करता है, Salesforce के शब्दों में, उसमें zero copy शामिल है: एक data federation तकनीक जो एंटरप्राइज़ को डेटा कॉपी किए बिना उस तक पहुँचने और उसकी क्वेरी करने देती है (Zero Copy (opens in a new tab))। क्षमताएँ और connectors तेज़ी से बदलते हैं, इसलिए Data 360 वाला अध्याय उन्हें ठीक से कवर करता है, बजाय इसके कि यह मॉड्यूल एक प्रोडक्ट टूर बन जाए।

लैंडस्केप को ज़िम्मेदारियों के रूप में पढ़ें

जब आप किसी लैंडस्केप को देखें, तो लोगो न पढ़ें; ज़िम्मेदारियाँ पढ़ें। ERP: यह किसका मालिक है? Warehouse: यह किन सवालों के जवाब देता है? इंटीग्रेशन प्लेटफ़ॉर्म: यह क्या ले जाता है? IdP: यह किसे ऑथेंटिकेट करता है? MDM: यह किस पहचान का गवर्नेंस करता है? Data 360: यह क्या जोड़ता है, और किसलिए? Salesforce: यह असल में किस चीज़ के लिए ज़िम्मेदार है? एक बार आप इनके जवाब दे सकें, तो बॉक्सों का कुछ मतलब बनने लगता है, और उनके बीच के तीर कहीं ज़्यादा दिलचस्प हो जाते हैं। आगे, हम उन्हें सोच-समझकर बनाते हैं।

आर्किटेक्ट यहाँ क्या तय करता है

• हर सिस्टम की भूमिका क्या है, उसके प्रोडक्ट नाम से आगे।
• हर अहम डेटा सेट के लिए कौन-सा सिस्टम आधिकारिक है, और कहाँ Salesforce सिर्फ़ एक स्थानीय कॉपी रखता है।
• क्या ERP के स्वामित्व वाला डेटा Salesforce में नियंत्रित writes के साथ उपलब्ध है, और वह स्वामित्व स्कीमा में कैसे दिखता है।
• एनालिटिक्स कहाँ होना चाहिए, इस आधार पर कि डेटा कहाँ रहता है।
• लैंडस्केप पर identity, इंटीग्रेशन, events और मास्टर डेटा का अधिकार कहाँ बैठते हैं।

दस आयतों वाला लैंडस्केप आर्किटेक्चर नहीं है; वह इन्वेंटरी है। आर्किटेक्चर तब शुरू होता है जब आप हर आयत की ओर इशारा करके बता सकें कि वह वहाँ क्यों है, वह किसका मालिक है, उसे कौन इस्तेमाल करता है, Salesforce को उससे क्या चाहिए, और उसकी भूमिका गलत समझने पर क्या टूटता है।

और जानें

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce, Zero Copy (opens in a new tab) (प्रोडक्ट पेज; अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (अंग्रेज़ी में)।