आज के लिए बनाएँ। कल की योजना बनाएँ। विफलता की योजना बनाएँ।

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: आज की ज़रूरतों के लिए डिज़ाइन करते हुए बढ़त और विफलता की योजना कैसे बनाएँ?

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

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

आज के लिए बनाएँ। कल की योजना बनाएँ। विफलता की योजना बनाएँ।

आपको तीनों चाहिए।

Click to enlarge

आज के लिए बनाएँ

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

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

छिपी हुई ज़रूरतें ढूँढ़ें

आपको जो ज़रूरतें बताई जाती हैं, ज़रूरी नहीं कि वे आपकी सारी ज़रूरतें हों। लगभग हमेशा कुछ छिपी हुई ज़रूरतें होती हैं।

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

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

अपने आँकड़े जानें

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

जब मेरे पास इससे बेहतर संख्या नहीं होती, तो मेरा आधार होता है हर साल 30 प्रतिशत बढ़त। यह भविष्यवाणी नहीं है; यह सोचने पर मजबूर करने का तरीका है। अगर कोई मुझसे कहता है कि आज हमारे पास 10 मिलियन रिकॉर्ड हैं, तो मैं नहीं चाहता कि चर्चा 10 मिलियन पर रुक जाए। 30 प्रतिशत सालाना पर अगले साल हम लगभग 13 मिलियन पर होंगे, उसके अगले साल 17 मिलियन, और उसके बाद लगभग 22 मिलियन। अब डिज़ाइन की बात करते हैं। अगर बिज़नेस मुझसे कहे कि 30 प्रतिशत बेतुका है, तो बढ़िया: असली संख्या दीजिए। मकसद बढ़त को आर्किटेक्चर की चर्चा का हिस्सा बनाना है।

मैं इसे Steve की “शून्यों की गिनती” (Steve’s Number of Zeros) कहता हूँ। एक अतिरिक्त शून्य आपका आर्किटेक्चर पूरी तरह बदल सकता है। दस हज़ार, सौ हज़ार, एक मिलियन, दस मिलियन, सौ मिलियन: फ़ीचर नहीं बदला, और शायद ज़रूरत भी नहीं बदली, लेकिन आर्किटेक्चर बदल सकता है।

मॉड्यूल 1 के अपॉइंटमेंट याद हैं? चलिए उन पर असली संख्याएँ रखते हैं। 1,200 से ज़्यादा लोकेशन, हर लोकेशन पर रोज़ 100 अपॉइंटमेंट, हफ़्ते में छह दिन, साल में लगभग 305 दिन। यानी पहले साल में ही 36 मिलियन से ज़्यादा अपॉइंटमेंट। हर विज़िट दो रिकॉर्ड बनाती है, तो 73 मिलियन से ज़्यादा रिकॉर्ड। अब पाँच साल का इतिहास रखें, हर साल 30 प्रतिशत बढ़त के साथ, और यह 650 मिलियन से ज़्यादा रिकॉर्ड हो जाते हैं। वही फ़ीचर, वही ज़रूरत। कुछ और शून्य, और बिल्कुल अलग आर्किटेक्चर।

कल की योजना बनाएँ

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

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

कल का सिस्टम आज न बनाएँ

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

मैं जिस सवाल का जवाब चाहता हूँ, वह है: क्या आज का आर्किटेक्चर विकसित होकर कल का बन सकता है? अगर हम आगे के साफ़ रास्ते के साथ सरल शुरुआत कर सकें, तो यह अक्सर बरसों पहले जटिलता की कीमत चुकाने से बेहतर है। खतरा छोटी शुरुआत में नहीं है। खतरा ऐसी जगह से शुरू करने में है जहाँ से आगे जाने का कोई रास्ता न हो।

विफलता की योजना बनाएँ

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

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

आंशिक सफलता भी ऐसी विफलता है जिसे आपको समझना होगा

डेटा आर्किटेक्चर में आंशिक विफलताएँ खास तौर पर खतरनाक होती हैं। सोचिए आप एक मिलियन रिकॉर्ड ले जा रहे हैं, और प्रोसेस बताता है कि वह पूरा हो गया। बढ़िया। लेकिन क्या एक मिलियन पहुँचे, या 999,997, और कौन-से तीन गायब हैं? शायद 200,000 फ़ेल हुए, कुछ दो बार बन गए, या सब पहुँच गए पर कुछ फ़ील्ड का ट्रांसफ़ॉर्मेशन फ़ेल हो गया।

“जॉब पूरा हुआ” और डेटा सही है, एक बात नहीं है। एक डेटा आर्किटेक्ट मिलान (reconciliation) के बारे में सोचता है: हमें कैसे पता चलेगा कि क्या होना चाहिए था, असल में क्या हुआ, और दोनों में फ़र्क क्या है? और फिर हम उसके बारे में क्या करेंगे?

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

Click to enlarge

सलीके से फ़ेल हों

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

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

जो मायने रखता है उसकी निगरानी करें

निगरानी के बिना विफलता की योजना असल में योजना नहीं है। अगर कोई इंटीग्रेशन रात 02:00 बजे फ़ेल होता है और तीन दिन बाद किसी ग्राहक के फ़ोन करने तक किसी को पता नहीं चलता, तो हमारे पास ऑपरेशनल आर्किटेक्चर नहीं था। हमारे पास बस उम्मीद थी।

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

तीनों दिशाओं में सोचें

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

टेक्नोलॉजी हर अध्याय में बदलती है। सवाल नहीं बदलते।

आर्किटेक्चर समय के पार मौजूद रहता है

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

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

आज के लिए बनाएँ। कल की योजना बनाएँ। विफलता की योजना बनाएँ। हम इन तीन नज़रियों का बार-बार इस्तेमाल करेंगे।

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

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