3.1 आर्किटेक्चर की बुनियादी बातें

अवलोकन और प्रेरणा

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

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

यह अध्याय उन टिकाऊ बुनियादी बातों को कवर करता है जो तकनीकी फ़ैशन से अधिक समय तक चलती हैं: गुणवत्ता एट्रिब्यूट (“-ilities”), आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताएँ, फ़िटनेस फ़ंक्शन और इवोल्यूशनरी आर्किटेक्चर, C4 और arc42 के साथ हल्का दस्तावेज़ीकरण, और संरचित ट्रेड-ऑफ़ विश्लेषण। ये वे टूल हैं जो एक बड़ी टीम को दुर्घटनावश के बजाय जानबूझकर आर्किटेक्चर के बारे में तर्क करने देते हैं।

मुख्य सिद्धांत

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

सिफ़ारिशें

गुणवत्ता एट्रिब्यूट को मापने योग्य परिदृश्यों के रूप में निर्दिष्ट करें

“सिस्टम तेज़ होना चाहिए” या “अत्यधिक उपलब्ध” जैसे अस्पष्ट लक्ष्यों का परीक्षण या प्रवर्तन नहीं किया जा सकता। इसके बजाय, हर गुणवत्ता एट्रिब्यूट को एक उत्तेजना, एक संदर्भ, और एक मापने योग्य प्रतिक्रिया के साथ एक ठोस परिदृश्य के रूप में लिखें: “जब पीक समवर्ती उपयोगकर्ता 50,000 तक पहुँचते हैं, तो 95% खोज अनुरोध 300 ms के भीतर पूरे होते हैं।” उन एट्रिब्यूट को कवर करें जो आपके डोमेन के लिए मायने रखते हैं: उपलब्धता, प्रदर्शन, स्केलेबिलिटी, सुरक्षा, अनुरक्षणीयता, ऑब्ज़र्वेबिलिटी, एक्सेसिबिलिटी, पोर्टेबिलिटी, और लागत-दक्षता। इन्हें ज़ोर से रैंक करें, क्योंकि आप इन सबको एक साथ अधिकतम नहीं कर सकते। अधिकतम स्थिरता के लिए ट्यून किया गया सिस्टम अधिकतम उपलब्ध भी नहीं होगा।

आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं (ASR) की पहचान करें

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

इवोल्यूशनरी आर्किटेक्चर और फ़िटनेस फ़ंक्शन अपनाएँ

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

C4 और arc42 से दस्तावेज़ीकरण करें

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

संरचित ट्रेड-ऑफ़ विश्लेषण चलाएँ और जोखिम से डिज़ाइन चलाएँ

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

तरीका	फ़ायदे	नुकसान
भारी अग्रिम आर्किटेक्चर	समन्वय स्पष्टता; निश्चित-दायरे वाले कार्यक्रमों में कम देर से आने वाले आश्चर्य	जब ज्ञान सबसे कम हो तब लिए गए निर्णय; धीमा; परिवर्तन के प्रति नाज़ुक
उद्भवशील / इवोल्यूशनरी आर्किटेक्चर	सीखने के अनुकूल; कम बर्बादी; तेज़ डिलीवरी का समर्थन करता है	फ़िटनेस फ़ंक्शन के बिना बहकने का जोखिम; मज़बूत इंजीनियरिंग अनुशासन चाहिए
औपचारिक ATAM-शैली मूल्यांकन	कठोर, ऑडिट करने योग्य, छिपे टकराव सामने लाता है	समय- और विशेषज्ञता-गहन; छोटे परिवर्तनों के लिए अत्यधिक
हल्के ADR + C4	सस्ता, सुबोध, वृद्धिशील, कई टीमों तक स्केल होता है	केवल उतना ही अच्छा जितना उन्हें वर्तमान रखने का अनुशासन

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

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

3. आपके अगले उच्च-दांव वाले, उलटने में कठिन निर्णय के लिए, कमरे में किसे होना चाहिए, और आप विकल्पों को किन परिदृश्यों के विरुद्ध स्कोर करेंगे? ATAM-शैली की एक संरचित ट्रेड-ऑफ़ समीक्षा अपनी लागत तब कमाती है जब कोई निर्णय अपरिवर्तनीय होता है और एक साथ कई गुणवत्ता एट्रिब्यूट को छूता है, और इसकी शक्ति मौजूद लोगों से आती है: डिलीवरी, सुरक्षा, संचालन, और नीति या व्यवसाय के स्वामी जो परिणाम महसूस करते हैं। उनमें से एक आवाज़ छोड़ दें और आप बिल्ड के बाद टकराव खोजते हैं, जैसे एक कैशिंग विकल्प चुपचाप एक ऑडिट करने योग्यता आवश्यकता को तोड़ सकता है। स्कोरिंग रूब्रिक के रूप में प्राथमिकता प्राप्त गुणवत्ता-एट्रिब्यूट परिदृश्य लाएँ, और संवेदनशीलता बिंदुओं की तलाश करें जहाँ कोई विकल्प एक ही एट्रिब्यूट को ज़ोर से हिलाता है और ट्रेड-ऑफ़ बिंदुओं की जहाँ यह कई को हिलाता है। जो आउटपुट आप चाहते हैं वह एक छोटा ADR है जो उन विकल्पों को रिकॉर्ड करता है जिन्हें आपने अस्वीकार किया और क्यों, ताकि तर्क उन लोगों से आगे बचे जिन्होंने इसे बनाया। यदि कोई आगामी निर्णय इसे उचित नहीं ठहराता दिखता, तो यह स्वयं जाँचने लायक है, क्योंकि एक बड़ा कार्यक्रम जिसके क्षितिज पर कोई अपरिवर्तनीय निर्णय नहीं है वह आमतौर पर पर्याप्त आगे नहीं देख रहा है।

4. यदि किसी नए शामिल होने वाले या किसी बाहरी ऑडिटर के पास केवल आपका लिखित आर्किटेक्चर होता, तो क्या वे पुनर्निर्मित कर पाते कि सिस्टम इस तरह क्यों आकार लिया है, और आपने आखिरी बार इसे कब जाँचा था? आर्किटेक्चर जो कुछ वरिष्ठ दिमागों में रहता है वह एक एकल विफलता बिंदु है: जब वे लोग आगे बढ़ जाते हैं, तो हर कठिन-उलटने योग्य निर्णय के पीछे का तर्क उनके साथ चला जाता है, और अगली टीम इसे घटनाओं के माध्यम से दोबारा सीखती है। एक बड़े संगठन के लिए आर्किटेक्चर की सुबोधता (C4 आरेख जो वास्तविकता से मेल खाते हैं, एक arc42 कथा, ADR जो अस्वीकृत विकल्पों को रिकॉर्ड करते हैं) वही है जो दर्जनों टीमों को बिना किसी बैठक के एक ही सिस्टम के बारे में तर्क करने देता है। एक हालिया ADR और एक वर्तमान आरेख लाएँ, उन्हें किसी ऐसे व्यक्ति को दें जिसने घटक नहीं बनाया, और देखें कि किसी व्यक्ति से पूछने से पहले वे कितनी दूर तक पहुँचते हैं। एंटरप्राइज़ और सरकारी सेटिंग्स में एक ऑडिटर ठीक यही अभ्यास करेगा, और दस्तावेज़ीकरण जो पिछले साल के सिस्टम का वर्णन करता है वह किसी दस्तावेज़ीकरण न होने से भी बुरा है क्योंकि यह उन्हीं लोगों को गुमराह करता है जिन्हें प्रमाणित करना है। लिखित रिकॉर्ड की ताज़गी को एक मापने योग्य गुण मानें, और इसे सच रखने के पीछे एक फ़िटनेस फ़ंक्शन या समीक्षा समय-सारिणी रखें।

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

6. जब आप तय करते हैं कि कोई आवश्यकता आर्किटेक्चरल रूप से महत्वपूर्ण है या नहीं, तो यह निर्णय कौन लेता है, और आप ASR सूची को सब कुछ या कुछ भी नहीं बनने से कैसे रोकते हैं? आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं को नाम देने का मूल्य चयनात्मकता से आता है: हर आवश्यकता को महत्वपूर्ण मानें और डिज़ाइन ठप हो जाता है, किसी को भी महत्वपूर्ण न मानें और संरचनात्मक, जोखिम भरे, बदलने में कठिन आवश्यकताएँ बिना सुरक्षा के फिसल जाती हैं। एक बड़ी टीम में प्रलोभन यह है कि हर स्क्वाड को स्थानीय रूप से तय करने दिया जाए, जो असंगत मानदंड और क्रॉस-टीम आश्चर्य पैदा करता है जब एक समूह का “मामूली” विकल्प दूसरे की संरचना को सीमित कर देता है। अपनी वर्तमान ASR सूची, आपके द्वारा उपयोग किए गए मानदंड (कई घटकों को छूता है, संतुष्ट करना महंगा, सख्त बाधा, तकनीकी रूप से जोखिम भरा), और सीमा को ज़ोर से जाँचने के लिए कुछ सीमांत आवश्यकताएँ लाएँ। एंटरप्राइज़ और सरकार के लिए, डेटा निवास, रिटेंशन, और ऑडिट करने योग्यता जैसे नियामक आदेश लगभग हमेशा महत्वपूर्ण और गैर-परक्राम्य होते हैं, इसलिए नाम दें कि सूची का स्वामी कौन है, इसकी समीक्षा कैसे होती है, और किसी ASR को जोड़ने या हटाने का निर्णय कैसे रिकॉर्ड किया जाता है, क्योंकि एक ASR जिसे कोई शासित नहीं करता वह एक ऐसी आवश्यकता है जिसका जाँच के तहत कोई बचाव नहीं करेगा।

क्षेत्र लेंस

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

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

एंटरप्राइज़। चुनौती कई टीमों और वर्षों के रोडमैप में सुसंगतता है, इसलिए साझा मशीनरी में निवेश करें: एक आर्किटेक्चर गिल्ड, गुणवत्ता-एट्रिब्यूट परिदृश्यों का एक सामान्य सेट, कोड के बगल में संग्रहीत ADR, और CI में फ़िटनेस फ़ंक्शन जो उन सीमाओं को लागू करते हैं जिन्हें स्केल पर कोई एक समीक्षक पुलिस नहीं कर सकता। अपरिवर्तनीय, क्रॉस-कटिंग निर्णयों के लिए संरचित ट्रेड-ऑफ़ विश्लेषण का उपयोग करें, डिज़ाइन समीक्षाओं में C4 आरेखों को साझा मानचित्र के रूप में रखें, और ASR सूची को केंद्रीय रूप से शासित करें ताकि समूह ऐसे स्थानीय रूप से उचित विकल्प बनाना बंद करें जो वैश्विक रूप से टकराते हैं।

सरकार। दीर्घजीवी, विनियमित सिस्टम दस्तावेज़ीकृत, बचाव करने योग्य आर्किटेक्चर को एक खरीद और जवाबदेही आवश्यकता बनाते हैं, कोई सुविधा नहीं। डेटा निवास, रिटेंशन, ऑडिट करने योग्यता, और एक्सेसिबिलिटी को आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं के रूप में मानें जो एक arc42 विवरण में लिखी गई हों जिसे ऑडिटर सीधे पढ़ सकें, और नीति व सुरक्षा अधिकारियों को शामिल करते हुए हल्की ट्रेड-ऑफ़ वर्कशॉप चलाएँ ताकि टकराव (जैसे कैशिंग बनाम ऑडिट करने योग्यता) कोड से पहले कागज़ पर सामने आएँ। तर्क के निशान को पर्याप्त रूप से पूर्ण रखें ताकि एक जवाबदेह अधिकारी उचित सावधानी दिखा सके, और ऐसे आर्किटेक्चर को प्राथमिकता दें जिनमें स्पष्ट निकास विकल्प हों बजाय उनके जो किसी सार्वजनिक निकाय को एक दशक के लिए एक ही विक्रेता में बंद कर दें।

उदाहरण

स्टार्टअप। एक छह-सदस्यीय सीड-स्टेज SaaS टीम अपना आर्किटेक्चर किसी औपचारिक प्रक्रिया के बजाय एक साझा दस्तावेज़ में रखती है, लेकिन फिर भी उन निर्णयों को लिखती है जिन्हें उलटना दर्दनाक होगा। वे लगभग एक दर्जन ADR रिकॉर्ड करते हैं (डॉक्यूमेंट स्टोर की तुलना में Postgres क्यों, सेवाओं की तुलना में मॉड्यूलर मोनोलिथ क्यों, उन्होंने अपना ऑथ प्रोवाइडर क्यों चुना) और दो गुणवत्ता-एट्रिब्यूट परिदृश्यों को पिन करते हैं जो वास्तव में शुरुआती ग्राहकों के लिए मायने रखते हैं: “एक साइनअप दो सेकंड से कम में पूरा होता है” और “कोई ग्राहक कभी किसी दूसरे टेनेंट का डेटा नहीं पढ़ सकता।” जब वे अपने सातवें और आठवें इंजीनियर को नियुक्त करते हैं, तो ये नोट्स नए लोगों को अपने पहले सप्ताह में शिप करने देते हैं बजाय हर किसी को यह पूछने के लिए बाधित करने के कि चीज़ें ऐसी क्यों हैं जैसी हैं।

एंटरप्राइज़। एक बहुराष्ट्रीय बैंक बारह क्षेत्रीय भुगतान सिस्टम को समेकित कर रहा है, इसलिए वह एक छोटा आर्किटेक्चर गिल्ड स्थापित करता है। गिल्ड आठ गुणवत्ता-एट्रिब्यूट परिदृश्य परिभाषित करता है (जिसमें “प्रति सेकंड 10,000 लेनदेन को शून्य खोए लेनदेन के साथ संसाधित करें” और “15 मिनट के भीतर एक क्षेत्र को पुनर्प्राप्त करें” शामिल हैं), लगभग चालीस ADR कैप्चर करता है, और CI (सतत एकीकरण) में फ़िटनेस फ़ंक्शन लागू करता है: कोई सेवा किसी दूसरे डोमेन के डेटाबेस में नहीं लिख सकती, सभी इंटर-सर्विस कॉल को ट्रेस किया जाना चाहिए, और किसी गंभीर CVE (Common Vulnerabilities and Exposures) वाली कोई भी निर्भरता बिल्ड को विफल कर देती है। C4 संदर्भ और कंटेनर आरेख हर डिज़ाइन समीक्षा में साझा मानचित्र बन जाते हैं, और क्रॉस-टीम एकीकरण विवाद तेज़ी से घट जाते हैं।

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

नेतृत्व के लिए, मामले को वैकल्पिकता और जोखिम के इर्द-गिर्द फ़्रेम करें। अच्छी आर्किटेक्चर बुनियादी बातें भविष्य के परिवर्तन की लागत को कम करती हैं (एक दशक-लंबे सिस्टम जीवन में डिलीवरी गति और स्वामित्व की कुल लागत पर सीधा लीवर), गंभीर घटनाओं की आवृत्ति और अवधि को कम करती हैं, और वह दस्तावेज़ीकरण ट्रेल पैदा करती हैं जो नियामक और ऑडिटर अब मांगते हैं। ADR की आदत अकेले तब अपनी लागत चुका देती है जब कोई नई नेतृत्व टीम पहली बार पूछती है “हमने इसे इस तरह क्यों बनाया?” और उन्हें एक फ़ोरेंसिक जाँच के बजाय मिनटों में उत्तर मिल जाता है। जहाँ हो सके वहाँ संख्याएँ लगाएँ: एक बड़े री-आर्किटेक्चर से बचने, या एक विफल ऑडिट से बचने की लागत को प्रथाओं की छोटी चल रही लागत के विरुद्ध तौलें।

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

• स्तर 1: आरंभ करें। आर्किटेक्चर अंतर्निहित है और व्यक्तियों के दिमाग में रहता है। कोई दस्तावेज़ीकृत गुणवत्ता एट्रिब्यूट नहीं, कोई ADR नहीं, कोई साझा आरेख नहीं। संरचना घटनाओं के दौरान खोजी जाती है, और हर क्रॉस-टीम निर्भरता शून्य से फिर से बातचीत की जाती है।
• स्तर 2: विकसित करें। कुछ टीमें उन निर्णयों को लिखती हैं जिन्हें उलटने में तकलीफ़ होगी और मुख्य आरेख स्केच करती हैं, लेकिन प्रथा असंगत है: एक स्क्वाड ADR रखता है जबकि दूसरा कोई नहीं रखता, गुणवत्ता एट्रिब्यूट को मापने योग्य परिदृश्यों के बजाय विशेषणों के रूप में नाम दिया जाता है, और दस्तावेज़ीकरण परियोजनाओं के बीच पुराना होता जाता है।
• स्तर 3: मानकीकृत करें। गुणवत्ता-एट्रिब्यूट परिदृश्य और आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताएँ एक दस्तावेज़ीकृत, संगठन-व्यापी मानक के अनुसार निर्दिष्ट और प्राथमिकता दी जाती हैं। ADR नियमित हैं और कोड के बगल में संग्रहीत हैं, C4 और arc42 दस्तावेज़ीकरण एक सामान्य टेम्पलेट के अनुसार बनाए रखा जाता है, और हर टीम में महत्वपूर्ण निर्णयों के लिए संरचित ट्रेड-ऑफ़ समीक्षाएँ आवश्यक हैं।
• स्तर 4: प्रबंधित करें। आर्किटेक्चर को दावा करने के बजाय आधार रेखाओं के विरुद्ध मापा जाता है। CI में फ़िटनेस फ़ंक्शन p99 विलंबता, लेयरिंग उल्लंघन, अनट्रेस्ड कॉल, और भेद्य निर्भरताओं जैसी विशेषताओं पर रिपोर्ट करते हैं; ADR कवरेज और दस्तावेज़ीकरण ताज़गी को मीट्रिक के रूप में ट्रैक किया जाता है; ट्रेड-ऑफ़ समीक्षाएँ प्राथमिकता प्राप्त परिदृश्यों के विरुद्ध विकल्पों को स्कोर करती हैं; और सहमत आधार रेखाओं के विरुद्ध बहाव आश्चर्य के बजाय एक परिभाषित प्रतिक्रिया को ट्रिगर करता है। ऑडिटर केवल कथा के बजाय मापे गए साक्ष्य पर निर्भर कर सकते हैं।
• स्तर 5: ऑर्केस्ट्रेट करें। आर्किटेक्चर पूरे संगठन में लगातार और अनुकूली रूप से विकसित होता है। फ़िटनेस-फ़ंक्शन और घटना डेटा वापस इस बात में फ़ीड होते हैं कि कौन-सी विशेषताएँ मायने रखती हैं और डिज़ाइन प्रयास कहाँ जाता है; ASR सूचियाँ, गुणवत्ता-एट्रिब्यूट प्राथमिकताएँ, और गार्डरेल को आदेशों और जोखिम के बदलने पर फिर से दायरा दिया जाता है; और प्रथा को डिलीवरी, सुरक्षा, और जोखिम योजना के साथ एकीकृत किया जाता है ताकि प्लेटफ़ॉर्म शून्य से फिर से बनाए जाने के बजाय नई आवश्यकताओं के अनुकूल हो जाए।

चर्चा के लिए विचार

1. आपके सबसे महत्वपूर्ण सिस्टम के लिए वास्तव में कौन-से तीन गुणवत्ता एट्रिब्यूट गैर-परक्राम्य हैं, और क्या आप आज हर एक को एक मापने योग्य परिदृश्य के रूप में बता सकते हैं?
2. आप कैसे तय करते हैं कि कोई निर्णय ADR के हक़दार होने के लिए “आर्किटेक्चरल रूप से महत्वपूर्ण” कब है बनाम बस इसे कर देना?
3. फ़िटनेस फ़ंक्शन कहाँ ऐसे बहाव को पकड़ेंगे जो आपकी वर्तमान कोड समीक्षा चूक जाती है?
4. क्या आपका संगठन अति-आर्किटेक्चरिंग कर रहा है या अल्प-आर्किटेक्चरिंग, और कौन-सा प्रमाण आपको बताता है कि कौन सा है?
5. एक टीम-की-टीम संरचना में आर्किटेक्चर के लिए कौन जवाबदेह है, और आप हाथी-दाँत मीनार और पूर्ण अराजकता दोनों से कैसे बचते हैं?
6. एक बाहरी ऑडिटर आज जो लिखा गया है उससे आपके आर्किटेक्चर के इरादे को कैसे पुनर्निर्मित करेगा?

मुख्य निष्कर्ष

• आर्किटेक्चर उन निर्णयों का समूह है जिन्हें उलटना महंगा है; उन ट्रेड-ऑफ़ को जानबूझकर करें और उन्हें रिकॉर्ड करें।
• गुणवत्ता एट्रिब्यूट को मापने योग्य परिदृश्यों के रूप में निर्दिष्ट करें और उन आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं की पहचान करें जो संरचना को आकार देती हैं।
• क्रमिक रूप से डिज़ाइन करें और स्वचालित फ़िटनेस फ़ंक्शन से मुख्य आर्किटेक्चरल विशेषताओं की रक्षा करें।
• C4 आरेख, एक arc42 कथा, और कोड के बगल रखे गए प्रति-निर्णय ADR का उपयोग करके हल्का लेकिन सत्यनिष्ठ दस्तावेज़ीकरण करें।
• कठोरता को जोखिम से मिलाएँ: अपरिवर्तनीय, उच्च-प्रभाव निर्णयों के लिए भारी विश्लेषण; बाकी हर जगह हल्की प्रक्रिया।
• व्यावसायिक मामला है बचा हुआ दोबारा काम, छोटी घटनाएँ, तेज़ भविष्य का परिवर्तन, और ऑडिट-तैयार साक्ष्य।

संदर्भ और आगे पढ़ने के लिए

• Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice
• Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures
• Simon Brown, Software Architecture for Developers (and the C4 model)
• Mark Richards and Neal Ford, Fundamentals of Software Architecture
• George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
• Michael Nygard, “Documenting Architecture Decisions” (the ADR pattern)
• Gernot Starke and Peter Hruschka, arc42 documentation template
• Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
• ISO/IEC 25010, Systems and software quality models