अपने टूल्स को जानें: नौ सवाल

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

मॉड्यूल 6 (कुल 7 में से) — अध्याय डेटा आर्किटेक्ट की तरह सोचना, Data Architect कोर्स का अध्याय 1। हर मॉड्यूल अपने आप में पूरा है। पिछला: आज के लिए बनाएँ। कल की योजना बनाएँ। विफलता की योजना बनाएँ। · अगला: AI के दौर में डेटा आर्किटेक्ट

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

आर्किटेक्ट्स को समझ-बूझ चाहिए। लेकिन ज्ञान के बिना समझ-बूझ बहुत काम की नहीं। आपको फिर भी अपने टूल्स जानने होंगे।

मैं बरसों से आर्किटेक्ट्स को पढ़ा रहा हूँ, और मेरा एक फ़्रेमवर्क सवालों का एक सेट है, जिनका जवाब आपको अपने आर्किटेक्चर के हर अहम टूल या क्षमता के बारे में दे पाना चाहिए। शुरू में मैं आठ सवाल पढ़ाता था। मैंने एक नौवाँ जोड़ा है। टेक्नोलॉजी बदलती है, Salesforce बदलता है, नए प्रोडक्ट आते हैं और पुरानी क्षमताएँ विकसित होती हैं, और AI इस सबको और तेज़ कर रहा है। ये सवाल काम करते रहते हैं।

नौ सवाल

जब भी आप कोई टेक्नोलॉजी सीख रहे हों या परख रहे हों, पूछें:

1. यह क्या है?
2. यह कहाँ इस्तेमाल होता है?
3. मैं इसे कैसे इस्तेमाल करूँ?
4. मेरे पास और क्या विकल्प हैं?
5. इसकी खूबियाँ क्या हैं?
6. इसकी कमज़ोरियाँ क्या हैं?
7. मैं इसे डेवलपर्स, बिज़नेस और एग्ज़िक्यूटिव्स को कैसे समझाऊँ?
8. लंबे समय तक इसका रखरखाव कैसे होता है?
9. इसकी लागत क्या है, इसके लिए कौन-सी लाइसेंसिंग चाहिए, और इसकी सीमाएँ क्या हैं?

अगर आप सभी नौ सवालों का जवाब दे सकते हैं, तो आप टूल को एक आर्किटेक्ट की तरह समझने लगे हैं। ध्यान दें कि सूची में क्या नहीं है: “क्या मैं इसे कॉन्फ़िगर कर सकता हूँ?” यह मायने रखता है, लेकिन यह टूल को जानने का सिर्फ़ एक हिस्सा है।

Click to enlarge

1. यह क्या है?

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

2. यह कहाँ इस्तेमाल होता है?

कोई चीज़ क्या करती है यह जानना, और यह जानना कि वह आर्किटेक्चर में कब सही बैठती है, एक बात नहीं है। यह किस तरह की समस्याओं में अच्छा है? कौन-सी परिस्थितियाँ इसे उपयुक्त बनाती हैं, और किन परिस्थितियों में मुझे इस पर शक होना चाहिए? यह “मैं यह फ़ीचर जानता हूँ” से “मैं वह समस्या पहचानता हूँ जिसे यह फ़ीचर हल करता है” तक का कदम है, और यह एक बड़ा कदम है। आप अपनी पसंदीदा टेक्नोलॉजी इस्तेमाल करने की जगहें ढूँढ़ते हुए नहीं घूमना चाहते। आप समस्याएँ पहचानना चाहते हैं और जानना चाहते हैं कि कौन-से टूल उनमें फ़िट होते हैं।

3. मैं इसे कैसे इस्तेमाल करूँ?

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

4. मेरे पास और क्या विकल्प हैं?

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

5. इसकी खूबियाँ क्या हैं?

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

6. इसकी कमज़ोरियाँ क्या हैं?

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

7. मैं इसे अलग-अलग लोगों को कैसे समझाऊँ?

यह उन सवालों में से एक है जो तकनीकी ज्ञान को आर्किटेक्चरल हुनर से अलग करते हैं। क्या आप एक ही टेक्नोलॉजी को डेवलपर, बिज़नेस और एग्ज़िक्यूटिव को समझा सकते हैं? ये एक जैसी व्याख्या नहीं होनी चाहिए। डेवलपर को API, ट्रांज़ैक्शन का बर्ताव, सिक्योरिटी, विफलता को संभालना और इम्प्लीमेंटेशन पैटर्न चाहिए। बिज़नेस की परवाह इस बात की है कि इससे क्या संभव होता है और उनका प्रोसेस कैसे बदलता है। एग्ज़िक्यूटिव की परवाह लागत, जोखिम, समय, संगठन पर असर, और इस बात की है कि यह फ़ैसला कौन-से विकल्प खुले रखता है या बंद करता है। आप सच नहीं बदल रहे; आप अमूर्तता का स्तर (level of abstraction) बदल रहे हैं। अगर आप किसी टेक्नोलॉजी को सिर्फ़ उसके डॉक्यूमेंटेशन की शब्दावली में ही समझा सकते हैं, तो अपनी समझ पर काम करते रहें।

8. लंबे समय तक इसका रखरखाव कैसे होता है?

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

9. इसकी लागत क्या है, इसके लिए कौन-सी लाइसेंसिंग चाहिए, और इसकी सीमाएँ क्या हैं?

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

फिर सीमाएँ हैं, और हर प्लेटफ़ॉर्म की होती हैं: API, स्टोरेज, क्वेरी, ट्रांज़ैक्शन, समवर्तिता (concurrency), थ्रूपुट और लाइसेंसिंग की सीमाएँ। कुछ सख्त हैं, कुछ लचीली; कुछ बढ़ाई जा सकती हैं और कुछ नहीं; कुछ हमारे पैमाने पर तब तक मायने नहीं रखतीं जब तक हम एक शून्य और न जोड़ दें। आपको Salesforce की हर सीमा रटनी नहीं है, और ऐसा करना आपके समय का बेहद खराब इस्तेमाल होगा। आपको यह जानना है कि सीमाएँ मौजूद हैं, उनमें से कौन-सी आपके आर्किटेक्चर के लिए मायने रखती हैं, और कब जाकर मौजूदा संख्या की जाँच करनी है। संख्याएँ बदलेंगी। आर्किटेक्चर का सवाल बना रहेगा।

एक हल किया हुआ उदाहरण: Apex sharing

सवालों को काम करते दिखाने के लिए यह मेरे सबसे आम उदाहरणों में से एक है। हमें पेचीदा शेयरिंग की ज़रूरत मिलती है, ऐसी शेयरिंग जो owner-based या criteria-based किसी भी शेयरिंग रूल से पूरी नहीं हो सकती। इससे हम Apex sharing तक पहुँचते हैं: ऐसा कोड जो शेयरिंग रिकॉर्ड खुद लिखता है। तो अब हमें जानना है कि Apex sharing क्या है, कहाँ इस्तेमाल होता है, इसे कैसे इस्तेमाल करें, और बाकी सब। यह एक कदम ऊपर जाना है: जब हमें चाहिए नियम owner-based और criteria-based शेयरिंग की पहुँच से आगे जाते हैं, तब Apex sharing विकल्प (सवाल 4) है।

अब इसकी कमज़ोरियाँ (सवाल 6)। मान लीजिए हमारी एक customer community है जिसके 10 या 20 मिलियन सदस्य हैं, और हम Customer Community लाइसेंस इस्तेमाल करते हैं, Customer Community Plus नहीं। ये high-volume यूज़र्स हैं। उनके रोल नहीं होते, और वे शेयरिंग मॉडल बिल्कुल इस्तेमाल नहीं करते: उनका एक्सेस sharing sets और share groups से आता है, जो उनके account और contact के ज़रिए मिलाया जाता है। उनके लिए Apex के लिखने को कोई share रिकॉर्ड ही नहीं है, इसलिए उनके लिए Apex sharing काम नहीं करता। और लागत और लाइसेंसिंग का सवाल (सवाल 9) ही हमें यहाँ लाया: लाइसेंस के चुनाव ने तय किया कि कौन-से शेयरिंग टूल मौजूद भी हैं।

तो जैसे Apex sharing owner-based और criteria-based नियमों का विकल्प था, वैसे ही आपके सामने ऐसा मामला आ सकता है जहाँ आपको Apex sharing का विकल्प चाहिए। और उस मोड़ पर पेचीदा शेयरिंग नियमों के लिए असल में कॉन्फ़िगरेशन वाला कोई विकल्प नहीं होता। आखिर में आप ऑब्जेक्ट को read-only बना देते हैं और एक्सेस को Apex से नियंत्रित करते हैं। इसीलिए आप चुनने से पहले सभी नौ सवाल पूछते हैं, बाद में नहीं।

प्लेटफ़ॉर्म को रटें नहीं

Salesforce आर्किटेक्चर सीखते समय यह सबसे ज़्यादा मायने रखता है। Salesforce को रटने की कोशिश न करें। आप रट नहीं सकते: प्लेटफ़ॉर्म बहुत बड़ा है, और बहुत तेज़ी से बदलता है। मैं लंबे समय से Salesforce के साथ काम कर रहा हूँ, और मैं अब भी सीख रहा हूँ। यह सामान्य है।

मैं चाहता हूँ कि आप सीखने का एक फ़्रेमवर्क विकसित करें। जब Salesforce कल कोई नई क्षमता रिलीज़ करे, तो मुझे उसे पहले देखा होना ज़रूरी नहीं। मुझे पता है कि क्या पूछना है: यह क्या है, यह कहाँ फ़िट होता है, मैं इसे कैसे इस्तेमाल करूँ, मैं और क्या इस्तेमाल कर सकता हूँ, यह किसमें अच्छा है, कहाँ यह जूझता है, मैं इसे कैसे समझाऊँ, मैं इसे कैसे चलाऊँ, और इसकी लागत क्या है और सीमाएँ कहाँ हैं? अब मैं इसे परखना शुरू कर सकता हूँ। यह एक और फ़ीचर मैट्रिक्स रटने से कहीं ज़्यादा कीमती है।

परीक्षा से आगे: AI नौ सवालों के जवाब तेज़ी से देता है, और उनमें गलती करना भी आसान बना देता है। कोई ऐसी टेक्नोलॉजी सामने आए जिसे आप नहीं जानते, तो आप AI से उसे समझाने, तीन तरीकों की तुलना करने, उसकी सीमाएँ और आम विफलताएँ गिनाने, या उसे इस्तेमाल न करने के पक्ष में तर्क देने को कह सकते हैं। यह कमाल का रिसर्च असिस्टेंट है। लेकिन यह गलत हो सकता है, पुराना हो सकता है, या पूरे भरोसे से मिलते-जुलते नाम वाले दो प्रोडक्ट या एडिशन को आपस में मिला सकता है। जो कुछ भी किसी फ़ैसले पर असर डाले, उसकी जाँच करें: सोर्स तक जाएँ और मौजूदा डॉक्यूमेंटेशन, सीमाएँ और लाइसेंसिंग जाँचें। भरोसा करें, पर जाँचें (मॉड्यूल 7)।

सवाल सीखें, सिर्फ़ जवाब नहीं

इस कोर्स में हम बहुत सारी टेक्नोलॉजी से मिलेंगे। मैं नहीं चाहता कि आप जवाब इकट्ठा करें; मैं चाहता हूँ कि आप सवालों का अभ्यास करें। जब हम big objects, बाहरी डेटा, Data 360, इंटीग्रेशन पैटर्न, या Salesforce की उस AI क्षमता की बात करें जो इस अध्याय के लिखे जाने के छह महीने बाद रिलीज़ हो, तो वही नौ सवाल पूछें।

जवाब बदलेंगे। सवाल टिकाऊ हैं। यही इसे एक अध्ययन गाइड के बजाय आर्किटेक्चर फ़्रेमवर्क बनाता है।

अपने टूल्स को जानें: वे किसमें अच्छे हैं, किसमें खराब, आप और क्या इस्तेमाल कर सकते हैं, उनकी लागत क्या है और वे कहाँ टूटते हैं। और इतना जानें कि उन लोगों को फ़ैसला समझा सकें जिन्हें उसके साथ जीना है। एक आर्किटेक्ट टेक्नोलॉजी ऐसे ही सीखता है।

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

• कोई टूल समस्या में फ़िट होता है या नहीं, सभी नौ सवालों पर परखकर, सिर्फ़ इस पर नहीं कि वह कॉन्फ़िगर हो सकता है या नहीं।
• विकल्प क्या हैं, और आपके पैमाने पर टूल की लागत, लाइसेंसिंग और सीमाओं का क्या मतलब है।
• तीन साल बाद इसका रखरखाव कौन करेगा, और कैसे।
• टूल के बारे में कौन-से तथ्य उन पर भरोसा करने से पहले जाँचने हैं।

और जानें

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): high-volume यूज़र्स (External Apps, Customer Community, High Volume Customer Portal और Authenticated Website लाइसेंस) के रोल नहीं होते; उनका एक्सेस sharing sets और share groups से आता है; उन्हें owner-based शेयरिंग रूल में शामिल नहीं किया जा सकता, और जिन रिकॉर्ड के वे मालिक हैं उन्हें मैनुअली शेयर नहीं किया जा सकता।
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): high-volume यूज़र्स (Customer Community, High Volume Customer Portal, Authenticated Website) शेयरिंग मॉडल इस्तेमाल नहीं करते, क्योंकि उनके लाइसेंस रोल सपोर्ट नहीं करते; एक्सेस यूज़र को Account और Contact lookups से मिलाकर, sharing sets या share groups के ज़रिए काम करता है। उसी पेज पर यह भी है कि Apex managed sharing कब सही टूल है।
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Trailblazer Community का सवाल, नवंबर 2024 (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): एक प्रैक्टिशनर बताता है कि high-volume यूज़र्स के लिए share रिकॉर्ड डालने पर एरर आया। यह मैदान से आई रिपोर्ट है, आधिकारिक डॉक्यूमेंटेशन नहीं। (ऑनलाइन Trailblazer Community 30 अक्टूबर 2026 को read-only हो जाएगी; लिंक बदल सकता है।)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया): sharing set यूज़र के account या contact से जुड़े रिकॉर्ड का एक्सेस देता है।