टेकवे: होस्ट एरिक कवानाग रॉबिन ब्लॉर, डेझ ब्लांचफिल्ड आणि आयडीआरए च्या रॉन हुईझेंगा यांच्यासह चपळ विकासामध्ये डेटा मॉडेलिंगच्या महत्त्वविषयी चर्चा करते.
आपण सध्या लॉग इन केलेले नाही. कृपया व्हिडिओ पाहण्यासाठी लॉग-इन किंवा साइन-अप करा.
एरिक कवानाग: ठीक आहे, स्त्रिया आणि सज्जन. पुन्हा एकदा आपले स्वागत. त्याचा बुधवार 4:00 EST वाजता याचा अर्थ असा आहे की हॉट टेक्नॉलॉजीजची वेळ आहे. हो नक्कीच. माझे नाव एरिक कवानाग आहे, मी तुमचा यजमान होईन.
आजच्या विषयासाठी ते एक जुने पण चांगले आहे. हे दररोज अधिक चांगले होत आहे कारण ते आमच्या डेटा व्यवस्थापन जगाला आकार देणारे आहे, "डेटा ऑफ मॉडेलिंग इन एगेल वातावरणा". आपल्याबद्दल खरोखर एक स्लाइड आहे, मला @eric_kavanagh वर दाबा. आपण त्या स्लाइडवर खरोखर ते ठेवले पाहिजे. मी त्या वर जावे लागेल.
त्यामुळे वर्षे गरम. डेटा मॉडेलिंग कायमच आहे. हे खरोखर माहिती व्यवस्थापन व्यवसायाचे हृदय आणि आत्मा आहे, डेटा मॉडेल्स डिझाइन करीत आहे, व्यवसाय मॉडेल समजून घेण्याचा प्रयत्न करीत आहे आणि आपल्या डेटा मॉडेलमध्ये त्यांना संरेखित करतात. आपण जे करण्याचा प्रयत्न करीत आहात ते खरंच आहे ना?
डेटा मॉडेल मूलभूत मार्गाने व्यवसायाचे प्रतिनिधित्व करतो, मग हे सर्व नवीन डेटा स्रोत गेम बदलत कसे आहेत? त्याबद्दल शोधून काढत होतो. आपण चपळ मार्गाने गोष्टींच्या वर कसे रहाल हे शोधत आहात. आणि अर्थातच हा वर्षाचा शब्द आहे.
आमच्याबरोबर रॉबिन ब्लॉरस, आमचे मुख्य विश्लेषक, ऑस्ट्रेलियाचे सिडनीहून कॉल करणारे डेझ ब्लान्कफिल्ड आणि आयडेराचे वरिष्ठ उत्पादन व्यवस्थापक रॉन हुईझेंगा - या जागेचे माझे दीर्घ काळापासूनचे मित्र, या उत्कृष्ट स्पीकरला त्याची सामग्री माहित आहे, म्हणून लाजाळू नका, त्याला विचारू नका कठीण प्रश्न, लोकांना, कठीण प्रश्न. त्यासह, मी रॉबिनला सादरकर्ता बनविणार आहे, आणि ते घेऊन जाईल.
डॉ रॉबिन ब्लॉर: ठीक आहे. पण, त्याबद्दल धन्यवाद, एरिक. मला असे वाटते की मॉडेलिंगबद्दल मला असे वाटते की मी अस्तित्त्वात येण्यापूर्वीच मी आयटीच्या जगात होतो, ज्या अर्थाने मी काम केले त्या विमा कंपनीत मला आठवते, आमच्याकडे एक माणूस आला होता आणि आम्हाला सर्व प्रकारची देईल डेटाचे मॉडेल कसे करावे यावर कार्यशाळेचे. तर जवळपास years० वर्षे बघत होती, ती years० वर्षे आहे का? कदाचित त्याहूनही लांब, कदाचित 35 वर्षांपूर्वी. एक दीर्घ, दीर्घ काळापासून मॉडेलिंग हा खरोखर उद्योगाचा एक भाग आहे आणि अर्थातच कॅटवॉकवर असलेल्या स्त्रियांसह त्याचे काहीही झाले नाही.
मला म्हणायचे होते की मी सामान्यत: जे करतो तेच मी आणि डेझ वेगवेगळ्या गोष्टींबद्दल बोलतो आणि मला वाटायचे की आयडी मॉडेलिंगला सर्वसाधारण विहंगावलोकन देते पण आता यातून वास्तव दिसून येत आहे.
आमच्याकडे, आपल्याला माहिती आहे, मोठी डेटा सत्यता आहे, आमच्याकडे अधिक डेटा आहे, अधिक डेटा स्रोत आहेत, आम्हाला डेटा स्ट्रीम मिळाला आहे ज्याने मागील तीन किंवा चार वर्षांत समीकरण प्रविष्ट केले आहे आणि त्यातील मोठा भाग मिळवण्यास सुरवात केली आहे, आणि तेथे आहे डेटा समजून घेण्याची अधिक आवश्यकता आणि बदलाच्या दरामध्ये होणारी वाढ ही अधिक डेटा जोडली जात आहे आणि अधिक डेटा स्ट्रक्चर्स वापरली जात आहेत.
हे एक कठीण जग आहे. येथे एक चित्र आहे, जे खरोखर जवळजवळ तीन वर्षांपूर्वी आम्ही काढले परंतु मुळात एकदा आपण मिश्रण मध्ये प्रवाहित केले आणि आपल्याला डेटा रिफायनरी, डेटा हब, डेटा लिंक किंवा जे काही मिळेल याची कल्पना येते तेव्हा आपल्याला दिसते की तेथे डेटा आहे. खरोखर विश्रांती, या अर्थाने की हे बरेच काही हलवित नाही. आणि मग डेटा, प्रवाह आणि आपल्याला सर्व व्यवहारात्मक अनुप्रयोग प्राप्त झाले, तसेच आजकाल आपल्याला कार्यक्रम, कार्यक्रमात घडणा and्या आणि डेटा आवश्यक असलेल्या गोष्टी मिळाल्या आहेत, आणि आजकाल लॅम्ब्डा आर्किटेक्चरविषयी ज्या प्रत्येक गोष्टीविषयी बोलत आहे, त्यांचा खरोखरच प्रभाव पडत आहे फक्त डेटा संपूर्ण फील्ड.
आणि आजकाल तेथे डेटा लेयर असल्याच्या दृष्टीने विचार करा. डेटा लेयर एक प्रकारचा आभासी मार्गाने अस्तित्वात आहे, या अर्थाने की त्याचा एक चांगला तुकडा ढगात असू शकतो आणि तो डेटा सेंटरमध्ये पसरला जाऊ शकतो, तो वर्कस्टेशन्सवर अस्तित्वात असू शकतो. डेटा लेयर म्हणजे काही प्रमाणात, सर्वत्र आणि त्या अर्थाने, सर्वत्र अशी प्रक्रिया आहेत जी डेटावर प्रक्रिया करण्यासाठी आणि डेटा हलविण्यासाठी एका मार्गाने प्रयत्न करत आहेत. परंतु आपण त्याबद्दल हालचाल करता तेव्हा काय आहे हे देखील जाणून घेणे ही एक मोठी गोष्ट आहे.
जर आम्ही सर्वसाधारणपणे डेटा मॉडेलिंगकडे पाहिले तर या प्रकारच्या स्टॅकच्या तळाशी आपल्याकडे फायली आणि डेटाबेस आहेत. आपल्याकडे डेटा घटक आहेत, ज्यात की, घटक व्याख्या, उपनावे, प्रतिशब्द, विशिष्ट भौतिक स्वरूप आणि नंतर आमच्याकडे हा मेटाडेटा स्तर आहे.
मेटाडेटाबद्दल मनोरंजक गोष्ट म्हणजे डेटाचा अर्थ कसा होतो हे मेटाडेटा पूर्णपणे आहे. आपल्याकडे वास्तविकपणे मेटाडेटा नसल्यास, नंतर आपण डेटाच्या अर्थाचा अंदाज लावू शकता, परंतु आपल्याला खूपच अडचणी असतील. मेटाडेटा तेथे असणे आवश्यक आहे, परंतु अर्थात रचना आहे. मला अर्थशास्त्राच्या तत्वज्ञानामध्ये जायचे नाही, परंतु डेटाद्वारे आपण ज्या पद्धतीने व्यवहार करतो त्या मार्गानेदेखील मानवी विचार आणि मानवी भाषेमध्ये बरेच कुतूहल आहे जे डेटामध्ये सहजपणे व्यक्त होत नाहीत. परंतु आपण जगात प्रत्यक्षात प्रक्रिया केलेल्या डेटाच्या बाबतीतही, मेटाडेटाचा अर्थ आहे आणि मेटाडेटाची रचना - दुसर्‍याच्या संबंधातील डेटाचा एक तुकडा आणि जेव्हा ते एकत्र ठेवले जातात तेव्हा याचा अर्थ काय आहे आणि जेव्हा ते दुसर्‍यासह सामील झाले तेव्हा याचा अर्थ काय आहे डेटा, आम्ही हे मॉडेल बनवण्याची मागणी करतो. फक्त गोष्टींमध्ये मेटाडेटा टॅग रेकॉर्ड करणे इतके चांगले नाही, आपल्याला दर रचना आणि अर्थ यांच्यातील संबंध रेकॉर्ड करणे आवश्यक आहे.
तर आपल्याकडे वरच्या थरात आहे, व्यवसाय व्याख्या, जे सामान्यत: मेटाडेटा दरम्यान अर्थ हस्तांतरित करण्याचा प्रयत्न करणारा एक स्तर आहे, जो डेटा संगणकावरील आणि मानवी अर्थांवर डेटा व्यवस्थित केला जातो त्या मार्गाने डेटा व्याख्याचा एक प्रकार आहे. तर आपल्याकडे व्यवसायाच्या अटी, परिभाषा, नातेसंबंध, अस्तित्वा-पातळीवरील संकल्पना आहेत ज्या त्या थरात अस्तित्वात आहेत. आणि जर या थरांमध्ये विसंगती असेल तर आपल्याकडे डेटा मॉडेलिंग असणे आवश्यक आहे. हे खरोखर पर्यायी नाही. स्वयंचलित करण्याच्या बाबतीत आपण जितके हे करू शकता तितके चांगले. परंतु याचा अर्थ करण्याबरोबरच त्याला पर्यायी बनविणे खरोखर अवघड आहे. रेकॉर्डमध्ये मेटाडेटा पकडणे आणि अर्थांच्या मालिकेतून ते प्राप्त करण्यास सक्षम असणे इतके सोपे आहे, परंतु हे आपल्याला रेकॉर्डची रचना किंवा रेकॉर्डचा अर्थ किंवा विनोदी म्हणजे काय ते सांगत नाही.
तर, हे असे आहे जे माझ्या मते, डेटा मॉडेलिंगचे आहे. लक्षात ठेवण्याचे मुद्देः डेटा विश्वाचे जितके गुंतागुंतीचे होईल तितके आपल्याला त्याचे मॉडेल तयार करण्याची आवश्यकता आहे. दुस words्या शब्दांत सांगायचे तर असे आहे की, जगामध्ये गोष्टींच्या नुसत्या उदाहरणे न घालता, जी डेटा रेकॉर्डशी संबंधित असेल, परंतु अधिकाधिक गोष्टींवर डेटा कॅप्चर करून जगाला अधिक अर्थ दर्शविते. ही आम्हाला अधिकाधिक समजून घ्यावी लागणारी जास्तीत जास्त गुंतागुंतीची भावना बनणे होय.
सिद्धांत एक डेटा विश्व आहे आणि आम्हाला त्या दृष्टीने आवश्यक आहे. सराव मध्ये, वास्तविक मेटाडेटा हा डेटा विश्वाचा एक भाग आहे. तर, ही साधी परिस्थिती नाही. सुरुवातीस मॉडेलिंग टॉप-डाऊन आणि बॉट-अप आहे. आपल्याला दोन्ही दिशानिर्देश तयार करण्याची आवश्यकता आहे आणि त्यामागील कारण म्हणजे डेटा आणि संगणक आणि प्रक्रियेसाठी अर्थ आहे, त्यावर प्रक्रिया करणे आवश्यक आहे, परंतु त्याचा स्वतःच्या अर्थाने अर्थ आहे. तर, आपल्याला एक तळागाळातील अर्थ आवश्यक आहे, जो डेटामध्ये प्रवेश करण्यासाठी आवश्यक असलेल्या सॉफ्टवेअरला संतुष्ट करतो आणि आपल्याला टॉप-डाऊन अर्थ आवश्यक आहे जेणेकरुन मानव ते समजू शकेल. मेटाडेटा मॉडेल्सची इमारत एक प्रकल्प नाही आणि कधीही असू शकत नाही; ही एक चालू असलेली क्रियाकलाप - अस्तित्वात असलेल्या प्रत्येक वातावरणात चालू असलेली क्रियाकलाप असावी. सुदैवाने, बरीच वातावरणे आहेत, जिथे खरं तर तसे दिसत नाही आणि त्यानुसार गोष्टी नियंत्रणातून बाहेर पडतात.
तंत्रज्ञानाच्या पुढे जाताना मॉडेलिंगचे महत्त्व वाढते. माझे मत. पण जर तुम्ही आयओटीकडे पाहिले तर आम्हाला मोबाईल पूर्वीच्यापेक्षा जास्त समजू शकेल, जरी तिचे नवीन परिमाण असले तरी: मोबाईलसह स्थानाचे परिमाण. एकदा तुम्ही आयओटीला गेल्यावर असामान्य डेटा समस्यांकडे पहात होता जो आपल्याला यापूर्वी कधीच करण्याची गरज नव्हती आणि आपल्याला एक मार्ग किंवा दुसरा आवश्यक आहे की आपल्याला काय मिळाले आहे ते अचूकपणे समजून घेण्यासाठी, आपण ते एकत्र कसे करू शकतो, आपण काय करू शकतो एकत्रितपणे अर्थ प्राप्त होण्याच्या दृष्टीने आणि अर्थातच आम्ही त्यावर प्रक्रिया केल्यावर आपण त्याचे काय करू शकतो.
मला असे वाटते की मला पुरेसे सांगितले. मी डेझ ब्लांचफिल्डला जात आहे, आणखी काही तरी सांगा.
डेझ ब्लांचफील्ड: धन्यवाद. अनुसरण करणे नेहमीच कठीण असले पाहिजे, परंतु प्रीशो बॅनरमध्ये आम्ही या विषयावर संक्षिप्तपणे बोललो आणि याबद्दल थोडा वेळ बोललो आणि जर आपण लवकर डाययल केले तर आपण कदाचित संपूर्ण रत्ने पकडली पाहिजेत. टेकवेजपैकी एक, आणि मला या विशिष्ट व्यक्तीची मेघगर्जना चोरण्याची इच्छा नाही, परंतु मला सांगायचंय अशा आमच्या प्रीशो बॅनरमधून एखादा मार्ग घ्या, जर आपण ते पकडले नाही, तर फक्त डेटाच्या प्रवासाच्या विषयावर होता. आणि वर्षानुसार महिने, आठवडा, दिवस, तास, मिनिट, सेकंद - आणि डेटाभोवतालची कॉन त्या कॉनच्या आत स्थित असतात आणि प्रत्यक्षात पिढ्यान्पिढ्या आयुष्यात डेटा वेगळ्या बाबीने घेत असलेल्या प्रवासाबद्दल विचार करून मला ते लिहिले. . मी विकसक चालू असलेला कोड असो, किंवा मी एखादा डेटा तज्ञ आणि रचनांचा आणि स्वरूपाचा आणि प्रत्येक घटकांच्या आसपास मेटाडेटाबद्दल विचार करीत आहे किंवा सिस्टम आणि व्यवसाय ज्या प्रकारे त्याद्वारे संवाद साधतो त्या मार्गाचा आहे.
फक्त एक गोष्ट लक्षात घेण्यासारखी ही एक रोचक गोष्ट आहे, परंतु तरीही, मला त्यात डुंबू द्या. डेटा डिझाइन, विशेषतः, मी एक गोष्ट आहे जी मी सर्व गोष्टींबद्दल बोलण्यासाठी वापरतो आणि विशेषत: अनुप्रयोग किंवा डेटाबेस मूलभूत सुविधांचा विकास करतो. मला वाटते की डेटा डिझाइन ही एक संज्ञा आहे जी हे सर्व माझ्या मनात अगदी चांगल्या प्रकारे व्यापते. आजकाल आम्ही जेव्हा डेटा डिझाइनबद्दल बोलतो, तेव्हा आम्ही आधुनिक चपळ डेटा डिझाइनबद्दल बोलतो आणि माझे मत असे आहे की विकासक आणि डेटा तज्ञांनी एकटेच काम केले म्हणून इतका वेळ झाला नाही; ते त्यांच्या स्वत: च्या सिलोमध्ये होते आणि डिझाइनचे तुकडे एका सिलोमधून दुस .्या सिलोवर गेले. परंतु, आजकाल मी बरेच काही पाहतो आहे, केवळ तेच नव्हे तर ते बदललेच पाहिजे; ही एक प्रकारची गरज आहे आणि ती ती म्हणजे अनुप्रयोग - डेव्हलपर आणि डेटाशी संबंधित असलेल्या विकासासाठी काहीही करावे, स्कीम आणि फील्ड आणि रेकॉर्ड्स आणि स्थान आणि डेटाबेस सिस्टम आणि मूलभूत संरचना, मॉडेलिंग आणि संपूर्ण व्यवस्थापन या संबंधित डिझाइन घटकांचे डिझाइन करणारे डिझाइनर त्या भोवती आव्हान. हा आता एक कार्यसंघ खेळ आहे आणि म्हणूनच आकाशातून पडणार्‍या लोकांची दृश्यास्पद प्रतिमा बाहेर खेळण्यासाठी माझे लोक विखुरलेल्या विमानातून उडी मारताना एका टीमच्या रूपात काम करीत असल्याचे माझे चित्र आहे.
तिसरे, हे घडवून आणण्यासाठी काय घडले? बरं, १ 6 in in मधे दोन सज्जनांनी लिहिलेला एक लेख आहे ज्यांच्या नावावर मी न्याय मिळवण्याचा कठोर प्रयत्न केला, हिरोटाका टेकूची आणि इकुजिरो नॉनका, मला असं वाटतं की त्यांनी "मोव्हिंग द स्क्रॅम डाउनफिल्ड" या शीर्षकातील एक लेख तयार केला. या स्क्रम क्रियाकलापातून रग्बीचा खेळ जिंकण्याच्या पद्धतीची ही कल्पना आहे, जिथे प्रत्येकजण एकाच ठिकाणी येतो आणि दोन संघ आवश्यकतेने डोक्यावर लॉक ठेवतात ज्यामुळे बॉलवर नियंत्रण मिळविण्यासाठी आणि शेतात खाली खेळायला मिळते. ट्राय लाईनवर जा आणि बॉलसह मैदानाला स्पर्श करा आणि बिंदू मिळवा, ज्याला ट्राईन म्हणतात आणि आपण या प्रक्रियेची पुनरावृत्ती करा आणि आपल्याला संघासाठी अधिक गुण मिळतील.
हा लेख १ 6 in6 मध्ये हार्वर्ड बिझिनेस रिव्ह्यू मध्ये प्रकाशित झाला होता आणि उत्सुकतेने त्याकडे बरेच लक्ष वेधले गेले. त्याकडे बरेच लक्ष गेले कारण त्याने आश्चर्यकारक नवीन संकल्पना आणल्या आणि त्या समोरच्या स्क्रीनशॉटवर आहे. म्हणून त्यांनी गेम रग्बीच्या बाहेर स्क्रॅमची ही संकल्पना घेतली आणि त्यांनी ती व्यवसायात आणि विशेषत: डिझाइन आणि प्रकल्प वितरणाच्या गेममध्ये आणली, विशेषत: प्रोजेक्ट वितरण.
स्क्रिन काय केले ते आम्हाला PRINCE2 किंवा PMBOK च्या आवडीच्या तुलनेत एक नवीन कार्यपद्धती दिली गेली होती जी आम्ही यापूर्वी वॉटरफॉल मेथडॉलॉजी म्हणून वापरत होती, आपल्याला माहित आहे, ही गोष्ट आणि ही गोष्ट करा आणि त्या अनुक्रमे अनुसरण करा आणि कनेक्ट करा आजूबाजूची सर्व ठिपके जे आपल्याकडे होते यावर अवलंबून असतात किंवा आपण भाग एक करेपर्यंत भाग दोन करू नका कारण तो भाग एकवर अवलंबून आहे. आम्हाला थोडी अधिक चपळ होण्याची नवीन पद्धत आहे, जिथून हा शब्द आला आहे, आम्ही वस्तू कशा वितरित करतो आणि विशेषतः डिझाईन आणि विकास तळागाळातील प्रकल्प वितरणासाठी.
काही मुख्य भाडेकरू - इतकेच मी यासह पुढे जाऊ - स्क्रॅमच्या मुख्य भाडेकरूंच्या आसपास आहे.याने अस्थिरता निर्माण करण्याच्या संकल्पनेची ओळख करुन दिली, की जर आपण अराजकाच्या भीतीबद्दल विचार केला तर जग अनागोंदीच्या स्थितीत अस्तित्वात आहे, परंतु ग्रह निर्माण झाला, जो मनोरंजक आहे, म्हणून अस्थिरता निर्माण करणे, थोडीशी उडी मारण्याची क्षमता आणि तरीही प्रत्यक्षात गोष्टी कार्य करतात, स्वत: ची आयोजन करणार्या प्रकल्पांचे कार्यसंघ, अत्यंत जबाबदार विकासाद्वारे ओव्हरलॅपिंग अनुकूलता, प्रकल्पांच्या प्रवासाच्या प्रवासात विविध प्रकारचे शिक्षण आणि नियंत्रण, शिक्षणाचे संस्थात्मक हस्तांतरण. तर मग आम्ही व्यवसायाच्या एका भागाकडून माहिती कशी घेऊ आणि ज्यांना कल्पना आहे परंतु ज्यांचा कोड विकसित होत नाही किंवा डेटाबेस आणि पायाभूत सुविधा विकसित होत नाहीत अशा लोकांकडून ती दुसर्‍याकडे हस्तांतरित करा, परंतु त्या लोकांसाठी डेटा कसा आहे? आणि विशेषत: टाइम-बॉक्स्ड निकाल. दुस words्या शब्दांत, हे काही कालावधीसाठी करूया, एकतर 24 तासांप्रमाणे एक दिवस, किंवा आठवड्यात किंवा दोन आठवड्यांपर्यंत आणि आपण काय करू शकतो ते पाहू आणि नंतर मागे वळून पहा.
आणि म्हणूनच, जर तुम्ही शब्दाला माफ केले तर हा प्रकल्प वितरणामधील खरोखरच एक नवीन खेळ आहे आणि त्यातील तीन मूलभूत घटक ज्यामुळे आपल्याला थोडासा पुढे जाताना अर्थ प्राप्त होईल - उत्पादन आहे: या सर्व लोकांची कल्पना आहे आणि ती आहे काहीतरी करण्याची गरज आणि आसपासची गोष्ट. डेव्हलपर जे त्यांच्या कथा मिळवण्याच्या चपळ मॉडेलमध्ये कार्य करतात आणि त्यावर चर्चा करण्यासाठी आणि त्यांना काय करण्याची आवश्यकता आहे हे समजण्यासाठी दररोज स्क्रॅम पद्धतीचा वापर करुन स्टँडअप्सद्वारे कार्य करतात आणि नंतर जा आणि पुढे जाऊन ते करा. मग लोकांनो, आम्ही स्क्रॅम मास्टर्सविषयी ऐकले आहे जे या संपूर्ण गोष्टीवर देखरेख ठेवतात आणि ते चालविण्यास कार्यपद्धती चांगल्या प्रकारे समजतात. आम्ही येथे या प्रतिमा पाहिल्या आहेत ज्या मला येथे उजव्या बाजूला सापडलेल्या भिंती आणि व्हाईटबोर्ड पोस्ट-इट नोट्सने भरलेल्या आहेत आणि त्या कानबंदीच्या भिंती म्हणून दिल्या आहेत. कानबान कोण आहे हे आपल्याला माहित नसल्यास, मी तुम्हाला गूगलला आमंत्रित करतो कि श्री कानबान कोण होते आणि आम्ही एका भिंतीतून एका बाजूला दुसर्‍या बाजूला वस्तू हलवण्याच्या मार्गाने हा बदल का झाला होता.
एका दृष्टीक्षेपात, स्क्रम वर्कफ्लो हे करते: ते एखाद्या संस्थेला करू इच्छित असलेल्या गोष्टींची यादी घेते, ज्यास आम्ही 24 तासांच्या कालावधीत, महिन्याभराच्या कालावधीत विभाजित केलेल्या एसएस कॉल करतो त्या मालिकेद्वारे त्यांना चालवा. आउटपुटची ही वाढीव मालिका मिळवा. प्रोजेक्टच्या वितरणाच्या मार्गामध्ये हा महत्त्वपूर्ण बदल आहे, त्या टप्प्यापर्यंत पोहचविला गेला कारण त्या भागाचा काही भाग अमेरिकन सैन्यासारखा वाहतो ज्याला पीएमबीओके नावाच्या गोष्टी विकसित करण्याचा मोठा भाग होता, जसे की टाकी शेतात न घेता ही कल्पना जोपर्यंत आपण गोळ्यांपर्यंत वस्तू ठेवत नाही कारण शेतातल्या टँकमध्ये बुलेट नसल्यास ते निरुपयोगी आहे. म्हणून भाग एक टाकी मध्ये बुलेट्स ठेवले आहे, भाग दोन शेतात टाकी ठेवले आहे. दुर्दैवाने, तरीही, विकास जगातील विकसकांसह जे काही घडले त्यास या चपळ पद्धतीचा ताबा मिळाला आणि आपण त्यास क्षमस्व माफ केले तर एस.
जे घडले तेच होते, जेव्हा आपण चातुर्याचा विचार करतो तेव्हा आम्ही सहसा विकसकांचा आणि डेटाबेसचा नसतो आणि डेटाबेसच्या जगाशी काहीही विचार करतो. हा एक दुर्दैवी परिणाम होता कारण वास्तविकता अशी आहे की चपळता केवळ विकासकांपुरती मर्यादित नाही. खरं तर, माझ्या दृष्टीने चपळ हा शब्द बर्‍याचदा चुकीच्या पद्धतीने केवळ सॉफ्टवेअर डेव्हलपर्सशी संबंधित असतो न की डेटाबेस डिझाइनर आणि आर्किटेक्ट्सशी. सॉफ्टवेअर आणि developmentप्लिकेशन डेव्हलपमेंटमध्ये आपल्याला जे आव्हान येत आहे त्या सर्व गोष्टींना डिझाइन, डेव्हलपमेंट, ऑपरेशन आणि देखभाल आणि म्हणूनच डेटा इन्फ्रास्ट्रक्चर आणि विशेषत: डेटाबेसमध्ये सामोरे जावे लागते. या विशिष्ट डेटा कास्टमधील कलाकारांमध्ये डेटा आर्किटेक्ट, मोल्डर्स, प्रशासक, डेटाबेस इन्फ्रास्ट्रक्चर्सचे मॅनेजर आणि वास्तविक डेटाबेस स्वतः व्यवसाय आणि सिस्टीम विश्लेषक आणि आर्किटेक्ट पर्यंत बसतात आणि सिस्टम कसे असतात याबद्दल विचार करतात आणि व्यवसाय चालवितो आणि याद्वारे डेटा कसा प्रवाहित केला जातो.
हा एक विषय आहे जो मी नियमितपणे समोर आणतो कारण डेटा निराकरण करण्याच्या प्रत्येक घटकामध्ये खरोखरच, विशेषत: विकासासाठी जवळजवळ सामील होणे आवश्यक आहे - असे मला वाटते की डेटा तज्ञांनी आवश्यक आहे असे केले पाहिजे असे मला वाटते. आमच्यासाठी ते नाही, मग आम्ही खरोखरच स्वत: ला चांगल्या परिणामासाठी सर्वोत्तम संधी देत नाही. आम्हाला बर्‍याचदा मागे वळावे लागते आणि या गोष्टींबद्दल पुन्हा विचार करावा लागतो कारण तेथे एक परिदृश्य अस्तित्त्वात आहे, आम्ही तयार केलेल्या अ‍ॅप्लिकेशनवर पोहोचतो आणि आम्हाला आढळते की विकसक नेहमीच डेटा तज्ञ नसतात. डेटाबेससह कार्य करण्यासाठी खूप खास कौशल्ये आवश्यक असतात, विशेषत: डेटाच्या आसपास, आणि एक अनुभव तयार करते. आपण त्वरित एका रात्रीत डेटाबेस गुरु किंवा डेटा ज्ञान तज्ञ बनू शकत नाही; आयुष्याच्या अनुभवातून आणि डॉ. रॉबिन ब्लॉर यांच्या संहिता आजच्या कोडवर ज्यांनी हे पुस्तक लिहिले आहे अशा अनेकदा हे बर्‍याचदा येते.
बर्‍याच प्रकरणांमध्ये - आणि हे दुर्दैवी आहे पण ते एक वास्तव आहे - हे आहे की या नाण्याच्या दोन भाग आहेत, ते म्हणजे सॉफ्टवेअर डेव्हलपर्सकडे डेटाबेस तज्ञांप्रमाणेच ब्लॅकआउट आहे आणि डेटाबेस डिझाइन मॉडेलिंगमध्ये आपल्याला आवश्यक कौशल्ये तयार केल्या आहेत, मॉडेल विकास फक्त एक आहे गुरू अभियांत्रिकीसाठी डेटा कसा येतो आणि प्रवासाची संघटना कशी घेते आणि ती कशा दिसली पाहिजे किंवा कशी असू नये याविषयी किंवा निःसंशयपणे हे शोधण्यात आले आहे की हे समजले आहे की सॉफ्टवेअर डेव्हलपरसाठी सामान्यतः मुळ कौशल्यांमध्ये ते मिळवले आहे. आणि आमची कोणती सामान्य आव्हाने आहेत ज्यात फक्त एक गोष्ट सांगायची असेल तर मूलभूत निर्मिती आणि देखभाल आणि मुख्य डेटाबेस डिझाइनची स्वतःच व्यवस्था करणे, डेटा आणि डेटाबेस इन्फ्रास्ट्रक्चरचे दस्तऐवजीकरण करणे आणि नंतर त्या डेटा मालमत्ता, स्कीमा डिझाइन, स्कीमा पिढ्या, स्कीमाचे प्रशासन आणि देखभाल आणि त्यायोगे वापर, हे स्कीमा एका विशिष्ट मार्गाने का डिझाइन केले गेले आहे याबद्दल माहिती सामायिक करणे आणि वेळोवेळी आलेल्या सामर्थ्य आणि कमकुवतपणामुळे डेटा बदलते, डेटा मॉडेलिंग आणि प्रकार आम्ही त्यांच्याद्वारे वाहणा systems्या सिस्टम आणि डेटावर मॉडेल्सचा वापर करतो. डेटाबेस कोड जनरेशन आणि ते एकत्रित होते आणि नंतर त्यांच्याभोवती डेटा तयार केला जातो आणि नंतर डेटाच्या आसपास सुरक्षितता नियंत्रित करण्यासाठी अधिक द्रुतपणे प्रवेश केला जातो, डेटाची अखंडता आम्ही तिची अखंडता टिकवून ठेवत डेटाभोवती फिरत असतो, तेथे पुरेसा मेटाडेटा असतो? ते, विक्रीमध्ये सर्व रेकॉर्ड टेबलमध्ये पहावेत की त्यांना फक्त पत्ता, प्रथम नाव, आडनाव जे आपण पोस्टमध्ये भरता आहात ते पहावे? आणि मग अर्थातच सर्वांत मोठे आव्हान म्हणजे मॉडेलिंग डेटाबेस प्लॅटफॉर्म जे पूर्णपणे स्वतःमध्ये एक भिन्न संभाषण आहे.
या दृष्टीकोनातून असेही लक्षात येते की या सर्वांपैकी कोणत्याही निर्वाणास शक्य करणे आवश्यक आहे, डेटा तज्ञ आणि विकसक दोघांनाही योग्य साधने आहेत आणि ती साधने संघ-केंद्रित प्रकल्प वितरण करण्यास सक्षम आहेत, डिझाइन, विकास आणि चालू परिचालन देखभाल. आपणास माहित आहे की डेटा तज्ञ आणि सॉफ्टवेअर विकसक यांच्यात प्रकल्पांमध्ये सहयोग करणे, डेटाबेसचे स्वत: चे दस्तऐवजीकरण करणे यासारख्या सर्व गोष्टींसाठी सत्य एकल बिंदू किंवा सत्याचा एक स्रोत . मला वाटते की या दिवसात आणि युगात हे अगदीच गंभीर आहे, आम्हाला राजा म्हणून डेटाचे हे निर्वाण मिळणार आहे, की योग्य साधने त्या जागी असणे आवश्यक आहे कारण आता स्वतःहून हे करण्याचे आव्हान आपल्यासाठी खूप मोठे आहे आणि लोक एका संस्थेमध्ये आणि पुढे जाणे, एखादी व्यक्ती चांगली असू शकते आणि ती कौशल्ये आणि क्षमता पुढे सरकवू शकत नाही अशा समान प्रक्रिया किंवा कार्यपद्धतीचे अनुसरण करणे आपल्यासाठी सोपे नाही.
हे लक्षात घेऊन, मी आयडीआरए येथे आमच्या चांगल्या मित्राकडे जाईन आणि त्या साधनाबद्दल आणि त्याद्वारे या गोष्टींकडे कसे लक्ष वेधेल याबद्दल मी ऐकत आहे.
रॉन हुईझेन्गा: मंचा खरोखरच चांगल्याप्रकारे सेट केल्याबद्दल रॉबिन व डेझ दोघांचे खूप आभार आणि मी बोललेल्या काही गोष्टींमध्ये आपण थोडेसे आच्छादित पाहणार आहात. परंतु मी डेटा मॉडेलिंगच्या दृष्टीकोनातून ज्या गोष्टींबद्दल बोलणार आहे अशा काही संकल्पनांसाठी त्यांनी खरोखर एक भक्कम पाया तयार केला आहे. जेव्हा मी टीम मॉडेल तसेच डेटा मॉडेलिंग आणि डेटा आर्किटेक्चरमध्ये काम करणारे सल्लागार होतो तेव्हा - त्या म्हणाल्या त्या बर्‍याच गोष्टी माझा स्वत: चा अनुभव प्रतिबिंबित करतात - सुरुवातीच्या काळात धबधबा आणि आम्ही ज्या प्रकल्पांमध्ये चतुर वापरत होतो अशा प्रकल्पांसह अधिक आधुनिक उत्पादनांमध्ये विकसित होत होता. उपाय वितरीत करण्यासाठी पद्धती.
म्हणून मी आज ज्या गोष्टींबद्दल बोलणार आहे ते त्या अनुभवांवर तसेच साधनांच्या दृश्यावर आणि त्या प्रवासासाठी आम्हाला मदत करण्यासाठी वापरलेल्या साधनांमधील काही क्षमतांवर आधारित आहे. मी जे थोडक्यात सांगणार आहे ते म्हणजे, मी बर्‍याच तपशीलात स्क्रॅममध्ये जाणार नाही; आमच्याकडे फक्त ते काय आहे याबद्दल खरोखर चांगले विहंगावलोकन होते. मी या संदर्भात याबद्दल बोलणार आहे, डेटा मॉडेल काय आहे आणि आपल्यासाठी याचा अर्थ काय आहे? आणि आम्ही आमच्या संस्थांमधील चपळ डेटा मॉडेलरची संकल्पना कशी सक्षम करू, या संदर्भात आम्ही डेटा मॉडेलर कसे व्यस्त ठेवू, त्या दरम्यान मॉडेलर आणि आर्किटेक्टचा सहभाग काय आहे, कोणत्या प्रकारच्या क्रियाकलापांमध्ये त्या गुंतल्या पाहिजेत. आणि त्या पार्श्वभूमीवर, त्या नोकरी सुलभ करण्यात खरोखरच मदत करण्यासाठी आपण वापरत असलेल्या काही मॉडेलिंग टूल्स क्षमता कोणत्या आहेत? मग मी काही लपेटून जाईन आणि काही व्यवसाय मूल्ये आणि डेटा मॉडेलरमध्ये सामील होण्याच्या फायद्यांविषयी किंवा मी प्रत्यक्षात ज्या प्रकारची कथा सांगणार आहे त्याबद्दल थोडीशी चर्चा करू. डेटा मॉडेलर पूर्णपणे प्रकल्पांमध्ये व्यस्त नसल्याची समस्या आणि मी त्या अनुभवावर आधारित आहे आणि मी बर्‍याच वर्षांपूर्वी गुंतलेल्या वास्तविक प्रकल्पाच्या आधी आणि नंतरच्या अनुभवावर आधारित आहे. आणि मग आम्ही आणखी काही मुद्द्यांचा सारांश घेऊ आणि त्यानंतर त्या व्यतिरिक्त प्रश्न आणि उत्तरे आमच्याकडे असतील.
थोडक्यात, ईआर स्टुडिओ एक अतिशय शक्तिशाली संच आहे ज्यामध्ये त्याचे बरेच वेगळे घटक आहेत. डेटा आर्किटेक्ट, जिथे डेटा मॉडेलर आणि आर्किटेक्ट त्यांचा बहुतेक वेळ डेटा मॉडेलिंग करण्यात घालवतात. यूएमएल मॉडेलिंगसाठी आम्ही काही मॉडेलिंग प्रक्रिया आणि सॉफ्टवेअर आर्किटेक्ट, जसे की बिझिनेस आर्किटेक्ट यासारख्या गोष्टींबद्दल बोलणार नाही. मग रेपॉजिटरी आहे, जिथे आम्ही तपासणी करतो आणि आम्ही मॉडेल्स सामायिक करतो आणि आम्ही कार्यसंघांना त्यासह सहयोग करण्यास आणि त्यांना कार्यसंघ सर्व्हरवर प्रकाशित करण्यास अनुमती देतो जेणेकरुन एका प्रकल्पात गुंतलेले एकाधिक भागधारक प्रेक्षक प्रत्यक्षात त्या कलाकृती पाहू शकतील. आम्ही डेटा प्रोजेक्टमध्ये आणि इतर गोष्टी बनवित आहोत जे आपण प्रकल्प वितरीत करत आहोत.
आज मी ज्या गोष्टीवर लक्ष केंद्रित करणार आहे त्या काही गोष्टी आम्ही डेटा आर्किटेक्टच्या बाहेर पाहणार आहोत आणि त्याबद्दल आम्हाला भांडार-आधारित पैलूंचे सहकार्य असणे खरोखर महत्वाचे आहे. विशेषत: जेव्हा आपण बदल व्यवस्थापन यासारख्या संकल्पनांबद्दल बोलणे सुरू करतो जे केवळ चपळ विकास प्रकल्पच नव्हे तर कोणत्याही प्रकारच्या विकासास पुढे जात आहे.
तर आपण क्षणभर चपळ डेटा मॉडेलरबद्दल बोलूया. आम्ही जसे आहोत तसे, सादरीकरणात पूर्वीचे संकेत दिले गेले आहेत, ते म्हणजे आपल्याकडे डेटा मॉडेलर आणि / किंवा आर्किटेक्ट पूर्णपणे चपळ विकास प्रक्रियेत गुंतलेले असणे अत्यावश्यक आहे. आता, ऐतिहासिकदृष्ट्या जे घडले तेच होय, आम्ही विकासाच्या दृष्टिकोनातून चापळपणाबद्दल खरोखर विचार केला आहे आणि त्यापैकी बर्‍याच गोष्टी घडल्या आहेत ज्यामुळे त्या घडल्या. त्यातील एक भाग म्हणजे विकास ज्या प्रकारे प्रगट झाला त्या स्वभावामुळे. जसजसे चपळ विकास सुरू झाला आणि आम्ही स्वयं-संघटनांच्या या संकल्पनेपासून सुरुवात केली, जर आपण कूल्ड-एड थोडासा शुद्ध प्याला आणि आपण गोष्टींच्या अत्यंत प्रोग्रामिंगच्या बाजूने असाल तर, अशा गोष्टींचे अगदी शाब्दिक अर्थ लावले गेले स्वयं-संघटना संघ, ज्याचा अर्थ बर्‍याच लोकांनी व्यक्त केला, आम्हाला फक्त विकासकांचा एक गट आहे जो संपूर्ण निराकरण तयार करू शकतो. याचा अर्थ कोड विकसित करणे, डेटाबेस किंवा त्यामागील डेटास्टोअर्स आणि सर्व काही विकसकांकडे सुटले होते. परंतु त्याबरोबर काय होते ते म्हणजे आपण लोकांमधील विशेष क्षमता गमावल्यास. मला आढळले की सर्वात मजबूत संघ असे असतात जे वेगवेगळ्या पार्श्वभूमीवरील लोक असतात. जसे की मजबूत सॉफ्टवेअर विकसक, डेटा आर्किटेक्ट, डेटा मॉडेलर, व्यवसाय विश्लेषक आणि व्यवसायातील सर्व घटकांचे संयोजन, समाप्तीची समाधानासाठी एकत्रितपणे एकत्र काम करणे.
आज मी जे बोलतो आहे ते आहे, मी हे एका विकास प्रकल्पाच्या अनुषंगाने करणार आहे जिथे आपण एखादा अनुप्रयोग तयार करीत आहोत जो साहजिकच डेटा घटक देखील संबद्ध करेल. तसे करण्यापूर्वी आम्हाला एक पाऊल मागे टाकण्याची आवश्यकता आहे, कारण आपल्याला हे समजणे आवश्यक आहे की तेथे केवळ काही विकास प्रकल्पातच मर्यादित असलेल्या डेटा निर्मिती आणि खर्चावर आपले लक्ष केंद्रित करते. . आम्हाला एका दिशेने एक पाऊल पुढे टाकण्याची आवश्यकता आहे आणि डेटाच्या दृष्टिकोनातून आणि प्रक्रियेच्या दृष्टीकोनातून एकंदरीत संस्थात्मक दृष्टिकोन पाहणे आवश्यक आहे. कारण आम्हाला जे माहिती मिळाली ती ती आहे जी आम्ही वापरत आहोत ती संस्था मध्ये आधीच अस्तित्वात असू शकते. मॉडेलर आणि आर्किटेक्ट म्हणून आम्ही ते प्रकाशात आणतो जेणेकरुन आम्हाला माहित आहे की स्वतः प्रकल्पांमधून ती माहिती कोठे मिळवायची. आम्हाला यात सामील असलेल्या डेटा स्ट्रक्चर्सची माहिती देखील आहे कारण विकसकांच्या कोडची डिझाइन पॅटर्न प्रमाणेच आमच्याकडे डिझाइन पॅटर्न आहेत. आणि आपण हा एकंदरीत संस्थात्मक दृष्टीकोन ठेवण्याची देखील आवश्यकता आहे. आम्ही तयार करीत असलेल्या अ‍ॅप्लिकेशनच्या कॉनमधील डेटा पाहत नाही. आम्हाला डेटा मॉडेल करणे आवश्यक आहे आणि आम्ही ते दस्तऐवजीकरण केले आहे याची खात्री करणे आवश्यक आहे कारण ते अनुप्रयोगांपेक्षा बरेच लांब आहे. ते अनुप्रयोग येतात आणि जातात, परंतु आम्हाला डेटा पाहण्याची आणि त्याची खात्री असणे आवश्यक आहे की ते दृढ आणि सुसंघटित आहे, केवळ अर्जासाठीच नाही तर क्रियाकलाप नोंदविणार्‍या निर्णयासाठी, द्वितीय अहवाल आणि इतर अनुप्रयोगांमध्ये समाकलन, अंतर्गत आणि आमच्या संस्थांना देखील बाह्य. म्हणून आम्हाला डेटाचे हे संपूर्ण मोठे चित्र आणि त्या डेटाचे जीवन चक्र काय आहे हे पाहणे आवश्यक आहे आणि संपूर्ण माहिती संस्थेच्या पाळणापासून कबरेपर्यंतच्या प्रवासात समजून घेणे आवश्यक आहे.
आता प्रत्यक्ष कार्यसंघाकडे परत आणि आम्हाला प्रत्यक्ष काम कसे करावे लागेल, धबधबा कार्यपद्धती निष्कर्षापेक्षा कमी गतीची समजली गेली. कारण, टँकच्या उदाहरणासह सूचित केल्यानुसार, ते एकापाठोपाठ एक पाऊल होते आणि कार्य करण्यायोग्य अंतिम निकाल देण्यात बर्‍याचदा वेळ लागला. आम्ही आता एक पुनरावृत्ती कार्य शैली असणे आवश्यक आहे जिथे आम्ही त्याचे घटक वाढवत आहोत आणि वेळोवेळी तपशीलवार वर्णन करत आहोत जिथे आपण वापरण्यायोग्य कोड किंवा वापरण्यायोग्य कलाकृती तयार करीत आहोत, प्रत्येक गोष्टसाठी मी सांगणार आहे. कार्यसंघातील तांत्रिक हितधारक आणि व्यवसायातील भागधारक यांच्यात सहकार्य आहे कारण आम्ही त्या वापरकर्त्याच्या कथा कोडच्या अंमलबजावणीयोग्य दृष्टीकडे नेण्यास सहकार्य करीत आहोत आणि त्या कोडला समर्थन देणारा डेटा. आणि अ‍ॅगिल डेटा मॉडेलर स्वतःच बर्‍याचदा असे आढळेल की आमच्याकडे संस्थांमध्ये पुरेसे मॉडेलर नाहीत म्हणून एखादा डेटा मॉडेलर किंवा आर्किटेक्ट एकाचवेळी अनेक संघांना सहाय्य करू शकेल.
आणि त्याचा दुसरा पैलू म्हणजे आपल्याकडे अनेक मॉडेल्सर्स असले तरीही, आम्हाला खात्री करुन घेणे आवश्यक आहे की आमच्याकडे एक टूल सेट आहे ज्याचा आम्ही वापर करीत आहोत जे एकाच वेळी विमानात जाणारे बहुविध प्रकल्पांचे सहकार्य आणि त्या सामायिकरणांना अनुमती देते. डेटा कृत्रिमता आणि चेक-इन आणि चेक-आउट क्षमता. मी या गोष्टी अगदी त्वरेने पार पाडणार आहे कारण आम्ही आधीच्या भागात हे आधीच कव्हर केले आहे. चपळतेचा वास्तविक आधार म्हणजे आपण गोष्टींचा किंवा गोष्टींच्या अनुशेषाच्या आधारे गोष्टींचा आधार घेत आहात. पुनरावृत्तीच्या आत आम्ही एक गट म्हणून सहयोग करीत आहोत. सहसा संस्थेवर अवलंबून दोन-आठवडे किंवा एक महिन्याचा कालावधी खूप सामान्य असतो. आणि दररोज पुनरावलोकन आणि स्टँडअप मीटिंग्ज जेणेकरुन आम्ही ब्लॉकर्सना काढून टाकत आहोत आणि आम्ही जात आहोत की आम्ही जात असताना वेगवेगळ्या भागात न थांबता सर्व बाजू पुढे करत आहोत हे सुनिश्चित करत आहोत. आणि त्या एस मध्ये आम्ही हे सुनिश्चित करू इच्छित आहोत की आम्ही प्रत्येकजणांचा एक भाग म्हणून वापरण्यायोग्य वितरणाची निर्मिती करीत आहोत.
थोडेसे वेगळे घ्या, त्याचा विस्तार आणखी वाढवा, स्क्रम ही मी कार्यपद्धती आहे ज्याबद्दल मी येथे अधिक विशिष्टपणे बोलणार आहे आणि आम्ही मूळत: त्या मागील चित्राला काही इतर बाबींसह वाढविले आहे. थोडक्यात एक प्रॉडक्ट बॅकलॉग आहे आणि मग तिथे बॅकलॉग आहे. म्हणून आमच्याकडे एक संपूर्ण अनुशेष आहे की प्रत्येक पुनरावृत्तीच्या सुरूवातीस, “आम्ही हे काय बनवणार आहोत?” आणि ते एका नियोजन बैठकीत पूर्ण केले, मग आम्ही त्याशी संबंधित असलेली कार्ये खंडित करतो आणि आम्ही दररोजच्या पुनरावलोकनांसह त्या एका ते चार आठवड्यांत कार्यान्वित करतो. आपला विकास वेग काय आहे यासारख्या गोष्टी स्थापित करण्यासाठी आपण काय तयार करीत आहोत आणि काय बनवायचे आहे याचा मागोवा घेण्यासाठी आपण बर्न-अप चार्ट आणि बर्न-डाउन चार्टद्वारे आपली प्रगती ट्रॅक करीत आहोत, आपण आपले कार्य करणार आहोत वेळापत्रक, सर्व प्रकारच्या गोष्टी. हे सर्व काही महिने रस्त्यावर खाली जाण्याऐवजी आणि आपण थोडक्यात येणार आहोत हे शोधण्याऐवजी सतत वर्णन केले जाते आणि आपल्याला प्रकल्पाचे वेळापत्रक वाढविणे आवश्यक आहे. आणि अगदी महत्त्वाचे म्हणजे, संपूर्ण संघ, शेवटी एक पुनरावलोकन आहे आणि पूर्वसूचनात्मक आहे, म्हणूनच पुढील पुनरावृत्ती बंद करण्यापूर्वी आपण काय केले त्याचे पुनरावलोकन करत आहात आणि आपण ज्या मार्गांवर सुधारणा करू शकता त्यावर मार्ग शोधत आहात. पुढच्या वेळी
वितरणाच्या बाबतीत, ही मुळात एक स्लाइड आहे जी एसएस मध्ये चालू असलेल्या विशिष्ट प्रकारच्या गोष्टींचा सारांश देते. आणि हे अगदी विकास-केंद्रित आहे, म्हणून येथे ज्या बर्‍याच गोष्टी आपण पाहत आहोत, जसे की कार्यात्मक डिझाईन्स आणि वापर प्रकरणे, डिझाइन कोड चाचण्या करणे, जेव्हा आपण येथे या बॉक्सकडे पाहतो, आणि मी त्याद्वारे जात नाही कोणत्याही स्तरावरील तपशीलात ते खूप विकासभिमुख असतात. आणि या खाली दफन केले गेले आहे की या प्रयत्नास पाठिंबा देण्यासाठी आपल्याकडे डेटा डिलिव्हरेबल्स देखील असणे आवश्यक आहे. म्हणून प्रत्येक वेळी जेव्हा आम्ही अनुशेष, आवश्यकता आणि वापरकर्ता कथा यासारख्या गोष्टी पाहतो तेव्हा आपण ज्या विकासाचे कार्य केले आहेत ते काय आहेत, विश्लेषणाचे तुकडे काय करावे लागतील, त्याबद्दल कसे पहावे लागेल डेटा डिझाईन किंवा डेटा मॉडेल, व्यवसायातील शब्दकोष यासारख्या गोष्टींबद्दल काय असेल जेणेकरुन आम्ही ज्या उत्पादनास तयार करीत आहोत त्या सर्वांना व्यवसायाचा अर्थ जोडता येईल? कारण आम्हाला प्रत्येक बाबतीत त्या वापरण्यायोग्य वितरणांची निर्मिती करणे आवश्यक आहे.
काही लोक म्हणतील की आम्हाला प्रत्येक शेवटी वापरण्यायोग्य कोड तयार करणे आवश्यक आहे. तेवढेच प्रकरण नाही, ते अगदी शुद्ध विकासाच्या दृष्टीकोनातून आहे, परंतु बर्‍याचदा - विशेषत: सुरुवातीला - आपल्याकडे एस शून्यासारखे काहीतरी असू शकते जिथे आपण पूर्णपणे उभे राहण्यावर लक्ष केंद्रित केले आहे, आमची चाचणी नीती मिळवण्यासारख्या गोष्टी करत आहोत. जागा.आम्ही तपशील भरणे सुरू करण्यापूर्वी ते सुरू करण्यासाठी उच्च स्तरीय डिझाइन आणि आम्ही इतर प्रेक्षकांना गुंतविण्यास सुरूवात करण्यापूर्वी आमच्याकडे प्रारंभ करण्याच्या कथा किंवा आवश्यकतांचा एक स्वच्छ सेट आहे याची खात्री करून आणि पुढे जाताना एक संघ म्हणून पुढे जाणे निश्चित केले. नेहमीच थोडासा तयारीचा वेळ असतो, बर्‍याचदा आपल्याकडे शून्य किंवा समान शून्य आणि एक असतो. आम्ही तोडगा काढण्यामध्ये पूर्ण उड्डाण घेण्यापूर्वी थोडासा स्टार्टअप टप्पा असू शकतो.
चला या कॉनमधील डेटा मॉडेल्सबद्दल थोडक्यात सांगूया. जेव्हा लोक डेटा मॉडेल्सचा विचार करतात, तेव्हा बहुतेकवेळा ते माहितीच्या वेगवेगळ्या माहितीचे तुकडे कसे एकत्र जोडतात हे एक चित्र म्हणून एखाद्या मॉडेलचा विचार करतात - ही केवळ हिमशैलीची टीप आहे. आपल्याला डेटा मॉडेलिंगकडे कसे जायचे आहे या भावनेस पूर्णपणे मूर्त रूप देण्यासाठी - ते चपळ विकासात आहे किंवा इतर गोष्टींचे आहे - आपल्याला हे समजून घेणे आवश्यक आहे की डेटा मॉडेल, योग्यरित्या केले गेले तर त्या त्या संस्थेतील डेटाचा अर्थ काय आहे याबद्दल आपले संपूर्ण तपशील बनले आहे आणि हे बॅक-एंड डेटाबेसमध्ये कसे तैनात आहे. जेव्हा मी डेटाबेस म्हणतो, तेव्हा मी म्हणालो की केवळ आपण वापरत असलेले रिलेशनल डेटाबेसच नाही तर आजच्या आर्किटेक्चर्समध्ये जिथे आमच्याकडे मोठा डेटा किंवा NoSQL प्लॅटफॉर्म आहेत, जसे मी त्यांना कॉल करण्यास प्राधान्य देतो. तसेच ते मोठे डेटा स्टोअर्स कारण आम्ही कदाचित डेटा वापरण्याच्या दृष्टीने बर्‍याच वेगवेगळ्या डेटा स्टोअर्सना एकत्रित करत असू आणि त्या आमच्या सोल्यूशन्समध्ये आणत आहोत तसेच आम्ही ती माहिती कशी कायम ठेवतो किंवा आमच्या सोल्यूशन्समधून ती कशी जतन करतो.
दिलेल्या अनुप्रयोगाच्या दृष्टीने आम्ही एकाच वेळी एकाधिक डेटाबेस किंवा डेटा स्रोतांसह कार्य करीत असू. सर्वात महत्त्वाचे म्हणजे आम्हाला एक संपूर्ण तपशील असणे सक्षम होऊ इच्छित आहे, म्हणून याचा अर्थ काय आहे याचा अर्थ लॉजिकल स्पष्टीकरण म्हणजे संघटनात्मक दृष्टीकोनातून, शारीरिक बांधकामे म्हणजे आपण वास्तविक डेटा कसा परिभाषित करतो त्या दृष्टीने, त्यातील संबंध डेटाबेस, आपल्या संदर्भातील अखंडतेची मर्यादा, तपासणी प्रतिबंध, आपण सहसा विचार करता त्या सर्व वैधतेचे तुकडे. वर्णनात्मक मेटाडेटा अत्यंत महत्वाचा आहे. आपल्या अनुप्रयोगांमधील डेटा कसा वापरायचा हे आपल्याला कसे माहित आहे? जोपर्यंत आपण त्यास परिभाषित करू शकत नाही आणि आपल्याला त्याचा अर्थ काय आहे हे माहित नाही किंवा आपण त्या अनुप्रयोगांमध्ये अचूक डेटा वापरत आहात हे सुनिश्चित करण्यासाठी कोठून आला आहे हे सुनिश्चित करणे - आमच्याकडे नेमकी नामकरण संमेलने, पूर्ण परिभाषा आहेत, ज्याचा अर्थ केवळ संपूर्ण डेटा कोश नाही या सारण्यांचा समावेश असलेल्या तक्त्या आणि स्तंभ - आणि आम्ही त्याचा उपयोग कसा करतो याबद्दल तपशील उपयोजन नोट्स कारण आपल्याला हा ज्ञानरचना तयार करणे आवश्यक आहे कारण हा अनुप्रयोग झाल्यावरही ही माहिती इतर उपक्रमांसाठी वापरली जाईल म्हणून आम्हाला खात्री करणे आवश्यक आहे भविष्यातील अंमलबजावणीसाठी आमच्याकडे कागदपत्रे आहेत.
पुन्हा आम्ही डेटा प्रकार, की, अनुक्रमणिका यासारख्या गोष्टींकडे दुर्लक्ष करतो, डेटा मॉडेल स्वतःच बर्‍याच व्यवसाय नियमांमध्ये मूर्त स्वरुप धारण करतो. नाती वेगवेगळ्या सारण्यांमधील अडचणी नसतात; ते सहसा आम्हाला डेटाचे वर्तन कसे करतात आणि एकत्रित युनिट म्हणून एकत्र कसे कार्य करतात याबद्दल खरे व्यवसाय नियम काय आहेत याचे वर्णन करण्यास मदत करतात. आणि अर्थातच, मूल्य निर्बंध खूप महत्वाचे आहेत. आता नक्कीच, आपण ज्या गोष्टींबरोबर सातत्याने व्यवहार करीत आहोत त्यापैकी एक आणि ती अधिकाधिक प्रचलित होत चालली आहे, ती म्हणजे डेटा प्रशासनासारख्या गोष्टी. तर डेटा गव्हर्नन्सच्या दृष्टीकोनातून आपणसुद्धा पाहत असण्याची गरज आहे की आपण येथे काय परिभाषित करीत आहोत? आम्हाला सुरक्षा वर्गीकरण यासारख्या गोष्टी परिभाषित करायच्या आहेत. आम्ही कोणत्या प्रकारचे डेटा हाताळत आहोत? मास्टर डेटा व्यवस्थापन काय मानले जाईल? आम्ही तयार करीत असलेली व्यवहारात्मक स्टोअर कोणती आहेत? या अनुप्रयोगांमध्ये आम्ही कोणता संदर्भ डेटा वापरत आहोत? ते आमच्या मॉडेलमध्ये योग्यरित्या कॅप्चर केले गेले आहे याची खात्री करणे आवश्यक आहे. आणि तसेच डेटा गुणवत्तेवर विचार करणे, माहितीचे असे काही भाग आहेत जे एखाद्या संस्थेसाठी इतरांपेक्षा अधिक महत्वाचे आहेत.
मी अशा प्रकल्पांमध्ये सामील आहे जिथे आम्ही नवीन व्यवसाय प्रक्रियेसह डझनभर लेगसी सिस्टम पुनर्स्थित करीत होतो आणि त्याऐवजी नवीन अनुप्रयोग आणि डेटा स्टोअर डिझाइन करीत आहोत. आम्हाला माहिती कोठून येत आहे हे माहित असणे आवश्यक आहे. व्यवसायाच्या दृष्टीकोनातून माहितीच्या सर्वात महत्त्वाच्या तुकड्यांकरिता, जर आपण येथे घेतलेल्या या विशिष्ट डेटा मॉडेल स्लाइडवर नजर टाकली तर तुम्हाला दिसेल की या विशिष्ट घटकांमधील तळातील बॉक्स, जे फक्त एक छोटा उपसेट आहे, मी खरंच व्यवसाय मूल्य कॅप्चर करण्यात सक्षम आहे. संस्थेमध्ये या भिन्न बांधकामासाठी या प्रकारच्या गोष्टींसाठी उच्च, मध्यम किंवा कमी असो. आणि मी मास्टर डेटा क्लासेस, जरी ते मास्टर टेबल्स आहेत की नाही, संदर्भ आहेत का, त्या व्यवहारात आहेत का अशा गोष्टी देखील मी हस्तगत केल्या आहेत. म्हणून आम्ही आमच्या मॉडेलमध्ये आमच्या मेटाडेटाचा विस्तार डेटाच्या स्वतःहून इतर वैशिष्ट्ये देण्यासाठी करू शकतो, ज्याने मूळ प्रकल्पांच्या बाहेरील इतर उपक्रमांमध्ये खरोखर मदत केली आणि ती पुढे नेली. आता एका स्लाइडमध्ये बरेच काही होते, मी या उर्वरित गोष्टींकडून अगदी द्रुतगतीने जाईन.
आम्ही आता या वेगळ्या एसएसमधून जात असताना डेटा मॉडेलर काय करते याबद्दल मी लवकरच बोलणार आहे. सर्व प्रथम, s च्या नियोजन सत्राचा संपूर्ण सहभागी, जिथे आपण वापरकर्ता कथा घेत आहोत, त्यामध्ये आपण काय वितरित करणार आहोत यासाठी वचनबद्ध आहोत आणि आम्ही त्याची रचना आणि ती कशी वितरीत करणार आहोत याचा शोध घेत आहोत. डेटा मॉडेलर म्हणून मी काय करीत आहे हे मला ठाऊक आहे की मी वेगळ्या क्षेत्रात वेगवेगळ्या विकसकांसह किंवा भिन्न लोकांमध्ये काम करत आहे. म्हणून आपल्याकडे असणारी एक महत्त्वाची वैशिष्ट्य म्हणजे जेव्हा आम्ही डेटा मॉडेल बनवितो तेव्हा आम्ही त्या डेटा मॉडेलला वेगवेगळ्या दृश्यांमध्ये विभागू शकतो, आपण त्यांना विषय क्षेत्र किंवा उप-मॉडेल म्हणाल की नाही, ही आमची शब्दावली आहे. म्हणून आम्ही मॉडेल तयार करीत असताना आम्ही हे या भिन्न उप-मॉडेल दृष्टीकोनातून देखील दर्शवित आहोत जेणेकरून भिन्न प्रेक्षक फक्त त्यांच्याशी काय संबंधित आहेत ते पहावे जेणेकरुन ते काय विकसित करतात आणि पुढे कसे ठेवतात यावर लक्ष केंद्रित करू शकतात. म्हणून मी कदाचित एखाद्यास एखाद्या अर्जाच्या वेळापत्रकात काम करत असू शकते, कदाचित मी दुसरे एखादे ऑर्डर एंट्रीवर काम करीत आहे जिथे आपण एकाच गोष्टीमध्ये या सर्व गोष्टी करत आहोत, परंतु मी त्या सब-मॉडेल्सच्या माध्यमातून त्यांना दृष्टिकोन देऊ शकतो ज्या क्षेत्रावर ते कार्यरत आहेत त्यांना लागू करा. आणि मग जे प्रेक्षकांना पाहण्याची आवश्यकता आहे त्यांची भिन्न मते देण्यासाठी ते एकूणच मॉडेल आणि उप-मॉडेल्सची संपूर्ण रचना तयार करतात.
आम्हाला पाहिजे असलेल्या डेटा मॉडेलिंगच्या दृष्टीकोनातून मूलतत्त्वे म्हणजे, आपल्याकडे परत जाण्याची एक बेसलाइन असते कारण आपल्याला करण्यासारख्या गोष्टींपैकी एक म्हणजे ती शेवटी आहे किंवा शेवटी आहे कित्येक एस, आम्ही कोठे सुरू केले हे जाणून घेऊ इच्छितो आणि डेल्टा म्हणजे काय किंवा आम्ही दिलेल्या एस मध्ये तयार केलेल्या गोष्टींमध्ये काय फरक आहे हे जाणून घेण्यासाठी नेहमीच बेसलाइन असते. आपल्याकडे त्वरित बदल होऊ शकतात हे देखील आपण सुनिश्चित करणे आवश्यक आहे. जर आपण त्यात डेटा मॉडेलर म्हणून आलात परंतु “नाही, नाही, तुम्ही असे करू शकत नाही, असे म्हणण्याची भूमिकेत आधी आपण हे सर्व काम करावे लागेल,” तुम्हाला खरोखर गरज असेल तेव्हा तुम्हाला संघातून वगळले जाईल. त्या सर्व चपळ विकास कार्यसंघामध्ये सक्रिय सहभागी होण्यासाठी. याचा अर्थ असा की काही गोष्टी दिल्यास वॅगन खाली पडतात आणि आपण त्या नंतरच्या काळात उचलल्या.
उदाहरण म्हणून, आपण फक्त डेटा स्ट्रक्चर्सवर लक्ष केंद्रित करू शकता जेणेकरुन मी बोललो होतो त्या ऑर्डर एंट्री पीसचा विकास. नंतर, आपण परत येऊ शकता आणि आपण तयार केलेल्या त्या कलाकृतींपैकी काही डेटा शब्दकोशांसाठी असलेले काही दस्तऐवजीकरण सारखे डेटा भरू शकता. आपण ही व्याख्या सर्व एकाच से पूर्ण करणार नाही; आपण वाढत्या प्रमाणात आपल्या वितरणात जात आहात कारण विकसक अनुप्रयोग डेटा तयार करण्यात व्यस्त असतात आणि त्या डेटा स्टोअरच्या भोवती टिकून राहतात तेव्हा व्यवसाय विश्लेषकांसह आपण कार्य करू शकता अशी वेळ येईल. आपणास सोयीचे व्हायचे आहे आणि अडथळा बनू इच्छित नाही. विकसकांसह कार्य करण्याचे वेगवेगळे मार्ग आहेत. काही गोष्टींसाठी आमच्याकडे डिझाइन नमुने आहेत जेणेकरून आम्ही समोर एक पूर्ण सहभागी आहोत, म्हणून आपल्याकडे एक डिझाइन नमुना असू शकेल जेथे आम्ही असे म्हणू की आम्ही ते मॉडेलमध्ये ठेवू, आम्ही त्यास विकसकांच्या सँडबॉक्स डेटाबेसमध्ये ढकलून देऊ आणि मग ते करू शकतील त्यासह कार्य करण्यास प्रारंभ करा आणि त्यामध्ये बदलांची विनंती करा.
विकसक कार्यरत असणारी इतरही क्षेत्रे असू शकतात, त्यांना ज्या गोष्टींवर त्यांनी काम केले आहे त्यांना काहीतरी मिळाले आहे आणि ते काही गोष्टींचा नमुना देत आहेत जेणेकरून ते त्यांच्या स्वत: च्या विकास वातावरणात काही गोष्टी प्रयत्न करतात. ते काम करीत असलेले डेटाबेस आम्ही घेतो, आमच्या मॉडेलिंग टूलमध्ये आणू, आमच्याकडे असलेल्या मॉडेल्सची तुलना करा आणि नंतर त्यांचे निराकरण व बदल परत हलवा जेणेकरुन ते त्यांच्या कोडचे रिफेक्टर करू शकतील जेणेकरून ते योग्य डेटा स्ट्रक्चरचे अनुसरण करीत असतील. ज्याची आम्हाला गरज आहे. कारण त्यांनी आमच्याकडे आधीपासूनच असलेल्या काही गोष्टी तयार केल्या असू शकतात, म्हणून आम्ही खात्री करतो की त्या योग्य डेटा स्रोतासह कार्य करीत आहेत. आम्ही संपूर्ण मार्गाने पुनरावृत्ती करत राहतो जेणेकरुन आम्हाला संपूर्ण डेटा वितरण, संपूर्ण दस्तऐवजीकरण आणि आम्ही तयार करीत असलेल्या सर्व डेटा स्ट्रक्चर्सची व्याख्या मिळेल.
अतिशय चांगल्या प्रसंगाच्या बाबतीत मी सहभागी झालेले सर्वात यशस्वी चपळ प्रकल्प म्हणजे आमच्याकडे तत्वज्ञान होते, संपूर्ण शारीरिक डेटाबेस तपशीलांमध्ये बदल करण्याचे मॉडेल होते. थोडक्यात, डेटा मॉडेल आपण वापरत असलेल्या नवीन कशासाठी आपण कार्य करीत असलेले उपयोजित डेटाबेस बनले आणि आम्ही इतर बाह्य डेटाबेसमधून वापरत असल्यास इतर डेटा स्टोअरचा संपूर्ण संदर्भ आहे. त्याचाच एक भाग म्हणून आम्ही प्रत्येक वेळी पूर्ण पिढी करण्याच्या विरूद्ध वाढीची स्क्रिप्ट तयार करीत आहोत. आम्ही आमच्या डिझाइन नमुन्यांचा वापर करीत आहोत ज्याद्वारे आम्ही कार्य करीत असलेल्या वेगवेगळ्या विकास संघांमधील गोष्टींच्या बाबतीत द्रुत उंचावतो.
तसेच क्रियाकलापांमध्ये, तुलना / विलीन करण्यासाठी पुन्हा तीच आधारभूत रेखा आहे, तर मग आपण प्रत्येक बदलांचे मॉडेलिंग करण्याचा विचार करूया. प्रत्येक वेळी जेव्हा आपण एखादा बदल करतो, आपल्याला काय करायचे आहे ते म्हणजे आम्हाला त्या बदलाचे मॉडेलिंग करायचे आहे आणि काय महत्वाचे आहे, डेटा मॉडेलिंगमध्ये जे काही हरवत आहे ते अलीकडील काळापर्यंत, प्रत्यक्षात जोपर्यंत आपण त्याचे पुन: परिचय देत नाही तोपर्यंत मॉडेलिंगला जोडण्याची क्षमता कार्ये आणि वापरकर्त्याच्या कथांसह आपली वितरणे आणि कार्ये ज्यामुळे प्रत्यक्षात ते बदल घडतात. आम्हाला आमच्या मॉडेलमधील बदलांची तपासणी करण्यास सक्षम व्हायचे आहे, त्याचप्रकारे विकसकांनी त्यांच्या कोडमध्ये तपासणी केली, आपल्याकडे असलेल्या वापरकर्त्याच्या कथांचा संदर्भ देऊन आम्ही प्रथम ठिकाणी बदल का केले हे आम्हाला ठाऊक आहे, हे आम्ही करतो. जेव्हा आम्ही ते करतो, तेव्हा आम्ही आमची वाढीची डीडीएल स्क्रिप्ट तयार करतो आणि त्या पोस्ट करतो जेणेकरुन ते इतर विकास वितरीत करण्यायोग्य लोकांसमवेत उचलून आमच्या बिल्ड सोल्यूशनमध्ये तपासू शकतील. पुन्हा, आमच्याकडे एक मॉडेल असू शकते किंवा एकाधिक कार्यसंघांसह कार्य करीत आहे. आणि जसे मी याबद्दल बोललो आहे, काही गोष्टी डेटा मॉडेलरद्वारे उद्भवल्या आहेत, इतर गोष्टी विकसकांद्वारे तयार केल्या गेल्या आहेत आणि आम्ही संपूर्णपणे सर्वोत्कृष्ट डिझाइनसह समोर येण्यास आणि त्यास पुढे आणण्यासाठी आणि ते आमच्यामध्ये योग्यरित्या डिझाइन केलेले असल्याची खात्री करण्यासाठी एकत्र भेटलो. एकूण डेटा स्ट्रक्चर्स. आपण पुढे जात असताना आमच्या डेटा मॉडेलमध्ये सर्व योग्य बांधकामे असल्याचे सुनिश्चित करण्याची शिस्त पाळली पाहिजे, ज्यामध्ये शून्य आणि निरर्थक मूल्ये नाहीत, संदर्भित अडचणी आहेत, मुळात तपासणीची बंधने आहेत या सर्व गोष्टींचा आपण सामान्यपणे विचार करू शकतो. .
आता आपण याबद्दल काही मदत करणार्या काही साधनांचे काही स्क्रीनशॉट्स बद्दल बोलूया. मला जे महत्वाचे वाटते ते म्हणजे ते सहकारी भांडार असणे म्हणजे डेटा मॉडेलर म्हणून आपण काय करू शकतो - आणि हे पार्श्वभूमीतील डेटा मॉडेलचा भाग आहे - जेव्हा आपण ज्या गोष्टींवर कार्य करत असतो तेव्हा आपल्याला खात्री करुन घ्यायची असते आम्ही ज्या वस्तू बदलू शकलो आहोत, त्यामध्ये बदल करू या, डीडीएल स्क्रिप्ट्स तयार केल्या पाहिजेत ज्या गोष्टी आम्ही परत तपासतो त्यादृष्टीने आपण कार्य करूया. ER स्टुडिओ मध्ये एक उदाहरण आहे, कार्य करण्यासाठी आम्ही ऑब्जेक्ट्स किंवा ऑब्जेक्ट्सचे गट तपासू शकतो, आम्हाला संपूर्ण मॉडेल किंवा उप-मॉडेल तपासण्याची गरज नाही, आम्ही आपल्यासाठी आवडीच्या असलेल्या गोष्टी तपासू शकतो. त्यानंतर आम्हाला जे करायचे आहे ते एकतर चेक आउट किंवा चेक इन वेळेत आहे - आम्ही ते दोन्ही प्रकारे करतो कारण भिन्न विकास कार्यसंघ वेगवेगळ्या प्रकारे कार्य करतात. आम्हाला याची खात्री करुन घ्यायची आहे की आम्ही या आवश्यक गोष्टी चालविणार्‍या वापरकर्त्याच्या कथेसह किंवा कार्यासह संबद्ध करतो आणि तेच वापरकर्ता कथा किंवा कार्य असेल जे विकसक विकसित करीत असतील आणि त्यासाठी त्यांचा कोड तपासत असतील.
तर आमच्या बदल व्यवस्थापन केंद्रांपैकी एकाच्या दोन स्क्रीनचा एक द्रुत स्निपेट येथे आहे. हे काय करते, मी येथे मोठ्या प्रमाणात तपशील घेणार नाही, परंतु आपण जे पाहत आहात ती म्हणजे वापरकर्ता कथा किंवा कार्य आणि आपण ज्या प्रत्यक्ष बदलांच्या नोंदी पहात आहात त्या प्रत्येकाच्या खाली इंडेंट केलेले - आम्ही स्वयंचलित बदल रेकॉर्ड तयार केले तेव्हा आम्ही चेक-इन आणि चेक-आउट करतो आणि त्या बदलांच्या रेकॉर्डवर आम्ही अधिक वर्णन ठेवू शकतो. हे कार्य संबंधित आहे, आम्ही अपेक्षेप्रमाणे आपल्याकडे प्रति कार्यात अनेक बदल करु शकतात. आणि जेव्हा आपण त्या बदलांच्या नोंदीत जाऊ तेव्हा आपण त्याकडे पहातो आणि महत्त्वाचे म्हणजे आपण काय बदलले? या विशिष्ट कथेसाठी, तेथील हायलाइट केलेल्या कथेत मला एक प्रकारचा बदल घडवून आणला गेला आणि जेव्हा मी प्रत्यक्ष बदलाच्या नोंदींकडे पहातो तेव्हा त्याने मॉडेलमधील वैयक्तिक तुकडे बदलले आहेत. मी येथे काही वैशिष्ट्ये बदलली, त्यांचा सारखा बदल केला आणि यामुळे त्या वाढत्या डीएलएलमध्ये व्युत्पन्न होतील यावर अवलंबून असलेल्या दृढ बदल करण्याची गरज असल्याचे मत त्यांनी पुढे आणले. हे केवळ बेस ऑब्जेक्टवर मॉडेलिंग करत नाही तर यासारखे उच्च-शक्तीचे मॉडेलिंग साधन देखील डेटाबेसमधील डेटा किंवा मॉडेलमधील अवलंबून असलेल्या वस्तूंद्वारे होणारे बदल शोधून काढते.
जर आम्ही विकसकांसह कार्य करीत आहोत आणि आम्ही हे काही वेगवेगळ्या गोष्टींमध्ये करीत आहोत, जे त्यांच्या सँडबॉक्समध्ये काहीतरी करीत आहे आणि फरक कुठे आहे हे तुलना करू आणि पाहू इच्छित असल्यास आम्ही उजवीकडील आणि डाव्या कोप compare्यात तुलना / विलीन क्षमता वापरतो. बाजूला आपण असे म्हणू शकतो की, “डाव्या बाजूला आमचे हे मॉडेल आहे, येथे त्यांचा उजवा बाजूला डेटाबेस आहे, मला फरक दाखवा.” मग आपण डेटाबेसमध्ये गोष्टी ढकलतो की नाही हे बदल कसे सोडवू शकतो ते निवडू शकतो. डेटाबेसमध्ये त्यांच्याकडे असलेल्या काही गोष्टी आहेत ज्या आम्ही मॉडेलमध्ये परत आणल्या. आम्ही द्विपक्षीय जाऊ शकतो जेणेकरून आम्ही दोन्ही दिशानिर्देश एकाच वेळी दोन्ही स्त्रोत आणि लक्ष्य अद्यतनित करू आणि नंतर डेटाबेस वातावरणात बदल बदलण्यासाठी वाढीव डीडीएल स्क्रिप्ट तयार करू जे अत्यंत महत्वाचे आहे. आम्ही हे देखील करू शकतो की आपण या तुलना आणि कोणत्याही वेळी विलीन करण्याची क्षमता देखील वापरू शकतो, जर आम्ही त्या मार्गावर स्नॅपशॉट घेत असाल तर आम्ही नेहमीच एका एसच्या प्रारंभाची तुलना करू शकतो किंवा दुसर्‍याच्या शेवटी होतो जेणेकरुन आम्ही पाहू शकतो. दिलेल्या विकासात किंवा एसएसच्या मालिकेमध्ये जे काही केले होते त्याचा पूर्ण वाढीव बदल.
हे बदलत्या स्क्रिप्टचे एक त्वरित उदाहरण आहे, तुमच्यापैकी कोणाकडेही डेटाबेससह काम केले असेल तर त्यांनी हा प्रकार पाहिला असेल, हे असे आहे की आम्ही कोडला बदलून स्क्रिप्ट म्हणून बाहेर काढू शकू जेणेकरुन आम्ही खात्री करुन घेत आहोत की आम्ही येथे गोष्टी टिकवून ठेवा. गोंधळ कमी करण्यासाठी मी इथून जे काढले तेच हे आहे की आपण या बदललेल्या स्क्रिप्ट्स सह असेही करतो की आम्ही असे गृहित धरले आहे की त्या टेबल्समध्येही डेटा आहे, तर आम्ही डीएमएल देखील निर्माण करू जे तात्पुरते टेबल्सची माहिती काढेल आणि त्यास नवीन डेटा स्ट्रक्चर्स मध्ये परत ढकलून द्या म्हणजे आम्ही त्या स्ट्रक्चर्स मध्ये नसून फक्त स्ट्रक्चर्सच नाही तर डेटा आधीच पहात आहोत.
स्वयंचलित बिल्ड सिस्टमबद्दल खूप द्रुत बोलण्याकडे जा कारण जेव्हा आम्ही बर्‍याचदा चपळ प्रकल्प करत असतो तेव्हा आम्ही स्वयंचलित बिल्ड सिस्टमसह कार्य करत असतो जिथे आपण आमची इमारत मोडणार नाही याची खातरजमा करण्यासाठी आपल्याला वेगवेगळ्या वितरणामध्ये एकत्रित तपासणी करणे आवश्यक आहे. याचा अर्थ म्हणजे आम्ही डिलीव्हरेबल्स समक्रमित करतो, डीडीएल स्क्रिप्टसह मी बोललेल्या त्या स्क्रिप्ट्सची तपासणी करणे आवश्यक आहे, संबंधित अनुप्रयोग कोड एकाच वेळी चेक इन करणे आवश्यक आहे आणि आता बर्‍याच विकसकांचा विकास नक्कीच नाही डेटाबेस आणि त्या प्रकारची विरूद्ध डायरेक्ट एसक्यूएलने केले जात आहे. बर्‍याचदा आम्ही चिकाटी फ्रेमवर्क किंवा डेटा सेवा इमारत वापरत असतो. आम्हाला खात्री करणे आवश्यक आहे की त्या फ्रेमवर्क किंवा सेवांसाठी बदल त्याच वेळी चेक इन केले आहेत. ते काही संस्थांमध्ये स्वयंचलित बिल्ड सिस्टममध्ये जातात आणि जर बिल्ड ब्रेक झाल्यास, चपळ पद्धतीत, आपण पुढे जाण्यापूर्वी तयार होणा dec्या डेक फिक्सिंगवर सर्व हात आहे जेणेकरुन आपल्याला माहित होईल की पुढे जाण्यापूर्वी आपल्याकडे कार्यरत समाधान आहे. आणि मी ज्या प्रकल्पात सामील होतो त्यापैकी एक, आम्ही यास टोकापर्यंत नेले - जर इमारत खराब झाली तर आम्ही आमच्या क्षेत्रातील असंख्य संगणकांशी जोडले होते जिथे आम्ही व्यावसायिक वापरकर्त्यांसह एकत्र आहोत, आमच्याकडे फक्त लाल चमकणारे दिवे होते. पोलिसांच्या गाड्यांप्रमाणेच. आणि जर हा बिल्ड तुटला, तर त्या लाल चमकणारे दिवे बंद होऊ लागले आणि आम्हाला माहिती आहे की हे सर्व डेकवर आहे: बिल्ड निश्चित करा आणि मग आम्ही जे करीत होतो त्यासह पुढे जा.
मला इतर गोष्टींबद्दल बोलू इच्छित आहे, आणि ईआर स्टुडिओची ही एक अद्वितीय क्षमता आहे, जेव्हा आम्ही या दृढनिश्चितीच्या सीमांसाठी विकसक म्हणून या कलाकृती तयार करण्याचा प्रयत्न करीत असतो तेव्हा आपल्याला खरोखर मदत होते, आपल्याकडे व्यवसाय डेटा ऑब्जेक्ट्स नावाची संकल्पना आहे आणि यामुळे आम्हाला काय परवानगी मिळते आपण उदाहरण म्हणून या अगदी सोप्या डेटा मॉडेलकडे पहात असाल तर ते आपल्यास अस्तित्व किंवा मर्यादा असलेल्या सीमारेषा अस्तित्त्वात असलेल्या घटकांच्या समूहांना समेट करण्यास अनुमती देते. जिथे आम्ही डेटा मॉडेलर म्हणून खरेदी ऑर्डर शीर्षलेख आणि ऑर्डर संरेखित करतो आणि इतर तपशीलवार सारण्यांसारख्या गोष्टीबद्दल विचार करू शकतो जे त्यास तयार करते त्या प्रकारे जोडेल आणि आमच्या डेटा सेवा विकसकांना त्या भिन्न डेटावर गोष्टी कशा टिकून राहतील हे माहित असणे आवश्यक आहे. संरचना. आमचे विकसक एक ऑब्जेक्ट म्हणून खरेदी ऑर्डरसारख्या गोष्टींचा विचार करतात आणि त्या विशिष्ट वस्तू कशा तयार करतात याबद्दल त्यांचा काय करार आहे. आम्ही ते तांत्रिक तपशील उघड करू शकतो जेणेकरून डेटा सर्व्हर तयार करणारे लोक खाली असलेल्या गोष्टी पाहू शकतील आणि आम्ही अन्य प्रेक्षकांना त्या जटिलतेपासून वाचवू शकू जेणेकरुन त्यांना फक्त भिन्न उच्च-स्तरीय वस्तू दिसतील, जे व्यवसायासह संप्रेषण करण्यासाठी देखील फार चांगले कार्य करतात. विश्लेषक आणि व्यवसाय भागधारक जेव्हा आपण भिन्न व्यवसाय संकल्पनांच्या परस्परसंवादाबद्दल बोलत असतो.
त्याबद्दल चांगली गोष्ट म्हणजे आपण रचनात्मकपणे याचा विस्तार आणि संकुचित करतो जेणेकरून आम्ही उच्च-ऑर्डर ऑब्जेक्ट्समधील संबंध कायम राखू शकू जेणेकरून त्या व्यवसाय डेटा ऑब्जेक्टमध्येच त्यांच्यातील रचनांपासून उद्भवू शकतात. आता एक मॉडेलर म्हणून, s च्या शेवटी जा, s रॅप-अपच्या शेवटी, माझ्याकडे बर्‍याच गोष्टी करण्याची आवश्यकता आहे, ज्यास मी पुढील घरकाजासाठी माझे घरकुल म्हणतो. ज्याला मी नामित रिलीझ म्हणतो त्या प्रत्येकजणाने मी तयार करतो - जे आता रिलीझच्या शेवटी माझ्याकडे आहे त्याकरिता मला बेसलाइन देते. तर याचा अर्थ असा आहे की माझी आधारभूतरेखा पुढे जात आहे, या माझ्या सर्व भांडारांमध्ये तयार केलेल्या आणि जतन केलेल्या नामित रीलिझ मी तुलना / विलीन करण्यासाठी वापरू शकतो जेणेकरून मी इतर कोणत्याही शेवटच्या टोकांशी नेहमी तुलना करू शकतो, प्रवासातील मार्गावर आपल्या डेटा मॉडेलमध्ये काय बदल होते हे जाणून घेणे खूप महत्वाचे आहे.
मी सुरुवातीपासून शेवटपर्यंत तुलना / विलीन करून डेल्टा डीडीएल स्क्रिप्ट देखील तयार करतो. मी कदाचित वाढीव स्क्रिप्टचा संपूर्ण समूह तपासला असेल, परंतु मला याची आवश्यकता असल्यास आता माझ्याकडे इतर सँडबॉक्सेस उभे करण्यासाठी मी तैनात करू शकणारी स्क्रिप्ट आहे जेणेकरून एका वर्षाच्या सुरूवातीस आमच्याकडे जे होते तेच मी सांगू शकतो. त्यातून, पुढील गोष्टींपासून प्रारंभ करण्यासाठी सँडबॉक्स म्हणून डेटाबेस तयार करा आणि आम्ही स्टँडअप क्यूए उदाहरणे यासारख्या गोष्टी करण्यासाठी देखील त्या गोष्टी वापरु शकतो आणि शेवटी आम्ही आपले बदल उत्पादनाकडे आणू इच्छितो जेणेकरून आपल्याकडे अनेक गोष्टी चालू आहेत. त्याच वेळी. पुन्हा आम्ही नियोजन आणि पूर्वसूचनांमध्ये पूर्णपणे भाग घेतो, पूर्वगामी खरोखर शिकलेले धडे आहेत आणि ते अत्यंत महत्वाचे आहे, कारण आपण चपळाईच्या वेळी खूप पटकन जाऊ शकता, आपल्याला आता थांबवून यशांची उत्सव साजरा करण्याची आवश्यकता आहे. काय चूक आहे ते समजून घ्या, पुढच्या वेळी त्यास अधिक चांगले बनवा, परंतु जे योग्य झाले त्या गोष्टींचा उत्सव साजरा करा आणि आपण पुढील एसएसमध्ये पुढे जात असताना त्या तयार करा.
मी आता व्यवसाय मूल्याबद्दल खूप पटकन बोलणार आहे. एक प्रकल्प होता ज्यामध्ये मी बर्‍याच वर्षांपूर्वी सामील झालो होतो जो एक चपळ प्रकल्प म्हणून सुरू झाला आणि तो एक अत्यंत प्रकल्प होता, म्हणून हा एक शुद्ध स्वयं-संघटना संघ होता जिथे हे सर्व काही करीत असलेले विकसक होते. एक दीर्घ कथा लहान करण्यासाठी, हा प्रकल्प रखडत होता आणि त्यांना आढळले की ते आणखी कार्यक्षमता वाढवण्यापेक्षा त्यांच्यातील दोष दूर करण्यासाठी आणि निराकरण करण्यासाठी अधिकाधिक वेळ घालवत आहेत आणि खरं तर जेव्हा त्यांनी त्याकडे लक्ष दिले तेव्हा बर्न-डाऊन चार्टवर त्यांना प्रकल्पासाठी सहा महिन्यांचा खर्च मोठा खर्च करावा लागणार होता. आणि जेव्हा आम्ही त्याकडे पाहिले तेव्हा समस्येचे निराकरण करण्याचा मार्ग म्हणजे प्रकल्पातच कुशल डेटा मॉडेलरसह योग्य डेटा मॉडेलिंग साधनाचा उपयोग करणे.
जर आपण या विशिष्ट चार्टवरील उभ्या पट्टीकडे पहात असाल तर हे एकत्रित वस्तू विरूद्ध संचयी दोष दर्शवित आहे आणि मी डेटा ऑब्जेक्ट्स किंवा बांधकामांविषयी बोलत आहे जे अडचणी असलेले सारण्या आणि त्या प्रकारच्या गोष्टी तयार केल्या आहेत, जर आपण पाहिले तर हे डेटा मॉडेलर सादर होण्यापूर्वी, दोषांची संख्या प्रत्यक्षात ओलांडत होती आणि त्या क्षणापर्यंत तयार झालेल्या वस्तूंच्या वास्तविक संख्येपेक्षा थोडा अंतर तयार करण्यास सुरवात करत होती. २१ व्या आठवड्यानंतर, जेव्हा डेटा मॉडेलर आला, तेव्हा अनेक गोष्टी निश्चित करण्याच्या आधारावर डेटा मॉडेलचे रिफेक्टर केले आणि नंतर प्रकल्प पथकाचा भाग म्हणून मॉडेलिंग सुरू केले, त्या प्रकल्पातील बदल पुढे ढकलले जात होते. . आणि आपण एक द्रुत बदल घडवून आणला की सुमारे साडेसातच्या आत आम्ही तयार केलेल्या आणि तयार केलेल्या वस्तू आणि डेटा कन्स्ट्रक्शनच्या संख्येत एक प्रचंड वाढ झाली कारण आम्ही विकसक स्टिक इमारतीऐवजी डेटा मॉडेलिंग साधन तयार करीत होतो. त्यांना वातावरणात आणि ते योग्य होते कारण त्यांच्याकडे योग्य संदर्भित अखंडता होती आणि इतर बांधकामे तिच्याकडे असावीत. त्या जवळजवळ सपाटपणा विरुद्ध दोष पातळी. ती योग्य ती कारवाई करून आणि डेटा मॉडेलिंग पूर्णपणे गुंतलेली आहे याची खात्री करून, प्रकल्प उच्च गुणवत्तेसह वेळेवर वितरित करण्यात आला आणि खरं तर, जर ते पावले उचलले नसते तर ते नक्कीच वितरित केले नसते. तेथे बर्‍याच चपळ अपयश आहेत, योग्य भूमिका घेतल्यास योग्य लोकांना सामील केले तर बर्‍याच चपळ यश देखील आहेत. मी एक ऑपरेशनल शिस्त म्हणून चपळपणाचा एक प्रचंड समर्थक आहे, परंतु आपण एका चपळ प्रकारच्या प्रयत्नात पुढे जाताना आपल्याकडे प्रकल्प प्रकल्प म्हणून सामील असलेल्या सर्व योग्य गटांची कौशल्य असल्याची खात्री करणे आवश्यक आहे.
थोडक्यात, डेटा आर्किटेक्ट आणि मॉडेलर सर्व विकास प्रकल्पांमध्ये सामील असणे आवश्यक आहे; ते खरोखरच गोंद असतात जे सर्व काही एकत्र ठेवतात कारण डेटा मॉडेलर आणि आर्किटेक्ट म्हणून आम्हाला समजले जाते, केवळ दिलेल्या विकास प्रकल्पाची डेटा कॉन्स्ट्रक्टच नाही तर त्या संस्थेमध्ये डेटा कोठे अस्तित्त्वात आहे आणि आम्ही त्या डेटाचा स्रोत कोठून घेऊ शकतो आणि कसे ते देखील आम्ही कार्य करीत असलेल्या विशिष्ट अनुप्रयोगा बाहेरच त्याचा उपयोग आणि उपयोग होणार आहे. आम्हाला जटिल डेटा संबंध समजतात आणि ते पुढे जाण्यात सक्षम असणे आणि डॉक्युमेंट मॅप करण्यासाठी प्रशासनाच्या दृष्टीकोनातून आणि आपला संपूर्ण डेटा लँडस्केप कसा दिसतो हे समजणे हे सर्वात महत्त्वाचे आहे.
हे मॅन्युफॅक्चरिंगसारखे आहे; मी उत्पादन पार्श्वभूमीतून आलो आहे. आपण शेवटी एखाद्या गोष्टीमध्ये गुणवत्तेची तपासणी करू शकत नाही - आपल्याला आपल्या डिझाइनमध्ये अग्रभागी आणि आपल्या मार्गावर गुणवत्ता तयार करण्याची आवश्यकता आहे आणि डेटा मॉडेलिंग ही कार्यक्षमता आणि स्वस्त-प्रभावी पद्धतीने त्या गुणवत्तेची रचना तयार करण्याचा एक मार्ग आहे. . आणि पुन्हा, लक्षात ठेवण्यासाठी काहीतरी - आणि हे ट्रायट करणे नाही, परंतु हे सत्य आहे - अनुप्रयोग येतात आणि जातात, डेटा ही एक महत्वाची कॉर्पोरेट मालमत्ता आहे आणि ती त्या सर्व अनुप्रयोगांच्या मर्यादे ओलांडते. प्रत्येक वेळी जेव्हा आपण अनुप्रयोग लावत असता तेव्हा आपणास यापूर्वी आलेल्या इतर अनुप्रयोगांमधील डेटा जतन करण्यास सांगितले जाते, म्हणून आम्ही फक्त हे लक्षात ठेवण्याची गरज आहे की आम्ही वेळोवेळी देखभाल करत राहणे ही एक महत्त्वपूर्ण कॉर्पोरेट मालमत्ता आहे.
आणि तेच! येथून आम्ही अधिक प्रश्न घेऊ.
एरिक कवानाग: ठीक आहे, छान, मी ते आधी रॉबिनवर टाकू. आणि मग, डेझ, मला खात्री आहे की आपल्याकडे दोन प्रश्न आहेत. हे दूर घेऊन, रॉबिन.
डॉ रॉबिन ब्लॉर: ठीक आहे. खरं सांगायचं तर, चपळ विकासाच्या पद्धतींमध्ये मला कधीच अडचण आली नाही आणि आपण येथे काय करत आहात हे जाणवते. मला आठवतंय की 1980 च्या दशकात असे काहीतरी पहात होते जे खरोखरच एखाद्या प्रकल्पाच्या नियंत्रणाबाहेर जात असलेल्या समस्येवर अवलंबून असते, जर आपण चूक एखाद्या विशिष्ट टप्प्याच्या पलीकडे कायम राहिली तरच. आपल्याला तो टप्पा योग्य न मिळाल्यास निराकरण करणे अधिकच अवघड होते, म्हणून आपण येथे करत असलेल्या गोष्टींपैकी एक - आणि मला वाटते की ही स्लाइड आहे - परंतु आपण येथे करत असलेल्या गोष्टींपैकी एक आहे. शून्य मध्ये, माझ्या मते, हे अगदी महत्वाचे आहे कारण आपण खरोखर तेथे पोचण्यायोग्य गोष्टी पिन करण्याचा प्रयत्न करीत आहात. आणि आपणास डिलिव्हरेल्स पिन न झाल्यास, नंतर वितरणात बदल होईल.
हे एक प्रकारचे माझे मत आहे. हे माझे मत देखील आहे - आपल्याकडे जाण्यापूर्वी आपल्याकडे डेटा मॉडेलिंगच्या तपशीलांच्या एका विशिष्ट स्तरापर्यंत अधिकार प्राप्त झाला असावा या कल्पनांचा मला खरोखरच वाद नाही. आपण प्रयत्न करावेत आणि काय करावे असे मला वाटत आहे कारण मला त्याबद्दल पूर्ण ज्ञान झाले नाही, फक्त त्यापैकी कोणत्या प्रकल्पाचे आकार आहे त्या दृष्टीने ते कसे वाहते या संदर्भात वर्णन करेल, कोणास माहित आहे, समस्या कोसळल्या, त्या सोडवल्या गेल्या? कारण मला वाटते की ही स्लाइड त्यापैकी खूपच हृदय आहे आणि आपण त्याबद्दल थोडेसे अधिक तपशीलवार वर्णन करू शकल्यास, मी कृतज्ञ आहे.
रॉन हुईझेन्गा: नक्कीच, आणि मी दोन उदाहरण प्रकल्प वापरेन. एक म्हणजे एक प्रकारचे, प्रत्यक्षात योग्य लोकांना सामील करून आणि डेटा मॉडेलिंग करून परत आणल्या गेलेल्या रेलगाड्या सोडल्या आणि सर्वकाही खरोखरच याची खात्री करुन घेण्याचा एक मार्ग आहे की डिझाइन अधिक चांगले समजले गेले आहे आणि आमच्याकडे स्पष्टपणे अंमलबजावणीचे डिझाइन आहे हे मॉडेलिंग करून मार्गावर. कारण जेव्हा आपण हे मॉडेल तयार करता, तेव्हा आपल्याला माहित असते की आपण आपला डीडीएल आणि सर्वकाही साधनाच्या मागे आणि बाहेर व्युत्पन्न करण्याऐवजी तयार करू शकता जसे की लोक सामान्यत: थेट डेटाबेस वातावरणात जाऊन असे करतात. आणि विकसकांसोबत घडणार्‍या ठराविक गोष्टी म्हणजे ते तिथेच जातील आणि ते म्हणतील, ठीक आहे, मला या सारण्या आवश्यक आहेत. समजा आम्ही ऑर्डर प्रविष्ट्या करीत आहोत. म्हणून ते कदाचित ऑर्डर शीर्षलेख आणि ऑर्डर तपशील सारण्या आणि त्या प्रकारच्या गोष्टी तयार करतात. परंतु परदेशी की संबंधांचे प्रतिनिधित्व करण्यासाठी काही अडचणी आहेत हे सुनिश्चित करण्यासाठी ते बर्‍याचदा विसरतात किंवा दुर्लक्ष करतात. त्यांच्यात कदाचित कळा योग्य नसतील. नामनिर्देशित संमेलने देखील संशयास्पद असू शकतात. मला माहित नाही की मी किती वेळा वातावरणात गेलो आहे, उदाहरणार्थ, जेथे आपल्याला भिन्न नावे असलेली विविध सारण्यांचा एक समूह दिसतो, परंतु नंतर त्या सारण्यांमधील स्तंभ नावे आयडी, नाव किंवा जे काही आहेत, म्हणून आहेत. खरोखर काय आहे हे सारणीशिवाय खरोखर घसरुन गेले आहे.
तर, विशेषत: जेव्हा आम्ही डेटा मॉडेलिंग करीत असतो तेव्हा आम्ही हे सुनिश्चित करतो की आम्ही डीडीएलमध्ये तयार केलेल्या सर्व कलाकृतींवर योग्य नामकरण संमेलन लागू करीत आहोत. परंतु प्रकल्पांच्या स्वरुपांबद्दल स्वत: चे सामान्यपणे बोलणे मी बर्‍यापैकी मोठ्या पुढाकारांबद्दल बोलत आहे. त्यातील एक १$० दशलक्ष डॉलर्सचा व्यवसाय परिवर्तन प्रकल्प होता जिथे आम्ही एका डझनहून अधिक वारसा प्रणाल्या बदलल्या. आमच्याकडे पाच वेगवेगळ्या चपळ संघ एकाच वेळी चालू होते. माझ्याकडे पूर्ण डेटा आर्किटेक्चर टीम आहे, म्हणून माझ्याकडे माझ्या टीममधील डेटा मॉडेलर्स आहेत जे इतर अनुप्रयोग क्षेत्रातील प्रत्येक संघात एम्बेड केलेले आहेत आणि आम्ही गृह-व्यवसायातील तज्ञांच्या संयोजनासह काम करीत होतो ज्याला विषय माहित आहे, जे करत होते स्वत: च्या आवश्यकतांसाठी वापरकर्ता कथा. आमच्याकडे त्या प्रत्येक संघात व्यवसाय विश्लेषक होते जे प्रत्यक्षात व्यवसाय प्रक्रियेचे मॉडेलिंग करीत होते, क्रियाकलाप आरेखने किंवा व्यवसाय प्रक्रिया आकृत्या सह, वापरकर्त्याच्या कथांचा उपयोग टीममधील उर्वरित भाग घेण्यापूर्वी वापरकर्त्यांसह अधिक जाणून घेण्यास मदत करतात.
आणि मग अर्थातच, त्या वर डेव्हलपर जे अनुप्रयोग कोड तयार करीत होते. आणि आम्ही देखील कार्य करीत होतो, मला असे वाटते की ते चार वेगवेगळे सिस्टम एकत्रीकरण विक्रेते होते जे अनुप्रयोगाचे वेगवेगळे भाग तयार करीत होते तसेच एक कार्यसंघ डेटा सेवा तयार करीत होता, दुसरा एक क्षेत्रात अनुप्रयोग लॉजिक तयार करीत होता, दुसरा एक ज्यामध्ये तज्ञ होते दुसर्‍या व्यवसाय क्षेत्रात त्या क्षेत्रामध्ये अनुप्रयोग तर्क तयार केले जात होते. म्हणून आमचे संपूर्ण प्रकल्प या प्रकल्पात काम करणारे लोक होते. त्यापैकी एकावर आमच्याकडे संघात किनारपट्टीवर १ 150० लोक होते आणि संघात आणखी १ off० संसाधने ऑफशोअर आहेत जे ही गोष्ट बाहेर घालवण्यासाठी दोन आठवड्यांची मदत करत होते. आणि हे करण्यासाठी आपण सर्व सिलिंडर्सवर गोळीबार करत आहात याची खात्री करणे आवश्यक आहे आणि प्रत्येकजण त्यांचे वितरण काय आहे त्या दृष्टीने चांगले समक्रमित केले आहे आणि आम्ही सर्व आवश्यक शिल्लक वस्तूंचे वितरण पूर्ण करीत आहोत हे सुनिश्चित करण्यासाठी आपल्याकडे वारंवार रीसेट होते. प्रत्येक च्या शेवटी.
डॉ रॉबिन ब्लॉर: पण ते प्रभावी आहे. आणि त्याबद्दल थोड्या अधिक तपशीलांसाठी - आपण त्या प्रकल्पाच्या शेवटी संपूर्ण डेटा क्षेत्राचा एमडीएम नकाशा, एक पूर्ण करून घेतला होता का?
रॉन हुईझेन्गा: आमच्याकडे एक संपूर्ण डेटा मॉडेल आहे जो सर्व भिन्न व्यवसाय क्षेत्रांमधील विघटनसह खंडित झाला आहे. संपूर्ण परिभाषांच्या दृष्टीने डेटा शब्दकोश स्वतःच थोडासा कमी झाला. आमच्याकडे बहुतेक सारण्या परिभाषित केल्या गेल्या; आमच्याकडे बहुतेक स्तंभ परिभाषित केले होते की ते नेमके काय म्हणायचे होते. असे काही नव्हते जे येथे नव्हते, आणि विशेष म्हणजे पुरेशी माहिती, त्यापैकी बरेच माहिती असे होते की जे वारसा प्रणालीद्वारे आले, जेथे प्रकल्पाच्या कार्यक्षेत्र संपल्यानंतर, अद्याप त्याचा एक कॅरी-फॉरवर्ड सेट म्हणून दस्तऐवजीकरण करण्यात आला कलाकृती ज्याप्रमाणे ती प्रकल्पाच्या बाहेरच होती कारण संस्थेच्या पुढे जाणे आवश्यक होते. म्हणून त्याच वेळी संस्थेने डेटा गव्हर्नन्सच्या महत्त्वकडे पाहण्याचा दृष्टिकोन वाढविला कारण आम्ही त्या लेगसी सिस्टममध्ये बर्‍याच कमतरता पाहिल्या आणि आम्ही लिगेसी डेटा स्रोत वापरत आहोत ज्याचा आपण दस्तऐवजीकरण केलेले नाही. बर्‍याच उदाहरणांमध्ये आमच्याकडे फक्त डेटाबेस होते जे आम्हाला रिव्हर्स इंजिनियरला हवे होते आणि तेथे काय आहे आणि माहिती कशासाठी आहे हे शोधण्याचा प्रयत्न केला पाहिजे.
डॉ रॉबिन ब्लॉर: हे मला आश्चर्यचकित करीत नाही, त्या त्या विशिष्ट बाबीवर. डेटा गव्हर्नन्स आहे, याला कॉल करू या, ही एक अतिशय आधुनिक चिंता आहे आणि मला वाटते, खरोखर असे बरेच काम आहे जे डेटा गव्हर्नन्सवर ऐतिहासिकदृष्ट्या केले गेले पाहिजे. हे असे नव्हते कारण आपण, प्रकारचे, असे केल्याने दूर जाऊ शकता. परंतु जसे डेटा संसाधन नुकतेच वाढत आणि वाढत गेले, शेवटी आपण हे करू शकत नाही.
असं असलं तरी, मी डेझवर जात आहे कारण मला वाटतं की माझा वेळ माझ्याकडे आहे. देझ?
डेझ ब्लांचफील्ड: हो धन्यवाद. या संपूर्ण गोष्टींमधून मी स्वतःला हे पाहत आहे आणि विचार करतो की आम्ही बर्‍याच प्रकारे रागाच्या भरात चपळपणे पाहण्याविषयी बोलत आहोत. जरी त्यास नकारात्मक अर्थ प्राप्त झाले; मी याचा अर्थ सकारात्मक मार्गाने घेतला. आपण कदाचित आम्हाला एक परिदृश्य देऊ शकाल, याचा अर्थ असा आहे की मला येथे दोन ठिकाणी एक परिपूर्ण सेट आहे: एक नवीन प्रकल्प आहे ज्याचे फक्त पहिल्या दिवसापासून करावे लागतात, परंतु मला असे वाटते की माझ्या अनुभवात असे दिसते की बर्‍याचदा जेव्हा प्रकल्प मोठ्या प्रमाणात प्राप्त होते तेव्हा हे अनेक मार्गांनी आवश्यक आहे, तेव्हा दोन जगांना ग्लूइंग करणे एक रोचक आव्हान आहे, बरोबर? आपण एखाद्या संस्थेत जिथे गेलात तिथे पाहिलेल्या काही यशोगाथाबद्दल आपल्याला काही अंतर्दृष्टी देऊ शकता, हे स्पष्ट झाले आहे की त्यांच्यात दोन जगाचा किंचित संघर्ष झाला आहे आणि आपण यशस्वीरित्या सांगण्यास सक्षम आहात. हे त्या ठिकाणी आहे आणि मोठे प्रकल्प एकत्र आणतात जेथे ते कदाचित अन्यथा रेल्वेवर गेले असतील? मला माहित आहे की हा एक अतिशय विस्तृत प्रश्न आहे परंतु मी विचार करीत आहे की तेथे एखादा विशिष्ट केस स्टडी असेल तर आपण असे करू शकता की जेथे आपण सांगितले तेथे तुम्हाला सूचित केले आहे, आम्ही हे सर्व ठिकाणी ठेवले आहे आणि हे सर्व विकास संघासह एकत्र आणले आहे. डेटा कार्यसंघ आणि आम्ही असे केले आहे की अशा मार्गाने काहीतरी हलवले जे कदाचित अन्यथा बोट बुडले असेल?
रॉन हुईझेन्गा: नक्कीच, आणि खरं तर ज्या प्रकल्पात पाइपलाइन प्रकल्प झाला होता तोच हा होता की मी डेटा मॉडेलरचा सहभाग घेण्यापूर्वी आणि नंतरच्या दोषांविषयीचा चार्ट दर्शविला. बर्‍याचदा आणि पूर्वानुमानित कल्पना असतात, खासकरुन जेव्हा त्या निव्वळ विकास दृष्टीकोनातून घडविल्या गेल्या असतील तर अनुप्रयोग वितरित करण्यासाठी या चपळ प्रकल्पांमध्ये गुंतलेले फक्त विकसक आहेत. मग तिथे काय घडले, अर्थात ते रेल्वे आणि त्यांचे डेटा शिल्पकला खाली उतरले आहेत किंवा त्यांनी ज्या डेटा वितरणाद्वारे उत्पादन केले आहे त्या गुणवत्तेच्या दृष्टीने कमी पडतात आणि एकूणच गोष्टींकडे लक्ष देतात. आणि बर्‍याचदा हा गैरसमज आहे की डेटा मॉडेलर प्रकल्प हळू करतात आणि डेटा मॉडेलरकडे योग्य दृष्टीकोन नसल्यास ते करतील. मी म्हटल्याप्रमाणे, आपल्याला गमवावे लागेल - कधीकधी असे डेटा मॉडेलर्स असतात ज्यांची पारंपारिक गेटकीपर वृत्ती असते जेथे, "डेटा स्ट्रक्चर कशा दिसतात हे नियंत्रित करण्यासाठी आम्ही येथे आहोत" आणि ती मानसिकता नाहीशी झाली पाहिजे. चपळ विकासात गुंतलेल्या कोणालाही आणि विशेषत: डेटा मॉडेलर्सने कार्यसंघांना खरोखर पुढे जाण्यासाठी खरोखर मदत करणारी म्हणून भूमिका घ्यावी लागेल. आणि हे स्पष्ट करण्याचा उत्तम मार्ग म्हणजे संघांना ते बदल करण्याच्या मॉडेलिंगद्वारे ते किती उत्पादक असू शकतात हे द्रुतपणे दर्शविणे. आणि पुन्हा, म्हणूनच मी सहकार्याबद्दल बोललो.
अशा काही गोष्टी आहेत ज्या आम्ही विकसकांना बाहेर आणण्यासाठी प्रथम मॉडेल करू आणि डीडीएल व्युत्पन्न करू शकू. आम्ही हे देखील सुनिश्चित करू इच्छितो की त्यांना प्रतिबंधित केल्यासारखे वाटत नाही. म्हणून, ज्या गोष्टींवर त्या कार्यरत आहेत अशा काही गोष्टी असल्यास, त्यांना त्यांच्या विकास सँडबॉक्सेसमध्ये काम करत राहू द्या, कारण तेथेच विकसक त्यांच्या स्वत: च्या डेस्कटॉपवर किंवा इतर डेटाबेसवर काम करत आहेत जेथे गोष्टींची चाचणी घेत आहेत. आणि त्यांच्याशी सहयोग करा आणि म्हणा, “ठीक आहे, त्यासह कार्य करा.” आम्ही ते साधनात आणू, आम्ही त्याचे निराकरण करू आणि मग आम्ही त्यास पुढे ढकलू आणि त्या अद्ययावत करण्यासाठी आपण त्यास तैनात करू शकू अशा स्क्रिप्ट देऊ. डेटाबेस ज्यात आपण पुढे जात आहोत त्याप्रमाणे वास्तविक मंजूर ख production्या उत्पादनाचे दृष्य काय असेल यावर उन्नत करण्यासाठी. आणि आपण त्या एका अतिशय द्रुत फॅशनमध्ये फिरवू शकता. मला असे आढळले की माझे दिवस भरले गेले आहेत जिथे मी आता परत पुढे जात आहे आणि वेगवेगळ्या विकास संघांसह पुनरावृत्ती करीत आहे, बदल पहात आहे, तुलना करीत आहे, स्क्रिप्ट तयार करीत आहे, त्यांना जात आहे, आणि आम्ही एकदा चार विकास संघासह स्वत: ला पुढे ठेवण्यास सक्षम केले आहे एकदा आम्ही एकदा गती साध्य केली.
डेझ ब्लांचफील्ड: त्यामधून लक्षात येणार्‍या गोष्टींपैकी एक म्हणजे, आपल्याला माहिती आहे, मी दररोज बोलत असलेल्या बर्‍याच संभाषणे म्हणजे या फ्रेट ट्रेन आमच्याकडे येत आहे, क्रमवारीत, मशीन-टू-मशीन आणि आयओटी. आणि जर आम्हाला असे वाटते की आमच्याकडे सध्याच्या एंटरप्राइझमधील वातावरणाविषयी आम्हाला बराच डेटा मिळाला आहे, तर आपल्याला माहित आहे की जर आपण गिंगल्स आणि एस आणि उबर्सकडे डेटाचे पेटबाइट्स आहेत हे आपल्याला माहित असेल त्या क्षणासाठी आम्ही युनिकॉर्न बाजूला ठेवले तर, पारंपारिक उद्योगात आम्ही अजूनही शेकडो टेराबाइट आणि बर्‍याच डेटाबद्दल बोलत आहोत. पण माझ्या मालकीच्या दृष्टीने ही मालवाहतूक संस्था संघटनांकडे येत आहे आणि डॉ. रॉबिन ब्लॉरने त्यास आयओटीच्या आधी संकेत दिले आहेत. आपणास माहित आहे की आमच्याकडे बर्‍याच वेब रहदारी आहेत, आपल्याकडे सामाजिक रहदारी आहे, आपल्याकडे आता गतिशीलता आणि मोबाइल डिव्हाइस आहेत, ढग एक प्रकारचा आहे, फुटला आहे, परंतु आता आपल्याकडे स्मार्ट इन्फ्रास्ट्रक्चर, स्मार्ट शहरे आहेत. आणि नुकतेच फुटलेल्या डेटाचे हे संपूर्ण जग आहे.
दररोजच्या संस्थेसाठी, मध्यम ते मोठ्या संघटना जो तिथे बसलेला आहे आणि हे दु: खाचे जग त्यांना पाहत आहे आणि त्यांच्याकडे तातडीची योजना नाही आहे हे लक्षात ठेवून घ्या, आपण घ्यावयाच्या काही दोन वाक्यात, काही टेकवे काय आहेत? यापैकी काही पद्धती जागोजागी ठेवण्याविषयी त्यांना संभाषणात्मक विचार सुरू करणे आवश्यक आहे की नाही याबद्दल. जवळजवळ बसून लक्ष देण्याची आणि काही साधने जागोजागी तयार करण्याची आणि कार्यसंघाला प्रशिक्षित करण्यासाठी आणि आव्हानाच्या भोवती फिरणा voc्या आवाजातील संभाषण मिळविण्याची हीच योग्य वेळ आहे असे सांगण्याची त्यांना किती वेळ लागेल? कथेत किती उशीर झाले किंवा किती लवकर? आपण पहात असलेल्या काही संस्थांकरिता हे कसे दिसते?
रॉन हुईझेन्गा: मी बर्‍याच संस्थांसाठी म्हणेन की जर त्यांनी यापूर्वीच ते केले नसते आणि डेटा मॉडेलिंग आणि डेटा आर्किटेक्चरला यासारख्या शक्तिशाली साधनांसह रुपांतर केले असेल तर त्यांना करण्याची वेळ काल आहे. कारण हे मनोरंजक आहे की, आजही जेव्हा आपण संस्थांमधील डेटा पाहतो तेव्हा आमच्याकडे आमच्या संस्थांमध्ये इतका डेटा असतो आणि सामान्यत: काही सर्वेक्षणांच्या आधारे आम्ही पाहत असतो, त्या डेटाच्या पाच टक्के पेक्षा कमी आम्ही प्रभावीपणे वापरतो जेव्हा आपण संस्थांकडे पहातो. आणि आयओटी किंवा अगदी एसओएसक्यूएलसह, मोठा डेटा - जरी तो फक्त आयओटी नाही, परंतु सर्वसाधारणपणे फक्त मोठा डेटा आहे - जिथे आपण आता आपल्या संस्थांच्या बाहेरून उद्भवणार्‍या आणखी अधिक माहितीचा वापर करण्यास सुरवात करीत आहोत, ते आव्हान मोठे आणि मोठे होत चालले आहे सर्व वेळ. आणि त्या समस्येस सामोरे जाण्याची आमची एकमेव संधी आहे ती डेटा काय आहे हे समजून घेण्यात आम्हाला मदत करणे.
तर, वापर केस थोडे वेगळे आहे. जेव्हा आपण डेटा पाहतो तेव्हा आपण ते करीत आहोत, आपण ते हस्तगत करीत आहोत, आपल्याला त्यास उलटा अभियंता आवश्यक आहे, त्यामध्ये काय आहे ते पहावे, ते आपल्या डेटा सरोवरात किंवा आमच्या घरातील डेटाबेसमध्ये आहे काय डेटा म्हणजे अर्थ लावा आणि त्यास परिभाषा द्या म्हणजे डेटा म्हणजे काय ते आम्हाला समजू शकेल. कारण जोपर्यंत आम्हाला हे समजत नाही तोपर्यंत आम्ही हे अचूक किंवा पुरेसे वापरत आहोत हे सुनिश्चित करू शकत नाही. म्हणून आम्हाला खरोखर डेटा आहे त्याबद्दल हँडल घेणे आवश्यक आहे.आणि त्यातील दुसरा भाग म्हणजे ते करू नका कारण आपण हा सर्व बाह्य डेटा वापरण्याच्या दृष्टीने आपल्याकडे वापर बाह्यरुप आहे याची खात्री करुन घ्या की हा बाह्य डेटा वापरण्यास मदत करते. आपल्याला नंतर आवश्यक असलेल्या गोष्टी खेचण्याचा आणि त्यांचा उपयोग करण्यापेक्षा आपल्याला आवश्यक असलेल्या गोष्टींवर लक्ष केंद्रित करा. प्रथम महत्वाच्या गोष्टींवर लक्ष केंद्रित करा आणि त्याद्वारे आपले काम पूर्ण करताच, नंतर आपण बाहेरून इतर माहिती घेण्यास आणि समजून घेण्याचा प्रयत्न कराल.
याचे एक अचूक उदाहरण आहे, मला माहिती आहे की आम्ही आयओटी आणि सेन्सर बोलत आहोत, परंतु आयओटीपूर्वीही बर्‍याच वर्षांपासून समान प्रकारची समस्या बर्‍याच वर्षांपासून आहे. प्रॉडक्शन कंट्रोल सिस्टम असलेली कोणतीही, ते पाईपलाईन कंपनी असोत, मॅन्युफॅक्चरिंग, कोणतीही प्रक्रिया-आधारित कंपन्या ज्या वस्तू ज्या नियंत्रणासह बर्‍याच ऑटोमेशन करत आहेत आणि डेटा डेटा आणि त्यासारख्या गोष्टी वापरत आहेत. या डेटाची अग्निशामक आकडेवारी शोधण्यासाठी ते प्रयत्न करीत आहेत, माझ्या उत्पादन उपकरणात सिग्नल बनवण्यासाठी कोणत्या घटना घडल्या आहेत - काय घडले आणि केव्हा? आणि डेटाच्या या प्रचंड प्रवाहात केवळ माहितीचे काही विशिष्ट तुकडे किंवा टॅग आहेत ज्यांना त्यांना स्वारस्य आहे की त्यांना चाळणे, संश्लेषित करणे, मॉडेल तयार करणे आणि समजून घेणे आवश्यक आहे. आणि खरोखर हे समजून घेण्याची वेळ येईपर्यंत ते उर्वरित गोष्टींकडे दुर्लक्ष करू शकतात आणि मग जर त्यास अर्थ प्राप्त झाला तर त्या जास्तीत जास्त प्रमाणात ते वावराकडे आकर्षित करू शकतील.
डेझ ब्लांचफील्ड: हे खरंच आहे. एक प्रश्न आहे ज्यामध्ये मी नेतृत्व करणार आहे एरिक नावाच्या सज्जन माणसाचा, आणि आम्ही त्याबद्दल खाजगी गप्पा मारत आहोत. मी नुकतीच त्याची परवानगी मागितली आहे, जी त्याने दिली आहे, आपल्याकडून ती विचारण्यासाठी. कारण हे फक्त लपेटण्यासाठीच याकडे छान वळते कारण आपण आता काळानुरुप थोडेसे चालत आहोत आणि मी पुन्हा एरिकला हात जोडतो. परंतु दुसर्‍या एरिकचा प्रश्न हा होता की मॉडेलिंगच्या शब्दावलीच्या आसपासची अनोखी आव्हाने एखाद्या स्टार्टअपच्या मालकांना परिचित असतील आणि त्या समजून घेतील आणि हे समजावून सांगण्यासाठी वाजवी आहे का? तर, दुस words्या शब्दांत, एखादा स्टार्टअप सक्षम आणि तयार आणि इच्छुक असावा आणि यावर लक्ष केंद्रित करण्यास आणि वितरित करण्यास सक्षम असावा? किंवा हे काहीतरी त्यांनी खरेदी केले पाहिजे आणि त्यासह बोर्डात तज्ञ आणले पाहिजेत?
रॉन हुईझेन्गा: माझ्या मते लहान उत्तर खरोखरच अवलंबून आहे. जर एखादा असा स्टार्टअप असेल ज्यामध्ये डेटाबेस खरोखरच समजणारा एखादा डेटा आर्किटेक्ट किंवा मॉडेलर असेल तर आरंभ करण्याचा वेगवान मार्ग म्हणजे एखाद्यास सल्लामसाराची पार्श्वभूमी असणारी जी या जागेवर परिपूर्ण आहे आणि मिळवू शकते. ते जात आहेत. कारण आपल्याला काय सापडेल - आणि खरं तर, मी उत्पादनाच्या व्यवस्थापनात गडद बाजूकडे येण्यापूर्वी केलेल्या बर्‍याच गुंतवणूकीवर मी हे केले - मी सल्लागार म्हणून संस्थांमध्ये जाईन, त्यांच्या डेटा आर्किटेक्चर टीमचे नेतृत्व करू, जेणेकरून ते अशा प्रकारचे, स्वतःचे पुनर्बांधणी करु शकतील आणि अशा प्रकारच्या गोष्टी कशा कराव्यात याविषयी लोकांना प्रशिक्षण देऊ शकतील जेणेकरुन ते ते टिकवून ठेवतील आणि मिशन पुढे जातील. आणि मग मी माझ्या पुढच्या गुंतवणूकीला पुढे जाऊ, जर ती समजली तर. तेथे बरेच लोक आहेत जे असे करतात, त्यांना खूप चांगला डेटा अनुभव आहे जो त्यांना पुढे जाऊ शकेल.
डेझ ब्लांचफील्ड: हा एक चांगला टेकवे मार्ग आहे आणि मी त्याच्याशी पूर्णपणे सहमत आहे आणि मला खात्री आहे की डॉ. रॉबिन ब्लॉरदेखील हे करेल. विशेषतः स्टार्टअपमध्ये, आपण स्वतःच आपल्या स्टार्टअप व्यवसायाचा एक भाग म्हणून तयार करू इच्छित असलेल्या प्रस्तावाच्या विशिष्ट मूल्यावर एसएमई बनण्यावर आपले लक्ष केंद्रित केले आहे आणि आपल्याला कदाचित प्रत्येक गोष्टीत तज्ञ असण्याची गरज नाही, म्हणून उत्कृष्ट सल्ला. पण एक आभारी प्रेझेंटेशन. खरोखर छान उत्तरे आणि प्रश्न. एरिक, मी तुझ्याकडे परत जात आहे कारण मला माहित आहे की आम्ही बहुदा वेळेत दहा मिनिटे निघून गेले आहोत आणि मला माहित आहे की आपण आमच्या टाइम विंडोजवळ चिकटून राहणे पसंत केले आहे.
एरिक कवानाग: ठीक आहे. आमच्याकडे कमीतकमी काही चांगले प्रश्न आहेत. मला एक टेकू द्या. मला असे वाटते की आपण इतरांपैकी काहींना उत्तर दिले आहे. परंतु एका उपस्थिताने लिहिलेले एक अतिशय मनोरंजक निरीक्षण आणि प्रश्न, कधीकधी चपळ प्रकल्पांमध्ये डेटा मॉडेलर असतो ज्यामध्ये संपूर्ण दीर्घकालीन चित्र नसते आणि म्हणून ते एस मध्ये काहीतरी डिझाइन करतात आणि नंतर तीन किंवा चार मध्ये पुन्हा डिझाइन करतात. हे प्रतिकूल असल्याचे दिसत नाही? आपण अशा प्रकारची गोष्ट कशी टाळू शकता?
रॉन हुईझेन्गा: हे फक्त चापुरपणाचे स्वरूप आहे की आपण दिलेल्या मध्ये सर्व काही अगदी अचूक मिळवणार नाही. आणि प्रत्यक्षात चापुरपणाचा हाच एक भाग आहे, त्यासह कार्य करा - आपण दिलेल्या कोडमध्ये कोडवर कार्य करत आहात तेथे आपण प्रोटोटाइपिंग करत आहात आणि आपण त्यास परिष्कृत करणार आहात. आणि त्या प्रक्रियेचा एक भाग म्हणजे जेव्हा आपण शेवटच्या वापरकर्त्याने ती पाहतो आणि म्हटले की “हो ते जवळ आहे, परंतु मला हे खरोखर थोडेसे करण्याची गरज आहे.” त्यामुळे केवळ कार्यात्मक रचनेवर त्याचा परिणाम होत नाही. कोड स्वतःच परंतु बर्‍याचदा आम्हाला वापरकर्त्यास हवे ते वितरीत करण्यासाठी या विशिष्ट गोष्टींच्या खाली अधिक डेटा रचना सुधारणे किंवा जोडणे आवश्यक आहे. आणि हा सर्व वाजवी खेळ आहे आणि म्हणूनच आपल्याला खरोखर उच्च-शक्तीचे साधन वापरायचे आहे कारण आपण मॉडेलिंग साधनामध्ये त्वरेने मॉडेल तयार करू शकता आणि त्यामध्ये बदल करू शकता आणि नंतर डेटाबेससाठी डीडीएल व्युत्पन्न करू शकता जे विकसक त्या वितरणासाठी त्या विरूद्ध कार्य करू शकतात. आणखी द्रुतगतीने बदला. आपण त्यांना डेटा स्ट्रक्चर्ससारखेच हँड कोडिंग करण्यापासून वाचवित आहात आणि त्यांना ज्या प्रोग्रामिंगवर किंवा अ‍ॅप्लिकेशन लॉजिकवर सर्वात जास्त कौशल्य आहे त्याकडे लक्ष केंद्रित करण्यास ते देत आहेत.
एरिक कवानाग: पूर्ण अर्थ प्राप्त होतो. आमच्याकडे काही इतर लोकांकडे असे विशिष्ट प्रश्न विचारत होते की हे सर्व टूलला कसे बांधते. मला माहित आहे की आपण उदाहरणे देऊन थोडा वेळ घालवला आणि आपण या सामग्रीपैकी काही खरोखर कसे बाहेर आणता याबद्दल आपण काही स्क्रीनशॉट दर्शवित आहात. या संपूर्ण प्रक्रियेच्या दृष्टीने, आपण संस्थांमधील नाटकात आणि पारंपारिक प्रक्रियेत किती वेळा पाहता ज्यामध्ये गोष्टी फक्त, प्रकारची असतात आणि जास्त वेळ घेतात? आपल्या दृष्टीकोनातून एस-शैलीचा दृष्टीकोन किती प्रचलित आहे?
रॉन हुईझेन्गा: मला वाटते की आम्ही ते अधिकाधिक पहात आहोत. मला हे माहित आहे की, कदाचित मी म्हणेन, कदाचित गेल्या 15 वर्षात विशेषतः जलद वितरण स्वीकारणे आवश्यक आहे हे ओळखून मी लोकांना बरेचसे स्वीकारले आहे. म्हणून मी बर्‍याच संस्था चपळ बँडवॅगनवर उडी घेतल्याचे पाहिले आहे. संपूर्णपणे आवश्यक नाही; ते कार्य करते हे सिद्ध करण्यासाठी काही पायलट प्रकल्प सुरू करू शकतात, परंतु असे काही अजूनही आहेत जे खूप पारंपारिक आहेत आणि धबधब्याच्या पद्धतीनुसार आहेत. आता अर्थात ही चांगली बातमी अशी आहे की त्या संस्थांमध्ये तसेच त्या प्रकारच्या कार्यपद्धतींसाठी साधने अतिशय चांगली काम करतात, परंतु आमच्याकडे उपकरणात अनुकूलता आहे जेणेकरून जे बोर्डवर उडी घेतात त्यांच्याकडे टूलबॉक्समध्ये साधने असतील त्यांच्या बोटांच्या टोकांवर. तुलना आणि विलीन करण्यासारख्या गोष्टी, रिव्हर्स-इंजिनीअरिंग क्षमता यासारख्या गोष्टी, जे विद्यमान डेटा स्त्रोत काय आहेत हे ते पाहू शकतात, म्हणूनच ते खरोखर वाढीव डीडीएल स्क्रिप्ट्सची तुलना आणि वेगाने तयार करू शकतात. आणि जेव्हा ते त्यास आलिंगन देतात आणि त्यांची उत्पादनक्षमता येऊ शकते हे पाहताच, चपळाईने मिठी मारण्याचा त्यांचा कल अधिकच वाढतो.
एरिक कवानाग: लोकांनो, ही छान सामग्री आहे. मी चॅट विंडोमध्ये तिथे असलेल्या स्लाइडचा दुवा नुकताच पोस्ट केला आहे, म्हणून ते तपासा; हे आपल्यासाठी तेथे थोडेसे आहे. आमच्याकडे नंतर पाहण्यासाठी हे सर्व वेबकास्ट आहेत. आपल्या मित्रांसह आणि सहका with्यांसह मोकळ्या मनाने सामायिक करा. आणि रॉन, आज आपल्या वेळेबद्दल मनापासून आभार, तुम्ही नेहमीच या कार्यक्रमात भाग घेण्यास आनंददायी आहात - शेतात एक ख expert्या तज्ज्ञ आणि आपल्याला आपली सामग्री माहित आहे हे स्पष्ट आहे. तर, आपले आभार आणि आयडेरा आणि अर्थातच, डेझ आणि आमच्या स्वतःच्या रॉबिन ब्लॉरचे आभार.
आणि त्याद्वारे आम्ही आपणास निरोप देणार आहोत, लोकांनो. आपला वेळ आणि लक्ष दिल्याबद्दल पुन्हा धन्यवाद. आम्ही तुमचे 75 मिनिटे चिकटून राहिल्याबद्दलचे कौतुक करतो, ते एक चांगले चिन्ह आहे. चांगले शो अगं आम्ही पुढच्या वेळी तुमच्याशी बोलू. बाय बाय.