पलटने की कसौटी

🌐 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 (कुल 7 में से) — अध्याय डेटा आर्किटेक्ट की तरह सोचना, Data Architect कोर्स का अध्याय 1। हर मॉड्यूल अपने आप में पूरा है। पिछला: डेटा मॉडल ही हड्डियाँ है · अगला: आर्किटेक्चर ट्रेड-ऑफ़ की कला है

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

आर्किटेक्ट बहुत सारे फ़ैसले लेते हैं।

लेकिन हर फ़ैसला आर्किटेक्चरल फ़ैसला नहीं होता।

यह एक अहम फ़र्क है। अगर हम हर फ़ैसले को आर्किटेक्चर मान लें, तो हम अपना सारा समय उन चीज़ों पर बहस में लगा देंगे जिन्हें बदलना अपेक्षाकृत आसान है। अगर हम उन फ़ैसलों को न पहचानें जो सच में आर्किटेक्चरल हैं, तो हम आज पाँच मिनट में ऐसा फ़ैसला ले सकते हैं जिसे सुलझाने में पाँच साल लगें।

तो हम फ़र्क कैसे पहचानें?

मुझे एक सीधा सवाल पूछना पसंद है:

बाद में इस फ़ैसले को पलटना कितना मुश्किल होगा?

मैं इसे पलटने की कसौटी (Reversibility Test) कहता हूँ।

किसी चीज़ को पलटना जितना मुश्किल हो, और उस पर जितनी ज़्यादा दूसरी चीज़ें निर्भर होंगी, वह उतने ही ज़्यादा आर्किटेक्चरल ध्यान की हकदार है।

कुछ फ़ैसले बदलना सस्ता होता है

चलिए कुछ सीधी चीज़ से शुरू करते हैं।

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

हमने एक फ़ैसला लिया। हमने मन बदला। हम आगे बढ़ गए।

अब इसकी तुलना एक अलग फ़ैसले से करें।

हम ग्राहकों के लिए एक आइडेंटिफ़ायर बना रहे हैं। हम तय करते हैं कि उसका मतलब क्या है, उसका फ़ॉर्मेट क्या है, और कौन-सा सिस्टम उसे बनाता है। फिर हम उसे प्रकाशित कर देते हैं।

Salesforce उसे इस्तेमाल करता है। डेटा वेयरहाउस उसे इस्तेमाल करता है। इंटीग्रेशन प्लेटफ़ॉर्म उसे इस्तेमाल करता है। कस्टमर पोर्टल उसे इस्तेमाल करता है। पाँच दूसरे एप्लिकेशन उसे स्टोर करने लगते हैं। रिपोर्ट और डेटा पाइपलाइन उसे इस्तेमाल करती हैं। शायद आखिरकार ग्राहक भी उसे देखने लगते हैं।

तीन साल बाद कोई कहता है:

शायद हमें आइडेंटिफ़ायर को उस तरह डिज़ाइन नहीं करना चाहिए था।

यह बिल्कुल अलग बातचीत है।

फ़र्क यह नहीं है कि एक फ़ैसला दूसरे से ज़्यादा तकनीकी है।

फ़र्क है पलटे जा सकने का।

यह ऐसे हो सकता है। मान लीजिए बिज़नेस अपनी keys ग्राहक के नाम के एक हिस्से और एक नंबर से बनाता आ रहा है। यह बरसों चलता है, क्योंकि किसी को कभी नाम बदलना नहीं पड़ा। फिर, एक साल या उससे ज़्यादा बाद, कोई नाम बदल जाता है, और अचानक keys उस पैटर्न से मेल नहीं खातीं जिसकी बाकी डेटा को उम्मीद है। यह एक वजह है कि keys में अपना कोई अंतर्निहित अर्थ नहीं होना चाहिए।

आर्किटेक्चर गुरुत्व पैदा करता है

एक आर्किटेक्चरल फ़ैसला अपने आसपास चीज़ें जमा करता जाता है। मैं इसे गुरुत्व मानता हूँ।

एक ऑब्जेक्ट मॉडल चुनें, और उसके इर्द-गिर्द ऑटोमेशन बनने लगता है।

एक key चुनें, और दूसरे सिस्टम उसे स्टोर करने लगते हैं।

चुनें कि मास्टर डेटा कहाँ रहेगा, और इंटीग्रेशन उसकी ओर और उससे दूर बहने लगते हैं।

एक शेयरिंग मॉडल चुनें, और बिज़नेस प्रोसेस इस पर निर्भर होने लगते हैं कि कौन क्या देख सकता है।

एक इंटीग्रेशन पैटर्न चुनें, और सिस्टम उसकी टाइमिंग और व्यवहार पर निर्भर होने लगते हैं।

ये फ़ैसले जितने लंबे समय तक रहते हैं, उनका गुरुत्व उतना बढ़ता जाता है। आखिरकार, मूल फ़ैसले को बदलने का मतलब होता है उसके आसपास जमा हुई हर चीज़ को बदलना।

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

इसीलिए डेटा मॉडल का “हड्डियाँ” होना मायने रखता है। हम इसलिए सावधान नहीं हैं कि बदलाव बुरा है। हम इसलिए सावधान हैं क्योंकि निर्भरताएँ बदलाव को महँगा बना देती हैं।

दो सवाल पूछें

जब मैं किसी डिज़ाइन फ़ैसले को देखता हूँ, तो दो सवाल पूछता हूँ:

इसे पलटना कितना मुश्किल है?

इस पर कितना कुछ निर्भर होगा?

ये जुड़े हुए हैं, पर एक जैसे नहीं। कोई चीज़ तकनीकी रूप से बदलने में आसान हो सकती है पर उसके सैकड़ों उपभोक्ता हो सकते हैं। लोग स्पष्टता के लिए स्टैंडर्ड ऑब्जेक्ट को नया लेबल दे दिया करते थे, जैसे Account को “Customer”। करना आसान था। फिर किसी दूसरे सिस्टम को Partners के लिए Accounts इस्तेमाल करने थे, और वह नहीं कर पाया। किसी दूसरी चीज़ के शायद कुछ ही उपभोक्ता हों पर उसे बदलने के लिए बहुत बड़ा माइग्रेशन चाहिए, जैसे किसी ऑब्जेक्ट का API नाम जो अंदर कई जगह रेफ़र होता है। बाहर कोई उसे नहीं देखता, पर गलत नाम टीम को उलझाता रहता है। दोनों ही ध्यान के हकदार हैं।

कुछ आम डेटा फ़ैसलों के बारे में सोचें:

• कौन-सा Salesforce ऑब्जेक्ट इस बिज़नेस कॉन्सेप्ट को दर्शाता है?
• यूनिक ID क्या है?
• कौन-सा सिस्टम system of record है?
• क्या यह डेटा Salesforce में कॉपी होता है या कहीं और से एक्सेस किया जाता है?
• क्या यह एक ऑब्जेक्ट है या कई जुड़े हुए ऑब्जेक्ट?
• डेटा का मालिक कौन है, और हम उसे कितने समय तक रखते हैं?
• हमारी डिफ़ॉल्ट एक्सेस सीमाएँ क्या हैं?
• यह डेटा सिस्टमों के बीच कैसे आता-जाता है?

ये यह तय करने से बहुत अलग हैं कि कोई फ़ील्ड Lightning पेज पर कहाँ दिखे। पेज डिज़ाइन भी मायने रखता है। पर गलत होने की कीमत अलग है।

Click to enlarge

असर के दायरे के बारे में सोचें

पलटे जा सकने के बारे में सोचने का एक और तरीका है असर का दायरा (blast radius): अगर मैं यह फ़ैसला बदलूँ, तो और क्या-क्या हिलेगा?

मान लीजिए जिसे हमने फ़ील्ड के रूप में मॉडल किया था, उसे असल में चाइल्ड ऑब्जेक्ट बनना है। यह सिर्फ़ स्कीमा का बदलाव नहीं है। मौजूदा डेटा का क्या होगा? रिपोर्ट, उस फ़ील्ड की उम्मीद करने वाले इंटीग्रेशन, उसे रेफ़र करने वाले Apex और Flows, सिक्योरिटी, एनालिटिक्स, और ऐसे AI एजेंट का क्या होगा जिसके एक्शन मूल ढाँचे पर निर्भर हैं?

दायरा जितना बड़ा हो, मूल फ़ैसला उतनी ही सावधानी से लेना चाहिए।

इसीलिए आर्किटेक्ट्स को सिस्टम के अपने हिस्से से आगे भी देखना होता है। Salesforce के अंदर से कोई बदलाव आसान लग सकता है। एंटरप्राइज़ के स्तर पर वह बारह दूसरे सिस्टमों पर असर डाल सकता है।

एंटरप्राइज़ के फ़ैसले और Salesforce के फ़ैसले

एक Data Architect दो स्तरों पर सोचता है।

Salesforce के अंदर, हम ऑब्जेक्ट, संबंध, keys, वॉल्यूम, एक्सेस, ऑटोमेशन तय करते हैं, और यह कि प्लेटफ़ॉर्म पर डेटा कैसे बर्ताव करता है।

पूरे एंटरप्राइज़ में, हम बड़े सवाल पूछते हैं। Customer असल में कहाँ रहता है? Product का मालिक कौन है? कौन-सा सिस्टम Order बनाता है? हमारा आधिकारिक आइडेंटिफ़ायर क्या है? कौन-सी जानकारी सिस्टमों के बीच कॉपी होती है, और कौन-सी जहाँ है वहीं रहती है?

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

आर्किटेक्चर दो-तरफ़ा ट्रैफ़िक है।

Click to enlarge

महँगे फ़ैसलों पर रुककर सोचें

टेक्नोलॉजी में एक खतरा यह है कि जो फ़ैसले लागू करने में सबसे आसान हैं, वे लेने में भी सबसे आसान लग सकते हैं। ये दोनों एक बात नहीं हैं।

एक और कस्टम ऑब्जेक्ट बनाना आसान है। एक और फ़ील्ड बनाना आसान है। एक और API जोड़ना आसान होता जा रहा है, और AI यह सब और भी आसान बना देता है।

लेकिन लागू करने की आसानी हमें आर्किटेक्चरल फ़ैसले की कीमत के बारे में लगभग कुछ नहीं बताती।

किसी मुश्किल से पलटने वाले फ़ैसले से पहले, इतनी देर रुकें कि ये पूछ सकें: हम असल में कौन-सी समस्या हल कर रहे हैं? हमने किन विकल्पों पर विचार किया? हम क्या मानकर चल रहे हैं? वॉल्यूम बढ़ने पर, और बिज़नेस बदलने पर क्या होगा? इस पर और क्या निर्भर होगा? अगर हम गलत निकले तो क्या होगा?

हर बार ऑब्जेक्ट बनाते समय हमें छह महीने की समीक्षा नहीं चाहिए। हमें गलत होने की कीमत के अनुपात में सोच-विचार ज़रूर चाहिए। अगर यह किसी एक विभाग या सबसिस्टम का ऑब्जेक्ट है, तो आप ज़्यादा तेज़ी से आगे बढ़ सकते हैं। अगर यह रेफ़रेंस डेटा है, कोई अहम कस्टमर ऑब्जेक्ट है, या कई सिस्टमों में इस्तेमाल होने वाली चीज़ है, तो इसे पूरी तरह सोचने के लिए समय लें।

लिख लें कि क्यों

अहम फ़ैसलों के साथ एक और समस्या है: लोग भूल जाते हैं कि वे क्यों लिए गए थे।

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

अगर हम सिर्फ़ यह दर्ज करें कि हमने क्या तय किया और यह नहीं कि क्यों, तो अगले आर्किटेक्ट के पास जानने का कोई तरीका नहीं होता।

अहम फ़ैसलों के लिए, उसे लिख लें। इसके लिए 50 पेज का डॉक्यूमेंट ज़रूरी नहीं। एक काम का निर्णय रिकॉर्ड बहुत छोटा हो सकता है:

संदर्भ: हम कौन-सी समस्या हल कर रहे हैं?

विकल्प: हमने किन व्यावहारिक विकल्पों पर विचार किया?

फ़ैसला: हमने क्या चुना?

नतीजे: हमें क्या मिलता है, और हम क्या छोड़ रहे हैं?

मालिक: इस फ़ैसले के लिए जवाबदेह कौन है?

समीक्षा: कौन-सी वजह या तारीख हमें इस पर दोबारा विचार करवाएगी?

असली वैल्यू डॉक्यूमेंट में नहीं है। असली वैल्यू तर्क को सहेजने में है।

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

Click to enlarge

परीक्षा से आगे: AI फ़ैसले से निर्भरता तक का समय घटा देता है। एक AI टूल सेकंडों में डेटा मॉडल सुझा सकता है, फिर उसके ऊपर ऑब्जेक्ट, ऑटोमेशन, इंटीग्रेशन कोड और यूज़र इंटरफ़ेस बना सकता है। पहले किसी संदिग्ध फ़ैसले पर बहुत कुछ निर्भर होने में महीनों का डेवलपमेंट लगता था; अब निर्भरताएँ लगभग तुरंत आ जाती हैं। इसलिए सिर्फ़ आउटपुट की नहीं, आउटपुट के नीचे के फ़ैसलों की समीक्षा करें। AI मदद कर सकता है: वह विकल्पों की सूची बना सकता है, मान्यताओं को चुनौती दे सकता है और निर्णय रिकॉर्ड का ड्राफ़्ट बना सकता है। लेकिन फ़ैसला फिर भी आर्किटेक्ट लेता है, और फ़ैसला पलटना जितना मुश्किल हो, इंसानी समझ उतनी ही ज़्यादा मायने रखती है।

जानें कि कौन-से फ़ैसले मायने रखते हैं

एक हुनर जो मैं चाहता हूँ कि आप विकसित करें, वह है यह जानना कि अपना ध्यान कहाँ लगाना है।

हर कॉन्फ़िगरेशन विकल्प को आर्किटेक्चर शिखर सम्मेलन न बना दें।

लेकिन ऐसा फ़ैसला यूँ ही न ले लें जिसके साथ संगठन को अगले दस साल जीना पड़े।

पूछें:

इसे पलटना कितना मुश्किल होगा?

इस पर कितना कुछ निर्भर होगा?

अगर जवाब बहुत मुश्किल और बहुत कुछ हैं, तो शायद आपको एक आर्किटेक्चरल फ़ैसला मिल गया है।

Click to enlarge

रुककर सोचें। ज़रूरत को समझें। विकल्प तलाशें। ट्रेड-ऑफ़ को सामने रखें। फ़ैसला लें। और लिख लें कि क्यों।

आर्किटेक्चर का लक्ष्य ऐसे फ़ैसले लेना नहीं है जो कभी बदल ही न सकें।

लक्ष्य उन फ़ैसलों को पहचानना है जहाँ मन बदलना महँगा पड़ने वाला है।

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

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

और जानें

• Object Relationships Overview (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): master-detail संबंध में detail का एक्सेस और ownership master के हिसाब से चलते हैं, और master को डिलीट करने पर उसके details भी डिलीट हो जाते हैं।
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): lookup तभी master-detail में बदलता है जब हर रिकॉर्ड में उसकी वैल्यू हो; बदलने से शेयरिंग मॉडल बदल जाता है (Controlled by Parent हो जाता है), और संबंध का टाइप तय करता है कि कौन-से स्टैंडर्ड रिपोर्ट टाइप उपलब्ध होंगे।
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया; 2026-10-12 को दोबारा जाँचा गया): roll-up summary फ़ील्ड सिर्फ़ master-detail संबंधों पर होती हैं, और master-detail को lookup बनाने से पहले उन्हें डिलीट करना पड़ता है।