सॉफ्टवेयर फैक्ट्री क्या है?

इस वर्ष की शुरुआत में, 8090 में हमारी टीम ने एक बड़ी संस्था के बिलिंग इंजन को अलग किया। यह COBOL और असेंबली की 18 मिलियन लाइनें थीं जो हमारे कुछ इंजीनियरों के जन्म से पहले से जमा हो रही थीं। अब कोई भी इसे पूरी तरह से नहीं समझता था, लेकिन अपने सॉफ़्टवेयर फ़ैक्टरी का उपयोग करके, हमने इसे 40 दिनों में 100,000 से अधिक सादे-अंग्रेज़ी नियमों में रिवर्स-इंजीनियर किया। उस काम को पूरा करने पर मुझे एहसास हुआ कि क्यों "सॉफ़्टवेयर फ़ैक्टरी" वाक्यांश अचानक हर किसी के द्वारा इस्तेमाल किया जा रहा था।

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

यह शब्द जितना लोग समझते हैं उससे कहीं अधिक पुराना है

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

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

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

यही मानक है, और मैं तर्क दूंगा कि आधुनिक सॉफ़्टवेयर फ़ैक्टरियों को भी इसका पालन करना चाहिए।

पाँच परीक्षण

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

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

परीक्षण दो: एक फ़ैक्टरी निरंतर परिवर्तन के तहत सुसंगतता बनाए रखती है। यह सबसे कठिन परीक्षण है, और यह वह है जिसके बारे में AI टूलिंग बाज़ार में लगभग कोई बात नहीं करता, क्योंकि उनके उत्पाद इसे और खराब करते हैं।

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

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

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

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

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

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

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

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

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

हमारे एक ग्राहक, एक सार्वजनिक रूप से कारोबार करने वाला स्वास्थ्य बीमाकर्ता, ने अपने देय-दावों के नियमों को एक नियतात्मक प्री-फिल्टर में बदल दिया और एक पे-पर-कैच विक्रेता को भेजे जाने वाले दावों को 80% से अधिक कम कर दिया, जिससे चार वर्षों में $20 मिलियन से अधिक की बचत हुई। ऐसे आंकड़े तभी होते हैं जब काम करने वाली पार्टी परिणाम के लिए जिम्मेदार होती है।

क्या एक फ़ैक्टरी नहीं है

परीक्षणों को लागू करें और जो खुद को फ़ैक्टरी कहते हैं उनमें से कई इसके बजाय कुछ और हैं।

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

एजेंट ऑर्केस्ट्रेशन डैशबोर्ड पर्यवेक्षण उपकरण हैं। वे एजेंटों को काम करते देखना आसान बनाते हैं।

बेंचमार्क उपकरणों के लिए माप हार्नेस हैं। एक उच्च स्कोर आपको बताता है कि एक उपकरण बेंचमार्क किए गए कार्यों में अच्छा है। यह आपको यह नहीं बता सकता कि क्या मनुष्यों और एजेंटों की मिश्रित टीमों द्वारा निरंतर परिवर्तन के दो वर्षों के बाद आपका सिस्टम सुसंगत रहता है।

अभी परिभाषा क्यों मायने रखती है

सॉफ़्टवेयर उत्पादन की लागत गिर रही है। और जब उत्पादन लागत गिरती है, तो मूल्य उस ओर स्थानांतरित हो जाएगा जो कोई भी आउटपुट की गारंटी दे सकता है। इससे पहले हर औद्योगीकरण प्रक्रिया में ऐसा हुआ है और अब AI में फिर से होगा।

'फ़ैक्टरी' शब्द को पकड़ने वाले स्टार्टअप सहज रूप से इसे समझते हैं। लेकिन कई औद्योगिक उत्पादन की विश्वसनीयता तक पहुंच रहे हैं बिना उस दायित्व को स्वीकार किए जिसने पहली बार में वह विश्वसनीयता पैदा की।

इसलिए डेमो और बेंचमार्क को अनदेखा करें, और हर सॉफ़्टवेयर फ़ैक्टरी से एक प्रश्न पूछें: जब सिस्टम उत्पादन में टूटता है, तो कॉल कौन लेता है?

एक सॉफ़्टवेयर फ़ैक्टरी के मामले में, उत्तर 'हम करते हैं' होना चाहिए।