आर्किटेक्ट की तरह सोचना

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

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

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

अपने करियर के ज़्यादातर हिस्से में मैं एक बिल्डर रहा हूँ।

मैंने डेवलपर के रूप में शुरुआत की। Salesforce में आने से पहले मैंने Java और .NET में काम किया, और मैंने बरसों तक सिस्टम डिज़ाइन किए, कोड लिखा, प्लेटफ़ॉर्म इंटीग्रेट किए, आर्किटेक्ट्स को पढ़ाया, और आर्किटेक्चर की समीक्षा की।

लेकिन इस सफ़र में मैंने जो सबसे ज़रूरी सबक सीखे, उनमें से एक यह है कि एक बेहतरीन बिल्डर होना और एक बेहतरीन आर्किटेक्ट होना हमेशा एक ही बात नहीं है।

एक बिल्डर पूछता है:

मैं इसे कैसे बनाऊँ?

एक आर्किटेक्ट को अलग तरह के सवाल पूछने पड़ते हैं:

क्या हमें इसे बनाना चाहिए?

हम इसे इसी तरीके से क्यों बना रहे हैं?

और क्या विकल्प हैं?

जब यह बड़ा होगा तब क्या होगा?

जब यह फ़ेल होगा तब क्या होगा?

और आज हम कौन-सा ऐसा फ़ैसला ले रहे हैं जिसके बारे में तीन साल बाद हम सोचेंगे कि काश उस पर और गहराई से सोचा होता?

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

सोच का यही बदलाव असल में इस कोर्स का विषय है।

Click to enlarge

वह व्यक्ति जिसके हाथ में ब्लूप्रिंट है

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

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

लेकिन किसी के हाथ में ब्लूप्रिंट भी होना चाहिए।

उस व्यक्ति को समझना होता है कि ये सारे हिस्से आपस में कैसे जुड़ते हैं। उसे ध्यान देना होता है कि प्रोजेक्ट के एक हिस्से में जो हो रहा है, वह कहीं और कब कोई समस्या खड़ी कर रहा है।

यही आर्किटेक्चर है।

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

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

यह बिल्कुल अलग हुनर है।

ज़रूरत को बस यूँ ही न मान लें

मैं चाहता हूँ कि आर्किटेक्ट्स सबसे पहले जो आदत डालें, वह सीधी-सी है:

“क्यों” पूछें।

कोई आपसे कहता है:

हमें एक और ऑब्जेक्ट चाहिए।

क्यों?

हमें यह फ़ील्ड Account पर कॉपी करनी है।

क्यों?

हमें यह सारा डेटा Salesforce में रखना है।

क्यों?

इसका मतलब अड़ियल बनना नहीं है। इसका मतलब है सुझाए गए समाधान को तुरंत लागू करने के बजाय असली बिज़नेस ज़रूरत को समझना।

कोई ज़रूरत अक्सर डिज़ाइन का भेस पहनकर आती है।

“हमें एक नया कस्टम ऑब्जेक्ट चाहिए” ज़रूरी नहीं कि ज़रूरत हो। असली ज़रूरत शायद यह हो कि “हमें यह जानकारी अलग से ट्रैक करनी है।” ये दोनों एक बात नहीं हैं।

एक बार असली ज़रूरत समझ आ जाए, तो आप विकल्प तलाशना शुरू कर सकते हैं। हो सकता है नया ऑब्जेक्ट ही बिल्कुल सही जवाब हो। हो सकता है वह जानकारी किसी ऐसी जगह की हो जो पहले से मौजूद है। हो सकता है वह डेटा Salesforce के पास होना ही नहीं चाहिए।

आर्किटेक्ट को बिज़नेस को क्या चाहिए और उसे पूरा करने के एक सुझाए गए तरीके को अलग करना होता है।

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

ज़रूरत से आगे सोचना

“क्यों” पूछने से दो आदतें निकलती हैं, और इस अध्याय में आगे हर एक का अपना मॉड्यूल है।

आम तौर पर जवाब एक से ज़्यादा होते हैं। Salesforce हमें किसी समस्या को हल करने के बहुत सारे तरीके देता है, और उनमें से कुछ तो लगभग फ़ौरन गलत साबित हो जाते हैं। जो काम करते हैं, उनमें से चुनना ट्रेड-ऑफ़ की कला है (मॉड्यूल 4)।

और आपको जो ज़रूरतें बताई जाती हैं, वे आपकी सारी ज़रूरतें नहीं होतीं। कोई नहीं कहता “पक्का करें कि यह तब भी चले जब रात का लोड आधा ही सफल हो,” लेकिन यह फिर भी एक ज़रूरत है। मैं हर डिज़ाइन को तीन नज़रियों से देखता हूँ: आज के लिए बनाएँ, कल की योजना बनाएँ, विफलता की योजना बनाएँ (मॉड्यूल 5)।

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

Click to enlarge

अपनी सोच को सामने रखें

आर्किटेक्ट को कमरे में आकर बस यह घोषणा नहीं करनी चाहिए, “हम यह करने जा रहे हैं।”

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

और ऐसा करने का तरीका है साफ़ ब्लूप्रिंट और निर्देश, बिल्कुल कंस्ट्रक्शन साइट पर ब्लूप्रिंट थामे उस व्यक्ति की तरह। Data Architect के लिए इन ब्लूप्रिंट में सबसे ज़रूरी में से एक है डेटा मॉडल।

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

आर्किटेक्ट को सब कुछ खुद नहीं बनाना होता

एक और बदलाव है जो मुश्किल हो सकता है, खासकर उन लोगों के लिए जो डेवलपमेंट के रास्ते आर्किटेक्चर में आते हैं।

आपको सब कुछ खुद नहीं बनाना है।

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

कभी इसका मतलब होता है किसी क्वेरी, किसी API या किसी डेटा मॉडल में गहराई तक उतरना।

कभी इसका मतलब होता है एक कदम पीछे हटकर पूछना कि क्या हमें यह सब करना भी चाहिए।

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

यह बिल्डर से आर्किटेक्ट बनने के सफ़र का हिस्सा है।

आपका काम फ़ैसले लेना है

आखिरकार, आर्किटेक्चर फ़ैसलों के बारे में है।

कुछ फ़ैसले बदलना आसान होता है। कुछ नहीं।

पेज लेआउट बदला जा सकता है। लेबल का नाम बदला जा सकता है।

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

ये आर्किटेक्चरल फ़ैसले हैं। और यह कोर्स ठीक इसी तरह के फ़ैसलों पर ध्यान देता है।

Data Architect के रूप में आप यह तय करेंगे कि जानकारी का ढाँचा कैसा हो, वह कहाँ रहे, कैसे बढ़े, कैसे आगे-पीछे जाए, उसे कौन देख सके, और बाकी एंटरप्राइज़ उसे कैसे समझे।

टेक्नोलॉजी मायने रखती है।

लेकिन Salesforce के हर फ़ीचर को जानना लक्ष्य नहीं है।

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

यही आर्किटेक्ट की तरह सोचना है।

और अब हम एक Data Architect की तरह सोचना शुरू कर सकते हैं।

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

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