8.4 प्लेटफ़ॉर्म इंजीनियरिंग और डेवलपर अनुभव

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

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

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

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

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

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

सिफारिशें

प्लेटफ़ॉर्म को एक उत्पाद के रूप में बनाएं

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

गोल्डन पथ और पक्की सड़कें प्रदान करें

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

वास्तविक स्व-सेवा इन्फ्रास्ट्रक्चर डिलीवर करें

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

डेवलपर पोर्टल, सेवा कैटलॉग, और स्कोरकार्ड प्रदान करें

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

संतुलित ढांचों के साथ डेवलपर अनुभव को मापें

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

संज्ञानात्मक भार को कम करने को एक प्रथम-श्रेणी लक्ष्य के रूप में रखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

स्टार्टअप। एक बारह-व्यक्तियों वाले स्टार्टअप के पास कोई प्लेटफ़ॉर्म टीम नहीं है, इसलिए एक वरिष्ठ इंजीनियर कुछ शुक्रवार एक ही “नई सेवा” टेम्पलेट रिपॉज़िटरी बनाने में बिताता है जो CI, एक Dockerfile, लिंटिंग, और एक स्वास्थ्य जांच के साथ पहले से जुड़ी आती है। कोई भी इंजीनियर इसे क्लोन कर सकता है और एक घंटे के भीतर स्टेजिंग में एक सेवा चला सकता है, बजाय इसके कि किसी पुरानी परियोजना से कॉन्फ़िग कॉपी करे और अंतरालों का अनुमान लगाए। टेम्पलेट गोल्डन पथ है, और क्योंकि यह स्पष्ट रूप से सभी का समय बचाता है, पूरी टीम इसे बिना किसी के कहे अपना लेती है।

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

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

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

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

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

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

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

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

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

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

स्तर 3: मानकीकृत करें। एक प्लेटफ़ॉर्म टीम दस्तावेज़ीकृत गोल्डन पथ, स्व-सेवा प्रोविज़निंग, एक सेवा कैटलॉग वाला डेवलपर पोर्टल, और स्कोरकार्ड चलाती है, पूरे संगठन में लागू। सुरक्षा, नीति, और अनुपालन के लिए गार्डरेल पक्की सड़कों में एम्बेडेड हैं, इसलिए मानक कार्यप्रवाह ही अनुपालक कार्यप्रवाह है, और समूह के अनुसार बदलने के बजाय समान परंपराएं सभी टीमों में लागू होती हैं।

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

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

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

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

मुख्य बातें

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

संदर्भ और आगे का पठन

• Matthew Skelton and Manuel Pais, Team Topologies.
• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, et al., “The SPACE of Developer Productivity” (पेपर)।
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
• Gregor Hohpe, The Software Architect Elevator.
• Camille Fournier, The Manager’s Path.
• Cloud Native Computing Foundation, प्लेटफ़ॉर्म इंजीनियरिंग श्वेतपत्र (white paper)।