Pemodelan data dalam lingkungan yang gesit

Oleh Staf Techopedia, 16 November 2016

Takeaway: Host Eric Kavanagh membahas pentingnya pemodelan data dalam pengembangan tangkas dengan Robin Bloor, Dez Blanchfield dan Ron Huizenga dari IDERA.

Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.

Eric Kavanagh: Oke, tuan dan nyonya. Selamat datang kembali sekali lagi. Ini hari Rabu jam 4:00 EST. Itu berarti saatnya untuk Teknologi Panas. Ya memang. Nama saya Eric Kavanagh, saya akan menjadi tuan rumah Anda.

Untuk topik hari ini, ini adalah oldie tapi goodie. Semakin baik setiap hari karena ini membentuk dunia manajemen data kami, “Pemodelan Data dalam Lingkungan yang Agile.” Ada seluncuran tentang Anda yang sebenarnya, buat saya di Twitter @eric_kavanagh. Kita harus benar-benar meletakkannya di slide itu. Saya harus mengerti.

Jadi tahun ini panas. Pemodelan data telah ada selamanya. Ini benar-benar merupakan jantung dan jiwa dari bisnis manajemen informasi, merancang model data, mencoba memahami model bisnis dan menyelaraskannya dengan model data Anda. Itu benar-benar apa yang Anda coba lakukan, bukan?

Model data mewakili bisnis dengan cara yang mendasar, jadi bagaimana semua sumber data baru ini mengubah permainan? Kami akan mencari tahu tentang itu. Kami akan mencari tahu bagaimana Anda bisa tetap unggul dalam berbagai hal dengan cara yang gesit. Dan tentu saja, itulah kata tahun ini.

Robin Bloor bersama kami, kepala analis kami, Dez Blanchfield menelepon dari Sydney, Australia dan Ron Huizenga, Manajer Produk Senior dari IDERA - teman lama saya, pembicara hebat di ruang ini, tahu barang-barangnya, jadi jangan malu-malu, tanyakan dia pertanyaan sulit, orang-orang, yang sulit. Dengan itu, aku akan menjadikan Robin presenter, dan membawanya pergi.

Robin Bloor: Oke. Terima kasih untuk itu, Eric. Saya harus mengatakan tentang pemodelan yang saya pikir, saya benar-benar di dunia IT sebelum ada, dalam arti yang saya ingat di perusahaan asuransi tempat saya bekerja, bahwa kami memiliki seorang pria masuk dan memberi kami semua jenis lokakarya tentang cara memodelkan data. Jadi kita melihat sekitar 30 tahun, apakah 30 tahun? Mungkin bahkan lebih lama dari itu, mungkin 35 tahun yang lalu. Pemodelan yang sangat lama telah menjadi bagian dari industri dan tentu saja tidak ada hubungannya dengan wanita di catwalk.

Hal yang ingin saya katakan, karena apa yang biasanya kita lakukan, adalah saya dan Dez berbicara tentang hal-hal yang berbeda dan saya hanya berpikir saya akan memberikan gambaran umum untuk pemodelan, tetapi ada kenyataan untuk ini, yang sekarang menjadi jelas.

Kami memiliki, Anda tahu, realitas big data, kami memiliki lebih banyak data, lebih banyak sumber data, kami memiliki aliran data yang telah memasukkan persamaan dalam tiga atau empat tahun terakhir dan mulai mendapatkan bagian yang lebih besar darinya, dan ada kebutuhan yang lebih besar untuk memahami data dan peningkatan laju perubahan yaitu lebih banyak data yang ditambahkan dan juga lebih banyak struktur data yang digunakan.

Ini dunia yang sulit. Berikut ini gambarnya, yang sebenarnya adalah sesuatu yang kami gambar sekitar tiga tahun yang lalu tetapi pada dasarnya, setelah Anda memasukkan streaming ke dalam campuran dan Anda mendapatkan gagasan tentang kilang data, hub data, tautan data atau apa pun, Anda melihat bahwa ada data yang benar-benar beristirahat, dalam arti bahwa itu tidak banyak bergerak. Dan kemudian ada data, aliran dan Anda memiliki semua aplikasi transaksional, ditambah saat ini Anda punya acara, aliran data acara yang terjadi dalam aplikasi dan mungkin perlu, dan saat ini dengan arsitektur lambda yang dibicarakan semua orang, benar-benar berdampak hanya pada seluruh bidang data.

Dan saat ini berpikir dalam hal ada lapisan data. Lapisan data ada dalam semacam cara virtual, dalam arti bahwa sepotong yang baik itu bisa berada di cloud dan dapat menyebar di seluruh pusat data, itu bisa ada di workstation. Lapisan data, sampai taraf tertentu, di mana-mana dan dalam arti itu, ada proses di mana-mana yang berusaha dengan satu atau lain cara untuk memproses data dan memindahkan data tentang. Tetapi juga mengetahui apa itu ketika Anda memindahkannya, adalah masalah besar.

Jika kita melihat pemodelan data dalam pengertian paling umum, di bagian bawah tumpukan ini Anda memiliki file dan database. Anda memiliki elemen data, yang memiliki kunci, definisi elemen, alias, sinonim, format fisik tertentu dan kemudian kita memiliki lapisan metadata ini.

Hal yang menarik tentang metadata adalah bahwa metadata sepenuhnya bagaimana data mendapatkan maknanya. Jika Anda tidak benar-benar memiliki metadata, maka paling baik Anda bisa menebak arti data, tetapi Anda akan memiliki banyak kesulitan. Metadata perlu ada di sana, tetapi makna memiliki struktur. Saya tidak ingin masuk ke filosofi makna, tetapi bahkan dalam cara kita menangani data, ada banyak kecanggihan dalam pemikiran manusia dan bahasa manusia, yang tidak mudah mengekspresikan dirinya dalam data. Tetapi bahkan dalam hal data yang benar-benar kami proses di dunia, metadata memiliki makna dan struktur metadata - sepotong data dalam hubungannya dengan yang lain dan apa artinya ketika mereka disatukan dan apa artinya ketika mereka ' kembali bergabung dengan data lain, menuntut agar kami memodelkannya. Tidak cukup hanya merekam tag metadata ke berbagai hal, Anda sebenarnya harus merekam makna per struktur dan hubungan antara struktur.

Kemudian kita memiliki di lapisan atas, definisi bisnis, yang biasanya merupakan lapisan yang mencoba mentransfer makna antara metadata, yang merupakan bentuk definisi data yang mengakomodasi cara data disusun pada komputer dan makna manusia. Jadi, Anda memiliki istilah bisnis, definisi, hubungan, konsep tingkat entitas yang ada di lapisan itu. Dan jika kita akan memiliki inkoherensi antara lapisan-lapisan ini, maka kita harus memiliki pemodelan data. Itu tidak benar-benar opsional. Semakin Anda benar-benar dapat melakukannya dalam hal mengotomatiskannya, semakin baik. Tetapi karena ini berkaitan dengan makna, sangat sulit untuk berganti-ganti. Cukup mudah untuk menangkap metadata dalam rekaman dan bisa mendapatkannya dari serangkaian makna, tetapi itu tidak memberi tahu Anda struktur catatan atau apa arti catatan atau konteks catatan.

Jadi, inilah yang dimaksud dengan pemodelan data. Poin yang perlu diperhatikan: semakin kompleks jagad data, semakin Anda perlu memodelkannya. Dengan kata lain, ini agak seperti kita menambahkan tidak hanya lebih banyak contoh hal ke dunia, yang akan sesuai dengan catatan data, tetapi kita sebenarnya menambahkan lebih banyak makna ke dunia dengan menangkap data pada lebih banyak hal. Ini menjadi perasaan yang semakin kompleks yang harus kita pahami.

Secara teori ada jagad data dan kita perlu melihatnya. Dalam praktiknya, metadata yang sebenarnya adalah bagian dari semesta data. Jadi, ini bukan situasi yang sederhana. Pemodelan awal adalah top-down dan bottom-up. Anda perlu membangun di kedua arah dan alasan untuk itu adalah, data memiliki arti bagi komputer dan proses, yang harus memprosesnya, tetapi memiliki makna dalam dirinya sendiri. Jadi, Anda memerlukan makna bottom-up, yang memuaskan perangkat lunak yang perlu mengakses data dan Anda perlu makna top-down sehingga manusia dapat memahaminya. Pembangunan model metadata bukanlah dan tidak pernah bisa menjadi proyek; ini merupakan aktivitas yang berkelanjutan - harus menjadi aktivitas berkelanjutan di setiap lingkungan yang ada. Untungnya, ada banyak lingkungan, di mana itu sebenarnya tidak terjadi dan hal-hal menjadi tidak terkendali.

Ke depan, pemodelan meningkat dengan penting saat teknologi bergerak maju. Itu pendapat saya. Tetapi jika Anda melihat pada IoT kita dapat lebih memahami mobile daripada sebelumnya, meskipun memperkenalkan dimensi baru: dimensi lokasi dengan mobile. Setelah Anda sampai di IoT, kami melihat masalah data luar biasa yang tidak pernah benar-benar harus kami lakukan sebelumnya dan kami perlu, dengan satu atau lain cara, untuk memahami dengan tepat apa yang kami dapatkan, persis bagaimana kami dapat menggabungkannya, apa yang bisa kita lakukan dalam hal mendapatkan makna dari agregasi, dan tentu saja, apa yang bisa kita lakukan dengannya, ketika kita sudah memprosesnya.

Saya pikir itu saya sudah cukup mengatakan. Saya akan menyampaikan kepada Dez Blanchfield, yang akan mengatakan sesuatu yang lain sepenuhnya.

Dez Blanchfield: Terima kasih. Selalu tindakan yang sulit untuk diikuti, tetapi ini adalah topik yang kami sepakati dan bicarakan secara singkat di olok-olok preshow, dan jika Anda menelepon lebih awal, Anda mungkin akan menangkap sejumlah permata besar. Salah satu takeaways, dan saya tidak ingin mencuri guntur yang satu ini, tetapi salah satu takeaways dari olok-olok preshow kami yang ingin saya bagikan, jika Anda tidak menangkapnya, hanya sekitar topik perjalanan data, dan saya terpikir untuk benar-benar menuliskannya memikirkan perjalanan data yang diambil dalam konteks yang berbeda di sekitar masa hidup generasi - tahun, bulan, minggu, hari, jam, menit, detik - dan konteks di sekitar data adalah diposisikan dalam konteks itu. Apakah saya seorang pengembang menjalankan kode, atau apakah saya seorang spesialis data dan saya berpikir tentang struktur dan format dan metadata di sekitar masing-masing elemen, atau cara sistem dan bisnis berinteraksi dengannya.

Ini adalah takeaway kecil yang menarik hanya untuk dicatat, tapi bagaimanapun, izinkan saya menyelam. Desain data, khususnya, adalah ungkapan yang saya gunakan untuk berbicara tentang semua hal data dan khususnya pengembangan aplikasi atau infrastruktur basis data. Saya pikir desain data adalah istilah yang hanya menangkap semuanya dengan baik dalam pikiran saya. Hari-hari ini ketika kita berbicara tentang desain data, kita berbicara tentang desain data yang gesit modern, dan pandangan saya adalah bahwa belum lama berselang para pengembang dan pakar data bekerja sendiri; mereka berada di silo mereka sendiri dan desainnya berpindah dari satu silo ke silo lainnya. Tapi saya sangat banyak pandangan hari ini, bahwa tidak hanya itu kasus yang berubah, tetapi harus berubah; itu semacam keharusan dan itu adalah bahwa aplikasi - pengembang dan segala sesuatu yang harus dilakukan seputar pengembangan yang berhubungan dengan data, perancang yang melakukan elemen desain yang relevan dari skema dan bidang dan catatan dan lokasi dan sistem basis data dan infrastruktur, pemodelan dan seluruh manajemen tantangan di sekitar itu. Itu adalah olahraga tim sekarang dan karenanya gambar saya tentang sekelompok orang yang melompat keluar dari pesawat terbang bertindak sebagai tim untuk memainkan gambar yang secara visual menarik dari orang-orang yang jatuh di langit.

Ketiga, apa yang terjadi untuk mewujudkan ini? Nah, ada sebuah artikel pada tahun 1986 yang ditulis oleh beberapa pria yang namanya saya coba mati-matian untuk melakukan keadilan, Hirotaka Takeuchi dan Ikujiro Nonaka, saya pikir itu diucapkan, menghasilkan sebuah artikel yang berjudul "Memindahkan Scrum Downfield." ide metodologi memenangkan permainan rugby dari kegiatan scrum ini, di mana setiap orang berkeliling di satu tempat dan dua tim pada dasarnya mengunci kepala dalam sesuatu yang disebut scrum untuk mencoba dan mengendalikan bola dan memainkannya di lapangan untuk sampai ke garis coba dan menyentuh tanah dengan bola dan mendapatkan poin, disebut trine, dan Anda mengulangi proses ini dan Anda mendapatkan lebih banyak poin untuk tim.

Artikel ini diterbitkan pada tahun 1986 di Harvard Business Review, dan anehnya itu benar-benar mendapat banyak perhatian. Itu mendapat banyak perhatian karena memperkenalkan konsep-konsep baru yang menakjubkan dan di sini adalah screenshot dari depannya. Jadi mereka mengeluarkan konsep scrum dari game rugby dan membawanya ke dalam bisnis dan khususnya dalam game desain dan pengiriman proyek, khususnya pengiriman proyek.

Apa scrum lakukan adalah memberi kami metodologi baru dibandingkan dengan orang-orang seperti PRINCE2 atau PMBOK yang sebelumnya kami gunakan dalam apa yang kami sebut metodologi air terjun, Anda tahu, melakukan hal ini dan hal ini dan hal ini dan mengikuti mereka secara berurutan dan terhubung semua titik di sekitar, yang tergantung pada apa yang Anda miliki, atau tidak melakukan bagian dua sampai Anda selesai bagian satu karena tergantung pada bagian satu. Apa yang diberikannya kepada kami adalah metodologi baru untuk menjadi sedikit lebih gesit, dari mana istilah itu berasal, tentang bagaimana kami memberikan barang, dan khususnya seputar desain dan pengembangan pengiriman proyek akar rumput.

Beberapa penyewa utama - supaya saya bisa melanjutkan ini - ada di sekitar penyewa utama scrum. Ini memperkenalkan gagasan membangun ketidakstabilan, yang secara efektif jika Anda berpikir tentang ketakutan akan kekacauan, dunia ada dalam keadaan kacau, tetapi planet ini terbentuk, yang menarik, sehingga membangun ketidakstabilan, kemampuan untuk bangkit sedikit dan masih benar-benar membuat hal-hal bekerja, tim proyek yang mengatur diri sendiri, bantuan yang tumpang tindih melalui pengembangan yang sangat bertanggung jawab, berbagai jenis pembelajaran dan kontrol melalui perjalanan pengiriman proyek, transfer pembelajaran organisasi. Jadi bagaimana kita mengambil informasi dari satu bagian bisnis dan mentransfernya ke bagian lain dari orang yang punya ide tetapi tidak mengembangkan kode atau tidak mengembangkan basis data dan infrastruktur, tetapi data untuk orang-orang itu? Dan secara khusus hasil waktu-kotak. Dengan kata lain, mari kita lakukan ini untuk jangka waktu tertentu, baik sehari seperti dalam 24 jam, atau seminggu atau beberapa minggu dan lihat apa yang bisa kita lakukan dan kemudian mundur dan melihatnya.

Jadi, jika Anda memaafkan permainan kata-kata, ini benar-benar permainan baru dalam pengiriman proyek dan tiga komponen inti yang akan masuk akal ketika kita sedikit lebih jauh di sini - ada produk: semua orang memiliki ide dan memiliki kebutuhan untuk menyelesaikan sesuatu dan kisah yang mengelilingi mereka. Pengembang yang beroperasi dalam model gesit untuk mendapatkan cerita mereka dan melalui standup sehari-hari menggunakan metodologi scrum untuk membahasnya dan memahami apa yang perlu mereka lakukan, dan kemudian pergi dan melanjutkan dan melakukannya. Lalu, orang-orang, kita pernah mendengar master scrum yang mengawasi semua ini dan memahami metodologi dengan cukup baik untuk mendorongnya. Kita semua telah melihat gambar-gambar ini yang saya dapatkan di sisi kanan sini tembok dan papan tulis penuh dengan catatan Post-It dan mereka disajikan sebagai dinding Kanban. Jika Anda tidak tahu siapa Kanban, saya mengundang Anda ke Google siapa Pak Kanban dan mengapa itu merupakan perubahan cara kami memindahkan sesuatu dari satu sisi ke sisi lain di dinding secara harfiah tetapi dalam sebuah proyek.

Sekilas, alur kerja scrum melakukan ini: dibutuhkan daftar hal-hal yang ingin dilakukan organisasi, menjalankannya melalui serangkaian hal yang kita sebut sprint yang dipecah menjadi periode 24 jam, periode bulan-panjang, dan kami dapatkan serangkaian output tambahan ini. Ini adalah perubahan signifikan dalam cara proyek dikirim, dikirim ke tahap itu karena sebagian dari itu mengalir seperti tentara AS yang memiliki bagian besar dalam mengembangkan sesuatu yang disebut PMBOK, seperti gagasan yang tidak membawa tank ke lapangan sampai Anda memasukkan peluru ke dalam benda itu karena jika sebuah tank di lapangan tidak memiliki peluru, itu tidak berguna. Jadi oleh karena itu bagian satu dimasukkan peluru ke dalam tangki, bagian kedua adalah menempatkan tangki di lapangan. Sayangnya, apa yang terjadi dengan para pengembang di dunia pengembangan entah bagaimana bisa mendapatkan metodologi tangkas ini dan berlari dengan itu datar, jika Anda memaafkan permainan kata-kata, di sprint.

Apa yang terjadi adalah, ketika kita berpikir tentang lincah, kita biasanya memikirkan pengembang dan bukan database dan apa pun yang berkaitan dengan dunia database. Itu adalah hasil yang disayangkan karena kenyataannya adalah gesit tidak terbatas pada pengembang. Bahkan, istilah lincah dalam pandangan saya sering salah dikaitkan secara eksklusif dengan pengembang perangkat lunak dan bukan perancang basis data dan arsitek. Selalu tantangan yang sama yang Anda hadapi dalam pengembangan perangkat lunak dan aplikasi dihadapi dalam semua hal yang berkaitan dengan desain dan pengembangan dan operasi dan pemeliharaan dan oleh karena itu infrastruktur data dan terutama database. Aktor-aktor dalam pemeran data khusus ini termasuk orang-orang seperti arsitek data, pembuat cetakan, administrator, manajer infrastruktur basis data dan database aktual sendiri sepanjang jalan hingga analis bisnis dan sistem dan arsitek, orang-orang yang duduk dan berpikir tentang bagaimana sistemnya dan bisnis beroperasi dan bagaimana kami dapat mengalirkan data melalui ini.

Ini adalah topik yang saya kemukakan secara terus-menerus karena ini adalah frustasi saya yang terus-menerus karena saya sangat berpandangan bahwa spesialis data harus - tidak harus - sekarang harus terlibat secara intim dalam setiap komponen pengiriman proyek, sungguh, terutama pengembangan. Bagi kita untuk tidak, maka kita benar-benar tidak memberi diri kita kesempatan terbaik untuk hasil yang baik. Kita sering harus berputar kembali dan memikirkan hal-hal ini karena ada skenario, kita sampai ke aplikasi yang sedang dibangun dan kita menemukan pengembang tidak selalu ahli data. Bekerja dengan basis data membutuhkan keterampilan yang sangat khusus, terutama seputar data, dan membangun pengalaman. Anda tidak hanya langsung menjadi guru basis data atau pakar pengetahuan data dalam semalam; ini sering kali merupakan sesuatu yang berasal dari pengalaman seumur hidup dan tentunya dengan orang-orang seperti Dr. Robin Bloor di Code Today, yang cukup kaya menulis buku itu.

Dalam banyak kasus - dan sangat disayangkan tetapi ini kenyataan - bahwa ada dua bagian dari koin ini, yaitu pengembang perangkat lunak memiliki pemadaman sendiri untuk spesialis basis data dan membangun keterampilan yang Anda butuhkan dalam pemodelan desain basis data, pengembangan model hanya menjadi dasar untuk rekayasa guru tentang bagaimana data masuk dan bagaimana pengorganisasian perjalanan yang dilakukan dan seperti apa seharusnya atau tidak seharusnya, atau tidak diragukan lagi bahwa tertelan dan memahami bahwa itu biasanya dalam keterampilan asli yang ditetapkan untuk pengembang perangkat lunak. Dan beberapa tantangan umum yang kita hadapi, hanya untuk menempatkannya dalam konteks, termasuk orang-orang seperti penciptaan dan pemeliharaan dasar dan manajemen desain basis data itu sendiri, mendokumentasikan data dan infrastruktur basis data dan kemudian menggunakan kembali aset data tersebut, desain skema, generasi skema, administrasi dan pemeliharaan skema dan penggunaannya, berbagi pengetahuan tentang mengapa skema ini dirancang dengan cara tertentu dan kekuatan dan kelemahan yang menyertainya dari waktu ke waktu menyebabkan perubahan data dari waktu ke waktu, pemodelan data dan jenisnya model yang kami terapkan pada sistem dan data yang kami mengalir melalui mereka. Pembuatan kode basis data dan berjalan pada integrasi dan kemudian memodelkan data di sekitar mereka dan kemudian lebih cepat mengakses untuk mengontrol keamanan di sekitar data, integritas data kita memindahkan data sekitar saat kita mempertahankan integritasnya, apakah ada cukup metadata di sekitar itu, haruskah penjualan melihat semua catatan dalam tabel atau haruskah mereka hanya melihat alamat, nama depan, nama belakang yang mengirimkan barang kepada Anda di pos? Dan tentu saja tantangan terbesar dari semuanya adalah memodelkan platform basis data yang sepenuhnya merupakan percakapan yang berbeda.

Saya sangat berpandangan bahwa dengan semua ini dalam pikiran untuk membuat nirwana ini menjadi mungkin, sangat penting bahwa baik spesialis data dan pengembang memiliki alat yang sesuai dan bahwa alat-alat tersebut mampu pengiriman proyek yang berfokus pada tim, desain, pengembangan, dan pemeliharaan operasional yang berkelanjutan. Anda tahu, hal-hal seperti berkolaborasi lintas proyek antara pakar data dan pengembang perangkat lunak, satu titik kebenaran atau satu sumber kebenaran untuk semua hal seputar dokumentasi dari basis data itu sendiri, data, skema, dari mana catatan berasal, pemilik catatan tersebut . Saya pikir di zaman sekarang ini sangat penting, kita akan mendapatkan nirwana data ini sebagai raja, bahwa alat yang tepat harus ada di tempat karena tantangannya terlalu besar bagi kita untuk melakukannya secara manual, dan jika orang-orang pindah dan keluar dari satu organisasi, terlalu mudah bagi kita untuk tidak mengikuti proses atau metodologi yang sama dengan yang ditetapkan oleh satu orang yang baik dan tidak serta-merta mengalihkan keterampilan dan kemampuan itu ke depan.

Dengan mengingat hal itu, saya akan mengunjungi teman baik kami di IDERA dan mendengar tentang alat itu dan bagaimana alat itu menangani hal-hal ini.

Ron Huizenga: Terima kasih banyak dan terima kasih kepada Robin dan Dez untuk benar-benar mengatur panggung dengan baik, dan Anda akan melihat sedikit tumpang tindih dalam beberapa hal yang saya bicarakan. Tetapi mereka benar-benar telah menetapkan fondasi yang sangat kuat untuk beberapa konsep yang akan saya bicarakan dari perspektif pemodelan data. Dan banyak hal yang mereka katakan menggemakan pengalaman saya sendiri ketika saya adalah seorang konsultan yang bekerja dalam pemodelan data dan arsitektur data, bersama dengan tim - baik air terjun pada hari-hari awal dan berkembang menjadi produk yang lebih modern dengan proyek-proyek di mana kami menggunakan gesit metodologi untuk memberikan solusi.

Jadi apa yang akan saya bicarakan hari ini didasarkan pada pengalaman-pengalaman tersebut serta pandangan tentang alat-alat dan beberapa kemampuan dalam alat-alat yang kami gunakan untuk membantu kami sepanjang perjalanan itu. Apa yang akan saya bahas secara singkat adalah, saya tidak akan membahas banyak detail; kami hanya memiliki gambaran yang sangat bagus tentang apa itu. Saya akan membicarakannya dalam hal, apa itu model data dan apa artinya sebenarnya bagi kami? Dan bagaimana kita mengaktifkan konsep pemodel data tangkas dalam organisasi kita, dalam hal, bagaimana kita melibatkan pemodel data, apa partisipasi pemodel dan arsitek selama sprint, apa jenis kegiatan yang harus mereka lakukan., dan, sebagai latar belakang untuk itu, apa saja beberapa kemampuan alat pemodelan penting yang kami gunakan untuk benar-benar membantu membuat pekerjaan itu lebih mudah? Lalu saya akan membahas sedikit dan hanya berbicara sedikit tentang beberapa nilai bisnis dan manfaat dari melibatkan seorang pemodel data, atau cara saya sebenarnya akan menceritakan kisahnya adalah, masalah tidak memiliki pemodel data yang sepenuhnya terlibat dalam proyek dan saya akan menunjukkan kepada Anda bahwa berdasarkan pengalaman dan grafik cacat dari gambar sebelum dan sesudah proyek sebenarnya yang saya terlibat dengan beberapa tahun yang lalu. Dan kemudian kita akan meringkas beberapa poin lagi dan kemudian memiliki pertanyaan dan jawaban di samping itu.

Secara singkat, ER Studio adalah suite yang sangat kuat yang memiliki banyak komponen berbeda. Arsitek Data, yang merupakan tempat para pemodel data dan arsitek menghabiskan sebagian besar waktu mereka melakukan pemodelan data. Ada komponen lain juga yang tidak akan kita bicarakan sama sekali hari ini seperti Arsitek Bisnis, di mana kita melakukan pemodelan proses dan Arsitek Perangkat Lunak, untuk beberapa pemodelan UML. Lalu ada Repositori, tempat kami check in dan kami bagikan model-model itu dan kami mengizinkan tim untuk berkolaborasi dalam hal itu dan menerbitkannya ke server tim sehingga banyak audiensi pemangku kepentingan yang terlibat dalam suatu proyek dapat benar-benar melihat artefak yang kami miliki. menciptakan dari perspektif data serta hal-hal lain yang kami lakukan dalam pengiriman proyek itu sendiri.

Apa yang akan saya fokuskan hari ini adalah beberapa hal yang akan kita lihat dari Arsitek Data dan karena itu sangat penting bahwa kita memiliki kolaborasi aspek-aspek berbasis Repositori itu. Terutama ketika kita mulai berbicara tentang konsep-konsep seperti manajemen perubahan yang sangat penting untuk, tidak hanya proyek-proyek pembangunan tangkas, tetapi semua jenis pembangunan akan maju.

Jadi mari kita bicara tentang Agile Data Modeler sejenak. Seperti yang telah kita singgung sebelumnya dalam presentasi, adalah penting bahwa kita memiliki pemodel data dan / atau arsitek yang sepenuhnya terlibat dalam proses pengembangan tangkas. Sekarang, apa yang terjadi secara historis adalah, ya, kami benar-benar berpikir tentang lincah dari perspektif pembangunan, dan ada beberapa hal yang telah terjadi yang benar-benar menyebabkan hal itu terjadi. Sebagian darinya adalah karena sifat dari cara pembangunan itu sendiri dibuka. Ketika pengembangan tangkas dimulai dan kami mulai dengan konsep tim yang mengatur diri sendiri ini, jika Anda minum Kool-Aid sedikit terlalu murni dan Anda berada di sisi pemrograman yang ekstrem, ada interpretasi yang sangat literal mengenai hal-hal seperti tim yang mengatur diri sendiri, yang diartikan oleh banyak orang, yang kita butuhkan adalah sekelompok pengembang yang dapat membangun seluruh solusi. Apakah itu berarti mengembangkan kode, database atau datastore di belakangnya dan semuanya diserahkan kepada pengembang. Tetapi yang terjadi dengan itu adalah Anda kehilangan kemampuan khusus yang dimiliki orang. Saya telah menemukan bahwa tim terkuat adalah mereka yang terdiri dari orang-orang dari latar belakang yang berbeda. Seperti kombinasi dari pengembang perangkat lunak yang kuat, arsitek data, pemodel data, analis bisnis, dan pemangku kepentingan bisnis, semuanya bekerja sama untuk mengusir solusi akhir.

Apa yang saya bicarakan hari ini adalah, saya akan melakukan ini dalam konteks proyek pengembangan di mana kami sedang mengembangkan aplikasi yang jelas akan memiliki komponen data yang terkait dengannya juga. Kita perlu mengambil langkah mundur sebelum kita melakukannya, karena kita perlu menyadari bahwa ada sangat sedikit proyek pengembangan Greenfield di luar sana di mana kita memiliki total fokus pada penciptaan dan konsumsi data yang terbatas hanya dalam proyek pengembangan itu sendiri . Kita perlu mengambil langkah mundur dan melihat keseluruhan sudut pandang organisasi dari perspektif data dan perspektif proses. Karena yang kami temukan adalah informasi yang kami gunakan mungkin sudah ada di suatu tempat di organisasi. Sebagai pemodel dan arsitek, kami mengungkapnya sehingga kami tahu dari mana sumber informasi itu berasal dari proyek itu sendiri. Kami juga tahu struktur data yang terlibat karena kami memiliki pola desain seperti halnya pengembang memiliki pola desain untuk kode mereka. Dan kita juga perlu mengambil perspektif organisasi secara keseluruhan. Kami tidak bisa hanya melihat data dalam konteks aplikasi yang kami bangun. Kita perlu memodelkan data dan memastikan bahwa kita mendokumentasikannya karena itu hidup lama di luar aplikasi itu sendiri. Aplikasi itu datang dan pergi, tetapi kita harus dapat melihat data dan memastikan itu kuat dan terstruktur dengan baik, tidak hanya untuk aplikasi, tetapi juga untuk keputusan yang melaporkan kegiatan, pelaporan BI dan integrasi ke aplikasi lain, internal dan di luar organisasi kami juga. Jadi kita perlu melihat keseluruhan gambaran besar data dan apa siklus hidup data itu dan memahami perjalanan potongan informasi di seluruh organisasi dari buaian ke liang kubur.

Sekarang kembali ke tim yang sebenarnya dan bagaimana kita sebenarnya perlu bekerja adalah, metodologi air terjun dianggap terlalu lambat untuk memberikan hasil. Karena, sebagaimana ditunjukkan dengan contoh tangki, itu adalah langkah demi langkah dan sering kali terlalu lama untuk memberikan hasil akhir yang bisa diterapkan. Apa yang kita lakukan sekarang adalah kita perlu memiliki gaya kerja berulang di mana kita secara bertahap mengembangkan komponen itu dan menguraikannya melalui waktu di mana kita menghasilkan kode yang dapat digunakan atau artefak yang dapat digunakan, saya akan mengatakan, untuk setiap sprint. Yang penting adalah kolaborasi di antara para pemangku kepentingan teknis dalam tim dan para pemangku kepentingan bisnis saat kami berkolaborasi untuk mendorong kisah-kisah pengguna ke dalam visi kode yang dapat diterapkan dan data yang mendukung kode itu juga. Dan Agile Data Modeler itu sendiri akan sering menemukan bahwa kita tidak memiliki cukup pemodel dalam organisasi sehingga satu pemodel data atau arsitek dapat secara bersamaan mendukung banyak tim.

Dan aspek lain dari itu adalah, bahkan jika kita memang memiliki banyak pemodel, kita perlu memastikan bahwa kita memiliki seperangkat alat yang kita gunakan yang memungkinkan kolaborasi beberapa proyek yang sedang terbang pada saat yang sama dan berbagi dari mereka artefak data dan kemampuan check-in dan check-out. Saya akan membahas ini dengan sangat cepat karena kita sudah membahasnya di bagian sebelumnya. Premis nyata dari gesit adalah bahwa Anda mendasarkan hal-hal dari tumpukan, cerita atau persyaratan. Dalam iterasi kami berkolaborasi sebagai grup. Biasanya sprint dua minggu atau satu bulan, tergantung pada organisasi, sangat umum. Dan juga ulasan harian dan pertemuan standup sehingga kita menghilangkan blocker dan memastikan bahwa kita memajukan semua aspek tanpa terhenti di area yang berbeda saat kita melewati. Dan dalam sprint tersebut kami ingin memastikan bahwa kami memproduksi kiriman yang dapat digunakan sebagai bagian dari setiap sprint.

Hanya sedikit berbeda pendapat tentang itu, memperluasnya lebih jauh, scrum adalah metodologi yang akan saya bicarakan lebih spesifik di sini dan kami pada dasarnya telah menambah gambar sebelumnya dengan beberapa aspek lainnya. Biasanya ada backlog produk dan kemudian ada sprint backlog. Jadi kami memiliki tumpukan keseluruhan yang, pada awal setiap sprint yang berulang, kami berkata, “Apa yang akan kita lakukan untuk membangun sprint ini?” Dan itu dilakukan dalam pertemuan perencanaan sprint. Kemudian kami memecah tugas-tugas yang terkait dengan itu dan kami mengeksekusi dalam sprint satu hingga empat minggu dengan ulasan harian tersebut. Saat kita melakukan itu, kita melacak kemajuan kita melalui grafik burn-up dan burn-down chart untuk melacak apa yang tersisa untuk dibangun versus apa yang kita bangun untuk membangun hal-hal seperti apa kecepatan perkembangan kita, apakah kita akan membuat kita jadwal, semua jenis hal itu. Semua itu dielaborasi terus-menerus selama sprint daripada berjalan beberapa bulan dan mengetahui bahwa Anda akan kekurangan dan Anda perlu memperpanjang jadwal proyek. Dan sangat penting, sebagai bagian dari itu, seluruh tim, ada ulasan sprint di akhir dan sprint retrospektif, jadi sebelum Anda memulai iterasi berikutnya Anda meninjau apa yang Anda lakukan dan Anda sedang mencari cara yang Anda bisa meningkatkan pada waktu berikutnya.

Dalam hal kiriman, ini pada dasarnya adalah slide yang merangkum jenis-jenis hal yang terjadi dalam sprint. Dan ini sangat pengembangan-sentris, jadi banyak hal yang kita lihat di sini, seperti, desain fungsional dan kasus penggunaan, melakukan tes kode desain, ketika kita melihat kotak-kotak ini di sini, dan saya tidak akan membahasnya dalam tingkat detail apa pun, mereka sangat berorientasi pengembangan. Dan terkubur di bawah sini adalah fakta bahwa kita juga perlu memiliki kiriman data yang sejalan dengan ini untuk mendukung upaya ini. Jadi setiap kali kita melihat hal-hal seperti simpanan, persyaratan, dan kisah pengguna, seperti yang kita alami, kita perlu melihat apa saja bagian pengembangan yang harus kita lakukan, apa potongan analisis yang perlu kita lakukan, bagaimana dengan desain data atau model data, bagaimana dengan hal-hal seperti glosarium bisnis sehingga kita dapat mengaitkan makna bisnis dengan semua artefak yang kami produksi? Karena kita perlu menghasilkan hasil yang dapat digunakan di setiap sprint.

Beberapa orang akan mengatakan kita perlu menghasilkan kode yang dapat digunakan di akhir setiap sprint. Itu belum tentu demikian, yaitu dalam perspektif pengembangan yang paling murni, tetapi cukup sering - terutama di awal - kita mungkin memiliki sesuatu seperti sprint nol di mana kita fokus murni pada hal-hal berdiri, melakukan hal-hal seperti mendapatkan strategi pengujian kami di tempat. Desain tingkat tinggi untuk memulainya sebelum kita mulai mengisi detail dan memastikan bahwa kita memiliki kumpulan cerita atau persyaratan awal yang bersih sebelum kita mulai melibatkan audiens lain dan kemudian membangun maju sebagai tim saat kita melangkah maju. Selalu ada sedikit waktu persiapan, jadi cukup sering kita akan memiliki sprint nol atau bahkan sprint nol dan satu. Mungkin sedikit fase startup sebelum kita mencapai penerbangan penuh dalam memberikan solusi.

Mari kita bicara tentang model data dalam konteks ini dengan sangat singkat. Ketika orang berpikir tentang model data, mereka sering menganggap model data sebagai gambaran tentang bagaimana berbagai informasi yang saling terkait - itu hanya puncak gunung es. Untuk sepenuhnya mewujudkan semangat bagaimana Anda benar-benar ingin melakukan pendekatan pemodelan data - apakah itu dalam pengembangan lincah dan hal-hal lain - adalah Anda perlu menyadari bahwa model data, jika dilakukan dengan benar, menjadi spesifikasi lengkap Anda untuk arti data dalam organisasi dan bagaimana itu digunakan di database back-end. Ketika saya mengatakan database, maksud saya bukan hanya database relasional yang mungkin kita gunakan, tetapi dalam arsitektur saat ini di mana kita memiliki data besar atau platform NoSQL, seperti yang saya lebih suka menyebutnya. Juga penyimpanan data besar itu karena kami mungkin menggabungkan banyak penyimpanan data yang berbeda dalam hal mengonsumsi informasi dan membawanya ke solusi kami serta bagaimana kami bertahan atau menyimpan informasi itu dari solusi kami juga.

Kami mungkin bekerja dengan banyak basis data atau sumber data secara bersamaan dalam konteks aplikasi yang diberikan. Apa yang sangat penting adalah kita ingin dapat memiliki spesifikasi lengkap, jadi spesifikasi logis tentang apa artinya ini bagi perspektif organisasi sprint, apa konstruksi fisik dalam hal bagaimana kita benar-benar mendefinisikan data, hubungan antara itu dalam basis data Anda, batasan integritas referensial Anda, batasan periksa, semua potongan validasi yang biasanya Anda pikirkan. Metadata deskriptif sangat penting. Bagaimana Anda tahu cara memanfaatkan data dalam aplikasi Anda? Kecuali Anda dapat mendefinisikannya dan tahu artinya atau tahu dari mana asalnya untuk memastikan Anda menggunakan data yang benar dalam aplikasi tersebut - memastikan bahwa kami memiliki konvensi penamaan yang benar, definisi penuh, yang berarti kamus data lengkap untuk tidak hanya tabel tetapi kolom yang terdiri dari tabel tersebut - dan detail catatan penggunaan tentang bagaimana kita memanfaatkannya karena kita perlu membangun basis pengetahuan ini karena bahkan ketika aplikasi ini selesai, informasi ini akan digunakan untuk inisiatif lain sehingga kita perlu memastikan bahwa kita memiliki semua yang didokumentasikan untuk implementasi di masa depan.

Sekali lagi, kita membahas hal-hal seperti tipe data, kunci, indeks, model data itu sendiri mencakup banyak aturan bisnis yang ikut bermain. Hubungan bukan hanya kendala antara tabel yang berbeda; mereka sering membantu kita untuk menggambarkan apa aturan bisnis yang sebenarnya di sekitar bagaimana data itu berperilaku dan bagaimana ia bekerja bersama sebagai unit kohesif. Dan tentu saja, batasan nilai sangat penting. Sekarang tentu saja, salah satu hal yang terus-menerus kita hadapi, dan semakin lazim, adalah hal-hal seperti tata kelola data. Jadi dari perspektif tata kelola data, kita juga perlu melihat, apa yang kita definisikan di sini? Kami ingin mendefinisikan hal-hal seperti klasifikasi keamanan. Jenis data apa yang kita hadapi? Apa yang akan dianggap sebagai manajemen data master? Apa toko transaksional yang kami buat? Data referensi apa yang kami gunakan dalam aplikasi ini? Kita perlu memastikan bahwa itu ditangkap dengan baik dalam model kita. Dan juga pertimbangan kualitas data, ada beberapa informasi tertentu yang lebih penting bagi organisasi daripada yang lain.

Saya telah terlibat dalam proyek-proyek di mana kami mengganti lebih dari selusin sistem lama dengan proses bisnis baru dan merancang aplikasi dan penyimpanan data baru untuk menggantikannya. Kami perlu tahu dari mana informasi itu berasal. Yang mana untuk bagian informasi yang paling penting, dari perspektif bisnis, jika Anda melihat slide model data tertentu yang saya dapatkan di sini, Anda akan melihat bahwa kotak-kotak terbawah dalam entitas-entitas khusus ini, yang hanya sebagian kecil, Sebenarnya sudah bisa menangkap nilai bisnis. Baik tinggi, sedang atau rendah untuk hal-hal seperti ini untuk konstruksi berbeda di dalam organisasi. Dan saya juga telah menangkap hal-hal seperti kelas data master, apakah mereka tabel master, apakah mereka referensi, jika mereka transaksional. Jadi kami dapat memperluas metadata kami dalam model kami untuk memberi kami banyak karakteristik lain di luar data itu sendiri, yang benar-benar membantu kami dengan inisiatif lain di luar proyek asli dan meneruskannya. Sekarang banyak sekali dalam satu slide, saya akan membahas sisanya dengan cukup cepat.

Saya sekarang akan berbicara dengan sangat cepat tentang apa yang dilakukan oleh seorang pemodel data ketika kita akan melalui berbagai sprint ini. Pertama-tama, peserta penuh dalam sesi perencanaan sprint, di mana kami mengambil cerita pengguna, berkomitmen pada apa yang akan kami sampaikan dalam sprint itu, dan mencari tahu bagaimana kami akan menyusunnya dan menyampaikannya. Apa yang saya juga lakukan sebagai pemodel data adalah saya tahu saya akan bekerja di area yang terpisah dengan pengembang yang berbeda atau dengan orang yang berbeda. Jadi salah satu karakteristik penting yang dapat kita miliki adalah ketika kita melakukan model data, kita dapat membagi model data itu menjadi tampilan yang berbeda, apakah Anda menyebutnya area subjek atau sub-model, adalah terminologi kami. Jadi saat kita membangun model kita juga menunjukkannya dalam perspektif sub-model yang berbeda ini sehingga audiens yang berbeda hanya melihat apa yang relevan bagi mereka sehingga mereka dapat berkonsentrasi pada apa yang mereka kembangkan dan kembangkan. Jadi saya mungkin memiliki seseorang yang bekerja pada bagian penjadwalan aplikasi, saya mungkin memiliki orang lain yang mengerjakan entri pesanan di mana kita melakukan semua hal ini dalam satu sprint, tapi saya bisa memberi mereka sudut pandang melalui sub-model yang hanya berlaku untuk area yang mereka kerjakan. Dan kemudian mereka menggulung ke model keseluruhan dan seluruh struktur sub-model untuk memberikan pandangan audiens yang berbeda apa yang perlu mereka lihat.

Dasar-dasar dari perspektif pemodelan data yang ingin kita miliki adalah, selalu memiliki garis dasar yang dapat kita kembalikan karena salah satu hal yang perlu kita lakukan adalah, apakah itu di akhir sprint atau di akhir dari beberapa sprint, kami ingin tahu di mana kami memulai dan selalu memiliki garis dasar untuk mengetahui apa itu delta atau perbedaan dari apa yang kami hasilkan dalam sprint yang diberikan. Kita juga perlu memastikan bahwa kita dapat memiliki perputaran cepat. Jika Anda menjadikannya sebagai pemodel data tetapi dalam peran penjaga gerbang tradisional mengatakan "Tidak, tidak, Anda tidak dapat melakukan itu, kami harus melakukan semua hal ini terlebih dahulu, " Anda akan dikeluarkan dari tim saat Anda benar-benar membutuhkannya. untuk menjadi peserta aktif dalam semua tim pengembangan tangkas. Itu berarti beberapa hal jatuh dari kereta melakukan sprint yang diberikan dan Anda mengambilnya di sprint kemudian.

Sebagai contoh, Anda dapat fokus pada struktur data hanya untuk mendapatkan perkembangan katakanlah, bahwa entri entri urutan yang saya bicarakan. Dalam sprint nanti, Anda dapat kembali dan mengisi data seperti beberapa dokumentasi untuk kamus data di sekitar beberapa artefak yang telah Anda buat. Anda tidak akan menyelesaikan definisi itu dalam satu sprint; Anda akan terus mengerjakan kiriman Anda secara bertahap karena akan ada saatnya Anda dapat mengisi informasi tersebut bekerja dengan analis bisnis ketika pengembang sibuk membangun aplikasi dan kegigihan di sekitar penyimpanan data tersebut. Anda ingin memfasilitasi dan tidak menjadi hambatan. Ada berbagai cara kami bekerja dengan pengembang. Untuk beberapa hal kami memiliki pola desain sehingga kami adalah peserta penuh di muka, jadi kami mungkin memiliki pola desain di mana kami akan mengatakan kami akan memasukkannya ke dalam model, kami akan mendorongnya ke database kotak pasir pengembang dan kemudian mereka dapat mulai bekerja dengannya dan minta perubahan itu.

Mungkin ada area lain yang telah dikerjakan pengembang, mereka telah mendapatkan sesuatu yang sedang mereka kerjakan dan mereka membuat prototipe beberapa hal sehingga mereka mencoba beberapa hal di lingkungan pengembangan mereka sendiri. Kami mengambil basis data yang telah mereka kerjakan, membawanya ke alat pemodelan kami, dibandingkan dengan model yang kami miliki dan kemudian menyelesaikan dan mendorong perubahan kembali kepada mereka sehingga mereka dapat memperbaiki kode mereka sehingga mereka mengikuti struktur data yang tepat yang kita butuhkan. Karena mereka mungkin telah menciptakan beberapa hal yang sudah kami miliki di tempat lain, jadi kami memastikan mereka bekerja dengan sumber data yang tepat. Kami terus mengulangi semua jalan melalui ini ke sprint kami sehingga kami mendapatkan kiriman data lengkap, dokumentasi lengkap dan definisi dari semua struktur data yang kami produksi.

Proyek tangkas yang paling sukses yang pernah saya lakukan dalam hal pengiriman yang sangat baik adalah, kami memiliki filosofi, memodelkan semua perubahan pada spesifikasi basis data fisik lengkap. Pada dasarnya, model data menjadi basis data yang digunakan yang Anda kerjakan untuk hal-hal baru yang kami buat dan memiliki referensi lengkap dari penyimpanan data lain jika kami mengkonsumsi dari basis data luar lainnya. Sebagai bagian dari itu kami memproduksi skrip inkremental dibandingkan melakukan generasi penuh setiap saat. Dan kami menggunakan pola desain kami untuk memberi kami tumpangan cepat dalam hal membuat sprint dengan berbagai tim pengembangan yang kami bekerja sama.

Dalam kegiatan sprint juga, sekali lagi bahwa garis dasar untuk perbandingan / penggabungan, jadi mari kita ambil ide pemodelan setiap perubahan. Setiap kali kita melakukan perubahan, apa yang ingin kita lakukan adalah kita ingin memodelkan perubahan dan apa yang sangat penting, apa yang telah hilang dari pemodelan data hingga saat ini, pada kenyataannya, sampai kita diperkenalkan kembali, adalah kemampuan untuk mengasosiasikan pemodelan tugas dan hasil Anda dengan cerita pengguna dan tugas yang sebenarnya menyebabkan perubahan itu terjadi. Kami ingin dapat memeriksa perubahan model kami, dengan cara yang sama pengembang memeriksa kode mereka, merujuk cerita pengguna yang kami miliki sehingga kami tahu mengapa kami membuat perubahan sejak awal, itu adalah sesuatu yang kami lakukan. Ketika kami melakukan itu, kami membuat skrip DDL tambahan kami dan mempostingnya sehingga mereka dapat diambil dengan hasil pengembangan lainnya dan diperiksa ke dalam solusi build kami. Sekali lagi, kami mungkin memiliki satu model atau bekerja dengan banyak tim. Dan seperti yang saya bicarakan, beberapa hal berasal dari pemodel data, hal lain berasal dari pengembang dan kami bertemu di tengah untuk menghasilkan desain terbaik secara keseluruhan dan mendorongnya ke depan dan memastikan itu dirancang dengan benar di struktur data keseluruhan. Kita harus menjaga disiplin memastikan bahwa kita memiliki semua konstruksi yang tepat dalam model data kita saat kita melangkah maju, termasuk hal-hal seperti nilai nol dan bukan nol, batasan referensi, pada dasarnya memeriksa batasan, semua hal yang biasanya kita pikirkan .

Mari kita bicarakan sekarang hanya beberapa tangkapan layar dari beberapa alat yang membantu kita melakukan ini. Apa yang saya pikir penting adalah memiliki repositori kolaboratif itu, jadi apa yang bisa kita lakukan sebagai pemodel data - dan ini adalah potongan dari bagian dari model data di latar belakang - adalah ketika kita mengerjakan hal-hal yang ingin kita pastikan bahwa kita bisa bekerja hanya pada objek yang kita butuhkan untuk dapat mengubah, membuat modifikasi, membuat skrip DDL untuk perubahan yang telah kita buat saat kita memeriksa kembali. Jadi yang bisa kita lakukan adalah, di ER Studio adalah contoh, kita dapat memeriksa objek atau kelompok objek untuk dikerjakan, kita tidak perlu memeriksa keseluruhan model atau sub-model, kita dapat memeriksa hanya hal-hal yang menarik bagi kita. Apa yang kami inginkan setelah itu adalah waktu check-out atau check-in - kami melakukan keduanya karena tim pengembangan yang berbeda bekerja dengan cara yang berbeda. Kami ingin memastikan bahwa kami mengaitkannya dengan cerita pengguna atau tugas yang mendorong persyaratan untuk ini dan itu akan menjadi cerita pengguna yang sama atau tugas yang akan dikembangkan oleh pengembang dan memeriksa kode mereka.

Jadi, inilah cuplikan singkat beberapa layar dari salah satu pusat manajemen perubahan kami. Apa yang dilakukan, saya tidak akan membahas secara rinci di sini, tetapi apa yang Anda lihat adalah kisah pengguna atau tugas dan menjorok ke bawah masing-masing orang yang Anda lihat catatan perubahan yang sebenarnya - kami telah membuat catatan perubahan otomatis saat kami melakukan check-in dan check-out dan kami dapat memberikan deskripsi lebih lanjut tentang catatan perubahan itu juga. Ini terkait dengan tugas, kami dapat memiliki beberapa perubahan per tugas, seperti yang Anda harapkan. Dan ketika kita masuk ke catatan perubahan itu kita bisa melihatnya dan yang lebih penting lihat, apa yang sebenarnya kita ubah? Untuk yang khusus ini, cerita yang disoroti di sana saya memiliki satu jenis perubahan yang dibuat dan ketika saya melihat catatan perubahan itu sendiri, itu telah mengidentifikasi potongan individu dalam model yang telah berubah. Saya mengubah beberapa atribut di sini, menyesuaikan mereka dan membawanya untuk perjalanan pandangan yang perlu diubah yang tergantung pada mereka juga sehingga mereka akan dihasilkan dalam DLL tambahan. Tidak hanya pemodelan pada objek dasar, tetapi alat pemodelan berdaya tinggi seperti ini juga mendeteksi perubahan yang harus diubah melalui objek dependen dalam database atau model data juga.

Jika kami bekerja dengan pengembang, dan kami melakukan ini dalam beberapa hal yang berbeda, yaitu melakukan sesuatu di kotak pasir mereka dan kami ingin membandingkan dan melihat di mana perbedaannya, kami menggunakan kemampuan bandingkan / gabungkan di mana di sisi kanan dan kiri sisi. Kita dapat mengatakan, "Ini model kami di sisi kiri, ini database mereka di sebelah kanan, tunjukkan perbedaannya." Kita kemudian bisa memilih bagaimana kita menyelesaikan perbedaan itu, apakah kita memasukkan sesuatu ke dalam basis data atau jika ada beberapa hal yang mereka miliki dalam database yang kami bawa kembali ke dalam model. Kita bisa pergi dua arah sehingga kita bisa pergi ke dua arah secara bersamaan memperbarui sumber dan target dan kemudian menghasilkan skrip DDL tambahan untuk menyebarkan perubahan itu ke lingkungan basis data itu sendiri, yang sangat penting. Apa yang juga bisa kita lakukan adalah kita juga dapat menggunakan kemampuan membandingkan dan menggabungkan ini pada waktu tertentu, jika kita mengambil snapshot dalam perjalanan, kita selalu dapat membandingkan awal dari satu sprint untuk memulai atau mengakhiri sprint lain sehingga kita dapat melihat perubahan tambahan penuh dari apa yang dilakukan dalam sprint pengembangan yang diberikan atau lebih dari serangkaian sprint.

Ini adalah contoh yang sangat cepat dari skrip alter, siapa pun dari Anda yang telah bekerja dengan database akan melihat hal semacam ini, ini adalah apa yang bisa kita dorong keluar dari kode sebagai skrip alter sehingga kami memastikan bahwa kami simpan barang-barang di sini. Apa yang saya tarik keluar dari sini, hanya untuk mengurangi kekacauan, adalah apa yang juga kami lakukan dengan skrip alter ini adalah kami mengasumsikan ada data dalam tabel tersebut juga, jadi kami juga akan menghasilkan DML yang akan menarik informasi dari tabel sementara dan dorong kembali ke struktur data baru juga sehingga kami melihat tidak hanya struktur tetapi data yang mungkin sudah kami miliki di struktur itu juga.

Pergi untuk berbicara dengan sangat cepat tentang sistem build otomatis karena ketika kita melakukan proyek agile cukup sering kita bekerja dengan sistem build otomatis di mana kita perlu memeriksa dalam pengiriman yang berbeda bersama-sama untuk memastikan bahwa kita tidak merusak build kita. Apa artinya itu adalah kita mensinkronkan kiriman, skrip perubahan yang saya bicarakan dengan skrip DDL perlu diperiksa, kode aplikasi yang sesuai harus diperiksa pada saat yang sama dan banyak pengembangan pengembang sekarang tentu saja tidak sedang dilakukan dengan SQL langsung terhadap database dan hal semacam itu. Cukup sering kita menggunakan kerangka kerja ketekunan atau membangun layanan data. Kita perlu memastikan bahwa perubahan untuk kerangka kerja atau layanan tersebut diperiksa pada waktu yang bersamaan. Mereka masuk ke sistem build otomatis di beberapa organisasi dan jika build rusak, dalam metodologi lincah, itu semua tangan di dek perbaikan yang membangun sebelum kita bergerak maju sehingga kita tahu bahwa kita memiliki solusi yang berfungsi sebelum kita melangkah lebih jauh. Dan salah satu proyek yang saya terlibat, kami mengambil ini ke ekstrim - jika membangun pecah kami benar-benar telah terpasang ke sejumlah komputer di daerah kami di mana kami bekerja sama dengan pengguna bisnis, kami memiliki lampu berkedip merah hanya seperti bagian atas mobil polisi. Dan jika bangunannya rusak, lampu merah yang menyala itu mulai padam dan kami tahu semuanya ada di tangan: perbaiki bangunannya lalu lanjutkan dengan apa yang kami lakukan.

Saya ingin berbicara tentang hal-hal lain, dan ini adalah kemampuan unik untuk ER Studio, sangat membantu ketika kami mencoba membangun artefak ini sebagai pengembang untuk batas-batas kegigihan ini, kami memiliki konsep yang disebut objek data bisnis dan apa yang memungkinkan kami untuk lakukan adalah jika Anda melihat model data yang sangat sederhana ini sebagai contoh, ini memungkinkan kami untuk merangkum entitas atau kelompok entitas di mana batas-batas kegigihan berada. Di mana kita sebagai pemodel data mungkin memikirkan sesuatu seperti tajuk pesanan pembelian dan perataan pesanan serta tabel terperinci lainnya yang akan menyatu dengan cara kami membangunnya dan pengembang layanan data kami perlu tahu bagaimana hal-hal bertahan pada data yang berbeda struktur. Pengembang kami memikirkan hal-hal seperti pesanan pembelian sebagai objek secara keseluruhan dan apa kontrak mereka dengan cara mereka membuat objek tertentu. Kami dapat mengekspos detail teknis tersebut sehingga orang yang membangun server data dapat melihat apa yang ada di bawahnya dan kami dapat melindungi audiens lain dari kerumitan sehingga mereka hanya melihat objek tingkat tinggi yang berbeda, yang juga bekerja dengan sangat baik untuk berkomunikasi dengan bisnis. analis dan pemangku kepentingan bisnis ketika kita berbicara tentang interaksi berbagai konsep bisnis juga.

Hal yang menyenangkan tentang itu juga adalah kita secara konstruktif memperluas dan menciutkan ini sehingga kita dapat menjaga hubungan antara objek tingkat tinggi meskipun mereka berasal dari konstruksi yang terkandung dalam objek data bisnis itu sendiri. Sekarang sebagai seorang modeler, sampai di ujung sprint, di akhir sprint, saya memiliki banyak hal yang perlu saya lakukan, yang saya sebut rumah tangga saya untuk sprint berikutnya. Setiap sprint saya membuat apa yang saya sebut Rilis Bernama - yang memberi saya garis dasar untuk apa yang sekarang saya miliki di akhir rilis. Jadi itu berarti bahwa baseline saya akan maju, semua baseline ini atau Named Releases yang saya buat dan simpan dalam repositori saya dapat saya gunakan untuk melakukan perbandingan / penggabungan sehingga saya selalu dapat membandingkan dengan ujung sprint yang diberikan dari sprint lain, yang sangat penting untuk mengetahui perubahan apa yang Anda lakukan terhadap model data Anda dalam perjalanannya.

Saya juga membuat skrip delta DDL menggunakan bandingkan / gabungkan lagi dari awal hingga akhir sprint. Saya mungkin telah memeriksa sejumlah skrip tambahan, tetapi jika saya membutuhkannya, saya sekarang memiliki skrip yang dapat saya gunakan untuk berdiri di kotak pasir lain sehingga saya bisa mengatakan ini adalah apa yang kami miliki di awal sprint, tekan itu melalui, membangun database sebagai kotak pasir untuk memulai dengan sprint berikutnya dan kami juga dapat menggunakan hal-hal itu untuk melakukan hal-hal seperti contoh QA standup dan akhirnya tentu saja kami ingin mendorong perubahan kami ke produksi sehingga kami memiliki beberapa hal yang terjadi pada waktu bersamaan. Sekali lagi, kami sepenuhnya berpartisipasi dalam perencanaan sprint dan retrospektif, retrospektif benar-benar pelajaran yang dipetik dan itu sangat penting, karena Anda bisa berjalan sangat cepat selama gesit, Anda perlu berhenti dan merayakan keberhasilan, seperti sekarang. Cari tahu apa yang salah, perbaiki yang lebih baik di waktu berikutnya, tetapi juga rayakan hal-hal yang berjalan dengan benar dan bangunlah saat Anda terus bergerak maju dalam sprint berikutnya ke depan.

Saya sekarang akan berbicara dengan sangat cepat tentang nilai bisnis. Ada sebuah proyek yang saya libatkan bertahun-tahun yang lalu yang dimulai sebagai proyek yang gesit, dan itu adalah proyek yang ekstrem, jadi itu adalah tim yang mengatur diri sendiri dengan murni di mana hanya para pengembang yang melakukan semuanya. Singkatnya, proyek ini macet dan mereka mendapati mereka menghabiskan lebih banyak waktu untuk memperbaiki dan memperbaiki cacat yang diidentifikasi daripada mendorong lebih banyak fungsi dan, pada kenyataannya, ketika mereka melihatnya berdasarkan pada grafik burn-down mereka harus memperpanjang proyek enam bulan dengan biaya besar. Dan ketika kami melihatnya, cara untuk memulihkan masalah adalah dengan menggunakan alat pemodelan data yang tepat dengan pemodel data yang terampil yang terlibat dalam proyek itu sendiri.

Jika Anda melihat bilah vertikal ini pada bagan khusus ini, ini menunjukkan cacat kumulatif versus objek kumulatif, dan saya berbicara tentang objek data atau konstruksi yang dibuat seperti tabel dengan batasan dan jenis-jenis hal, jika Anda melihat sebelum pemodel data diperkenalkan, jumlah cacat sebenarnya melebihi dan mulai membangun sedikit celah atas jumlah sebenarnya objek yang diproduksi hingga titik waktu. Setelah minggu 21, saat itulah pemodel data masuk, refactored model data berdasarkan apa yang ada untuk memperbaiki sejumlah hal dan kemudian mulai pemodelan sebagai bagian dari tim proyek ke depan, perubahan saat proyek itu didorong ke depan . Dan Anda melihat perputaran yang sangat cepat bahwa dalam waktu sekitar satu setengah berlari, kami melihat peningkatan besar dalam jumlah objek dan konstruk data yang dihasilkan dan dikonstruksi karena kami menghasilkan alat pemodelan data daripada tongkat pengembang. membangun mereka di lingkungan, dan mereka benar karena mereka memiliki integritas referensial yang tepat dan konstruksi lain yang seharusnya. Tingkat cacat terhadap mereka yang hampir rata. Dengan mengambil tindakan yang sesuai dan memastikan bahwa pemodelan data terlibat penuh, proyek disampaikan tepat waktu dengan tingkat kualitas yang jauh lebih tinggi, dan pada kenyataannya, itu tidak akan disampaikan sama sekali jika langkah-langkah itu tidak terjadi. Ada banyak kegagalan lincah di luar sana, ada juga banyak keberhasilan lincah jika Anda akan mendapatkan orang yang tepat dalam peran yang tepat terlibat. Saya seorang pendukung besar tangkas sebagai disiplin operasional, tetapi Anda perlu memastikan bahwa Anda memiliki keterampilan dari semua kelompok yang tepat terlibat sebagai tim proyek Anda saat Anda maju pada jenis usaha tangkas.

Untuk meringkas, arsitek data dan pemodel harus terlibat dalam semua proyek pembangunan; mereka benar-benar adalah lem yang menyatukan semuanya karena sebagai pemodel data dan arsitek kita memahami, tidak hanya data konstruksi dari proyek pengembangan yang diberikan, tetapi juga di mana data ada dalam organisasi dan di mana kita dapat sumber data itu dari dan juga bagaimana itu akan digunakan dan digunakan di luar aplikasi tertentu itu sendiri yang sedang kami kerjakan. Kami memahami hubungan data yang kompleks dan sangat penting untuk dapat bergerak maju dan juga dari perspektif tata kelola untuk memetakan dokumen dan memahami seperti apa lanskap data lengkap Anda.

Ini seperti manufaktur; Saya berasal dari latar belakang manufaktur. Anda tidak dapat memeriksa kualitas menjadi sesuatu pada akhirnya - Anda perlu membangun kualitas ke dalam desain Anda di muka dan dalam perjalanan Anda, dan pemodelan data adalah cara membangun kualitas ke dalam desain dengan cara yang efisien dan hemat biaya sepanjang jalan melalui . Dan lagi, sesuatu yang perlu diingat - dan ini bukan untuk basi, tetapi itu adalah kebenaran - aplikasi datang dan pergi, data adalah aset perusahaan yang vital dan melampaui semua batas aplikasi. Setiap kali Anda memasukkan aplikasi Anda mungkin diminta untuk menyimpan data dari aplikasi lain yang datang sebelumnya, jadi kami hanya perlu mengingat bahwa itu adalah aset perusahaan yang sangat penting yang kami pertahankan seiring waktu.

Dan itu dia! Dari sini kami akan mengambil lebih banyak pertanyaan.

Eric Kavanagh: Baiklah, bagus, izinkan saya melemparkannya ke Robin terlebih dahulu. Dan kemudian, Dez, saya yakin Anda memiliki beberapa pertanyaan. Bawa pergi, Robin.

Robin Bloor: Oke. Sejujurnya, saya tidak pernah memiliki masalah dengan metode pengembangan lincah dan menurut saya apa yang Anda lakukan di sini masuk akal. Saya ingat melihat sesuatu di tahun 1980-an yang mengindikasikan, sungguh, bahwa masalah yang sebenarnya Anda hadapi dalam hal proyek yang lepas kendali, biasanya jika Anda membiarkan kesalahan berlanjut di luar tahap tertentu. Semakin sulit untuk memperbaikinya jika Anda tidak mendapatkan tahap itu dengan benar, jadi salah satu hal yang Anda lakukan di sini - dan saya pikir ini adalah slide - tetapi salah satu hal yang Anda lakukan di sini dalam sprint zero, menurut saya, sangat penting karena Anda benar-benar berusaha untuk mendapatkan hasil yang disematkan di sana. Dan jika Anda tidak mendapatkan kiriman yang disematkan, maka kiriman berubah bentuk.

Itu, semacam, pendapat saya. Ini juga pendapat saya - saya benar-benar tidak memiliki argumen dengan gagasan bahwa Anda harus mendapatkan pemodelan data sampai ke tingkat detail tertentu sebelum Anda melanjutkan. Apa yang saya ingin Anda coba dan lakukan karena saya tidak memahami sepenuhnya, hanya menggambarkan salah satu proyek ini dalam hal ukurannya, dalam hal bagaimana hal itu mengalir, dalam hal siapa, Anda tahu, di mana masalah muncul, apakah mereka diselesaikan? Karena saya pikir slide ini adalah inti dari hal itu dan jika Anda bisa menguraikan sedikit lebih banyak tentang itu, saya akan sangat berterima kasih.

Ron Huizenga: Tentu, dan saya akan menggunakan beberapa proyek contoh. Salah satu yang, seperti, keluar dari rel yang dibawa kembali dengan benar-benar melibatkan orang yang tepat dan melakukan pemodelan data dan semuanya benar-benar cara untuk memastikan bahwa desain dipahami lebih baik dan kami jelas memiliki desain implementasi yang lebih baik di jalan melalui pemodelan itu. Karena ketika Anda memodelkannya, Anda tahu, Anda dapat menghasilkan DDL Anda dan semuanya keluar dari belakang dan keluar dari alat daripada harus tetap membangun ini seperti yang biasanya dilakukan orang dengan masuk langsung ke lingkungan basis data. Dan hal-hal khas yang akan terjadi dengan pengembang adalah mereka akan masuk ke sana dan mereka akan berkata, oke, saya perlu tabel ini. Katakanlah kita sedang melakukan entri pesanan. Jadi mereka mungkin membuat header pesanan dan tabel detail pesanan, dan hal-hal semacam itu. Tetapi mereka akan sering lupa atau mengabaikan untuk memastikan bahwa kendala ada untuk mewakili hubungan kunci asing. Mereka mungkin tidak memiliki kunci yang benar. Konvensi penamaan mungkin juga dicurigai. Saya tidak tahu berapa kali saya pergi ke suatu lingkungan, misalnya, di mana Anda melihat banyak tabel yang berbeda dengan nama yang berbeda, tetapi kemudian nama kolom dalam tabel tersebut seperti ID, Nama, atau apa pun, jadi mereka Sudah benar-benar kehilangan konteks tanpa tabel apa itu.

Jadi, biasanya ketika kita menjadi pemodelan data, kita akan memastikan bahwa kita menerapkan konvensi penamaan yang tepat untuk semua artefak yang dihasilkan di DDL juga. Tetapi untuk lebih spesifik tentang sifat dari proyek itu sendiri, secara umum, saya berbicara tentang inisiatif yang cukup besar. Salah satunya adalah proyek transformasi bisnis senilai $ 150 juta di mana kami mengganti lebih dari selusin sistem warisan. Kami memiliki lima tim tangkas yang berbeda terjadi secara bersamaan. Saya memiliki tim arsitektur data lengkap, jadi saya memiliki pemodel data dari tim saya yang tertanam di setiap tim area aplikasi lainnya, dan kami bekerja dengan kombinasi pakar bisnis internal yang mengetahui materi pelajaran, yang melakukan cerita pengguna untuk persyaratan itu sendiri. Kami memiliki analis bisnis di masing-masing tim yang sebenarnya memodelkan proses bisnis, dengan diagram aktivitas atau diagram proses bisnis, membantu menyempurnakan cerita pengguna dengan pengguna sebelum mereka dikonsumsi oleh anggota tim lainnya.

Dan tentu saja, para pengembang yang membangun kode aplikasi lebih dari itu. Dan kami juga bekerja sama, saya pikir itu adalah empat vendor integrasi sistem yang berbeda yang membangun bagian aplikasi yang berbeda juga di mana satu tim membangun layanan data, yang lain membangun logika aplikasi di satu area, yang lain memiliki keahlian di area bisnis lain sedang membangun logika aplikasi di area itu. Jadi kami memiliki kolaborasi seluruh orang yang mengerjakan proyek ini. Yang satu itu secara khusus kami punya 150 orang di darat di tim dan 150 sumber daya lainnya di lepas pantai di tim yang berkolaborasi sprint dua minggu untuk mengusir hal ini. Dan untuk melakukan itu Anda perlu memastikan bahwa Anda menembaki semua silinder, dan semua orang disinkronkan dengan baik dalam hal apa kiriman mereka, dan Anda memiliki pengaturan ulang yang sering untuk memastikan bahwa kami menyelesaikan pengiriman kami dari semua artefak yang diperlukan. di akhir setiap sprint.

Robin Bloor: Ya, itu mengesankan. Dan hanya untuk sedikit lebih detail tentang itu - apakah Anda berakhir dengan lengkap, apa yang akan saya sebut, peta MDM dari seluruh area data pada akhir proyek itu?

Ron Huizenga: Kami memiliki model data lengkap yang dipecah dengan dekomposisi di antara semua area bisnis yang berbeda. Kamus data itu sendiri dalam hal definisi penuh jatuh agak pendek. Kami memiliki sebagian besar tabel didefinisikan; kami memiliki sebagian besar kolom yang didefinisikan dengan tepat apa artinya. Ada beberapa yang tidak ada di sana dan, yang cukup menarik, banyak dari itu adalah potongan-potongan informasi yang berasal dari sistem warisan di mana, setelah akhir lingkup proyek itu sendiri, yang masih didokumentasikan sebagai seperangkat artefak, seolah-olah, di luar proyek itu sendiri, karena itu adalah sesuatu yang perlu dipertahankan oleh organisasi ke depan. Jadi pada saat yang sama organisasi mengambil sudut pandang yang jauh lebih besar tentang pentingnya tata kelola data karena kami melihat banyak kekurangan dalam sistem warisan tersebut dan sumber data warisan yang kami coba konsumsi karena tidak didokumentasikan. Dalam banyak kasus kami hanya memiliki database yang kami harus membalikkan insinyur dan mencoba untuk mencari tahu apa yang ada di sana dan untuk apa informasi itu.

Robin Bloor: Tidak mengherankan saya, aspek khusus itu. Tata kelola data, sebut saja, masalah yang sangat modern dan saya pikir, sungguh, ada banyak pekerjaan yang, katakanlah, seharusnya dilakukan secara historis pada tata kelola data. Itu tidak pernah terjadi karena Anda bisa, agak, lolos dengan tidak melakukannya. Tetapi ketika sumber daya data tumbuh dan berkembang, pada akhirnya Anda tidak bisa.

Ngomong-ngomong, aku akan pindah ke Dez karena kurasa aku sudah punya waktu yang ditentukan. Dez?

Dez Blanchfield: Ya, terima kasih. Melalui semua ini saya mengamati dan berpikir pada diri sendiri bahwa kita berbicara tentang melihat lincah digunakan dalam kemarahan dalam banyak hal. Meskipun itu punya konotasi negatif; Maksud saya dengan cara yang positif. Bisakah Anda memberi kami skenario, maksud saya, ada dua tempat yang dapat saya lihat sebagai rangkaian yang sempurna: satu adalah proyek baru yang hanya perlu dilakukan sejak hari pertama, tetapi saya pikir selalu, dalam pengalaman saya, sering kali kasus bahwa ketika proyek menjadi cukup besar sehingga ini diperlukan dalam banyak hal, ada tantangan yang menarik antara menempelkan kedua dunia, kan? Bisakah Anda memberi kami segala macam wawasan tentang beberapa kisah sukses yang Anda lihat di mana Anda pergi ke suatu organisasi, menjadi jelas bahwa mereka memiliki sedikit bentrokan dari dua dunia dan Anda telah berhasil menempatkan ini di tempat dan menyatukan proyek-proyek besar di mana mereka mungkin telah pergi di atas rel? Saya tahu ini adalah pertanyaan yang sangat luas tetapi saya hanya ingin tahu apakah ada studi kasus khusus yang dapat Anda lakukan, semacam, tunjukkan di mana Anda berkata, Anda tahu, kami menempatkan semua ini di tempatnya dan membawa semua tim pengembangan bersama dengan tim data dan kami telah, semacam, membahas sesuatu yang mungkin telah menenggelamkan kapal?

Ron Huizenga: Tentu, dan sebenarnya satu proyek yang kebetulan merupakan proyek pipa adalah yang saya singgung di mana saya menunjukkan grafik dengan cacat sebelum dan sesudah pemodel data terlibat. Cukup sering, dan ada gagasan yang terbentuk sebelumnya, terutama jika hal-hal berputar di mana itu dilakukan dari perspektif pengembangan murni, hanya pengembang yang terlibat dalam proyek tangkas ini untuk mengirimkan aplikasi. Jadi apa yang terjadi di sana, tentu saja, adalah mereka benar-benar turun dari rel dan artefak data mereka pada khususnya, atau pengiriman data yang mereka hasilkan, tidak memenuhi standar dalam hal kualitas dan benar-benar menangani hal-hal secara keseluruhan. Dan sering kali kesalahpahaman ini bahwa pemodel data akan memperlambat proyek, dan mereka akan melakukannya jika pemodel data tidak memiliki sikap yang benar. Seperti yang saya katakan, Anda harus kehilangan - kadang-kadang ada pemodel data yang memiliki sikap penjaga gerbang tradisional di mana, "Kami di sini untuk mengontrol seperti apa struktur data, " dan mentalitas itu harus menghilang. Siapa pun yang terlibat dalam pengembangan tangkas, dan khususnya pemodel data, harus mengambil peran sebagai fasilitator untuk benar-benar membantu tim bergerak maju. Dan cara terbaik untuk menggambarkan itu adalah dengan sangat cepat menunjukkan kepada tim seberapa produktif mereka dengan memodelkan perubahan terlebih dahulu. Dan lagi, itu sebabnya saya berbicara tentang kolaborasi.

Ada beberapa hal yang dapat kita modelkan terlebih dahulu dan hasilkan DDL untuk mendorong keluar ke pengembang. Kami juga ingin memastikan bahwa mereka tidak merasa dibatasi. Jadi, jika ada hal-hal yang sedang mereka kerjakan, biarkan mereka tetap bekerja di kotak pasir pengembangan mereka, karena di situlah pengembang bekerja di desktop mereka sendiri atau database lain untuk membuat beberapa perubahan di mana mereka menguji sesuatu. Dan berkolaborasi dengan mereka dan berkata, "Oke, bekerja dengan itu." Kami akan membawanya ke alat, kami akan mengatasinya dan kemudian kami akan mendorongnya ke depan dan memberi Anda skrip yang dapat Anda gunakan untuk memperbarui Anda basis data untuk memutakhirkannya menjadi seperti apa tampilan produksi sebenarnya yang disetujui itu saat kita terus bergerak maju. Dan Anda dapat membalikkannya dengan sangat cepat. Saya menemukan bahwa hari-hari saya dipenuhi di mana saya hanya bolak-balik iterasi dengan tim pengembangan yang berbeda, melihat perubahan, membandingkan, membuat skrip, membuat mereka pergi, dan saya bisa menjaga diri saya dengan empat tim pengembangan agak mudah begitu kita mencapai momentum.

Dez Blanchfield: Salah satu hal yang terlintas dalam pikiran adalah bahwa, Anda tahu, banyak percakapan yang saya lakukan setiap hari adalah tentang kereta barang yang datang kepada kami, semacam, mesin-ke -Mesin dan IOT. Dan jika kami pikir kami memiliki banyak data sekarang di lingkungan kami saat ini di perusahaan, Anda tahu, jika kami menyingkirkan unicorn sejenak di mana kami tahu bahwa Google dan Facebook dan Ubers memiliki petabyte data, tetapi dalam sebuah perusahaan tradisional kita berbicara tentang masih ratusan terabyte dan banyak data. Tetapi ada kereta barang yang datang di organisasi, dalam pandangan saya, dan Dr. Robin Bloor menyinggung sebelumnya tentang IOT. Anda tahu, kami punya banyak lalu lintas web, kami punya lalu lintas sosial, kami sekarang punya mobilitas dan perangkat seluler, cloud telah, semacam, meledak, tapi sekarang kami punya infrastruktur pintar, kota pintar dan ada seluruh dunia data ini yang baru saja meledak.

Untuk organisasi sehari-hari, organisasi menengah ke besar yang duduk di sana dan melihat dunia kesakitan ini datang pada mereka dan tidak memiliki rencana langsung dalam pikiran, apa saja yang bisa dibawa pulang, hanya dalam beberapa kalimat, yang akan Anda masukkan untuk mereka kapan dan di mana mereka perlu mulai berpikir secara percakapan tentang menempatkan beberapa metodologi ini di tempat. Seberapa dini mereka perlu mulai merencanakan untuk hampir duduk dan memperhatikan dan mengatakan ini adalah waktu yang tepat untuk mendapatkan beberapa alat di tempat dan membuat tim dilatih dan mendapatkan percakapan vocab untuk mengatasi tantangan ini? Seberapa terlambat dalam cerita itu terlambat atau kapan terlalu dini? Seperti apa bentuknya untuk beberapa organisasi yang Anda lihat?

Ron Huizenga: Saya akan mengatakan kepada sebagian besar organisasi bahwa jika mereka belum melakukannya dan mengadaptasi pemodelan data dan arsitektur data dengan alat-alat canggih seperti ini, waktu yang perlu mereka lakukan adalah kemarin. Karena itu menarik bahwa, bahkan hari ini, ketika Anda melihat data di organisasi, kami memiliki begitu banyak data di organisasi kami dan secara umum, berdasarkan beberapa survei yang kami lihat, kami menggunakan kurang dari lima persen dari data itu secara efektif ketika kita melihat seluruh organisasi. Dan dengan IoT atau bahkan NoSQL, data besar - bahkan jika bukan hanya IoT, tetapi hanya data besar secara umum - di mana kita sekarang mulai mengkonsumsi lebih banyak informasi yang berasal dari luar organisasi kita, tantangan itu menjadi semakin besar dan semakin besar sepanjang waktu. Dan satu-satunya cara kita memiliki kesempatan untuk mengatasinya adalah dengan membantu kita memahami tentang apa data itu.

Jadi, use case sedikit berbeda. Apa yang kami lakukan adalah ketika kami melihat data itu, kami menangkapnya, kami perlu merekayasa baliknya, melihat apa yang ada di dalamnya, apakah itu di dalam data kami atau bahkan di dalam database kami, mensintesis apa yang data adalah, terapkan makna padanya dan definisinya agar kita dapat memahami apa data itu. Karena sampai kita memahami apa itu, kita tidak dapat memastikan bahwa kita menggunakannya dengan benar atau memadai. Jadi kita benar-benar perlu memahami apa data itu. Dan bagian lain dari itu adalah, jangan lakukan itu karena Anda dapat, dalam hal mengkonsumsi semua data eksternal ini, pastikan bahwa Anda memiliki use case yang mendukung penggunaan data eksternal ini. Fokus pada hal-hal yang Anda butuhkan daripada hanya mencoba menarik dan memanfaatkan hal-hal yang mungkin Anda butuhkan nanti. Fokus pada hal-hal penting terlebih dahulu dan saat Anda mengerjakannya, maka Anda akan dapat mengkonsumsi dan mencoba memahami informasi lain dari luar.

Contoh sempurna dari hal itu adalah, saya tahu kita berbicara tentang IOT dan sensor, tetapi jenis masalah yang sama sebenarnya telah terjadi di banyak organisasi selama bertahun-tahun, bahkan sebelum IOT. Siapa pun yang memiliki sistem kontrol produksi, apakah mereka perusahaan pipa, manufaktur, semua perusahaan berbasis proses yang memiliki banyak hal di mana mereka melakukan banyak otomatisasi dengan kontrol dan mereka menggunakan aliran data dan hal-hal seperti itu, memiliki firehosis data ini yang mereka coba minum untuk mencari tahu, apa saja peristiwa yang telah terjadi di peralatan produksi saya untuk memberi sinyal - apa yang terjadi dan kapan? Dan di antara aliran data yang sangat besar ini, hanya ada informasi atau tag khusus yang mereka minati yang perlu disaring, disintesis, dimodelkan, dan dipahami. Dan mereka dapat mengabaikan sisanya sampai tiba waktunya untuk benar-benar memahaminya, dan kemudian mereka dapat memperluas ruang lingkup mereka untuk menarik lebih banyak dan lebih banyak lagi ke dalam ruang lingkup, jika itu masuk akal.

Dez Blanchfield: Memang. Ada satu pertanyaan yang akan saya ajukan yang datang dari seorang pria bernama Eric, dan kami telah mengobrol tentang hal itu secara pribadi. Saya baru saja meminta izinnya, yang dia berikan, untuk menanyakannya kepada Anda. Karena itu mengarah dengan baik ke ini, hanya untuk menyelesaikan, karena kita akan sedikit dari waktu ke waktu sekarang, dan saya akan menyerahkan kembali kepada Eric. Tetapi pertanyaan dari Eric yang lain adalah, apakah masuk akal untuk mengasumsikan bahwa pemilik startup yang terbiasa dan memahami tantangan unik seputar terminologi pemodelan dan sebagainya, atau haruskah itu diserahkan kepada orang lain untuk ditafsirkan? Jadi, dengan kata lain, haruskah startup mampu dan siap dan mau dan mampu fokus dan memenuhi ini? Atau apakah itu sesuatu yang harus mereka beli dan bawa ahli?

Ron Huizenga: Saya kira jawaban singkatnya adalah itu benar-benar tergantung. Jika ini adalah startup yang tidak memiliki seseorang di rumah yang merupakan arsitek atau pemodel data yang benar-benar memahami database, maka cara tercepat untuk memulai adalah membawa seseorang dengan latar belakang konsultasi yang sangat berpengalaman dalam ruang ini dan bisa mendapatkan mereka pergi. Karena apa yang akan Anda temukan - dan pada kenyataannya, saya melakukan ini pada banyak keterlibatan yang saya lakukan sebelum saya datang ke sisi gelap dalam manajemen produk - adalah saya akan masuk ke organisasi sebagai konsultan, memimpin tim arsitektur data mereka, sehingga mereka dapat, semacam, memfokuskan kembali diri mereka dan melatih orang-orang mereka tentang cara melakukan hal-hal semacam ini sehingga mereka mempertahankannya dan membawa misi ke depan. Dan kemudian saya akan melanjutkan pertunangan saya berikutnya, jika itu masuk akal. Ada banyak orang di luar sana yang melakukan itu, yang memiliki pengalaman data yang sangat baik yang dapat membuat mereka berjalan.

Dez Blanchfield: Itu poin yang bagus dan saya sepenuhnya setuju dengan itu dan saya yakin Dr. Robin Bloor juga. Khususnya dalam sebuah startup, Anda berfokus untuk menjadi UKM pada nilai proposisi tertentu yang ingin Anda bangun sebagai bagian dari bisnis startup Anda sendiri dan Anda mungkin tidak perlu menjadi ahli dalam segala hal, saran yang sangat bagus. Tapi terima kasih banyak, presentasi yang fantastis. Jawaban dan pertanyaan yang sangat bagus. Eric, aku akan mengembalikan padamu karena aku tahu kita mungkin sudah sepuluh menit dari waktu ke waktu dan aku tahu kau suka dekat dengan jendela waktu kita.

Eric Kavanagh: Tidak apa-apa. Kami memiliki setidaknya beberapa pertanyaan bagus. Biarkan saya melemparkan satu ke Anda. Saya pikir Anda sudah menjawab beberapa yang lain. Tetapi pengamatan dan pertanyaan yang sangat menarik dari salah satu peserta yang menulis, kadang-kadang proyek gesit memiliki pemodel data tidak memiliki seluruh gambar jangka panjang dan akhirnya mereka merancang sesuatu dalam sprint satu dan kemudian harus mendesain ulang dalam sprint tiga atau empat. Bukankah ini tampak kontraproduktif? Bagaimana Anda bisa menghindari hal semacam itu?

Ron Huizenga: Hanya sifat lincah bahwa Anda tidak akan mendapatkan segalanya dengan benar dalam sprint yang diberikan. Dan itu sebenarnya bagian dari semangat lincah, adalah: bekerja dengannya - Anda akan melakukan prototyping di mana Anda bekerja pada kode dalam sprint yang diberikan, dan Anda akan membuat penyempurnaan terhadapnya. Dan bagian dari proses itu adalah ketika Anda memberikan hal-hal yang dilihat oleh pengguna akhir dan berkata, "Ya itu dekat, tapi saya benar-benar perlu membuatnya melakukan ini sedikit ekstra juga." Sehingga tidak hanya berdampak pada desain fungsional dari kode itu sendiri tetapi cukup sering kita perlu memodifikasi atau menambahkan lebih banyak struktur data di bawah hal-hal tertentu untuk memberikan apa yang diinginkan pengguna. Dan itu semua permainan yang adil dan itu sebabnya Anda benar-benar ingin menggunakan alat-alat bertenaga tinggi karena Anda dapat dengan cepat memodelkan dan membuat perubahan itu dalam alat pemodelan dan kemudian menghasilkan DDL untuk database yang kemudian dapat dikerjakan oleh pengembang untuk menghasilkan berubah lebih cepat lagi. Anda menyelamatkan mereka dari keharusan melakukan pengkodean tangan, seolah-olah, dari struktur data dan membiarkan mereka berkonsentrasi pada pemrograman atau logika aplikasi yang paling mereka kuasai.

Eric Kavanagh: Itu masuk akal. Kami memiliki beberapa orang lain yang hanya mengajukan pertanyaan spesifik tentang bagaimana semua ini terkait dengan alat ini. Saya tahu Anda menghabiskan beberapa waktu melalui contoh dan Anda telah menunjukkan beberapa tangkapan layar tentang bagaimana Anda benar-benar meluncurkan beberapa hal ini. Dalam hal seluruh proses sprint ini, seberapa sering Anda melihat bahwa dalam permainan di organisasi versus seberapa sering Anda melihat proses yang lebih tradisional di mana hal-hal yang adil, jenis, berjalan bersama dan mengambil lebih banyak waktu? Seberapa lazimkah pendekatan gaya sprint dari sudut pandang Anda?

Ron Huizenga: Saya pikir kita semakin melihatnya. Saya tahu bahwa, saya akan mengatakan, mungkin dalam 15 tahun terakhir khususnya, saya telah melihat lebih banyak adopsi orang yang mengakui bahwa mereka benar-benar perlu menerima pengiriman yang lebih cepat. Jadi saya telah melihat semakin banyak organisasi melompat pada kereta yang gesit. Tidak harus seluruhnya; mereka mungkin memulai dengan beberapa proyek percontohan untuk membuktikan bahwa itu berhasil, tetapi ada beberapa yang masih sangat tradisional dan mereka tetap menggunakan metode air terjun. Sekarang, kabar baiknya adalah, tentu saja, bahwa alat-alat tersebut bekerja dengan sangat baik di organisasi-organisasi itu juga untuk jenis metodologi tersebut, tetapi kami memiliki kemampuan beradaptasi dalam alat tersebut sehingga mereka yang melakukan lompatan memiliki alat-alat di kotak alat di ujung jari mereka. Hal-hal seperti membandingkan dan menggabungkan, hal-hal seperti kemampuan reverse-engineering, sehingga mereka dapat melihat apa sumber data yang ada, sehingga mereka benar-benar dapat membandingkan dan menghasilkan skrip DDL tambahan dengan sangat cepat. Dan ketika mereka mulai merangkul itu dan melihat bahwa mereka dapat memiliki produktivitas, kecenderungan mereka untuk merangkul gesit semakin meningkat.

Eric Kavanagh: Ya, ini barang bagus, kawan. Saya baru saja memposting tautan ke slide di sana di jendela obrolan, jadi periksa itu; itu sedikit Bitly di sana untuk Anda. Kami memiliki semua webcast ini untuk ditonton nanti. Jangan ragu untuk membaginya dengan teman dan kolega Anda. Dan Ron, terima kasih banyak atas waktu Anda hari ini, Anda selalu senang berada di acara itu - seorang ahli nyata di lapangan dan jelas bahwa Anda tahu barang-barang Anda. Jadi, terima kasih kepada Anda dan terima kasih kepada IDERA dan, tentu saja, kepada Dez dan Robin Bloor kami sendiri.

Dan dengan itu kami akan mengucapkan selamat tinggal, teman-teman. Sekali lagi terima kasih atas waktu dan perhatian Anda. Kami menghargai Anda bertahan selama 75 menit, itu pertanda bagus. Pertunjukan yang bagus kawan, kami akan berbicara dengan Anda lain kali. Sampai jumpa.