8.2 टूलिंग परिदृश्य: बिल्ड बनाम ख़रीद

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

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

कमोडिटी परत के लिए ख़रीदें: DORA, समीक्षा, और सर्वेक्षण अवसंरचना

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

वास्तव में संगठन-विशिष्ट परिणाम टेलीमेट्री के लिए बनाएँ

उन परिणाम मेट्रिक्स के लिए जिन्हें विषय 7.4 आपके मेट्रिक्स कार्यक्रम का गुरुत्वाकर्षण केंद्र होना चाहिए तर्क देता है, व्यावसायिक परिणाम सहसंबंध (विषय 5.3), आपके विशिष्ट उत्पाद से जुड़ा फ़ीचर अपनाना (विषय 5.2), आपकी विशिष्ट लागत संरचना से जुड़ा यूनिट अर्थशास्त्र (विषय 5.4), वाणिज्यिक टूलिंग कहीं कम मानकीकृत है और अक्सर व्यापक, महंगे अनुकूलन के बिना आपके संगठन के विशिष्ट व्यावसायिक तर्क और डेटा मॉडल को कैप्चर नहीं कर सकती जो अंततः परिणाम के पूर्ण नियंत्रण के साथ समकक्ष क्षमता को आंतरिक रूप से बनाने से अधिक लागत ले सकती है।

किसी विक्रेता के प्रति प्रतिबद्ध होने से पहले डेटा स्वामित्व और पोर्टेबिलिटी का मूल्यांकन करें

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

निर्णय के दोनों पक्षों पर एकीकरण लागत के लिए यथार्थवादी बजट बनाएँ

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

ख़रीद, सुरक्षा, और संप्रभुता बाधाओं का स्पष्ट रूप से और जल्दी हिसाब लगाएँ

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

समझौते: लाभ और हानि

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

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

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

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

क्षेत्र दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

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

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

विरोधी-पैटर्न और नुक़सान

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

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

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

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

हमारे वर्तमान मेट्रिक्स में से किसे उस अनुकूलन से सबसे अधिक लाभ होगा जो हमें वर्तमान में नहीं मिल रहा है?
क्या हमने पुष्टि की है कि यदि हमें विक्रेता बदलने की आवश्यकता होती तो हम अपना पूरा ऐतिहासिक मेट्रिक्स डेटा निर्यात कर सकते थे?
क्या हमारे अंतिम टूलिंग निर्णय ने यथार्थवादी रूप से एकीकरण लागत का हिसाब लगाया?
हम किस ख़रीद, सुरक्षा, या संप्रभुता बाधा को कम आँक रहे हो सकते हैं?
हमारे विशिष्ट मेट्रिक सेट के लिए एक जान-बूझकर हाइब्रिड रणनीति कैसी दिखेगी?

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

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

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

Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (मेट्रिक परिवार जिन पर इस विषय का बिल्ड-बनाम-ख़रीद विश्लेषण लागू होता है)।
Cloud FinOps, by J.R. Storment and Mike Fuller (टूलिंग निवेश निर्णयों पर लागू लागत विश्लेषण सिद्धांत)।
The FinOps Foundation’s FinOps Framework, finops.org (क्लाउड और SaaS टूलिंग लागतों का मूल्यांकन और प्रबंधन करने पर अभ्यासकर्ता मार्गदर्शन)।
U.S. Federal Risk and Authorization Management Program (FedRAMP) दस्तावेज़ीकरण: सरकारी क्लाउड टूलिंग सुरक्षा और संप्रभुता आवश्यकताओं पर आधिकारिक मार्गदर्शन।