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 कई सिस्टमों में से एक है, और अक्सर वह डेटा का मालिक नहीं होता।

यह तस्वीर 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 करना है।
मॉड्यूल 4 का लैंडस्केप, अपने तीरों के साथ।
इस अध्याय का रास्ता
Section titled “इस अध्याय का रास्ता ”छह मॉड्यूल, हर एक अपने आप में पूरा।
- Salesforce कई सिस्टमों में से एक है। लैंडस्केप बॉक्स से पहले क्यों आता है, वह इंटीग्रेशन जो मैं बार-बार देखता हूँ और वे वापसी वाले flow जिन पर वह निर्भर है, लहरों में आता डेटा, और core, near-core और Hyperforce।
- एंटरप्राइज़ डेटा के प्रकार। छह प्रकार; बनाया गया, एडिट किया गया, संदर्भित; OLTP और OLAP; real time, near real time और batch; श्रेणियों के पीछे के चार सवाल।
- Salesforce के आसपास के सिस्टम। सिस्टमों की भूमिकाएँ; ERP, warehouse और lakehouse; एनालिटिक्स डेटा के पीछे चलता है; MDM; इंटीग्रेशन और events; वह identity provider जिसे डेवलपर भूल जाते हैं; Data 360 कहाँ बैठता है।
- सिस्टम लैंडस्केप बनाएँ। मेरा लेआउट, खाली कैनवस से बनता हुआ; तीरों से पहले शून्य; initiator से शुरू होने वाले तीर; हर तीर के पीछे client और server, दोनों दिशाओं में; बातचीत के लिए swim lanes; तस्वीर के पीछे की इन्वेंटरी।
- org रणनीति लैंडस्केप का फ़ैसला है। एक org से शुरू करें; दूसरा org किस बात से जायज़ होता है; region, provider नहीं; GDPR की वजह से AMER और EMEA में बँटवारा; दूसरा org क्या जोड़ता है।
- Steve Trucking का लैंडस्केप। आज की स्थिति, ठीक से इम्प्लीमेंटेशन होने से पहले, निशान लगाकर: RouteDesk में उतरते मैनिफ़ेस्ट, रूट जिन्हें हाथ से Salesforce में और वापस दोबारा टाइप किया जाता है, GPS डेटा का एक टापू, फ़ाइनेंस को खिलाती एक spreadsheet, और साल में 108,000 “मेरी डिलीवरी कहाँ है?” कॉल।
पूरा करने के बाद, अध्याय की अध्ययन गाइड से ख़ुद को परखें: परीक्षा के लिए एक चेकलिस्ट, उसके आगे की आदतें, जानने लायक शब्द, और कुछ सवाल।
आर्किटेक्ट यहाँ क्या तय करता है
Section titled “आर्किटेक्ट यहाँ क्या तय करता है ”- कौन-से सिस्टम Salesforce को घेरे हुए हैं, और हर एक की भूमिका क्या है।
- हर अहम तरह के डेटा का मालिक कौन-सा सिस्टम है, यह तय करने से पहले कि Salesforce उसका कितना हिस्सा रखे।
- हर कनेक्शन कैसे काम करता है: क्या चलता है, किस दिशा में, वह कैसे ऑथेंटिकेट करता है, कितनी तेज़ी से, और बदले में क्या आता है।
- कितने org, और वे कहाँ चलते हैं, यह सबसे पहले तय होता है, क्योंकि लैंडस्केप पर बाकी सब इसी पर निर्भर है।
- क्या मौजूदा स्थिति इतनी अच्छी तरह समझी गई है कि लक्ष्य स्थिति (target state) डिज़ाइन की जा सके।
परीक्षा से आगे: लैंडस्केप एक एजेंट मैप बनता जा रहा है। इससे पहले कि कोई एजेंट “मेरी डिलीवरी कहाँ है?” का जवाब दे सके, किसी को पता होना चाहिए कि हर तथ्य के लिए कौन-सा सिस्टम आधिकारिक है, वह कितना ताज़ा है, और एजेंट उस तक कैसे पहुँच सकता है। हर मॉड्यूल इस बात के साथ खत्म होता है कि तस्वीर के उसके हिस्से के लिए AI क्या बदलता है।
और जानें
Section titled “और जानें ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
- CTA उम्मीदवारों के लिए आगे पढ़ने को: Salesforce Architects डायग्राम बनाने का अपना मार्गदर्शन प्रकाशित करता है, How to Build Salesforce Diagrams (opens in a new tab) (अंग्रेज़ी में)।
