डिप्लॉयमेंट के लिए सॉफ़्टवेयर संस्करण चुनना

IT हलकों में अक्सर एक बात पर चर्चा होती है — "मुझे सॉफ़्टवेयर का कौन सा संस्करण इंस्टॉल करना चाहिए।" यह किसी database, application, firmware या, सबसे अधिक, operating system पर लागू हो सकता है, और Windows XP के समर्थन समाप्ति के आसन्न होने के साथ यह विषय तीव्र बहस का केंद्र बन गया है।

इस चर्चा के प्रभावी रूप से दो पक्ष हैं। एक पक्ष का मानना है कि हमेशा नवीनतम और, माना जाता है, सर्वश्रेष्ठ सॉफ़्टवेयर का उपयोग किया जाना चाहिए। दूसरा मानता है कि सॉफ़्टवेयर को परिपक्व होने की जरूरत है और "प्रतीक्षा और देखें" का दृष्टिकोण अपनाता है या यहाँ तक कि प्रत्येक संस्करण को एक अलग उत्पाद मानता है।

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

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

आइए दूसरे मामले से शुरू करते हैं, क्योंकि इस पर मार्गदर्शन देना कहीं आसान है।

नए सॉफ़्टवेयर deployments (या नए operating systems) के मामले में, हमेशा सॉफ़्टवेयर का सबसे वर्तमान, नवीनतम संस्करण उपयोग करें — जब तक कि कोई स्पष्ट ज्ञात तकनीकी सीमा इसे रोक न दे जैसे ज्ञात bugs या सॉफ़्टवेयर असंगतताएं।

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

सॉफ़्टवेयर विकास लगभग एक सातत्य है। सामान्य विकास प्रक्रियाओं में नया सॉफ़्टवेयर पुराने के ऊपर बनाया जाता है। यह विचार कि प्रत्येक उत्तरोत्तर संस्करण पिछले से बेहतर है — यह गारंटी नहीं है, लेकिन सामान्यतः सॉफ़्टवेयर समय के साथ सुधरता है, विशेष रूप से व्यवसायों में उपयोग किए जाने वाले एंटरप्राइज़ क्लास सॉफ़्टवेयर के बारे में बात करते समय। नया सॉफ़्टवेयर न केवल पुराने सॉफ़्टवेयर का अगला चरण है, बल्कि यह पैच, bug fixes और अपडेट की वर्तमान स्थिति भी दर्शाता है।

सॉफ़्टवेयर की गुणवत्ता से परे, भविष्य में निवेश की अवधारणा है। सॉफ़्टवेयर हमेशा के लिए shelf पर नहीं रह सकता। पुराने सॉफ़्टवेयर को इंस्टॉल करने का अर्थ है अतीत में निवेश — इसे "technical debt" कहा जाता है। यह पुरानी तकनीक वर्षों या दशकों तक चल सकती है, लेकिन पुराना सॉफ़्टवेयर समय के साथ मूल्य खोता है और समर्थन करने में तेजी से महंगा होता जाता है।

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

जो मैंने पहले ही कहा है उसके ढांचे के भीतर, code maturity के बारे में बात करना महत्वपूर्ण है। अक्सर code maturity को "पुराना code" deploy करने के कारण के रूप में बताया जाता है, लेकिन मुझे लगता है कि यह सॉफ़्टवेयर विकास प्रक्रियाओं की IT गलतफहमी है। यदि हम released code की एक पंक्ति के बारे में सोचें, तो सिर्फ इसलिए कि यह released और उपयोग में है, यह वास्तव में इसे अधिक mature नहीं बनाता। Code जंगल में नहीं बदलता, यह बस वहाँ बैठा रहता है। उसी software code base पर आधारित बाद के संस्करण, लेकिन अधिक अप-टू-डेट, वास्तव में अधिक "mature" code हैं।

यह, कहिए, कार जैसे मामले के विपरीत है जहाँ प्रत्येक release एक ताज़ी चीज़ है जिसमें नए अवसर और विश्वसनीयता संबंधी चिंताएं हैं। सॉफ़्टवेयर ऐसा नहीं है। इसलिए अधिक mature सॉफ़्टवेयर की अवधारणा आपको "tried and true" के बजाय "latest and greatest" deploy करने की ओर धकेलेगी।

यदि हम सॉफ़्टवेयर संस्करण संख्याओं को उम्र की तरह सोचें, तो यह स्पष्ट हो जाता है। Linux 3.1, Linux 2.4 की तुलना में सॉफ़्टवेयर परिपक्वता के संदर्भ में बहुत पुराना है। इसमें एक दशक का अतिरिक्त विकास है।

आइए एक वास्तविक दुनिया का उदाहरण लें जो आज बहुत प्रासंगिक है। आप एक shop में अपना पहला server(s) install करने वाले हैं। Windows Server 2012 R2 अभी release हुआ है। क्या आपको Windows Server 2008, 2008 R2 (2010), Server 2012 या Server 2012 R2 (2013 के अंत में?) install करना चाहिए?

कई shops के लिए, ऐसा लगता है जैसे हम दो से चार अलग-अलग उत्पादों के बारे में बात कर रहे हैं। यह, बड़े पैमाने पर, असत्य है। प्रत्येक नया संस्करण बस एक upgrade, update, patch और पिछले पर feature वृद्धि है। यदि हम marketing नामों के बजाय kernel revision numbers देखें, तो यह समझ में आता है।

Windows Server 2008 Windows NT 6.0 था। Windows Server 2008 R2 Windows NT 6.1 था — स्पष्ट रूप से एक minor revision। Windows Server 2012 Windows NT 6.2 था और हमारा वर्तमान Windows Server 2012 R2 Windows NT 6.3 है। यदि हम marketing नामों के बजाय revision numbers उपयोग करते, तो जानबूझकर एक पुराना, कम mature, कम updated और कम patched संस्करण install करना लगभग पागलपन लगता।

नए सॉफ़्टवेयर deployments के लिए, जितना नया सॉफ़्टवेयर install किया जाए, उतना बेहतर — नवीनतम सुविधाओं का लाभ उठाने का अवसर और अपरिहार्य obsolescence से पहले सबसे अधिक समय मिलता है।

इस सोच की रेखा का अनुसरण करने से हम यह महसूस कर सकते हैं कि pre-release या beta सॉफ़्टवेयर deploy करना भी उचित होगा। और जबकि कुछ विशिष्ट मामलों में यह समझ में आता है — जैसे कंपनी में व्यापक रिलीज से पहले सॉफ़्टवेयर की जांच के लिए "test groups" में — सामान्यतः यह उचित नहीं है। Pre-release सॉफ़्टवेयर की प्रकृति यह है कि यह supported नहीं है।

यह हमें दूसरी स्थिति पर लाता है — जिसमें हम मौजूदा सॉफ़्टवेयर को अपडेट कर रहे हैं। यह, निश्चित रूप से, एक fresh install से बिल्कुल अलग परिदृश्य है और इसमें कई और कारक शामिल हैं।

अधिकांश स्थितियों के लिए सबसे बड़े कारकों में से एक licensing है। नियमित रूप से सॉफ़्टवेयर अपडेट करने पर licensing fees लग सकती है जिसे लाभ और लागत समीकरण में शामिल करना होगा। कुछ उत्पाद, जैसे अधिकांश open source सॉफ़्टवेयर, इस लागत से मुक्त हैं।

सॉफ़्टवेयर अपडेट करने में एक और बड़ा कारक मानवीय प्रयास की लागत है। एक दशक के लिए सॉफ़्टवेयर का एक संस्करण बनाए रखने का अर्थ है कि उस समय upgrade प्रक्रियाओं के लिए संसाधन समर्पित नहीं थे। उस दौरान वार्षिक upgrade का अर्थ है कि संसाधनों का दस बार उपयोग किया गया।

यह सॉफ़्टवेयर अपडेट करना नकारात्मक नहीं लगना चाहिए, लेकिन यह एक ऐसा समीकरण है जहाँ दोनों पक्षों को तौलना होगा। नियमित अपडेट का अर्थ अक्सर छोटे, वृद्धिशील परिवर्तन होते हैं बजाय बड़ी छलांग के, जो end users को अधिक स्वाभाविक रूप से अनुकूलन करने की अनुमति देता है।

ऊपर के दो परिदृश्यों से जो हमने सीखा है, उससे एक और महत्वपूर्ण निष्कर्ष निकाला जा सकता है। एक बार अपडेट करने का निर्णय हो जाने पर, अक्सर सवाल होता है "किस संस्करण में अपडेट करें?" वास्तव में, हर अपडेट जो standard patching process से अधिक है, वह वास्तव में एक लघु "नए सॉफ़्टवेयर" खरीद निर्णय जैसा है। इसलिए अपडेट करते समय, हमें लगभग हमेशा जितना संभव हो उतना आगे — उम्मीद है कि वर्तमान संस्करण तक — अपडेट करना चाहिए।

Microsoft उदाहरण फिर से लागू करने के लिए, हम एक ऐसे संगठन को ले सकते हैं जिसके पास आज Windows XP deployed है। व्यवसाय एक नए संस्करण में अपडेट cycle में निवेश करने का निर्णय करता है। Microsoft के सक्रिय समर्थन के तहत अभी भी Windows desktop platform के कई संस्करण हैं — Windows Vista, Windows 7, Windows 8 और Windows 8.1। कम current संस्करणों में अपडेट करने से उस संस्करण के जीवन के अंत से पहले कम समय मिलता है, पुरानी तकनीकों में निवेश जारी रहता है और technical debt बढ़ता है।

प्रत्येक व्यवसाय को अपने लिए मौजूदा सॉफ़्टवेयर update cycles के लिए सही संतुलन खोजना होगा। Microsoft Windows, Microsoft Office या Oracle Database जैसे एंटरप्राइज़ सॉफ़्टवेयर इन मॉडलों का अच्छी तरह पालन करते हैं। सॉफ़्टवेयर विकास प्रक्रिया के प्रति सहानुभूति लागू करने पर विचार करें ताकि आप समझ सकें कि आप और आपका सॉफ़्टवेयर vendor आपके संगठन को सर्वोत्तम मूल्य देने के लिए कैसे साझेदारी कर सकते हैं।

लेकिन अंगूठे के नियम अपेक्षाकृत आसान हैं:

नया deploy करते समय या अपडेट करते समय, सॉफ़्टवेयर के नवीनतम उचित संस्करण का लक्ष्य रखें। किसी भी deployment के अवसर का उपयोग technical debt को जितना संभव हो कम करने के लिए करें।

जब सॉफ़्टवेयर पहले से मौजूद हो तो मानवीय प्रयास, licensing costs, पर्यावरणीय स्थिरता और compatibility testing जैसे कारकों को features, performance और technical debt में लाभ के विरुद्ध तौलें।