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

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

यह मॉड्यूल किस सवाल का जवाब देता है: डेटा आर्किटेक्ट org डिज़ाइन करने से पहले उसके आसपास की चीज़ें क्यों बनाता है?

जब मैं CTA उम्मीदवारों को पढ़ाता हूँ, तो पहले दिन के बाद का होमवर्क हमेशा एक ही होता है। परिदृश्य पढ़ें। खाली कैनवस से सिस्टम लैंडस्केप शुरू करें। उसके बाद ही डेटा मॉडल पर हाथ आज़माएँ। ऑब्जेक्ट नहीं, इंटीग्रेशन की बारीकियाँ नहीं: लैंडस्केप। Salesforce के अंदर क्या होना चाहिए, यह तय करने से पहले मैं देखना चाहता हूँ कि उसके आसपास क्या है।

बहुत से Salesforce प्रोफ़ेशनल्स के लिए यह नज़रिए का बदलाव है। अगर आपने अपना करियर एडमिन या डेवलपर के रूप में बिताया है, तो स्वाभाविक है कि Salesforce आपकी दुनिया का केंद्र है। आप Setup खोलते हैं, ऑब्जेक्ट बनाते हैं, flow बनाते हैं, Apex लिखते हैं, और दूसरे सिस्टमों को Salesforce में इंटीग्रेट करते हैं। लगता है सब कुछ org से शुरू होता है। आर्किटेक्ट को कैमरा पीछे खींचना पड़ता है, क्योंकि एक एंटरप्राइज़ में Salesforce कई सिस्टमों में से एक है, और अक्सर वह डेटा का मालिक नहीं होता।

पहले लैंडस्केप बनाएँ

अध्याय 2 ने लॉजिकल मॉडल बनाया, और अध्याय 3 ने पूछा कि वह Salesforce पर कैसे रहता है। अब मैं समस्या को बड़ा करने जा रहा हूँ। Salesforce किस चीज़ का मालिक हो, यह तय करने से पहले मैं उसके आसपास के एंटरप्राइज़ को समझना चाहता हूँ। कौन-से सिस्टम पहले से मौजूद हैं? ग्राहक कहाँ बनते हैं, प्रोडक्ट कहाँ परिभाषित होते हैं, ऑर्डर कहाँ शुरू होते हैं, इनवॉइस कहाँ बनते हैं? पहचान (identity) कहाँ रहती है? एनालिटिक्स कहाँ होता है, दस्तावेज़ कहाँ रखे जाते हैं, इतिहास कहाँ बैठा है? किन सिस्टमों को Salesforce का डेटा चाहिए, और Salesforce किन पर निर्भर है?

ये सवाल आर्किटेक्चर को बदल देते हैं। इसलिए मैं खाली कैनवस से शुरू करता हूँ, Salesforce को बीच में रखता हूँ, और उसके आसपास सब कुछ बनाता हूँ। मॉड्यूल 4 ठीक-ठीक दिखाता है कि मैं इसे कैसे सजाता हूँ। फ़िलहाल सबक बस इतना है: जिस दुनिया में org को रहना है, उसे समझने से पहले org डिज़ाइन न करें।

Salesforce अक्सर system of record नहीं होता

एक बहुत आम एंटरप्राइज़ लें: Salesforce और साथ में एक ERP, यानी SAP या Oracle जैसा enterprise resource planning सिस्टम, जो फ़ाइनेंस, प्रोडक्ट, इन्वेंटरी, ख़रीद और fulfillment चलाता है। अब एक आसान सवाल पूछें: ग्राहक कहाँ रहता है?

Salesforce हो सकता है, ERP हो सकता है, या दोनों, और यहीं बात दिलचस्प हो जाती है। सेल्स वाले संभावित ग्राहकों (prospects) पर Salesforce में Accounts के रूप में काम कर सकते हैं, जबकि भुगतान करने वाला ग्राहक बनते ही ERP आधिकारिक ग्राहक नंबर जारी करता है। प्रोडक्ट और कीमतें? शायद ERP। इन्वेंटरी? लगभग कभी Salesforce नहीं। ऑर्डर Salesforce में दर्ज हो सकते हैं और ERP में पूरे हो सकते हैं; इनवॉइस ERP से आते हैं; सर्विस Salesforce में रहती है; एनालिटिक्स Salesforce रिपोर्ट और एक warehouse में बँटा हुआ है। अचानक हमारा अच्छा-सा Salesforce डेटा मॉडल एंटरप्राइज़ का डेटा मॉडल नहीं रह जाता। वह उसका एक हिस्सा है।

वह इंटीग्रेशन जो मैं बार-बार देखता हूँ

सबसे आम इंटीग्रेशन जो मैं देखता हूँ, वह ऐसा होता है: ग्राहक, प्रोडक्ट और कीमतें ERP से Salesforce में आती हैं, और ऑर्डर बाहर जाते हैं। SAP, Oracle या कोई भी दूसरा ERP रख दें; आकार वही रहता है। ग्राहक और प्रोडक्ट का गोल्डन रिकॉर्ड ERP के पास है, इसलिए वे flow दाईं ओर से Salesforce में आते हैं। सेल्स टीम डील Salesforce में बंद करती है, इसलिए ऑर्डर वहीं से शुरू होता है और fulfillment, इनवॉइसिंग और हिसाब-किताब के लिए वापस ERP में जाता है।

ये flow सिर्फ़ इंटीग्रेशन नहीं हैं। ये मुझे बताते हैं कि एंटरप्राइज़ के हिसाब से सच कहाँ रहता है।

एकतरफ़ा तीर मुझे बेचैन करते हैं

जब भी मुझे सिर्फ़ एक flow वाला इंटीग्रेशन दिखता है, मुझे चिंता होने लगती है। ऊँचे स्तर पर कोई एक अकेला तीर बना देता है: Salesforce से ERP को ऑर्डर। ठीक है। अब गहराई में देखें। मैं ERP को ऑर्डर कैसे भेज सकता हूँ अगर मुझे उसके ग्राहक, उसके प्रोडक्ट या उसकी कीमतें ही नहीं पता? ऑर्डर ऐसे ग्राहक से जुड़ा होना चाहिए जो ERP के पास पहले से है, और हर लाइन ऐसा SKU होनी चाहिए जिसे ERP पहले से बेचता है। मैं ऐसे प्रोडक्ट का line item नहीं भेज सकता जो दूसरी तरफ़ मौजूद ही नहीं है। इसलिए उस ऑर्डर वाले तीर के काम करने से पहले, वापसी वाले flow मौजूद होने चाहिए, जो उलटी दिशा में चलते हैं।

यही सवाल मैं हर तीर से पूछता हूँ: यह flow किस पर निर्भर है? ऊँचे स्तर का जो तीर आपको दिखता है, उसे आमतौर पर ऐसे वापसी वाले flow चाहिए होते हैं जो आपने अभी तक बनाए ही नहीं।

और गहराई में देखें, तो आपको वापसी की यात्रा मिलती है। Salesforce एक ऑर्डर भेजता है। फिर क्या? वह स्वीकार हुआ या ठुकराया गया? शिप हुआ, आंशिक रूप से शिप हुआ, रद्द हुआ? इनवॉइस बना? क्या Salesforce में किसी को यह जानना ज़रूरी है? शायद नहीं। लेकिन किसी को पूछना चाहिए था। अगर कुछ वापस नहीं आता, तो ठीक है। मुझे बताइए क्यों।

एंटरप्राइज़ एक साथ नहीं आया

लैंडस्केप कुछ हद तक इसलिए पेचीदा हो जाते हैं क्योंकि किसी ने उन्हें एक साथ नहीं बनाया। डेटा लहरों में आया है। पहले फ़ाइलें: तय फ़ॉर्मैट वाले रिकॉर्ड, फिर CSV जैसी delimited फ़ाइलें। फिर ऑपरेशनल डेटा के लिए रिलेशनल डेटाबेस। फिर विश्लेषण के लिए सब कुछ एक जगह लाने वाले data warehouse। फिर दस्तावेज़ों, key-value जोड़ियों और graph के लिए NoSQL डेटाबेस, जो टेबलों में ठीक से नहीं बैठते। फिर भारी मात्रा में कच्चे और semi-structured डेटा के लिए data lake, और दोनों को मिलाने वाले lakehouse। Kafka या Salesforce event bus जैसे event stream डेटा को रात के batch के बजाय उसी वक्त आगे बढ़ाते हैं जब कुछ होता है। और अब federation, जिसमें किसी दूसरे प्लेटफ़ॉर्म के इस्तेमाल से पहले डेटा को एक जगह कॉपी करना ज़रूरी नहीं।

अभी तकनीक असली मुद्दा नहीं है। मुद्दा यह है: नई लहर पुरानी को शायद ही कभी गायब करती है। किसी बड़े एंटरप्राइज़ में जाइए, और आपको ये सब एक साथ मिलेंगे: रिलेशनल डेटाबेस, ERP, Salesforce, एक warehouse, एक lake, SFTP पर डाली गई फ़ाइलें, API, event stream, वह spreadsheet जिसे कोई आज भी हर शुक्रवार ईमेल करता है, और वह एक सिस्टम जिसे छूने से सब डरते हैं क्योंकि उसे बनाने वाला छह साल पहले रिटायर हो गया। आप उसी एंटरप्राइज़ का आर्किटेक्चर बना रहे हैं, प्रोडक्ट ब्रोशर वाले का नहीं।

अलग-अलग सिस्टम अलग-अलग वजहों से होते हैं

इसीलिए मैं कभी “सारा डेटा Salesforce में कैसे लाएँ?” से शुरू नहीं करता। मैं सारा डेटा वहाँ क्यों चाहूँगा? हो सकता है Salesforce सेल्स और सर्विस वालों के लिए ग्राहकों के साथ काम करने की सबसे अच्छी जगह हो। इससे वह फ़ाइनेंस सिस्टम, एंटरप्राइज़ warehouse, telemetry स्टोर, दस्तावेज़ों का आर्काइव, या कंपनी के हर क्लिक, हर GPS रीडिंग और हर पुराने ट्रांज़ैक्शन का घर नहीं बन जाता।

अध्याय 3 ने एक org के लिए पूछा था, यह डेटा कहाँ रहना चाहिए? एंटरप्राइज़ के स्तर पर वही सवाल बड़ा हो जाता है: कभी डेटा का मालिक Salesforce होता है, कभी वह एक कॉपी रखता है, कभी सिर्फ़ एक रेफ़रेंस, और कभी उसके पास वह डेटा होना ही नहीं चाहिए।

Core, core से बाहर और Hyperforce

एक और सीमा समझनी है: “Salesforce” भी एक runtime और एक डेटाबेस नहीं है। अध्याय 3 में core पर का मतलब था कि डेटा कहाँ बैठा है: आपकी मेज़ पर, org के अपने ऑब्जेक्ट में। यहाँ वही शब्द बताते हैं कि कोई प्रोडक्ट कहाँ चलता है। आप आर्किटेक्ट्स को दोनों अर्थों में इन्हें इस्तेमाल करते सुनेंगे।

ऐतिहासिक रूप से Core runtime प्लेटफ़ॉर्म का ज़्यादातर हिस्सा होस्ट करता था। आज Salesforce अपने प्लेटफ़ॉर्म को सैकड़ों स्वतंत्र, मेटाडेटा-आधारित सेवाओं के रूप में बताता है, जिसमें Core एप्लिकेशन मेटाडेटा का अकेला system of record बना रहता है (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab))। इसीलिए आप आर्किटेक्ट्स को कहते सुनेंगे कि कोई क्षमता core पर चलती है या core से बाहर।

यह प्लेटफ़ॉर्म के सेवाओं में बँटने से बहुत पहले से मायने रखता था। जब मैं क्लास से पूछता हूँ कि Salesforce ने quoting के लिए Apttus के बजाय SteelBrick क्यों ख़रीदा, तो मैं एक आसान जवाब चाहता हूँ: SteelBrick 100% core पर बना था। Flow और trigger core में रहते हैं, इसलिए वहाँ बना प्रोडक्ट अपने साथ प्लेटफ़ॉर्म का मेटाडेटा, कस्टमाइज़ेशन और ऑटोमेशन पाता है। वह quoting प्रोडक्ट तब से Revenue Cloud को जगह दे चुका है, लेकिन सबक नहीं बदला। फिर आता है near-core (core के पास), और इसके लिए मैं Data 360 का उदाहरण देता हूँ। Data 360 core नहीं है। उसका tenant core से बाहर है: डेटा और उसे प्रोसेस करने वाली व्यवस्थाएँ उसके अपने lakehouse में चलती हैं, org के रिलेशनल डेटाबेस के अंदर नहीं, बल्कि उसके बगल में (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab))। लेकिन उसे सेट अप और नियंत्रित करने वाली स्क्रीनें core पर, org में दिखती हैं। तो सबसे सटीक रूप में मैं इसे ऐसे कहूँगा: core पर मैनेज, core से बाहर होस्ट। कोई भी डेटा या प्रोसेसिंग असल में Core में नहीं चलती; Core पर UI, core से बाहर के tenant को नियंत्रित करता है। और फिर, बेशक, वह सब कुछ है जो core से बाहर है क्योंकि वह Salesforce है ही नहीं।

इस साल कौन-सा प्रोडक्ट कहाँ चलता है, यह रटने की मुझे कम परवाह है, क्योंकि वह बदलता रहता है; मुझे आदत की परवाह है: कोई सीमा डेटा की आवाजाही, latency, पहचान (identity), इंटीग्रेशन और residency (डेटा किस देश में रहे) पर असर डाल सकती है। इसलिए यह न मान लें कि किसी प्रोडक्ट पर Salesforce लिखा है तो उसका डेटा आपके Account रिकॉर्ड के ठीक बगल में बैठा है। असली आर्किटेक्चर देखें।

फिर है Hyperforce: Salesforce का इन्फ़्रास्ट्रक्चर, जो उसके पारंपरिक अपने डेटा सेंटरों के बजाय पब्लिक क्लाउड के लिए बना है और कोड के रूप में परिभाषित है, और जो ग्राहकों को यह चुनने की ज़्यादा आज़ादी देता है कि उनका डेटा कहाँ रहे (Salesforce Hyperforce: General Information and FAQ (opens in a new tab))। यह मायने रखता है, और मॉड्यूल 5 इस पर लौटता है। लेकिन इन्फ़्रास्ट्रक्चर आर्किटेक्चर एंटरप्राइज़ डेटा आर्किटेक्चर नहीं है। org को पब्लिक क्लाउड पर ले जाने से आपको यह पता नहीं चलता कि ग्राहक का मालिक कौन है, इन्वेंटरी कहाँ रहती है, एनालिटिक्स कहाँ चलता है, या कौन-सा डेटा सीमा पार कर सकता है। Hyperforce इनमें से कुछ फ़ैसलों को आकार दे सकता है, खासकर residency को। वह लैंडस्केप जानने की जगह नहीं ले सकता।

लैंडस्केप बॉक्स से पहले आता है

तो आदत यह है। कोई आपको एक परिदृश्य देता है। Salesforce सॉल्यूशन बनाना शुरू न करें। पहले सिस्टम ढूँढें: ERP, identity provider, warehouse, इंटीग्रेशन प्लेटफ़ॉर्म, पार्टनर सिस्टम, ग्राहक चैनल, दस्तावेज़ स्टोर। फिर उनके बीच चलने वाला डेटा ढूँढें: ग्राहक, प्रोडक्ट, ऑर्डर, इनवॉइस, दस्तावेज़, events, पहचानें (identities)। फिर पूछें कि हर एक का मालिक कौन है। उसके बाद ही तय करें कि Salesforce में क्या होना चाहिए। वरना आप एक ऐसा बॉक्स डिज़ाइन कर रहे हैं जिसके बारे में आपको पता ही नहीं कि वह किससे जुड़ता है।

Click to enlarge

चरण 1 (कुल 3 में से): वह org जिसे हम डिज़ाइन करते हैं, अकेला। यहाँ से वह पूरी दुनिया जैसा लगता है।

Click to enlarge

चरण 2 (कुल 3 में से): ज़ूम आउट करें। Salesforce कई सिस्टम में से एक सिस्टम है (मॉड्यूल 4 यह लेआउट सिखाता है)।

Click to enlarge

चरण 3 (कुल 3 में से): पहले तीर। ग्राहक, प्रोडक्ट और कीमतें ERP से अंदर, ऑर्डर बाहर: ये बताते हैं कि एंटरप्राइज़ के हिसाब से सच कहाँ रहता है।

लैंडस्केप डेटा मॉडल को बदल देता है

डेटा आर्किटेक्ट के लिए यह इसीलिए मायने रखता है। अध्याय 2 कहता है कि ग्राहक एक अहम एंटिटी है। ठीक है। फिर लैंडस्केप कहता है कि ग्राहक के लिए आधिकारिक सिस्टम ERP है। इससे फ़िज़िकल मॉडल बदल जाता है। Salesforce शायद अब भी एक स्थानीय Account रखे, क्योंकि लोग रोज़ उसे इस्तेमाल करते हैं, लेकिन अब हमें ERP का पहचानकर्ता (identifier) एक External ID के रूप में चाहिए; हमें जानना है कि Salesforce कौन-से फ़ील्ड बदल सकता है (मैं ERP के फ़ील्ड पर erp_ prefix लगाता हूँ, जैसा हम मॉड्यूल 3 में देखेंगे); ERP के बदलाव कितनी जल्दी आते हैं; क्या Salesforce किसी ग्राहक को ERP के जानने से पहले बना सकता है; और जब दोनों में असहमति हो तो क्या होता है। ये बाद के लिए इंटीग्रेशन के सवाल नहीं हैं। ये डेटा आर्किटेक्चर के सवाल हैं, और लैंडस्केप ने इन्हें उजागर किया।

इनमें से एक ऐसे काटता है। एक सेल्सपर्सन एक बड़ी बेवरेज कंपनी का lead बदलता है, Account बनाता है, डील जीतता है, और ग्राहक ERP में चला जाता है। लेकिन कंपनी उस बेवरेज कंपनी के साथ सालों से कारोबार कर रही है, और ERP में वह पहले से है। अब दो हो गए। क्या सेल्सपर्सन को वह Account बनाने की इजाज़त होनी भी चाहिए थी? अध्याय 5 और 6 इस पर लौटते हैं; लैंडस्केप वह जगह है जहाँ आप इसे आते हुए देखते हैं।

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

• कौन-से सिस्टम Salesforce को घेरे हुए हैं, और हर एक की भूमिका क्या है।
• हर अहम तरह के डेटा का मालिक कौन-सा सिस्टम है, यह तय करने से पहले कि Salesforce उसका कितना हिस्सा रखे।
• Salesforce में क्या आता है, क्या बाहर जाता है, और क्या वापस आता है।
• Salesforce को कौन-सा डेटा अपने पास रखना (own) चाहिए, कॉपी करना, संदर्भित करना, federate करना, आर्काइव करना या छोड़ देना चाहिए।
• प्लेटफ़ॉर्म और इन्फ़्रास्ट्रक्चर की कौन-सी सीमाएँ मायने रखती हैं, बजाय यह मान लेने के कि Salesforce नाम वाली हर चीज़ एक ही जगह रहती है।

डेवलपर से आर्किटेक्ट बनने का बदलाव अक्सर कोई और फ़ीचर सीखना नहीं होता। यह सीखना होता है कि Salesforce को देखना कब बंद करें: कैमरा पीछे खींचें, डेटा के पीछे चलें, पता करें कि सच का मालिक कौन है, फिर लौटकर तय करें कि Salesforce का काम क्या होना चाहिए।

और जानें

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।