जब मैं तकनीकी ऋण के बारे में सोचता हूँ, तो मुझे अभी भी वह पहला एप्लिकेशन याद आता है जिसे मैंने बनाया था, जिसने मुझे अनुपयुक्त आर्किटेक्चर के परिणामों का एहसास कराया था। यह 1990 के दशक के अंत में हुआ था, जब मैं पहली बार एक सलाहकार के रूप में काम शुरू कर रहा था।
क्लाइंट ने अपने ग्राहकों के लिए खरीद प्रणाली बनाने के लिए लोटस नोट्स प्लेटफ़ॉर्म के उपयोग का अनुरोध किया था। लोटस नोट्स क्लाइंट और एक कस्टम एप्लिकेशन का उपयोग करके, अंतिम उपयोगकर्ता ऐसे अनुरोध कर सकते थे जिन्हें एप्लिकेशन द्वारा ट्रैक किया जाएगा और उत्पाद स्वामी की टीम द्वारा पूरा किया जाएगा। सिद्धांत रूप में, यह वास्तव में एक अच्छा विचार था - खासकर तब जब वेब-विकसित एप्लिकेशन प्रचलित नहीं थे और हर कोई दैनिक आधार पर लोटस नोट्स का उपयोग करता था।
मुख्य समस्या यह है कि डेटा डिज़ाइन में बहुत रिलेशनल था - और लोटस नोट्स एक रिलेशनल डेटाबेस नहीं था। समाधान के डिज़ाइन में प्रत्येक लोटस नोट्स दस्तावेज़ के भीतर स्कीमा प्रबंधन की आवश्यकता थी और डेटा विशेषताओं के बीच संबंधों को अनुकरण करने के लिए बहु-मूल्य फ़ील्ड की एक श्रृंखला पर निर्भर था। यह एक गड़बड़ थी।
लोटस नोट्स एप्लीकेशन में बहुत अधिक तर्क की आवश्यकता नहीं होती यदि एक बेहतर प्लेटफ़ॉर्म की सिफारिश की गई होती। स्रोत कोड का समर्थन करना जटिल था। डेटा संरचना में संवर्द्धन के परिणामस्वरूप अंतर्निहित कोड का प्रमुख पुनर्रचना हुआ - मौजूदा डेटा को परिवर्तित करने के लिए सर्वर-आधारित जॉब चलाने का उल्लेख नहीं किया गया। रिपोर्ट निर्माण के पीछे के प्रयास के बारे में मुझे मत बताइए।
अपने करियर के शुरुआती दौर से ही मैंने क्लाइंट को बेहतर समाधान देने की कोशिश करने के बजाय वह समाधान देने पर ध्यान केंद्रित किया जो वह चाहता था। यह निश्चित रूप से एक सबक था जो मैंने अपने करियर की शुरुआत में सीखा था, लेकिन उस प्रोजेक्ट के बाद के वर्षों में, मुझे एहसास हुआ कि आर्किटेक्चरल तकनीकी ऋण का परिणाम एक दुर्भाग्यपूर्ण वास्तविकता है जिसका हम सभी सामना करते हैं।
आइये आर्किटेक्चर टेक ऋण की अवधारणा को वृहद स्तर पर थोड़ा और गहराई से समझें।
कार्नेगी मेलन विश्वविद्यालय में आर्किटेक्चरल टेक्निकल डेब्ट (एटीडी) लाइब्रेरी एटीडी की निम्नलिखित परिभाषा प्रदान करती है:
वास्तुकला तकनीकी ऋण एक डिजाइन या निर्माण दृष्टिकोण है जो अल्पावधि में समीचीन है, लेकिन यह एक तकनीकी संदर्भ बनाता है जिसमें समान कार्य के लिए वास्तुशिल्प पुनः कार्य की आवश्यकता होती है और बाद में इसे करने में वर्तमान की तुलना में अधिक लागत आती है (समय के साथ बढ़ी हुई लागत सहित)।
"त्वरित उत्तर: आर्किटेक्चर तकनीकी ऋण का प्रबंधन कैसे करें" (प्रकाशित 09/22/2023) में, गार्टनर समूह एटीडी को इस प्रकार परिभाषित करता है:
वास्तुकला तकनीकी ऋण, तकनीकी ऋण का वह प्रकार है जो वास्तुकला संबंधी विचलन, उप-इष्टतम वास्तुकला संबंधी निर्णयों, परिभाषित लक्ष्य उत्पाद वास्तुकला और स्थापित उद्योग वास्तुकला संबंधी सर्वोत्तम प्रथाओं के उल्लंघन, तथा तीव्र सॉफ्टवेयर वितरण के लिए किए गए वास्तुकला समझौतों के कारण उत्पन्न होता है।
दोनों ही मामलों में, जो लाभ अक्सर अल्पकालिक उत्सवों का परिणाम देते हैं, उन्हें दीर्घकालिक चुनौतियों से पूरा किया जा सकता है। यह परिचय में उल्लिखित मेरे लोटस नोट्स उदाहरण के समान है।
मामले को और अधिक जटिल बनाने के लिए, सॉफ्टवेयर विकास के अन्य पहलुओं की तुलना में सॉफ्टवेयर आर्किटेक्चर के लिए तकनीकी ऋण की पहचान और प्रबंधन में मदद करने वाले उपकरण गायब हैं:
कोड की गुणवत्ता, अवलोकनीयता और एससीए के लिए, सोनारक्यूब, डेटाडॉग, न्यू रेलिक, गिटहब और स्निक जैसे उत्पादों के साथ सिद्ध उपकरण मौजूद हैं। हालाँकि, सॉफ़्टवेयर आर्किटेक्चर सेगमेंट बिना किसी सिद्ध समाधान के पिछड़ गया है।
यह दुर्भाग्यपूर्ण है, इस तथ्य को देखते हुए कि एटीडी लगातार सबसे बड़ा - और सबसे हानिकारक - तकनीकी ऋण का प्रकार है, जैसा कि कार्नेगी मेलन द्वारा प्रकाशित " इसे मापें? इसे प्रबंधित करें? इसे अनदेखा करें? सॉफ्टवेयर प्रैक्टिशनर्स और तकनीकी ऋण " 2015 के अध्ययन में पाया गया है।
निम्नलिखित चित्रण उस रिपोर्ट से चित्र 4 का सारांश प्रस्तुत करता है, तथा निष्कर्ष निकालता है कि खराब आर्किटेक्चर विकल्प तकनीकी ऋण के स्रोतों में स्पष्ट अग्रणी थे।
यदि इसका प्रबंधन नहीं किया गया तो एटीडी समय के साथ बढ़ती दर से बढ़ना जारी रख सकता है, जैसा कि इस सरल उदाहरण में दिखाया गया है:
शमन के बिना, वास्तुकला ऋण अंततः मापे जा रहे अंतर्निहित समाधान के लिए एक टूटने वाले बिंदु पर पहुंच जाएगा।
एटीडी को प्रबंधित करने से पहले, हमें पहले समस्या को समझना होगा। डेसमंड टूटू ने एक बार समझदारी से कहा था, "हाथी को खाने का सिर्फ़ एक ही तरीका है: एक बार में एक निवाला।"
शिफ्ट-लेफ्ट दृष्टिकोण किसी दिए गए पहलू को जीवनचक्र के अंत की बजाय शुरुआत के करीब ले जाने की अवधारणा को अपनाता है। इस अवधारणा ने परीक्षण के लिए शिफ्ट-लेफ्ट के साथ लोकप्रियता हासिल की, जहां परीक्षण चरण को विकास प्रक्रिया के एक हिस्से में ले जाया गया था, न कि विकास समाप्त होने के बाद पूरा होने वाली एक अलग घटना में।
एटीडी के प्रबंधन में शिफ्ट-लेफ्ट को दो अलग-अलग तरीकों से लागू किया जा सकता है:
परीक्षण के लिए शिफ्ट-लेफ्ट की तरह, विकास चरण के दौरान लचीलेपन और सुरक्षा पर प्राथमिकता से ध्यान देने से अप्रत्याशित घटनाओं की संभावना कम हो जाएगी।
आर्किटेक्चरल ऑब्जर्वेबिलिटी इंजीनियरिंग टीमों को मैक्रो लेवल पर अपनी सेवाओं के भीतर आर्किटेक्चरल ड्रिफ्ट को क्रमिक रूप से संबोधित करने की क्षमता प्रदान करती है। वास्तव में, वॉल स्ट्रीट जर्नल ने इस साल की शुरुआत में "द इनविजिबल $1.52 ट्रिलियन प्रॉब्लम: क्लंकी ओल्ड सॉफ्टवेयर" लेख में तकनीकी ऋण को ठीक करने की लागत $1.52 ट्रिलियन बताई थी।
सफल होने के लिए, इंजीनियरिंग नेतृत्व को निम्नलिखित संगठनात्मक उद्देश्यों के साथ पूर्णतः संरेखित होना चाहिए:
मैंने हाल ही में vFunction के AI-संचालित आर्किटेक्चरल ऑब्जर्वेबिलिटी प्लेटफॉर्म की खोज की है, जो निम्नलिखित डिलीवरेबल्स पर केंद्रित है:
इसके अतिरिक्त, vFunction प्लेटफ़ॉर्म मोनोलिथ से क्लाउड-नेटिव समाधानों में परिवर्तन करने के लिए माइग्रेशन पथ प्रदान करने का साइड-बेनिफिट प्रदान करता है। एक बार जब टीमें अपने प्लेटफ़ॉर्म का आधुनिकीकरण कर लेती हैं, तो वे निरंतर चल रहे बहाव के लिए उनका निरीक्षण कर सकती हैं। यदि कंपनियों के पास पहले से ही माइक्रोसर्विस हैं, तो वे वितरित अनुप्रयोगों में जटिलता का पता लगाने और लचीलापन और मापनीयता को प्रभावित करने वाली निर्भरताओं को संबोधित करने के लिए vFunction का उपयोग कर सकते हैं। किसी भी मामले में, एक बार लागू होने के बाद, इंजीनियरिंग टीमें ब्रेकिंग पॉइंट तक पहुँचने से पहले ATD को कम कर सकती हैं।
उपरोक्त उदाहरण में, vFunction प्लेटफॉर्म के कार्यान्वयन और अंतर्निहित शिफ्ट-लेफ्ट दृष्टिकोण के कारण, इंजीनियरिंग टीमें प्रत्येक रिलीज के एक भाग के रूप में तकनीकी ऋण को कम करने में सक्षम हैं।
मेरे पाठकों को याद होगा कि मैं निम्नलिखित मिशन वक्तव्य पर केंद्रित रहा हूं, जो मुझे लगता है कि किसी भी आईटी पेशेवर पर लागू हो सकता है:
"अपना समय उन सुविधाओं/कार्यक्षमताओं को प्रदान करने पर केंद्रित करें जो आपकी बौद्धिक संपदा के मूल्य को बढ़ाती हैं। बाकी सभी चीज़ों के लिए फ्रेमवर्क, उत्पादों और सेवाओं का लाभ उठाएँ।" - जे. वेस्टर
vFunction प्लेटफ़ॉर्म मेरे मिशन कथन का पालन करता है, इंजीनियरिंग टीमों को मैक्रो स्तर पर अपनी सेवाओं की लचीलापन और सुरक्षा के लिए शिफ्ट-लेफ्ट दृष्टिकोण अपनाने में मदद करता है। यह एक महत्वपूर्ण अंतर है क्योंकि इस तरह के टूलिंग के बिना, टीमों को माइक्रो लेवल पर कम करने की संभावना है, तकनीकी ऋण का समाधान करना जो वास्तव में संगठनात्मक दृष्टिकोण से मायने नहीं रखता है।
जब मैं उस एप्लिकेशन के बारे में सोचता हूँ जिसने मुझे तकनीकी ऋण से जुड़ी चुनौतियों का एहसास कराया, तो मैं यह सोचने से खुद को रोक नहीं पाता कि उस समाधान ने प्रत्येक फीचर के साथ लाभ की तुलना में अधिक समस्याएँ उत्पन्न कीं। निश्चित रूप से, केवल लचीलेपन के लिए शिफ्ट-लेफ्ट का उपयोग अंतर्निहित आर्किटेक्चर के साथ समस्याओं को उस बिंदु पर सतह पर लाने में मदद करता जहाँ विकल्पों पर विचार करने की लागत व्यवहार्य होती।
यदि आप vFunction समाधान के बारे में अधिक जानने में रुचि रखते हैं, तो आप उनके बारे में यहां अधिक पढ़ सकते हैं।
आपका दिन सचमुच बहुत अच्छा हो!