इसे छोड़कर कंटेंट पर जाएं

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

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)

Data Architect का अध्याय 4, भाग 1: डेटा आर्किटेक्ट बनना। पिछला: Salesforce डेटा आर्किटेक्चर।

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

लोग इस क्रम से हैरान होते हैं। हम डेटा आर्किटेक्ट हैं; क्या हमें डेटा मॉडल से शुरू नहीं करना चाहिए? मैं ऐसा क्यों नहीं करता, यह रहा। अगर मैं पहले डेटा मॉडल बनाता हूँ, तो मैंने पहले ही तय कर लिया कि Salesforce में क्या होना चाहिए। अगर मैं पहले लैंडस्केप बनाता हूँ, तो मुझे वह सब दिखता है जिसे उस फ़ैसले को आकार देना चाहिए: वह ERP जो ग्राहकों और प्रोडक्ट्स का मालिक है, वह warehouse जो पाँच साल वाले सवालों के जवाब देता है, वह identity provider जो तय करता है कि कौन अंदर आए, वह पार्टनर जो हर दोपहर एक फ़ाइल भेजता है, वह पुराना (legacy) सिस्टम जिसके बारे में सब कहते हैं कि वह बंद होने वाला है।

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

धुँधली सुबह में मुख्य आर्किटेक्ट दो सहकर्मियों के लिए व्हाइटबोर्ड पर Salesforce के आसपास सिस्टम लैंडस्केप बना रहा है

यह तस्वीर AI से बनाई गई है।

इस अध्याय के विचार

Section titled “इस अध्याय के विचार ”
  • लैंडस्केप सबसे पहले आता है। सिस्टम ढूँढें, फिर उनके बीच चलने वाला डेटा, फिर यह कि हर टुकड़े का मालिक कौन है। उसके बाद ही तय करें कि Salesforce का काम क्या है।
  • एक तीर दूसरे तीरों पर निर्भर करता है। ERP को बाहर जाने वाले ऑर्डर के लिए पहले ग्राहक, प्रोडक्ट और कीमतें अंदर आनी चाहिए। जब भी मुझे सिर्फ़ एक flow वाला इंटीग्रेशन दिखता है, मुझे चिंता होने लगती है।
  • डेटा के प्रकार होते हैं, और वर्कलोड भी। मास्टर डेटा, रेफ़रेंस डेटा, ट्रांज़ैक्शनल डेटा, मेटाडेटा, एनालिटिकल डेटा और अनस्ट्रक्चर्ड डेटा अलग-अलग तरह बदलते, बढ़ते और इस्तेमाल होते हैं; ऑपरेशनल (OLTP), एनालिटिकल (OLAP) और स्ट्रीमिंग वर्कलोड को अलग-अलग घर चाहिए। org बिज़नेस चलाता है; warehouse और lake उसका विश्लेषण करते हैं।
  • सिस्टमों की भूमिकाएँ होती हैं, सिर्फ़ लोगो नहीं। Record, engagement, reference, insight। “Salesforce हमारा system of record है”: किस चीज़ के लिए?
  • एनालिटिक्स वहीं रहता है जहाँ डेटा रहता है। सब कुछ core पर: स्टैंडर्ड रिपोर्ट। डेटा दूसरे स्टोर में: एक एनालिटिक्स प्लेटफ़ॉर्म, और जब Salesforce डेटा को उसके साथ मिलाया जाए तो warehouse।
  • Data 360 near-core (core के पास) है: core पर मैनेज होता है, core से बाहर होस्ट होता है। यूज़र कभी उससे सीधे नहीं जुड़ते, इसलिए वह plumbing (पाइपलाइन) के साथ बैठता है।
  • ERP के स्वामित्व वाला डेटा स्थानीय रूप से पढ़ा जाता है और नियंत्रण में लिखा जाता है, erp_ prefix के साथ, ताकि स्कीमा दिखाए कि हर फ़ील्ड का मालिक कौन है।
  • लैंडस्केप पर, तीर उस सिस्टम से शुरू होता है जो कनेक्शन खोलता है, और उसका लेबल बताता है कि क्या चलता है और किस दिशा में। दो flow यानी दो तीर; दो सिरों वाला तीर सिर्फ़ connector के लिए है।
  • हर तीर का एक client और एक server होता है, और हर एक अपने आधे हिस्से का मालिक है। इसमें से कुछ भी लैंडस्केप पर नहीं जाता, लेकिन हर तीर में यह होता है।
  • तीर बनाने से पहले गिनें। शून्य इन्वेंटरी में जाते हैं, और वही तरीका चुनते हैं: batch, synchronous या events।
  • org रणनीति लैंडस्केप का फ़ैसला है, जो पहले कुछ मिनटों में होता है: एक org या कई, और वह कहाँ चलता है।
  • मौजूदा स्थिति (current state) दिखाती है कि क्या गलत है। खराब प्रोसेस के लिए लाल, हाथ से होने वाले काम के लिए डैश वाली लाइन, और जो गायब है उसके लिए लाल बिंदु।

Steve का लैंडस्केप लेआउट

Section titled “Steve का लैंडस्केप लेआउट ”

सिस्टम लैंडस्केप बनाने के कई तरीके हैं। यह मेरा तरीका है, कई सालों में निखरा हुआ, और यह एक वाक्य की तरह पढ़ा जाता है: बाईं ओर के लोग बीच में Salesforce तक पहुँचते हैं, जिस पर भरोसा उसके ऊपर के सिस्टमों से आता है, जो उसके नीचे के चैनलों से सेवा देता है, और जो दाईं ओर बैक ऑफ़िस से जुड़ा है।

कहाँवहाँ क्या जाता है
बाईं ओरलोग, ऊपर से नीचे: आंतरिक यूज़र, पार्टनर, ग्राहक
बीच मेंSalesforce, एक सादा बॉक्स, नीचे उससे सटी उसकी communities
ऊपरSalesforce के ऊपर identity providers; AppExchange थोड़ा दाईं ओर; पब्लिक वेबसाइटें ऊपर बाईं ओर
दाईं ओरइंटीग्रेशन लेयर, फिर आंतरिक सिस्टम: ERP, फ़ाइनेंस, warehouse
इंटीग्रेशन लेयर के नीचेData 360, near-core, plumbing के साथ
नीचेग्राहक चैनल: ईमेल, वेब फ़ॉर्म, फ़ोन, मैसेजिंग
नीचे दाईं ओरअंदर-बाहर आने-जाने वाला डेटा: आर्काइव, डेटा लोड, बाहरी स्रोत, पार्टनर

सिस्टम हल्के, लेबल वाले ज़ोन में कार्ड होते हैं, हर एक का एक आइकन होता है, और एक legend बताता है कि हर चीज़ का मतलब क्या है। तस्वीर के पीछे एक इन्वेंटरी होती है: हर डेटा सेट या flow के लिए उसका मालिक, वॉल्यूम, तरीका और टाइमिंग, ऑथेंटिकेशन, और यह कि उसे कॉपी करना है, संदर्भित करना है या federate करना है।

तीरों के साथ लैंडस्केप पहले वाला ही लैंडस्केप, अब तीरों के साथ; हर तीर उस सिस्टम से शुरू होता है जो कनेक्शन खोलता है, और उसका लेबल बताता है कि क्या जाता है और किस दिशा में। आंतरिक यूज़र Salesforce तक पहुँचते हैं, पार्टनर यूज़र Partner Community तक, और ग्राहक Customer Community तक। हर आइडेंटिटी प्रोवाइडर और Salesforce एक सर्टिफ़िकेट साझा करते हैं, जो हरी बिंदुदार लाइन से दिखाया गया है और जिसके दोनों सिरों पर एक सर्टिफ़िकेट है: यह भरोसा है, सीधी कॉल नहीं, क्योंकि साइन-ऑन यूज़र के ब्राउज़र से होकर redirects के रूप में जाता है। कर्मचारियों का आइडेंटिटी प्रोवाइडर Salesforce को यूज़र अपडेट भी भेजता है। Salesforce AppExchange के ई-सिग्नेचर ऐप को दस्तावेज़ बाहर भेजता है, और इंटीग्रेशन लेयर को ऑर्डर बाहर भेजता है, जो Salesforce को प्रोडक्ट अंदर भेजती है। इंटीग्रेशन लेयर ERP को ऑर्डर बाहर भेजती है और उससे प्रोडक्ट अंदर लाती है; ERP इंटीग्रेशन लेयर को ऑर्डर स्टेटस अंदर भेजता है; इंटीग्रेशन लेयर फ़ाइनेंस से भुगतान अंदर लाती है। इंटीग्रेशन लेयर के नीचे Data 360 अपने कनेक्शन खुद खोलता है: Salesforce से CRM डेटा बाहर, वेयरहाउस तक zero copy, और बाहरी डेटा का संदर्भ। नीचे से, ईमेल Salesforce में Case अंदर भेजता है और वेब फ़ॉर्म Lead अंदर भेजते हैं; Salesforce पुराने Case आर्काइव में बाहर भेजता है; डेटा लोड रिकॉर्ड अंदर भेजते हैं। ऊपर: आइडेंटिटी, APPEXCHANGE, वेब लोग दाएँ: आंतरिक सिस्टम नीचे: ग्राहक चैनल नीचे दाएँ: डेटा का आना-जाना आंतरिक यूज़र सेल्स, सर्विस, ऑपरेशंस पार्टनर यूज़र ग्राहक पब्लिक वेबसाइट कर्मचारियों का IdP सिंगल साइन-ऑन पार्टनर्स का IdP सिंगल साइन-ऑन AppExchange ऐप ई-सिग्नेचर Partner Community Customer Community Data 360 near-core: core पर मैनेज, core से बाहर होस्ट इंटीग्रेशन लेयर (ESB) ERP ऑर्डर, इनवॉइस फ़ाइनेंस भुगतान ऑर्डर मैनेजमेंट वेयरहाउस एनालिटिक्स ईमेल email-to-case वेब फ़ॉर्म web-to-lead फ़ोन कॉन्टैक्ट सेंटर मैसेजिंग SMS, चैट आर्काइव पुराने Case डेटा लोड माइग्रेशन बाहरी डेटा संदर्भित, कॉपी नहीं Salesforce वह org जिसके इर्द-गिर्द हम डिज़ाइन करते हैं साझा सर्टिफ़िकेट यूज़र अपडेट साझा सर्टिफ़िकेट दस्तावेज़ बाहर ऑर्डर बाहर प्रोडक्ट अंदर ऑर्डर बाहर, प्रोडक्ट अंदर ऑर्डर स्टेटस अंदर भुगतान अंदर CRM डेटा बाहर zero copy संदर्भित Case अंदर Lead अंदर पुराने Case बाहर रिकॉर्ड अंदर Salesforce एक कम्युनिटी लोग आइडेंटिटी, ऐप्स, वेब एक आंतरिक सिस्टम एक ग्राहक चैनल डेटा का आना-जाना इंटीग्रेशन लेयर डैश वाली: अभी लाइव नहीं, या सिर्फ़ संदर्भ कनेक्शन खोलने वाले सिस्टम से शुरू होता है; लेबल बताता है कि क्या जाता है साझा सर्टिफ़िकेट: भरोसा, सीधी कॉल नहीं © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

मॉड्यूल 4 का लैंडस्केप, अपने तीरों के साथ।

इस अध्याय का रास्ता

Section titled “इस अध्याय का रास्ता ”

छह मॉड्यूल, हर एक अपने आप में पूरा।

  1. Salesforce कई सिस्टमों में से एक है। लैंडस्केप बॉक्स से पहले क्यों आता है, वह इंटीग्रेशन जो मैं बार-बार देखता हूँ और वे वापसी वाले flow जिन पर वह निर्भर है, लहरों में आता डेटा, और core, near-core और Hyperforce।
  2. एंटरप्राइज़ डेटा के प्रकार। छह प्रकार; बनाया गया, एडिट किया गया, संदर्भित; OLTP और OLAP; real time, near real time और batch; श्रेणियों के पीछे के चार सवाल।
  3. Salesforce के आसपास के सिस्टम। सिस्टमों की भूमिकाएँ; ERP, warehouse और lakehouse; एनालिटिक्स डेटा के पीछे चलता है; MDM; इंटीग्रेशन और events; वह identity provider जिसे डेवलपर भूल जाते हैं; Data 360 कहाँ बैठता है।
  4. सिस्टम लैंडस्केप बनाएँ। मेरा लेआउट, खाली कैनवस से बनता हुआ; तीरों से पहले शून्य; initiator से शुरू होने वाले तीर; हर तीर के पीछे client और server, दोनों दिशाओं में; बातचीत के लिए swim lanes; तस्वीर के पीछे की इन्वेंटरी।
  5. org रणनीति लैंडस्केप का फ़ैसला है। एक org से शुरू करें; दूसरा org किस बात से जायज़ होता है; region, provider नहीं; GDPR की वजह से AMER और EMEA में बँटवारा; दूसरा org क्या जोड़ता है।
  6. Steve Trucking का लैंडस्केप। आज की स्थिति, ठीक से इम्प्लीमेंटेशन होने से पहले, निशान लगाकर: RouteDesk में उतरते मैनिफ़ेस्ट, रूट जिन्हें हाथ से Salesforce में और वापस दोबारा टाइप किया जाता है, GPS डेटा का एक टापू, फ़ाइनेंस को खिलाती एक spreadsheet, और साल में 108,000 “मेरी डिलीवरी कहाँ है?” कॉल।

पूरा करने के बाद, अध्याय की अध्ययन गाइड से ख़ुद को परखें: परीक्षा के लिए एक चेकलिस्ट, उसके आगे की आदतें, जानने लायक शब्द, और कुछ सवाल।

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

Section titled “आर्किटेक्ट यहाँ क्या तय करता है ”
  • कौन-से सिस्टम Salesforce को घेरे हुए हैं, और हर एक की भूमिका क्या है।
  • हर अहम तरह के डेटा का मालिक कौन-सा सिस्टम है, यह तय करने से पहले कि Salesforce उसका कितना हिस्सा रखे।
  • हर कनेक्शन कैसे काम करता है: क्या चलता है, किस दिशा में, वह कैसे ऑथेंटिकेट करता है, कितनी तेज़ी से, और बदले में क्या आता है।
  • कितने org, और वे कहाँ चलते हैं, यह सबसे पहले तय होता है, क्योंकि लैंडस्केप पर बाकी सब इसी पर निर्भर है।
  • क्या मौजूदा स्थिति इतनी अच्छी तरह समझी गई है कि लक्ष्य स्थिति (target state) डिज़ाइन की जा सके।

परीक्षा से आगे: लैंडस्केप एक एजेंट मैप बनता जा रहा है। इससे पहले कि कोई एजेंट “मेरी डिलीवरी कहाँ है?” का जवाब दे सके, किसी को पता होना चाहिए कि हर तथ्य के लिए कौन-सा सिस्टम आधिकारिक है, वह कितना ताज़ा है, और एजेंट उस तक कैसे पहुँच सकता है। हर मॉड्यूल इस बात के साथ खत्म होता है कि तस्वीर के उसके हिस्से के लिए AI क्या बदलता है।

अगला: डेटा गुणवत्ता और गवर्नेंस