AWS आर्किटेक्चर निर्णय रिकॉर्ड प्रक्रिया

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

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

ADR प्रक्रिया आर्किटेक्चर निर्णय रिकॉर्डों का एक संग्रह तैयार करती है। यह संग्रह निर्णय लॉग बनाता है। निर्णय लॉग परियोजना का संदर्भ तथा विस्तृत क्रियान्वयन और डिज़ाइन की जानकारी प्रदान करता है। परियोजना के सदस्य परियोजना के संदर्भ का अवलोकन पाने के लिए प्रत्येक ADR की सुर्खियाँ देखते हैं। वे परियोजना के क्रियान्वयन और डिज़ाइन विकल्पों में गहराई से उतरने के लिए ADR पढ़ते हैं।

जब टीम किसी ADR को स्वीकार कर लेती है, तो वह अपरिवर्तनीय हो जाता है। यदि नई अंतर्दृष्टि के कारण अलग निर्णय की आवश्यकता हो, तो टीम एक नया ADR प्रस्तावित करती है। जब टीम नए ADR को स्वीकार करती है, तो वह पिछले ADR का स्थान ले लेता है।

ADR प्रक्रिया का दायरा

परियोजना के सदस्यों को सॉफ़्टवेयर परियोजना या उत्पाद को प्रभावित करने वाले प्रत्येक आर्किटेक्चर की दृष्टि से महत्वपूर्ण निर्णय के लिए ADR बनाना चाहिए, जिनमें निम्नलिखित शामिल हैं (Richards और Ford 2020):

• संरचना (उदाहरण के लिए, माइक्रोसर्विसेज़ जैसे पैटर्न)

• अकार्यात्मक आवश्यकताएँ (सुरक्षा, उच्च उपलब्धता और दोष-सहनशीलता)

• निर्भरताएँ (घटकों का युग्मन)

• इंटरफ़ेस (API और प्रकाशित अनुबंध)

• निर्माण तकनीकें (लाइब्रेरी, फ़्रेमवर्क, उपकरण और प्रक्रियाएँ)

• कार्यात्मक और अकार्यात्मक आवश्यकताएँ ADR प्रक्रिया के सबसे आम इनपुट हैं।

ADR की विषय-वस्तु

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

ADR अपनाने की प्रक्रिया

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

जब टीम किसी आर्किटेक्चर निर्णय और उसके स्वामी की पहचान कर लेती है, तो प्रक्रिया की शुरुआत में ADR स्वामी ADR को प्रस्तावित (Proposed) अवस्था में प्रस्तुत करता है। प्रस्तावित अवस्था वाले ADR समीक्षा के लिए तैयार होते हैं।

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

यदि टीम को ADR को बेहतर बनाने के लिए कार्य-बिंदु मिलते हैं, तो ADR की अवस्था प्रस्तावित ही रहती है। ADR स्वामी कार्रवाइयाँ तैयार करता है और टीम के सहयोग से प्रत्येक कार्रवाई के लिए एक ज़िम्मेदार व्यक्ति नियुक्त करता है। प्रत्येक टीम सदस्य कार्य-बिंदुओं में योगदान दे सकता है और उन्हें हल कर सकता है। समीक्षा प्रक्रिया को दोबारा निर्धारित करना ADR स्वामी की ज़िम्मेदारी है।

टीम ADR को अस्वीकार करने का निर्णय भी ले सकती है। इस स्थिति में, भविष्य में उसी विषय पर चर्चा रोकने के लिए ADR स्वामी अस्वीकृति का कारण जोड़ता है। स्वामी ADR की अवस्था को अस्वीकृत (Rejected) में बदल देता है।

यदि टीम ADR को अनुमोदित करती है, तो स्वामी टाइमस्टैम्प, संस्करण और हितधारकों की सूची जोड़ता है। फिर स्वामी अवस्था को स्वीकृत (Accepted) में अद्यतन करता है।

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

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

ADR समीक्षा प्रक्रिया

टीम को ADR को स्वीकार या अस्वीकार करने के बाद उन्हें अपरिवर्तनीय दस्तावेज़ मानना चाहिए। किसी मौजूदा ADR में परिवर्तन के लिए नया ADR बनाना, नए ADR के लिए समीक्षा प्रक्रिया स्थापित करना और ADR को अनुमोदित करना आवश्यक है। यदि टीम नए ADR को अनुमोदित करती है, तो स्वामी को पुराने ADR की अवस्था प्रतिस्थापित (Superseded) में बदल देनी चाहिए।