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