आर्किटेक्चर ट्रेड-ऑफ़ की कला है

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: जब कई समाधान काम कर सकते हों, तो आर्किटेक्ट कैसे चुनता है, और अपनी पसंद कैसे समझाता है?

अगर आर्किटेक्चर बस सही जवाब पहचानने के बारे में होता, तो यह बहुत आसान होता। प्लेटफ़ॉर्म सीखो, पैटर्न सीखो, सीमाएँ सीखो, सही वाला चुनो, बस।

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

समस्या हल करने के कई तरीके

आर्किटेक्ट्स को पढ़ाते समय मैंने इस उदाहरण का कोई न कोई रूप कई बार इस्तेमाल किया है।

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

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

पिकलिस्ट जैसी सीधी चीज़ भी आज काम करती है और डेटा बढ़ने पर उसमें दिक्कतें आ सकती हैं। पिकलिस्ट यूज़र्स के लिए आसान है। लेकिन पूछें कि वैल्यू कहाँ से आती हैं, और कितनी हो सकती हैं। पिकलिस्ट लगभग 20 से कम वैल्यू के साथ सबसे अच्छी चलती हैं। कभी-कभी हम 50 तक जाते हैं, जैसे अमेरिका के राज्य, और शायद ही कभी 100 से ऊपर, जैसे देश, और वे बोझिल हो जाती हैं। इसलिए हर पिकलिस्ट की ऊपरी सीमा जानें। और पिकलिस्ट की वैल्यू बदलना मेटाडेटा का बदलाव है, डेटा का नहीं।

इसकी जगह lookup इस्तेमाल करें, तो यूज़र इंटरफ़ेस थोड़ा पेचीदा हो जाता है। लेकिन सूची बिना किसी ऊपरी सीमा के बढ़ती रह सकती है, और नई वैल्यू किसी इंटीग्रेशन से आ सकती हैं। यह उपयोग में आसानी के बदले किया गया ट्रेड-ऑफ़ है। यही संतुलन है।

Click to enlarge

सर्वोत्तम का मतलब परफ़ेक्ट नहीं

मैं सर्वोत्तम (optimal) शब्द सोच-समझकर इस्तेमाल करता हूँ। सर्वोत्तम आर्किटेक्चर वह नहीं है जिसमें हर अलग फ़ैसला परफ़ेक्ट हो; ऐसा आर्किटेक्चर शायद होता ही नहीं। यह वह है जिसमें पूरा समाधान संतुलित हो।

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

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

एक कम-से-सर्वोत्तम फ़ैसला सर्वोत्तम आर्किटेक्चर का हिस्सा हो सकता है

यह इस अध्याय के सबसे अहम विचारों में से एक है। कभी-कभी मैं जान-बूझकर आर्किटेक्चर के एक हिस्से में कम-से-सर्वोत्तम फ़ैसला लेता हूँ, क्योंकि उससे पूरा समाधान बेहतर बनता है।

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

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

जानें कि बदले में आप क्या छोड़ रहे हैं

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

एंटरप्राइज़ डेटा के एक बड़े सेट के लिए दो विकल्प लें। एक डेटा को Salesforce में कॉपी करता है, जिससे Salesforce की अपनी क्षमताएँ इस्तेमाल करना आसान हो जाता है, लेकिन अब उसे लाने-ले जाने, स्टोर करने, सिंक्रोनाइज़ करने, एक और कॉपी को सुरक्षित रखने और देरी (latency) से निपटने की ज़िम्मेदारी हमारी है। दूसरा डेटा को वहीं रहने देता है जहाँ वह है और ज़रूरत पड़ने पर उसे एक्सेस करता है। हमने कुछ दोहराव हटा दिया, लेकिन अब उपलब्धता, क्वेरी परफ़ॉर्मेंस, नेटवर्क पर निर्भरता और रिमोट सिस्टम की क्षमताएँ ज़्यादा मायने रखती हैं। कोई भी विवरण हमें यह नहीं बताता कि कौन-सा चुनें। वह हमें बताता है कि कौन-से सवाल पूछने हैं।

सारी ज़रूरतें बराबर नहीं होतीं

ट्रेड-ऑफ़ हमें यह देखने पर भी मजबूर करते हैं कि हर ज़रूरत का वज़न एक जैसा नहीं होता।

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

मुझे वे ज़रूरतें पसंद हैं जो सवालों के आगे टिकी रहें: कितना, कितने, कितनी तेज़, कितनी बार, किसके लिए, और अगर हम न करें तो क्या होगा? “तेज़” आर्किटेक्चर की ज़रूरत नहीं है। “ग्राहकों के 95 प्रतिशत अपडेट 30 सेकंड के अंदर सर्विस एजेंट को उपलब्ध होने चाहिए” इसके कहीं ज़्यादा करीब है। अब हम ट्रेड-ऑफ़ का आकलन कर सकते हैं।

पाबंदियाँ जवाब बदल देती हैं

कभी-कभी आर्किटेक्चर पर टेक्नोलॉजी की कोई पाबंदी होती ही नहीं। पाबंदी पैसे, लोगों, समय, लाइसेंसिंग या संगठन की परिपक्वता की होती है।

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

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

आर्किटेक्ट के पास “सर्वोत्तम” की एक तस्वीर होनी चाहिए

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

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

इसे बनाकर देखें

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

डायग्राम अस्पष्टता को सामने ले आता है, और सबको इशारा करने के लिए एक ही तस्वीर देता है।

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

क्योंकि हर मीटिंग में वही लोग होते थे, डायग्राम हमारी साझा भाषा बन गया। लोग उसके नाम इस्तेमाल करने लगे। बार-बार के सवाल कम होते गए, और मीटिंग बहुत आसान हो गईं। मैं इसे मीटिंग को ज़मीन देना (grounding the meeting) कहता हूँ: हर बार दिखाया गया एक सरल डायग्राम, उसे बनाने की लागत से कहीं ज़्यादा कीमती था।

लक्ष्य कलात्मक परफ़ेक्शन नहीं है। कभी यह इंजीनियरों के लिए विस्तृत डायग्राम होता है, कभी किसी एग्ज़िक्यूटिव के लिए पाँच बॉक्स और छह तीर। लक्ष्य है स्पष्टता।

ट्रेड-ऑफ़ समझाएँ

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

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

Think Correct. Think Fast.

हर विकल्प का विश्लेषण करने के लिए आपके पास हमेशा तीन हफ़्ते नहीं होंगे। कभी-कभी आपके पास तीन मिनट होंगे। मीटिंग में कोई ज़रूरत बदल जाती है, कोई ऐसी पाबंदी बताता है जिसके बारे में आपको पता नहीं था, या कोई एग्ज़िक्यूटिव पूछता है, “अगर अगले साल हमें यह यूरोप में चाहिए हो तो?”

मैंने यह वाक्य इस्तेमाल किया है: Think Correct. Think Fast. (सही सोचें। तेज़ सोचें।) रफ़्तार सोच को छोड़ देने से नहीं आती। यह उस पल के आने से पहले काफ़ी सोच चुके होने से आती है: आपने पैटर्न सीख लिए हैं, आप प्लेटफ़ॉर्म जानते हैं, आपने विफलताएँ देखी हैं, आप जानते हैं कि कौन-से सवाल पूछने हैं और कौन-से फ़ैसले पलटने में मुश्किल हैं। इसीलिए हम इस पूरे कोर्स में परिदृश्यों पर काम करते हैं। आप जितने ज़्यादा फ़ैसलों का विश्लेषण करेंगे, अगले फ़ैसले की शक्ल उतनी ही जल्दी पहचानेंगे।

मेरे एक ग्राहक को फ़ॉर्म एंट्री चाहिए थी। लेकिन फ़ॉर्म बहुत सारे थे, और सवाल समय के साथ बदल सकते थे। मैंने जल्दी पहचान लिया कि यहाँ एक सर्वे डेटा मॉडल चाहिए, एक ऐसा पैटर्न जिस पर हम कोर्स में आगे लौटेंगे। क्योंकि मैंने पैटर्न और समाधान पहचान लिया, मैं एक ज़्यादा पूरा डेटा मॉडल ला पाया, जो सिर्फ़ सामने की ज़रूरतें ही नहीं, आने वाली ज़रूरतें भी संभालता था।

आर्किटेक्चर संतुलन के बारे में है

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

सिद्धांत हैं, पैटर्न हैं और सीमाएँ हैं, और कभी-कभी साफ़ तौर पर गलत जवाब भी। लेकिन अक्सर आर्किटेक्ट का काम इस सिस्टम, इस बिज़नेस और इस पल के लिए सही संतुलन ढूँढ़ना है।

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

यह अनिर्णय नहीं है। यही आर्किटेक्चर है।

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

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