3.6 लेगेसी आधुनिकीकरण

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

लेगेसी सिस्टम वे सिस्टम हैं जो दुनिया चलाते हैं। कोर बैंकिंग लेजर, टैक्स और लाभ इंजन, हवाई यातायात और रक्षा सिस्टम, बीमा पॉलिसी प्रशासन, और सरकारी रजिस्ट्री जिन पर समाज निर्भर करते हैं, अक्सर दशकों पुराने होते हैं। कई COBOL (Common Business-Oriented Language) या अन्य पुरानी तकनीकों में लिखे गए हैं, और वे अभी भी अधिकांश महत्वपूर्ण लेन-देन को संसाधित करते हैं। “लेगेसी” कोई अपमान नहीं है। इसका मतलब है कि सिस्टम इतना मूल्यवान है कि वह बचा रहा, इतना महत्वपूर्ण है कि उसकी विफलता विनाशकारी होगी, और इतना पुराना है कि उसे सुरक्षित रूप से बदलना कठिन है। लेगेसी आधुनिकीकरण इन सिस्टम को सुधारने, माइग्रेट करने, या बदलने का अनुशासन है, बिना उन आवश्यक सेवाओं को बाधित किए जो वे प्रदान करते हैं।

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

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

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

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

सिफ़ारिशें

स्ट्रैंगलर फ़िग पैटर्न के साथ वृद्धिशील रूप से आधुनिकीकरण करें

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

आंतरिक सीमों (seams) के लिए ब्रांच-बाय-एब्सट्रैक्शन का उपयोग करें

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

लेगेसी जोखिम का जानबूझकर आकलन और प्राथमिकता तय करें

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

मेनफ्रेम और COBOL एस्टेट का प्रबंधकत्व करें, केवल उसे बदलें नहीं

हर मेनफ्रेम या COBOL सिस्टम को जल्द ही बदला नहीं जाना चाहिए, या सुरक्षित रूप से बदला नहीं जा सकता। निकट-अवधि की प्राथमिकता अक्सर प्रबंधकत्व (stewardship) होती है: ज्ञान को उसके सेवानिवृत्त होने से पहले कैप्चर करें। कोड में एन्कोड किए गए व्यावसायिक नियमों का दस्तावेज़ीकरण करें (जिनमें से अधिकांश अदस्तावेज़ीकृत और अप्रतिस्थापनीय हैं), स्वचालित टेस्ट में निवेश करें जो वर्तमान व्यवहार को पिन करते हैं ताकि भविष्य का परिवर्तन सुरक्षित हो, अनुरक्षकों की भर्ती और क्रॉस-ट्रेनिंग करें, और आसपास की डिलीवरी प्रैक्टिस को आधुनिक बनाएँ (सोर्स कंट्रोल, सतत एकीकरण (CI), स्वचालित टेस्टिंग) भले ही कोर अपनी जगह बना रहे। जहाँ आप आधुनिकीकरण करते हैं, वहाँ पहले चरण के रूप में आधुनिक API (एनकैप्सुलेशन) के माध्यम से लेगेसी क्षमताओं को उजागर करना पसंद करें। स्वचालित COBOL-से-आधुनिक-भाषा अनुवाद को सावधानी से लें, क्योंकि यह ऐसा कोड उत्पन्न करता है जो चलता है लेकिन अक्सर समझ से परे तर्क को यथावत् पुन: उत्पन्न करता है। सबसे दुर्लभ संसाधन समझ है, कंप्यूट नहीं।

डेटा माइग्रेशन और डुअल-रनिंग को परियोजना का मूल मानें

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

बिग-रीराइट के प्रलोभन को प्रबंधित करें

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

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

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

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

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

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

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

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

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

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

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

सेक्टर लेंस

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Michael Feathers, Working Effectively with Legacy Code
• Martin Fowler, “StranglerFigApplication” और “BranchByAbstraction”
• Sam Newman, Monolith to Microservices
• Nicholas Carr / मेनफ्रेम और COBOL निर्भरता पर उद्योग अध्ययन (लेगेसी एस्टेट के पैमाने पर संदर्भ)
• Robert Annett, Working with Legacy Systems
• Eric Evans, Domain-Driven Design (एंटी-करप्शन लेयर)
• Gregor Hohpe, Enterprise Integration Patterns और The Software Architect Elevator
• Standish Group CHAOS Report (बड़ी परियोजना और पुनर्लेखन विफलता दरों पर प्रमाण)