नीति मालिक तय करते हैं, आर्किटेक्ट उसे लागू करते हैं

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

Data Architect का अध्याय 5, भाग 1: डेटा आर्किटेक्ट बनना। पिछला: एंटरप्राइज़ डेटा को समझना।

“डेटा गवर्नेंस” कहिए, और लोगों के मन में मीटिंगें आती हैं: कमेटियाँ, नीतियाँ, एक दस्तावेज़ जिसे कोई नहीं पढ़ता। मैं हर बार एक अलग सवाल पूछता हूँ: नीति लागू कहाँ होती है?

अगर नीति कहती है कि कानूनी ग्राहक नाम सिर्फ़ Finance बदल सकता है, तो बाकी किसी को कौन रोकता है? अगर वह कहती है कि क्रू किसी प्राप्तकर्ता का पता सिर्फ़ अपने स्टॉप के लिए, सिर्फ़ उसी दिन देखें, तो इसे सच कौन बनाता है? अगर वह कहती है कि इसे सात साल रखो, तो सात साल बाद इसे कौन हटाता है? लागू करने के बिंदु (enforcement point) के बिना नीति ज़्यादातर बस एक इच्छा है। मेरा पक्ष सीधा है: नीति मालिक तय करते हैं; आर्किटेक्ट उसे लागू करते हैं। डेटा का मालिक फ़ैसला करता है। आर्किटेक्ट जो सिस्टम डिज़ाइन करता है, वह उसे मशीनी तौर पर सच बनाता है।

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

यह चित्र AI से बनाया गया है।

इस अध्याय में मेरे पक्ष

• प्रोग्राम वैसे चलाएँ जैसे कंपनी काम करती है: सेंट्रलाइज़्ड, फ़ेडरेटेड या हाइब्रिड; आर्किटेक्ट को पता होना चाहिए कि किसी नीति पर मुहर कौन लगाता है।
• रिकॉर्ड का मालिक डेटा का मालिक नहीं है। Owner फ़ील्ड असाइनमेंट और एक्सेस चलाता है; डेटा की जवाबदेही बिज़नेस के पास है।
• खुला या बंद क्रिएशन, डेटा के आसपास की गवर्नेंस पर निर्भर करता है। ज़्यादातर छोटे और मझोले org के लिए खुला ठीक है; जब Account किसी ERP में मास्टर होते हैं या उसके साथ सिंक होते हैं, तो इसे बंद करें; बीच का रास्ता एक अस्थायी (provisional) रिकॉर्ड टाइप है, जिसे नियंत्रित तरीके से गवर्न वाले टाइप में बदला जाता है।
• अगर कोई फ़ील्ड ERP में मास्टर होता है, तो आप उसे बदल नहीं रहे, बदलने का अनुरोध कर रहे हैं। गोल्डन रिकॉर्ड हाइब्रिड है: ERP के मास्टर फ़ील्ड अंदर आते हैं, Salesforce के अपने फ़ील्ड कभी वापस नहीं जाते, और दोतरफ़ा फ़्लो को टकराव का एक नियम चाहिए।
• संवेदनशील फ़ील्ड को वर्गीकृत करें, हर फ़ील्ड को नहीं। व्यापक रूप से डॉक्यूमेंट करें; सोच-समझकर वर्गीकृत करें; बिज़नेस और तकनीकी दोनों मेटाडेटा रखें।
• नियमों (regulations) को पढ़ाएँ। बहुत-से आर्किटेक्ट्स ने अपने क्षेत्र के बाहर के कानूनों के बारे में कभी सुना ही नहीं है, और ये कानून सिस्टम डिज़ाइन को आकार देते हैं।
• जहाँ भी हो सके, out-of-the-box सहमति मॉडल इस्तेमाल करें, उसे दोबारा बनाने के बजाय।
• भुला दिए जाने के अधिकार के लिए, पहले यह नियंत्रित करें कि व्यक्तिगत डेटा कहाँ जाता है। डिलीशन दुर्लभ और मुश्किल है; ऐसा डिज़ाइन करें कि व्यक्तिगत डेटा कम जगहों पर पहुँचे, फिर समय-सीमा खत्म होने से पहले हर कॉपी ढूँढ निकालें: फ़ील्ड हिस्ट्री, आर्काइव, एनालिटिक्स की कॉपियाँ, सर्च इंडेक्स और एजेंट की बातचीत।
• अहम नियामक आवश्यकताओं के लिए Shield ही जवाब है, जैसे at rest एन्क्रिप्शन, ऐसे ट्रेड-ऑफ़ के साथ जिनके लिए आप डिज़ाइन करते हैं।
• नियमन हो तो Field Audit Trail। स्टैंडर्ड फ़ील्ड हिस्ट्री डिफ़ॉल्ट है।
• ज़रूरत पड़ने से पहले Event Monitoring सेट करें, और इवेंट्स को Splunk जैसे किसी रिपॉज़िटरी में स्ट्रीम करें। ऐसा नहीं होना चाहिए कि कोई समस्या आए और तब पता चले कि आप उन्हें कैप्चर ही नहीं कर रहे थे।

गवर्न किया गया डेटा जीवनचक्र

Click to enlarge

डेटा के पूरे जीवन में सात सवाल। टूल नीति को सहारा देते हैं; उसे परिभाषित नहीं करते।

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

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

1. गवर्नेंस org में डिज़ाइन की जाती है। मालिक, स्टीवर्ड और कस्टोडियन; सेंट्रलाइज़्ड, फ़ेडरेटेड या हाइब्रिड; रिकॉर्ड का मालिक बनाम डेटा का मालिक; हर नीति को लागू करने के एक बिंदु में बदलना।
2. खराब डेटा को बाहर रखना। “काफ़ी अच्छा” एक बिज़नेस परिभाषा के रूप में; खुला बनाम बंद क्रिएशन, अस्थायी रिकॉर्ड और हर फ़्लो के लिए एक रिकॉर्ड टाइप; हाइब्रिड गोल्डन रिकॉर्ड और दोतरफ़ा फ़्लो; डेटा की हर सीमा पर गुणवत्ता का एक फ़ैसला।
3. अपने डेटा को जानें: डिक्शनरी, लिनिएज और वर्गीकरण। बिज़नेस और तकनीकी मेटाडेटा; इसका क्या मतलब है, यह कहाँ से आया, इसके साथ कैसा बर्ताव होना चाहिए, और लागू किए बिना वर्गीकरण सिर्फ़ सजावट क्यों है।
4. प्राइवेसी कानून डिज़ाइन को आकार देते हैं। पहचानने लायक कानून, उनमें क्या साझा है (अधिकार, ट्रांसफ़र, उल्लंघन की सूचना, जवाबदेही), और वे सवाल जो उनसे ज़्यादा टिकते हैं; अनामीकृत बनाम छद्मनामीकृत; कम्प्लायंस कोई प्रोडक्ट नहीं है।
5. सहमति और भुला दिए जाने का अधिकार। डेटा के रूप में सहमति, स्टैंडर्ड सहमति मॉडल, हर अनुरोध पर चलती घड़ी, और पहला अनुरोध आने से पहले मिटाने (erasure) का डिज़ाइन।
6. सुरक्षित रखें, सहेजें और साबित करें। एन्क्रिप्शन के ट्रेड-ऑफ़, सैंडबॉक्स, रिटेंशन, फ़ील्ड हिस्ट्री और Field Audit Trail, और ज़रूरत से पहले सेट किया गया Event Monitoring।

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

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

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

यह अध्याय आर्किटेक्चर का मार्गदर्शन है, कानूनी सलाह नहीं। कौन-से कानून लागू होते हैं और वे क्या माँगते हैं, यह लीगल और कम्प्लायंस टीमें तय करती हैं; आर्किटेक्ट उन आवश्यकताओं को डिज़ाइन में बदलता है।

परीक्षा से आगे: गवर्नेंस का एक नया उपभोक्ता है, एजेंट। वर्गीकरण तय करता है कि वह क्या निकाल (retrieve) सकता है, सहमति तय करती है कि वह डेटा को किस काम के लिए इस्तेमाल कर सकता है, और लिनिएज और ऑडिट को उस सब तक पहुँचना होता है जो उसने कहा और किया। हर मॉड्यूल इस बात पर खत्म होता है कि जीवनचक्र के उसके हिस्से के लिए AI क्या बदलता है।

और जानें

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), EUR-Lex (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।

अगला: मास्टर डेटा और पहचान