फुर्तीले वातावरण में डेटा मॉडलिंग

टेकोपेडिया स्टाफ द्वारा, 16 नवंबर 2016

Takeaway: होस्ट एरिक कवनघ ने रॉबिन ब्लोर, डीज़ ब्लांचफील्ड और आइडेरा के रॉन हुइज़ेंगा के साथ फुर्तीले विकास में डेटा मॉडलिंग के महत्व पर चर्चा की।

आप वर्तमान में लॉग इन नहीं हैं। वीडियो देखने के लिए कृपया लॉग-इन या साइन-अप करें।

एरिक कवनघ: ठीक है, देवियों और सज्जनों। एक बार फिर से आपका स्वागत है। यह बुधवार को 4:00 ईएसटी पर है। इसका मतलब है कि यह हॉट टेक्नोलॉजीज का समय है। हाँ सचमुच। मेरा नाम एरिक कवनघ है, मैं आपका मेजबान बनूंगा।

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

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

डेटा मॉडल एक मौलिक तरीके से व्यवसाय का प्रतिनिधित्व करता है, इसलिए ये सभी नए डेटा स्रोत गेम को कैसे बदल रहे हैं? हम इसके बारे में पता लगाने जा रहे हैं। हम यह पता लगाने जा रहे हैं कि आप किस तरह से चुस्त-दुरुस्त रह सकते हैं। और हां, यह साल का शब्द है।

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

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

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

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

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

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

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

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

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

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

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

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

मुझे लगता है कि मैंने काफी कुछ कहा है। मैं डीज़ ब्लांचफील्ड को पारित करने जा रहा हूं, जो पूरी तरह से कुछ और कहेगा।

Dez Blanchfield: धन्यवाद। पालन ​​करने के लिए हमेशा एक कठिन कार्य है, लेकिन यह एक ऐसा विषय है जिस पर हम सहमत हुए हैं और इस बारे में संक्षिप्त रूप में प्रीवेज़ नोट्टर में बात की है, और यदि आप जल्दी में डायल करते हैं, तो आप शायद महान रत्नों का एक पूरा गुच्छा पकड़ लेंगे। Takeaways में से एक, और मैं इस विशेष की गड़गड़ाहट को चोरी नहीं करना चाहता, लेकिन हमारे preshow प्रतिबंध से takeaways में से एक जिसे मैं साझा करना चाहता हूं, अगर आप इसे नहीं पकड़ते हैं, तो यह सिर्फ विषय के आसपास था डेटा की यात्रा, और इसने मुझे वास्तव में यह लिखने के लिए मारा कि यात्रा डेटा के बारे में सोचने के बारे में सोचती है जो कि पीढ़ीगत जीवनकाल के आसपास एक अलग संदर्भ में होती है - वर्ष, महीने, सप्ताह, दिन, घंटे, मिनट, दूसरा - और डेटा के आसपास के संदर्भ हैं उस संदर्भ में तैनात हैं। चाहे मैं एक डेवलपर कोड चला रहा हूं, या चाहे मैं एक डेटा विशेषज्ञ हूं और मैं संरचना और प्रारूप और मेटाडेटा में से प्रत्येक तत्व के आसपास, या जिस तरह से सिस्टम और व्यवसाय के साथ बातचीत करता हूं, उसके बारे में सोच रहा हूं।

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

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

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

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

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

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

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

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

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

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

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

इसे ध्यान में रखते हुए, मैं IDERA में अपने अच्छे दोस्त के पास जा रहा हूं और उस टूल के बारे में सुनता हूं और यह इन चीजों को कैसे संबोधित करता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

और बस! यहां से हम और सवाल करेंगे।

एरिक Kavanagh: ठीक है, अच्छा, मुझे इसे पहले रॉबिन को फेंक दें। और फिर, डीज़, मुझे यकीन है कि आपके पास कुछ सवाल हैं। इसे ले जाओ, रॉबिन।

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

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

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

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

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

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

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

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

वैसे भी, मैं डीज़ को पास कर दूंगा क्योंकि मुझे लगता है कि मुझे अपना आवंटित समय मिल गया है। Dez?

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

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

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

Dez Blanchfield: उनमें से एक चीज़ जो दिमाग में आती है, वह यह है कि, आप जानते हैं, मैं रोज़ाना होने वाली बहुत सी बातचीत इस मालगाड़ी के बारे में कर रहा हूँ, जैसे, मशीन-टू -मैचिन और IoT। और अगर हमें लगता है कि उद्यम में हमारे वर्तमान वातावरण पर अब हमें बहुत अधिक डेटा मिल गया है, तो आप जानते हैं, अगर हम यूनिकॉर्न्स को एक पल के लिए अलग लेते हैं, जहां हम जानते हैं कि Googles और Facebook और Ubers में डेटा की पेटाबाइट्स हैं, लेकिन एक पारंपरिक उद्यम में हम अभी भी सैकड़ों टेराबाइट्स और बहुत सारे डेटा के बारे में बात कर रहे हैं। लेकिन संगठनों में यह मालगाड़ी आ रही है, मेरे विचार में, और डॉ। रॉबिन ब्लोर ने इसे पहले, IoT को बताया। आप जानते हैं, हमने बहुत से वेब ट्रैफ़िक प्राप्त किए हैं, हमने सोशल ट्रैफ़िक प्राप्त किया है, अब हमें गतिशीलता और मोबाइल डिवाइस मिल गए हैं, क्लाउड में विस्फोट हो गया है, लेकिन अब हमें स्मार्ट इन्फ्रास्ट्रक्चर, स्मार्ट सिटी मिल गए हैं और इस डेटा की पूरी दुनिया है कि बस विस्फोट हो गया है।

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

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

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

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

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

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

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

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

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

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

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

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

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