वो दस जोखिम जो पुराने बिज़नेस सिस्टम को ख़तरनाक बनाते हैं, उनसे होने वाली रोज़ की परेशानियाँ, संभावना और असर का एक आसान हीट मैप, और strangler fig पैटर्न से लेगेसी सिस्टम को एक-एक हिस्सा करके बदलने का तरीक़ा।
Author
Anichur Rahaman
पुराना सॉफ़्टवेयर शायद ही कभी एकदम से बैठता है; वह धीरे-धीरे जवाब देता है। हर महीने कोई रिपोर्ट थोड़ा और ज़्यादा समय लेने लगती है। नया पेमेंट तरीक़ा जोड़ने के लिए कहा जाता है कि "कुछ हफ़्ते लगेंगे"। स्टॉक मॉड्यूल समझने वाला इकलौता डेवलपर छुट्टी पर जाता है, और पूरी टीम उसके लौटने की राह देखती रहती है।
समस्या का नाम लिए जाने से बहुत पहले ही मालिक इन लक्षणों को महसूस कर लेते हैं। किसी पुराने बिज़नेस सिस्टम की समीक्षा करते समय एक आर्किटेक्ट के तौर पर मेरा काम है उस धुंधली बेचैनी को ठोस जोखिमों की सूची में बदलना, हर जोखिम को अंक देना, और ऐसा रास्ता सुझाना जिससे कारोबार रुके बिना सिस्टम से बाहर निकला जा सके। यह लेख वही तरीक़ा साझा करता है।
यहाँ आपको मिलेंगे जाँचने लायक दस जोखिम, हर जोखिम से रोज़ होने वाली परेशानियाँ, जोखिम नापने का एक आसान heat map, और आधुनिकीकरण का एक तरीक़ा — strangler fig पैटर्न — जिसमें पूरा सिस्टम दोबारा लिखने का जुआ खेलने के बजाय पुराने सिस्टम का एक-एक हिस्सा धीरे-धीरे बदला जाता है।
लेगेसी होने का उम्र से कोई लेना-देना नहीं। पाँच साल पुराना सिस्टम भी आधुनिक हो सकता है, अगर उसमें टेस्ट हैं, दस्तावेज़ हैं और वह सपोर्ट वाले सॉफ़्टवेयर पर चलता है। वहीं दो साल पुराना सिस्टम भी लेगेसी हो सकता है, अगर उसे छूने की किसी की हिम्मत न हो। एक काम की परिभाषा:
लेगेसी सॉफ़्टवेयर वह हर सिस्टम है जिस पर बिज़नेस टिका है, लेकिन जिसे सुरक्षित तरीक़े से, जल्दी या किफ़ायत से बदला नहीं जा सकता।
इस नज़र से सवाल यह नहीं कि "सिस्टम कितना पुराना है?" सवाल यह है कि "इसे बदलना कितना जोखिम भरा है, और इसे जैसा है वैसा छोड़ देना कितना?" दोनों की क़ीमत चुकानी पड़ती है।
जब प्रोग्रामिंग भाषा के वर्ज़न या framework का सपोर्ट ख़त्म होता है, तो सिक्योरिटी अपडेट आने बंद हो जाते हैं। उसके बाद हर महीने ज्ञात कमज़ोरियों और आपकी सुरक्षा के बीच का फ़ासला बढ़ता जाता है। बाद में अपग्रेड करना भी मुश्किल होता जाता है, क्योंकि लाइब्रेरी आगे बढ़ जाती हैं और आपके वर्ज़न का साथ छोड़ देती हैं।
रोज़ की परेशानी: "वह पेमेंट गेटवे नहीं जुड़ सकता, उसकी लाइब्रेरी को नया PHP चाहिए।"
सिस्टम कैसे चलता है, यह सिर्फ़ एक डेवलपर या एक कॉन्ट्रैक्टर जानता है। कहीं कुछ लिखा नहीं, और उसके जाते ही जानकारी भी चली जाती है। असर के लिहाज़ से यह अक्सर सबसे बड़ा जोखिम होता है — और मालिकों का ध्यान इस पर सबसे आख़िर में जाता है।
रोज़ की परेशानी: रिलीज़, बग फ़िक्स, यहाँ तक कि डेटा का छोटा-सा सुधार भी एक व्यक्ति के समय का इंतज़ार करता है।
टेस्ट न हों तो हर बदलाव एक जुआ है, इसलिए टीम कम से कम बदलाव करती है। समस्या की जड़ तक जाने के बजाय ऊपर से पैबंद लगाए जाते हैं, और कोड को बदलना हर साल और मुश्किल होता जाता है।
रोज़ की परेशानी: "इनवॉइस की राउंडिंग ठीक की, अब डिस्काउंट की रिपोर्ट ग़लत आ रही है।"
सैकड़ों टेबल, जिन्हें ऐप का हर हिस्सा पढ़ता और लिखता है — कभी-कभी बाहरी स्क्रिप्ट भी। एक कॉलम बदलते ही कोई ऐसी स्क्रीन टूट सकती है जिसके होने की किसी को याद तक नहीं।
रोज़ की परेशानी: एक मामूली फ़ील्ड बदलने में पूरा हफ़्ता यह खोजने में निकल जाता है कि असर कहाँ-कहाँ पड़ेगा।
पुराने तरीक़े से रखे पासवर्ड, कोड के अंदर लिखी API key, बिना टू-फ़ैक्टर वाला एडमिन पैनल, एरर पेज पर डेटाबेस की जानकारी, लॉगिन पर बार-बार कोशिश की कोई सीमा नहीं। अलग-अलग देखें तो हर चीज़ छोटी लगती है, पर सब मिलकर एक खुला दरवाज़ा हैं।
रोज़ की परेशानी: कोई बड़ा क्लाइंट सिक्योरिटी प्रश्नावली भेजे, तो उसका जवाब देने को कोई तैयार नहीं।
ग्राहक की जानकारी स्टोर में, CRM में और एक स्प्रेडशीट में; स्टॉक सिस्टम में भी और गोदाम मैनेजर की कॉपी में भी। जब आँकड़े आपस में मेल नहीं खाते, तो लोग किसी पर भी भरोसा नहीं करते।
रोज़ की परेशानी: कौन-सी रिपोर्ट सही है, इसी बहस में मीटिंग का समय ख़त्म।
रात में FTP से जाती CSV फ़ाइलें, सप्लायर की वेबसाइट से जानकारी खींचने वाली स्क्रिप्ट, पासवर्ड की मियाद ख़त्म होते ही चुपचाप रुक जाने वाले इंटीग्रेशन। जब तक चलते हैं, चलते हैं — और रुक जाएँ तो कई दिन तक किसी को पता नहीं चलता।
रोज़ की परेशानी: "मंगलवार के बाद से कूरियर स्टेटस अपडेट ही नहीं हुए।"
लूप के अंदर एक-एक रिकॉर्ड खींचने वाली क्वेरी, कोई cache नहीं, पूरी टेबल खंगालकर बनने वाली रिपोर्ट। हज़ार ऑर्डर तक सब ठीक, दस लाख पर पहुँचते ही तकलीफ़।
रोज़ की परेशानी: महीने के आख़िर की रिपोर्ट रात भर चलती है, और उस दौरान स्टोर भी धीमा पड़ जाता है।
किसने क़ीमत, सैलरी या स्टॉक बदला, इसका कोई रिकॉर्ड नहीं। ग्राहक माँगे तो उसका निजी डेटा एक्सपोर्ट करने या मिटाने का कोई तरीक़ा नहीं। सहमति का कोई रिकॉर्ड नहीं रखा जाता। कई देशों के डेटा सुरक्षा क़ानूनों में ये सब क़ानूनी ज़िम्मेदारियाँ हैं, कोई अतिरिक्त सुविधा नहीं।
रोज़ की परेशानी: ऑडिटर के एक सवाल का जवाब जुटाने में हफ़्ता लग जाता है।
एक बंद सिस्टम, जिसमें आपके डेटा के एक्सपोर्ट पर वेंडर का नियंत्रण है, रिन्यूअल पर दाम बढ़ जाते हैं, या प्रोडक्ट ही बंद कर दिया जाता है। कभी-कभी कॉन्ट्रैक्ट ख़ुद सबसे बड़ा जोखिम होता है।
रोज़ की परेशानी: "हम दूसरा सिस्टम अपनाना चाहते हैं, लेकिन अपना डेटा काम के लायक रूप में निकाल ही नहीं पा रहे।"
शुरुआत के लिए किसी कंसल्टेंट की ज़रूरत नहीं। सिस्टम इस्तेमाल करने वालों और उसे संभालने वालों को साथ बिठाइए, और हर जोखिम को दो पैमानों पर 1 से 5 तक अंक दीजिए:
दोनों अंकों को गुणा कीजिए। 15 या उससे ज़्यादा आए तो उसे इसी तिमाही में ठीक करना है। 8 से 14 वाले रोडमैप में जाएँगे। 8 से कम वालों पर बस नज़र रखिए। ऊपर वाला heat map इसी टेबल की तस्वीर है — और आधुनिकीकरण के लिए बोर्ड से बजट मंज़ूर करवाने में मेरी जानकारी में यह सबसे असरदार स्लाइड है।
| जोखिम | संभावना (1–5) | असर (1–5) | अंक | कार्रवाई |
|---|---|---|---|---|
| सपोर्ट ख़त्म runtime | 5 | 5 | 25 | इसी तिमाही |
| एक व्यक्ति पर निर्भरता | 4 | 5 | 20 | इसी तिमाही |
| सुरक्षा का क़र्ज़ | 4 | 5 | 20 | इसी तिमाही |
| ऑटोमेटेड टेस्ट नहीं | 4 | 4 | 16 | इसी तिमाही |
| कमज़ोर इंटीग्रेशन | 3 | 3 | 9 | रोडमैप |
| वेंडर का शिकंजा | 2 | 4 | 8 | रोडमैप |
ऊपर के अंक उदाहरण हैं, कोई पैमाना नहीं। आपकी अपनी चर्चा में अलग अंक आएँगे — और वह चर्चा ही आधा काम है।
जोखिम सामने आते ही सबसे लुभावना जवाब होता है: "चलो, इस बार इसे ठीक से नए सिरे से बनाते हैं।" लेकिन पूरा सिस्टम दोबारा लिखने की कोशिशें कामयाब कम और नाकाम ज़्यादा होती हैं, और इसके कारण पहले से अंदाज़ा लगाए जा सकते हैं:
strangler fig (बरगद की तरह की एक लता) किसी पेड़ से लिपटकर तब तक बढ़ती है, जब तक अपने दम पर खड़ी न हो जाए। सॉफ़्टवेयर में भी नया सिस्टम पुराने के चारों ओर बढ़ता है, एक-एक काम अपने हाथ में लेता जाता है — जब तक पुराने कोर को बंद न किया जा सके।
पुराने सिस्टम के आगे एक routing परत लगाइए — कोई API gateway या हल्की-सी proxy। शुरुआत में यह 100% ट्रैफ़िक पुराने सिस्टम को ही भेजती है। साथ-साथ:
ऐसा हिस्सा चुनिए जो अहम हो और जिसकी सीमाएँ साफ़ हों: कैटलॉग और स्टॉक, या ऑर्डर। नया मॉड्यूल बनाइए या तैयार मॉड्यूल अपनाइए, और वह काम उसकी तरफ़ मोड़ दीजिए।
आख़िरी हिस्सा भी शिफ़्ट हो जाए, तो पुराना डेटा सिर्फ़ पढ़े जाने वाले स्टोरेज में आर्काइव कीजिए, बची हुई पुरानी स्क्रीनें बंद कीजिए और पुराना कोड हटा दीजिए। डेटा रखिए, जोखिम विदा कीजिए।
पुराने सिस्टम के हर हिस्से के साथ एक जैसा बर्ताव ज़रूरी नहीं। हर हिस्से का रास्ता तीन सवाल तय करते हैं:
कुछ सबक़ किताबों से नहीं, तजुर्बे से आते हैं:
StoreConsole अलग-अलग स्वतंत्र मॉड्यूल से बना है — कैटलॉग, इन्वेंटरी, ऑर्डर, डिलीवरी, अकाउंटिंग, HR, पेरोल, CRM और भी बहुत कुछ — जो आपस में सिर्फ़ event के ज़रिए बात करते हैं। इसलिए "बदलने" वाले रास्ते के लिए यह स्वाभाविक पसंद है: facade के पीछे एक मॉड्यूल लगाइए, पुराने सिस्टम के outbox से उसे डेटा दीजिए, और पहला स्थिर हो जाए तो अगले पर बढ़िए। हर मॉड्यूल में एक्टिविटी लॉग, रोल के हिसाब से अनुमतियाँ और टू-फ़ैक्टर साइन-इन मौजूद है, जिससे ऊपर के कई जोखिम पहले दिन से ही घट जाते हैं। नीचे के छोटे वीडियो में रोल, टू-फ़ैक्टर साइन-इन और ऑडिट ट्रेल दिखाए गए हैं।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते बिज़नेस के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की सटीकता और अपने ही सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
