एरिक जीएफेसर, एसपीआर के डेटा प्रैक्टिस के प्रिंसिपल आर्किटेक्ट – साक्षात्कार श्रृंखला

एरिक ने 2018 में एसपीआर के एमर्जिंग टेक्नोलॉजी ग्रुप के डेटा प्रैक्टिस में प्रिंसिपल आर्किटेक्ट के रूप में शामिल हुए।

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

आपको मशीन लर्निंग में शुरू में क्या आकर्षित किया?

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

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

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

आप एक बड़े ओपन सोर्स समर्थक हैं, आप ओपन सोर्स इतना महत्वपूर्ण क्यों है इस पर चर्चा कर सकते हैं?

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

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

व्यावसायिक ओपन सोर्स इन लाभों का लाभ उठाता है, वास्तविकता यह है कि कई आधुनिक उत्पाद ओपन सोर्स का उपयोग करते हैं, यहां तक कि व्यावसायिक संस्करणों में भी जो आमतौर पर ओपन सोर्स रिलीज के हिस्से के रूप में उपलब्ध नहीं होने वाले अतिरिक्त घटक प्रदान करते हैं, जो विभेदक और समर्थन प्रदान करते हैं यदि इसकी आवश्यकता है।

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

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

आपने प्रूफ ऑफ कॉन्सेप्ट, प्रोटोटाइप और एमवीपी के निर्माण के लिए ओपन सोर्स का उपयोग किया है। क्या आप इन उत्पादों में से कुछ के पीछे अपनी यात्रा साझा कर सकते हैं?

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

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

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

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

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

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

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

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

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

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

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

ओपन सोर्स के बारे में आपका एक और विश्वास यह है कि यह ‘मजबूत डेवलपर समुदायों तक पहुंच’ प्रदान करता है। इन समुदायों में से कुछ कितने बड़े हैं और वे इतने प्रभावी क्यों हैं?

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

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

आपने अपनी वेबसाइट पर 100 से अधिक पुस्तकों की समीक्षा की है, क्या आप अपने पाठकों के लिए तीन पुस्तकें सिफारिश कर सकते हैं?

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

(1) ओ’रेली से एक पुस्तक जिसे मैंने सिफारिश की है वह “इन सर्च ऑफ डेटाबेस निर्वाण” है। लेखक विस्तार से बताता है कि एक डेटा क्वेरी इंजन के लिए ओएलटीपी से लेकर विश्लेषण तक के स्पेक्ट्रम पर कार्यभार को समर्थन देने के लिए क्या चुनौतियां हैं, जिसमें मध्य में ऑपरेशनल और व्यवसायिक खुफिया कार्यभार शामिल हैं। यह पुस्तक एक मार्गदर्शक के रूप में उपयोग की जा सकती है ताकि यह आकलन किया जा सके कि एक डेटाबेस इंजन या क्वेरी और स्टोरेज इंजनों का संयोजन आपकी कार्यभार आवश्यकताओं को पूरा करने के लिए तैयार है या नहीं, चाहे वे लेन-देनकारी हों, विश्लेषणात्मक हों या इन दोनों का मिश्रण हों। इसके अलावा, लेखक का “डेटाबेस पेंडुलम” के बारे में हाल के वर्षों में कवरेज विशेष रूप से अच्छा है।

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

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

आप एसपीआर के डेटा प्रैक्टिस के प्रिंसिपल आर्किटेक्ट हैं। क्या आप बता सकते हैं कि एसपीआर क्या करता है?

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

एसपीआर के साथ आपकी कुछ जिम्मेदारियां क्या हैं?

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

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

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

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

क्या आप एसपीआर के साथ काम करने वाली किसी और परियोजना के बारे में कुछ और साझा करना चाहेंगे?

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

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

यह एक दिलचस्प साक्षात्कार रहा है जो कई विषयों को छूता है, मुझे लगता है कि मैंने ओपन सोर्स के बारे में बहुत कुछ सीखा है। जो पाठक अधिक जानना चाहते हैं वे एसपीआर की कॉर्पोरेट वेबसाइट या एरिक जीएफेसर की वेबसाइट पर जा सकते हैं।