IT आर्किटेक्चर की योजना: कम निर्भरताएँ, अधिक स्पष्ट निर्णय

आर्किटेक्चर सिस्टम के साथ जिम्मेदारियाँ भी बताता है

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

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

तीन ठोस व्यावसायिक प्रक्रियाओं से शुरू करें

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

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

अतिरिक्त घटक अपनी संचालन लागत कब सही ठहराता है

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

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

मोनोलिथ और माइक्रोसर्विस गुणवत्ता के स्तर नहीं हैं

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

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

उदाहरण: ग्राहक पोर्टल, इन्वेंटरी सिस्टम और अकाउंटिंग

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

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

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

निर्णय दर्ज करें और पूरा संचालन खर्च तुलना करें

Architecture Decision Record में एक निर्णय, संदर्भ, विकल्प और परिणाम दर्ज होते हैं। उसे स्पष्ट रूप से नए निर्णय से बदलना संभव हो। AWS ADR प्रक्रिया यह जीवनचक्र बताती है; दस्तावेज़ लंबाई से अधिक कारण सुरक्षित रखना महत्वपूर्ण है।

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

समान अवधि और आवश्यकताओं में निर्माण, इंफ़्रास्ट्रक्चर, लाइसेंस, सहायता, शुरुआत और बाहर निकलने की लागत तुलना करें। हर बदलाव में दुर्लभ विशेषज्ञता चाहिए तो सस्ती होस्टिंग महँगी हो सकती है। प्रबंधित प्लेटफ़ॉर्म काम घटा सकते हैं, लेकिन अनुबंध और एक्सपोर्ट की निर्भरताएँ जोड़ते हैं।

आर्किटेक्चर समीक्षा में ठोस प्रमाण लें

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

हाल के संबंधित बदलाव और घटनाएँ जोड़ें। किस निर्भरता ने टीम चौंकाई? कई टीम कहाँ साथ लगीं? बार-बार मैनुअल काम क्यों हुआ? व्यक्तिगत तकनीकी पसंद से पूरा परिवेश बदलने के बजाय कुछ उचित परिवर्तन निकालें।

तीन प्रदर्शन लक्ष्य डिज़ाइन जाँचने योग्य बनाते हैं

बदलने की क्षमता के लिए सामान्य व्यावसायिक बदलाव को घटकों, लोगों, मैनुअल चरणों और स्वीकृति समय तक ट्रेस करें। पुनर्प्राप्ति के लिए उचित परिवेश में महत्वपूर्ण प्रक्रिया की अपेक्षित वैकल्पिक व्यवस्था या बहाली जाँचें। हस्तांतरण के लिए दूसरे व्यक्ति से सिर्फ दस्तावेज़ उपयोग करके नियमित काम कराएँ।

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

बदलाव के संकेतों वाली योजना बनाएँ

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

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