Membina senibina data berasaskan perniagaan

Dengan Staf Techopedia, 28 September 2016

Takeaway: Tuan Rumah Rebecca Jozwiak membincangkan penyelesaian seni bina data dengan Eric Little dari OSTHUS, Malcolm Chisholm Pasangan San Francisco Pertama dan Ron Huizenga dari IDERA.

Anda tidak log masuk sekarang. Sila log masuk atau mendaftar untuk melihat video.

Rebecca Jozwiak: Tuan-tuan dan puan-puan, hello, dan selamat datang ke Hot Technologies 2016. Hari ini kita membincangkan "Membina Senibina Data yang Digerakkan Perniagaan, " pasti topik hangat. Nama saya Rebecca Jozwiak, saya akan menjadi tuan rumah anda untuk siaran web hari ini. Kami tweet dengan hashtag # HotTech16 jadi jika anda berada di Twitter sudah, sila berasa bebas untuk menyertai dalam itu juga. Sekiranya anda mempunyai soalan pada bila-bila masa, sila hantarkannya ke anak tetingkap Q & A di bahagian bawah sebelah kanan skrin anda dan kami akan memastikan mereka dijawab. Sekiranya tidak, kami akan memastikan tetamu kami mendapatkannya untuk anda.

Jadi hari ini kita mempunyai barisan yang sangat menarik. Banyak pemukul berat dengan kami hari ini. Kami mempunyai Eric Little, ketua sains data dari OSTHUS. Kami mempunyai ketua inovasi Malcolm Chisholm, yang merupakan tajuk yang sangat keren, untuk Rakan San Francisco Pertama. Dan kami mempunyai Ron Huizenga, pengurus produk kanan dari IDERA. Dan, anda tahu, IDERA mempunyai penyelesaian pengurusan data dan pemodelan yang sangat lengkap. Dan hari ini dia akan memberi kami demo bagaimana penyelesaiannya berfungsi. Tetapi sebelum kita sampai pada itu, Eric Little, saya akan lulus bola kepada kamu.

Eric Little: Baiklah, terima kasih banyak. Jadi saya akan meneruskan beberapa topik di sini yang saya fikir akan berkaitan dengan ucapan Ron sedikit dan semoga meletakkan pentas untuk beberapa topik ini juga, beberapa Q & A.

Jadi perkara yang menarik minat saya terhadap apa yang IDERA lakukan ialah saya fikir mereka betul menunjukkan bahawa persekitaran yang kompleks benar-benar memacu banyak nilai perniagaan pada masa kini. Dan dengan persekitaran yang rumit, kita bermakna persekitaran data yang rumit. Dan teknologi benar-benar bergerak pantas dan sukar untuk bersaing dalam persekitaran perniagaan hari ini. Jadi orang-orang yang bekerja di ruang teknologi akan sering melihat bahawa anda mempunyai pelanggan yang sedang menyelesaikan masalah dengan, "Bagaimana saya menggunakan data besar? Bagaimana saya memasukkan semantik? Bagaimanakah saya menghubungkan beberapa barang baru ini dengan data lama saya? "Dan sebagainya, dan jenis ini membawa kita pada masa kini ke dalam empat data besar yang banyak orang akrab, dan saya faham boleh ada lebih daripada empat kadang-kadang - saya telah melihat sebanyak lapan atau sembilan - tetapi biasanya, apabila orang bercakap tentang perkara seperti data besar atau jika anda bercakap mengenai data besar maka anda biasanya melihat sesuatu yang jenis skala perusahaan. Dan oleh itu orang akan berkata, baiklah, baiklah, fikirkan jumlah data anda, yang biasanya fokus - itu hanya berapa banyak yang anda miliki. Halaju data berkaitan dengan seberapa cepat saya boleh bergerak di sekitar atau berapa cepat saya boleh bertanya atau mendapatkan jawapan, dan sebagainya. Dan secara peribadi saya fikir sebelah kiri itu adalah sesuatu yang diselesaikan dan dikendalikan secara relatif dengan banyak pendekatan yang berbeza. Tetapi di sebelah kanan saya melihat banyak keupayaan untuk penambahbaikan dan banyak teknologi baru yang benar-benar datang ke latar depan. Dan itu benar-benar berkaitan dengan lajur ketiga, pelbagai data.

Jadi dengan kata lain, kebanyakan syarikat kini melihat data berstruktur, separa berstruktur dan tidak berstruktur. Data imej mulai menjadi topik hangat, jadi dapat menggunakan visi komputer, melihat piksel, dapat mengikis teks, NLP, pengekstrakan entiti, anda mempunyai maklumat graf yang keluar dari model statistik atau yang keluar dari semantik model, anda mempunyai data hubungan yang ada dalam jadual, dan sebagainya. Dan begitu menarik semua data itu bersama-sama dan semua jenis yang berbeza ini benar-benar mewakili cabaran besar dan anda akan melihat ini, anda tahu, dalam Gartner dan orang lain yang semacam mengikuti trend dalam industri.

Dan kemudian perkara terakhir yang dibincangkan oleh orang dalam data besar sering kali adalah tanggapan kesetiaan ini, yang benar-benar ketidakpastian data anda, kekaburannya. Seberapa baik anda tahu apa data anda tentang, seberapa baik anda memahami apa yang ada di dalamnya dan, anda tahu? Keupayaan untuk menggunakan statistik dan keupayaan untuk menggunakan beberapa jenis maklumat di sekitar apa yang anda ketahui atau menggunakan beberapa konteks, boleh bernilai di sana. Oleh itu, keupayaan untuk melihat data dengan cara ini dari segi berapa banyak yang anda miliki, seberapa cepat anda perlu mengalihkannya atau mendapatkannya, semua jenis data yang anda mungkin ada di perusahaan anda dan berapa pasti anda berada di mana ia adalah, apakah ia, apa kualiti ia masuk, dan sebagainya. Ini benar-benar memerlukan usaha yang besar dan diselaraskan sekarang di antara banyak individu untuk menguruskan data mereka dengan berkesan. Oleh itu, data pemodelan semakin penting di dunia hari ini. Jadi model data yang baik benar-benar memacu banyak kejayaan dalam aplikasi perusahaan.

Anda mempunyai sumber data dari pelbagai sumber, seperti yang kami katakan, yang benar-benar memerlukan banyak jenis integrasi. Oleh itu, menarik semua ini sangat berguna untuk dapat menjalankan pertanyaan, contohnya, merangkumi pelbagai jenis sumber data, dan menarik kembali maklumat. Tetapi untuk melakukan itu, anda memerlukan strategi pemetaan yang baik dan begitu pemetaan jenis data dan mengekalkan pemetaan tersebut boleh menjadi cabaran sebenar. Dan kemudian anda mempunyai masalah ini, bagaimana saya menghubungkan data warisan saya kepada semua sumber data baru ini? Oleh itu, adakah saya mempunyai graf, adakah saya mengambil semua data hubungan saya dan memasukkannya ke dalam graf? Biasanya itu bukan idea yang baik. Jadi bagaimana orang dapat menguruskan semua jenis model data yang sedang berlaku? Analisis benar-benar perlu dijalankan pada banyak jenis sumber data dan gabungannya. Jadi jawapan yang keluar dari ini, jawapan yang orang perlukan untuk membuat keputusan perniagaan yang baik adalah kritikal.

Oleh itu, ini bukan mengenai membina teknologi demi teknologi, sebenarnya, apa yang saya akan lakukan, apa yang boleh saya lakukan dengannya, analisis apa yang boleh saya laksanakan, dan keupayaan, oleh itu, kerana saya sudah telah bercakap tentang, untuk menarik barangan ini bersama-sama, untuk mengintegrasikannya adalah benar-benar penting. Dan satu daripada jenis analisis kemudian berjalan pada perkara-perkara seperti pencarian dan pertanyaan persekutuan. Itu benar-benar menjadi suatu keharusan. Pertanyaan anda biasanya perlu dibalut merentasi pelbagai jenis sumber dan menarik kembali maklumat yang boleh dipercayai.

Satu elemen utama yang sering, terutama orang akan melihat perkara-perkara penting seperti teknologi semantik - dan ini adalah sesuatu yang saya berharap Ron akan bercakap tentang sedikit dalam pendekatan IDERA - bagaimana anda memisahkan atau menguruskan lapisan model data anda dari lapisan data itu sendiri, dari data mentah itu? Oleh itu, pada lapisan data anda mungkin memiliki pangkalan data, anda mungkin mempunyai data dokumen, anda mungkin mempunyai data spreadsheet, anda mungkin memiliki data gambar. Jika anda berada dalam bidang seperti industri farmaseutikal, anda mempunyai sejumlah besar data saintifik. Dan kemudian di atas orang ini biasanya mencari cara untuk membina model yang membolehkan mereka untuk mengintegrasikan data dengan cepat dan benar-benar ketika anda mencari data sekarang anda tidak ingin menarik semua data ke dalam lapisan model anda, apa yang anda lihat pada lapisan model yang perlu dilakukan adalah memberikan gambaran logik yang bagus tentang apa yang ada, kosa kata yang biasa, jenis entiti dan hubungan yang sama, dan keupayaan untuk benar-benar mencapai data di mana ia berada. Jadi ia harus mengatakan apa itu, dan ia harus mengatakan di mana ia adalah, dan ia harus mengatakan bagaimana hendak mengambilnya dan membawanya kembali.

Oleh itu, ini merupakan satu pendekatan yang agak berjaya dalam menggerakkan teknologi semantik ke hadapan, yang merupakan kawasan di mana saya banyak bekerja. Jadi satu soalan yang saya ingin pose untuk Ron, dan yang saya fikir akan berguna dalam bahagian Q & A, adalah untuk melihat bagaimana ini dicapai oleh platform IDERA? Jadi, lapisan model sebenarnya terpisah dari lapisan data? Adakah mereka lebih bersepadu? Bagaimanakah cara itu berfungsi dan apakah beberapa hasil dan faedah yang mereka lihat dari pendekatan mereka? Oleh itu, data rujukan benar-benar menjadi sangat kritikal. Jadi, jika anda akan mempunyai model data seperti ini, jika anda akan dapat bersatu dan mencari sesuatu, anda mesti mempunyai data rujukan yang baik. Tetapi masalahnya ialah data rujukan boleh menjadi sangat sukar untuk dijaga. Begitu juga penamaan standard dan diri mereka adalah cabaran yang sukar. Satu kumpulan akan memanggil sesuatu X dan satu kumpulan akan memanggil sesuatu Y dan sekarang anda mempunyai masalah bagaimana seseorang mencari X dan Y ketika mereka mencari jenis maklumat ini? Kerana anda tidak mahu memberi mereka sebahagian daripada data, anda ingin memberi mereka segala yang berkaitan. Pada masa yang sama istilah berubah, perisian menjadi usang, dan sebagainya, bagaimana anda menyimpan dan mengekalkan data rujukan dari masa ke masa?

Dan sekali lagi, teknologi semantik, khususnya menggunakan perkara-perkara seperti taksonomi dan kosa kata, kamus data, telah menyediakan cara yang standard untuk melakukan ini, yang sangat teguh, ia menggunakan beberapa jenis piawai, tetapi komuniti pangkalan data telah melakukan ini untuk lama juga, hanya dengan cara yang berbeza. Saya fikir salah satu kunci di sini adalah untuk memikirkan bagaimana cara menggunakan model hubungan entiti mungkin, cara menggunakan model graf mungkin atau beberapa jenis pendekatan di sini yang sememangnya akan memberi anda semoga cara spasi yang standard untuk mengendalikan data rujukan anda. Dan kemudian sudah tentu apabila anda mempunyai data rujukan, strategi pemetaan perlu menguruskan pelbagai nama dan entiti. Jadi ahli-ahli subjek sering suka menggunakan istilah mereka sendiri.

Oleh itu, cabaran dalam ini adalah selalu, bagaimana anda memberikan maklumat seseorang tetapi menjadikannya relevan dengan cara mereka bercakap mengenainya? Jadi, satu kumpulan mungkin mempunyai satu cara untuk melihat sesuatu, sebagai contoh, anda mungkin seorang ahli kimia yang bekerja dengan ubat, dan anda mungkin ahli biologi struktur yang bekerja pada ubat yang sama, dan anda mungkin mempunyai nama yang berbeza untuk jenis entiti yang sama yang berkaitan dengan bidang anda. Anda perlu mencari cara untuk membawa istilah-istilah yang disesuaikan bersama-sama, kerana pendekatan lain adalah, anda perlu memaksa orang untuk menggugurkan istilah mereka dan menggunakan orang lain, yang sering mereka tidak suka. Satu lagi perkara di sini adalah menangani banyak sinonim yang banyak menjadi sukar, jadi terdapat banyak kata yang berbeza dalam banyak data orang yang boleh merujuk kepada perkara yang sama. Anda mempunyai masalah rujukan di sana menggunakan set hubungan yang banyak. Istilah khusus adalah berbeza dari industri ke industri jadi jika anda akan menghasilkan penyelesaian menyeluruh untuk jenis pengurusan data ini, betapa mudahnya portabel itu dari satu projek atau satu aplikasi ke yang lain? Itulah cabaran lain.

Automasi adalah penting dan ia juga merupakan satu cabaran. Ia mahal untuk mengendalikan data rujukan secara manual. Ia mahal untuk terus memetakan secara manual dan mahal untuk mempunyai pakar mata pelajaran berhenti melakukan pekerjaan sehari-hari dan perlu masuk dan sentiasa memperbaiki kamus data dan mengemas kini definisi dan sebagainya, dan sebagainya. Kosa kata yang tidak boleh ditiru benar-benar menunjukkan banyak nilai. Oleh itu, mereka adalah perbendaharaan kata sering kali anda boleh mencari luaran untuk organisasi anda. Jika anda melakukan kerja dalam minyak mentah, sebagai contoh, akan ada jenis kosa kata tertentu yang anda boleh pinjam dari ruang sumber terbuka, sama dengan farmaseutikal, sama dengan industri perbankan dan kewangan, sama dengan banyak bidang ini. Orang meletakkan kosa kata boleh digunakan semula, generik, boleh ditiru di luar sana untuk digunakan oleh orang ramai.

Dan, sekali lagi, melihat alat IDERA, saya ingin tahu bagaimana mereka mengendalikannya dari segi menggunakan jenis standard. Di dunia semantik, anda sering melihat perkara-perkara seperti model SKOS yang memberikan piawaian untuk sekurang-kurangnya lebih luas daripada / lebih sempit daripada hubungan dan perkara-perkara yang sukar untuk dilakukan dalam model ER tetapi, anda tahu, tidak mustahil, ia hanya bergantung kepada berapa banyak jentera dan yang menghubungkan yang anda boleh mengendalikan dalam jenis sistem tersebut.

Jadi, akhirnya saya hanya ingin membuat perbandingan dengan beberapa enjin semantik yang saya lihat dalam industri ini, dan semacam meminta Ron dan perdana dia sedikit untuk membicarakan tentang bagaimana sistem IDERA telah digunakan bersempena dengan mana-mana teknologi semantik. Adakah ia mampu disepadukan dengan kedai tiga, pangkalan grafik? Betapa mudahnya menggunakan sumber luaran kerana jenis-jenis benda di dunia semantik sering boleh dipinjam menggunakan SPARQL Endpoints? Anda boleh mengimport model RDF atau OWL terus ke dalam model anda - merujuk kembali kepada mereka - jadi, sebagai contoh, ontologi gen atau ontologi protein, yang boleh tinggal di suatu tempat dalam ruang sendiri dengan struktur tadbirnya sendiri dan saya hanya boleh mengimport semua atau sebahagian daripada itu kerana saya memerlukannya dalam model saya sendiri. Dan saya ingin tahu bagaimana IDERA menghampiri isu ini. Adakah anda perlu mengekalkan segala-galanya secara dalaman, atau adakah terdapat cara untuk menggunakan model lain yang standard dan menariknya dan bagaimana ia berfungsi? Dan perkara terakhir yang saya nyatakan di sini adalah berapa kerja manual benar-benar terlibat untuk membina glosari dan repositori metadata?

Jadi saya tahu Ron akan menunjukkan kepada kita beberapa demo mengenai perkara-perkara seperti ini yang akan menjadi sangat menarik. Tetapi masalah yang sering saya jumpi dengan pelanggan ialah banyak kesilapan berlaku jika orang menulis dalam definisi mereka sendiri atau metadata mereka sendiri. Jadi, anda mendapat salah ejaan, anda mendapat kesilapan jari-jari, itu satu perkara. Anda juga mendapat orang yang mungkin mengambil sesuatu dari, anda tahu, hanya Wikipedia atau sumber yang tidak semestinya mutu yang anda inginkan dalam takrif anda, atau definisi anda hanya dari perspektif seseorang sehingga ia tidak lengkap, dan ia tidak jelas bagaimana proses tadbir urus berfungsi. Pemerintahan, sememangnya menjadi isu yang sangat besar pada bila-bila masa anda bercakap tentang data rujukan dan bila-bila masa anda bercakap mengenai bagaimana ia mungkin sesuai dengan data induk seseorang, bagaimana mereka akan menggunakan metadata mereka, dan sebagainya.

Jadi saya hanya mahu meletakkan beberapa topik di luar sana. Ini adalah perkara-perkara yang saya lihat di ruang perniagaan dalam pelbagai jenis perundingan dan banyak ruang yang berbeza, dan saya benar-benar berminat untuk melihat apa yang akan ditunjukkan oleh Ron kepada IDERA untuk menunjukkan beberapa topik ini . Jadi terima kasih banyak.

Rebecca Jozwiak: Terima kasih banyak, Eric, dan saya sangat suka komen anda bahawa banyak kesilapan boleh berlaku jika orang menulis definisi atau metadata mereka sendiri. Saya tahu di dunia kewartawanan ada mantra yang "banyak mata membuat sedikit kesilapan, " tetapi apabila ia turun ke aplikasi praktikal, terlalu banyak tangan dalam balang cookie cenderung meninggalkan anda dengan banyak cookie yang patah, bukan?

Eric Little: Ya, dan kuman.

Rebecca Jozwiak: Ya. Dengan itu saya akan pergi dan melepaskannya ke Malcolm Chisholm. Malcolm, lantai adalah milik awak.

Malcolm Chisholm: Terima kasih banyak, Rebecca. Saya ingin melihat sedikit apa yang Eric bercakap tentang, dan menambah, semacam, beberapa pemerhatian yang, anda tahu, Ron juga mengambil berat untuk bertindak balas juga, dalam membicarakan tentang "Ke Arah Seni Bina Data yang Digerakkan Perniagaan "- apakah maksudnya didorong oleh perniagaan dan mengapa itu penting? Atau adakah ia hanya satu bentuk gembar-gembur? Saya tidak fikir ia.

Sekiranya kita melihat apa yang berlaku sejak itu, anda tahu, komputer kerangka utama benar-benar tersedia untuk syarikat - katakan, sekitar 1964 - hingga hari ini, kita dapat melihat bahawa terdapat banyak perubahan. Dan perubahan ini akan saya saksikan sebagai pergeseran dari proses-sentris kepada data-sentris. Dan itulah yang membuat arsitektur data yang didorong oleh perniagaan sangat penting dan sangat relevan untuk hari ini. Dan saya fikir, anda tahu, itu bukan sekadar kata kunci, itu sesuatu yang benar-benar nyata.

Tetapi kita dapat menghargai sedikit lebih jika kita menyelam sejarah, jadi kembali ke masa, kembali ke 1960-an dan untuk beberapa waktu selepas itu, kerangka utama dikuasai. Ini kemudian memberi laluan kepada PC di mana anda telah benar-benar pemberontakan pengguna apabila PC masuk. Pemberontakan terhadap IT berpusat, yang mereka fikir tidak memenuhi keperluan mereka, tidak cukup tangkas. Yang cepat menimbulkan pengkomputeran yang diedarkan, apabila PC dihubungkan bersama. Dan kemudian internet mula berlaku, yang kabur sempadan perusahaan - kini boleh berinteraksi dengan pihak-pihak di luar dirinya dalam hal pertukaran data, yang belum pernah terjadi sebelumnya. Dan sekarang kita telah pergi ke era awan dan data besar di mana awan adalah platform yang benar-benar mengutamakan prasarana dan jadi kami pergi, kerana itu, IT keperluan untuk menjalankan pusat data besar kerana, anda tahu, kami 'mempunyai kapasiti awan yang tersedia untuk kami, dan bersamaan dengan data besar yang Eric, anda tahu, sangat dibincangkan secara fasih. Dan secara keseluruhan, seperti yang kita lihat, sebagai peralihan teknologi berlaku, ia telah menjadi lebih berorientasikan data, kita lebih peduli terhadap data. Seperti dengan internet, bagaimana data sedang ditukar. Dengan data besar, empat atau lebih v data itu sendiri.

Pada masa yang sama, dan mungkin lebih penting lagi, kes penggunaan perniagaan beralih. Apabila komputer mula diperkenalkan, mereka digunakan untuk mengautomasikan perkara seperti buku dan rekod. Dan apa pun yang merupakan proses manual, yang melibatkan pengarah atau perkara-perkara seperti itu, diprogramkan, pada asasnya, di rumah. Itu beralih pada tahun 80-an dengan adanya pakej operasi. Anda tidak perlu menulis gaji anda lagi, anda boleh membeli sesuatu yang melakukannya. Ini mengakibatkan pengurangan besar pada masa itu, atau penstrukturan semula, di banyak jabatan IT. Tetapi perisikan perniagaan, dengan perkara-perkara seperti gudang data muncul, kebanyakannya pada tahun 90-an. Diikuti oleh model perniagaan dotcom yang tentu saja menjadi kegilaan besar. Kemudian MDM. Dengan MDM anda mula melihat bahawa kami tidak berfikir tentang automasi; kami hanya memberi tumpuan kepada mengkuring data sebagai data. Dan kemudian analitik, yang mewakili nilai yang anda dapat keluar dari data. Dan dalam analisis anda melihat syarikat-syarikat yang sangat berjaya yang model perniagaan utamanya berputar sekitar data. Google, Twitter, Facebook akan menjadi sebahagian daripada itu, tetapi anda juga boleh berhujah bahawa Walmart adalah.

Jadi perniagaan kini benar-benar memikirkan data. Bagaimana kita boleh mendapatkan nilai daripada data? Bagaimana data dapat memacu perniagaan, strategi, dan kami berada di zaman kegemilangan data. Oleh itu, apa yang berlaku dari segi senibina data kami, jika data tidak lagi dianggap hanya sebagai ekzos yang keluar dari hujung aplikasi, tetapi benar-benar penting kepada model perniagaan kami? Nah, sebahagian daripada masalah yang kita miliki dalam mencapai itu adalah IT benar-benar terperangkap pada masa lalu dengan kitaran hayat pembangunan sistem yang merupakan akibat daripada harus berurusan dengan cepat dengan fasa automasi proses pada awal usia IT, dan bekerja di projek adalah perkara yang sama. Untuk IT - dan ini sedikit karikatur - tetapi apa yang saya cuba katakan adalah bahawa beberapa halangan untuk mendapatkan arsitektur data yang didorong oleh perniagaan adalah kerana kita, semacam, tanpa menerima budaya dalam IT yang berasal dari zaman dahulu.

Jadi semuanya adalah satu projek. Beritahu saya keperluan anda secara terperinci. Jika perkara tidak berfungsi, itu kerana anda tidak memberitahu saya keperluan anda. Baik itu tidak berfungsi hari ini dengan data kerana kita tidak bermula dengan proses manual yang tidak automatik atau, anda tahu, penukaran proses perniagaan teknikal, kami mula sangat sering dengan data pengeluaran yang sedia ada yang kami cuba untuk mendapatkan nilai dari. Tetapi tiada siapa yang menaja projek yang berasaskan data benar-benar memahami bahawa data secara mendalam. Kita perlu melakukan penemuan data, kita perlu melakukan analisis data sumber. Dan itu tidak sepadan dengan pembangunan sistem, anda tahu - air terjun, kitaran hayat SDLC - yang mana Agile, saya akan mengekalkan, adalah sejenis versi yang lebih baik daripada itu.

Dan apa yang difokuskan ialah teknologi dan fungsi, bukan data. Sebagai contoh, apabila kita melakukan ujian dalam fasa ujian biasanya biasanya, apakah fungsi saya berfungsi, katakan ETL saya, tetapi kita tidak menguji data. Kami tidak menguji andaian tentang data sumber yang datang. Jika kami melakukannya, kami akan berada dalam bentuk yang lebih baik dan sebagai orang yang telah melakukan projek-projek gudang data dan mengalami perubahan huluan, membuang ETL saya, saya akan menghargai itu. Dan sebenarnya, apa yang ingin kita lihat adalah ujian sebagai langkah awal untuk pemantauan kualiti data pengeluaran berterusan. Oleh itu, kita telah mendapat banyak sikap di mana sukar untuk mencapai seni bina data yang didorong oleh perniagaan kerana kita dikondisikan oleh era proses-sentris. Kita perlu membuat peralihan kepada sentrisiti data. Dan ini bukanlah satu peralihan sepenuhnya, anda tahu, masih ada banyak proses yang berfungsi untuk melakukannya di luar sana, tetapi kita tidak benar-benar berfikir dalam terma-terma data apabila kita perlu, dan keadaan yang berlaku ketika kita benar-benar wajib berbuat demikian.

Sekarang perniagaan menyedari nilai data, mereka mahu membuka kunci data, jadi bagaimana kita akan melakukannya? Jadi bagaimana kita melakukan peralihan? Nah, kami meletakkan data di tengah-tengah proses pembangunan. Dan kami membiarkan perniagaan memimpin dengan keperluan maklumat. Dan kita memahami bahawa tiada siapa yang memahami data sumber sedia ada pada permulaan projek. Anda boleh berhujah bahawa struktur data dan data itu sendiri sampai di sana melalui IT dan operasi, masing-masing, jadi kita harus tahu itu, tetapi sebenarnya, kita tidak. Ini adalah pembangunan data-sentris. Oleh itu, kita perlu memikirkan bagaimana kita dan cara pemodelan data dalam dunia yang berpusatkan data, kita perlu mempunyai gelung maklum balas kepada pengguna dari segi menapis keperluan maklumat mereka, seperti yang kita lakukan penemuan data dan profil data, meramalkan analisis data sumber, dan ketika kami secara beransur-ansur mendapatkan lebih banyak kepastian tentang data kami. Dan sekarang saya bercakap tentang projek yang lebih tradisional seperti hub MDM atau gudang data, tidak semestinya projek data besar, walaupun ini masih, saya mengekalkan, agak dekat dengan itu. Dan sebagainya gelung maklum balas termasuk pemodelan data, anda tahu, secara beransur-ansur memajukan model data mereka dan berinteraksi dengan pengguna untuk memastikan keperluan maklumat disempurnakan berdasarkan apa yang mungkin, apa yang tersedia, dari data sumber kerana mereka lebih memahaminya, jadi ia bukan satu perkara lagi model data yang, anda tahu, dalam keadaan yang sama ada tidak ada atau benar-benar dilakukan, ia secara beransur-ansur membawa fokus kepadanya.

Begitu juga, lebih banyak hiliran bahawa kami mempunyai jaminan kualiti di mana kami membangunkan peraturan untuk ujian kualiti data untuk memastikan bahawa data berada dalam parameter yang kami membuat andaian tentang. Melangkah, Eric merujuk kepada perubahan dalam data rujukan, yang mungkin berlaku. Anda tidak mahu menjadi, sebagai korban hiliran, semacam, perubahan yang tidak dikendalikan di kawasan itu, maka peraturan jaminan kualiti boleh masuk ke dalam pasca produksi, pemantauan kualiti data berterusan. Jadi, anda boleh mula melihat sama ada kita akan menjadi data-centric, bagaimana kita melakukan pembangunan data-centric agak berbeza dengan SDLC berasaskan fungsi dan Agile. Dan kemudian kita perlu memberi perhatian kepada pandangan perniagaan juga. Kami mempunyai - dan sekali lagi ini menggema apa yang Eric katakan - kami mempunyai model data yang mendefinisikan cetak biru cerita data untuk pangkalan data kami, tetapi pada masa yang sama kami memerlukan model konseptual, pandangan perniagaan terhadap data yang secara tradisional tidak dilakukan masa lalu. Kami kadang-kadang, saya fikir, model data boleh melakukannya, tetapi kita perlu mempunyai pandangan konseptual, semantik, dan melihat data, menjadikannya melalui lapisan abstraksi yang menerjemahkan model penyimpanan ke dalam perniagaan pandangan. Dan, sekali lagi, semua perkara yang Eric bercakap tentang segi semantik, menjadi penting untuk melakukannya, jadi kita sebenarnya mempunyai tugas pemodelan tambahan. Saya rasa itu, anda tahu, menarik jika anda telah muncul dalam barisan sebagai pemodel data seperti yang saya lakukan, dan sekali lagi, sesuatu yang baru.

Dan akhirnya saya ingin mengatakan bahawa seni bina yang lebih besar juga harus mencerminkan realiti baru ini. Sebagai contoh, pelanggan tradisional MDM adalah jenis, okay, mari kita dapatkan data pelanggan kami menjadi hub di mana kita boleh, anda tahu, masuk akal dari segi kualiti data hanya untuk aplikasi back office. Yang dari perspektif strategi perniagaan adalah seperti menguap. Walau bagaimanapun, hari ini, kita melihat hab MDM pelanggan yang mempunyai data profil pelanggan tambahan di dalamnya, bukan hanya data statik, yang kemudiannya mempunyai antara muka dua arah dengan aplikasi transaksi pelanggan. Ya, mereka masih menyokong pejabat belakang, tapi sekarang kita tahu tentang perilaku pelanggan ini juga. Ini lebih mahal untuk dibina. Ini lebih kompleks untuk dibina. Tetapi ia berasaskan perniagaan dengan cara MDM pelanggan tradisional tidak. Anda berdagang orientasi kepada perniagaan dengan reka bentuk mudah yang lebih mudah untuk dilaksanakan, tetapi untuk perniagaan, inilah yang mereka ingin lihat. Kami benar-benar berada di era baru dan saya fikir terdapat beberapa tahap yang perlu kita balas terhadap seni bina data pemacu perniagaan dan saya fikir ia adalah masa yang sangat menarik untuk dilakukan.

Jadi terima kasih, kembali kepada awak Rebecca.

Rebecca Jozwiak: Terima kasih Malcolm, dan saya benar-benar menikmati apa yang anda katakan mengenai model data mesti memberi pandangan perniagaan, kerana, tidak seperti apa yang anda katakan, di mana IT memegang kekangan lama dan ia hanya bukan jenis kes itu lagi dan bahawa budaya perlu beralih. Dan saya yakin bahawa terdapat anjing di latar belakang yang bersetuju dengan anda 100%. Dan dengan itu saya akan lulus bola kepada Ron. Saya sangat teruja untuk melihat demo anda. Ron, lantai adalah milik awak.

Ron Huizenga: Terima kasih banyak dan sebelum kita melompat ke dalamnya, saya akan melalui beberapa slaid dan kemudian sedikit demo kerana, seperti Eric dan Malcolm telah menunjukkan, ini adalah topik yang sangat luas dan mendalam, dan dengan apa yang kita bercakap tentang hari ini kita hanya mengikis permukaannya kerana terdapat begitu banyak aspek dan begitu banyak perkara yang kita benar-benar perlu dipertimbangkan dan melihat dari arsitektur yang didorong oleh perniagaan. Dan pendekatan kami adalah benar-benar membuat model berasaskan dan memperoleh nilai sebenar daripada model kerana anda boleh menggunakannya sebagai kenderaan komunikasi serta lapisan untuk membolehkan sistem lain. Sama ada anda melakukan senibina berorientasikan perkhidmatan, atau perkara-perkara lain, model ini benar-benar menjadi nadi dari apa yang berlaku, dengan semua metadata di sekelilingnya dan data yang anda ada dalam perniagaan anda.

Apa yang saya ingin bicarakan, hampir, hampir mengambil langkah ini mundur, kerana Malcolm telah menyentuh beberapa sejarah tentang cara penyelesaian telah berkembang dan jenis itu. Satu cara untuk benar-benar menunjukkan betapa pentingnya untuk mempunyai senibina data yang baik adalah kes penggunaan yang sering digunakan ketika saya berunding sebelum saya masuk ke dalam peranan pengurusan produk, dan itu, saya akan pergi ke organisasi sama ada mereka melakukan transformasi perniagaan atau hanya menggantikan beberapa sistem sedia ada dan jenis perkara itu, dan ia menjadi jelas dengan cepat bagaimana organisasi yang kurang memahami data mereka sendiri. Jika anda mengambil kes penggunaan tertentu seperti ini, sama ada anda seorang perunding masuk atau mungkin orang yang baru saja bermula dengan organisasi, atau organisasi anda telah dibina selama bertahun-tahun dengan memperoleh syarikat yang berbeza, apa yang anda tamatkan dengan persekitaran yang sangat kompleks dengan cepat, dengan beberapa teknologi baru yang berbeza, serta teknologi warisan, penyelesaian ERP dan segala yang lain.

Jadi salah satu perkara yang boleh kita lakukan dengan pendekatan pemodelan kami adalah untuk menjawab soalan, bagaimana saya dapat memahami semua ini? Kami benar-benar boleh mula memotong maklumat bersama-sama, sehingga perniagaan dapat memanfaatkan maklumat yang kami miliki dengan baik. Dan ia keluar, apa yang kita ada di dalam persekitaran tersebut? Bagaimana saya boleh menggunakan model untuk mengusir maklumat yang saya perlukan dan memahami maklumat yang lebih baik? Dan kemudian kita mempunyai jenis metadata tradisional untuk semua perkara yang berbeza seperti model data hubungan, dan kami digunakan untuk melihat perkara-perkara seperti definisi dan kamus data, anda tahu, jenis data dan jenis perkara itu. Tetapi bagaimana pula dengan metadata tambahan yang anda ingin tangkap untuk benar-benar memberikan lebih banyak makna kepadanya? Seperti mana entiti mana-mana yang benar-benar calon yang harus menjadi objek data rujukan, yang seharusnya menjadi objek pengurusan data master dan jenis benda dan mengikatnya bersama-sama. Dan bagaimana maklumat mengalir melalui organisasi? Data mengalir dari bagaimana ia dimakan dari sudut pandang proses, tetapi juga keturunan data dari segi perjalanan maklumat melalui perniagaan kami dan bagaimana ia berjalan melalui sistem yang berbeza, atau melalui kedai data, jadi kami tahu apabila kita sedang membina penyelesaian I, atau jenis perkara itu, kita sebenarnya mengambil maklumat yang betul untuk tugas itu.

Dan kemudian, sangat penting ialah, bagaimana kita boleh mendapatkan semua pihak yang berkepentingan untuk bekerjasama, dan terutamanya pihak berkepentingan perniagaan kerana mereka adalah orang yang memberi kita makna sebenar tentang apa data itu. Perniagaan, pada akhir hari, memiliki data. Mereka membekalkan definisi untuk perbendaharaan kata dan perkara yang dikatakan Eric, jadi kita memerlukan tempat untuk mengikat semua itu bersama-sama. Dan cara yang kita lakukan adalah melalui model pemodelan data dan arsitektur repositori data kami.

Saya akan menyentuh beberapa perkara. Saya akan bercakap mengenai Edisi Pasukan ER / Studio Enterprise. Terutama saya akan bercakap tentang produk seni bina data di mana kami melakukan pemodelan data dan jenis perkara itu, tetapi terdapat banyak komponen suite lain yang saya akan sentuh secara ringkas. Anda akan melihat satu coretan Arkitek Perniagaan, yang mana kita boleh melakukan model konseptual, tetapi kita juga boleh melakukan model proses perniagaan dan kita boleh mengikat model-model proses untuk menghubungkan data sebenar yang kita ada dalam model data kami. Ia benar-benar membantu kami untuk mengikat bersama. Arkitek Perisian membolehkan kami melakukan pembinaan tambahan seperti pemodelan UML dan jenis perkara untuk memberi logik sokongan kepada beberapa sistem dan proses lain yang kami bincangkan. Tetapi yang sangat penting apabila kita bergerak ke bawah, kita mempunyai repositori dan pelayan pasukan, dan saya akan bercakap tentang itu sebagai dua bahagian yang sama. Repositori adalah tempat kami menyimpan semua metadata yang dimodelkan serta semua metadata perniagaan dari segi glosari dan istilah perniagaan. Dan kerana kita mempunyai persekitaran berasaskan repositori ini, kita kemudian dapat menjahit semua perkara-perkara yang berbeza bersama-sama dalam persekitaran yang sama dan kemudian kita boleh membuat mereka yang tersedia untuk konsumsi, bukan hanya untuk orang-orang teknis tetapi juga para ahli perniagaan. Dan itulah bagaimana kita benar-benar mula memacu kerjasama.

Dan kemudian bahagian terakhir yang saya akan bincangkan secara ringkas adalah, apabila anda berjalan dalam persekitaran ini, ia bukan hanya pangkalan data yang anda ada di sana. Anda akan mempunyai beberapa pangkalan data, kedai data, anda juga akan mempunyai banyak, apa yang saya akan panggil, artifak warisan. Mungkin orang telah menggunakan Visio atau gambar rajah lain untuk memetakan beberapa perkara. Mungkin mereka mempunyai alat pemodelan lain dan jenis perkara itu. Jadi, apa yang boleh kita lakukan dengan MetaWizard ini sebenarnya mengambil sebahagian daripada maklumat itu dan membawanya ke dalam model kami, menjadikannya semasa dan boleh menggunakannya, menggunakannya, dalam keadaan sekarang sekali lagi, dan bukannya hanya duduk di sana. Ia kini menjadi sebahagian aktif dalam model kerja kami, yang sangat penting.

Apabila anda masuk ke dalam organisasi, seperti yang saya katakan, banyak sistem yang berbeza di luar sana, banyak penyelesaian ERP, penyelesaian jabatan yang tidak sesuai. Banyak organisasi juga menggunakan penyelesaian SaaS, yang juga dikawal dan diuruskan secara luaran, jadi kami tidak mengawal pangkalan data dan jenis perkara dalam tuan rumah pada mereka, tetapi kami masih perlu tahu apa yang data itu kelihatan dan, tentu saja, metadata di sekelilingnya. Apa yang kita juga temukan adalah banyak sistem warisan usang yang belum dibersihkan kerana pendekatan berasaskan projek yang dibicarakan oleh Malcolm. Sungguh menakjubkan bagaimana dalam beberapa tahun kebelakangan ini, organisasi akan berputar-putar projek, mereka akan menggantikan sistem atau penyelesaian, tetapi sering kali tidak cukup anggaran projek yang tersisa untuk menghapuskan penyelesaian usang, sehingga sekarang mereka sedang dalam perjalanan. Dan kita perlu memikirkan apa yang sebenarnya dapat kita lenyapkan dalam persekitaran kita dan juga apa yang berguna pada masa hadapan. Dan hubungannya dengan strategi penolakan yang lemah. Itulah sebahagian dan perkara yang sama.

Apa yang kita juga temukan, kerana banyak organisasi telah dibina dari semua penyelesaian yang berbeza ini, kita melihat banyak antara muka titik-ke-titik dengan banyak data bergerak di beberapa tempat. Kita perlu dapat merasionalkan itu dan mengetahui keturunan data yang saya sebutkan sebelum ini supaya kita boleh mempunyai strategi yang lebih padan seperti penggunaan seni bina berorientasikan perkhidmatan, bas perkhidmatan perusahaan dan jenis perkara, untuk menyampaikan maklumat yang betul kepada jenis model penerbitan dan langganan yang kami gunakan dengan betul di seluruh perniagaan kami. Sudah tentu, kita masih perlu melakukan beberapa jenis analisis, sama ada kita menggunakan gudang data, data data dengan ETL tradisional atau menggunakan beberapa tasik data baru. Semuanya datang kepada perkara yang sama. Ini semua data, sama ada data besar, sama ada data tradisional dalam pangkalan data relasi, kita perlu membawa semua data itu bersama-sama supaya kita dapat mengurusnya dan mengetahui apa yang kita hadapi sepanjang model kita.

Sekali lagi, kerumitan yang akan kita lakukan ialah kita mempunyai beberapa langkah yang kita mahu lakukan. Pertama sekali, anda berjalan masuk dan anda mungkin tidak mempunyai pelan tindakan seperti apa landskap maklumat itu. Dalam alat pemodelan data seperti ER / Studio Data Architect anda mula-mula akan melakukan banyak kejuruteraan terbalik dari segi titik di sumber-sumber data yang ada di luar sana, bawa mereka masuk dan kemudian jahitkan mereka bersama-sama dengan lebih banyak wakil model yang mewakili keseluruhan perniagaan. Yang penting, adakah kita mahu dapat menguraikan model-model tersebut di sepanjang garis perniagaan supaya kita dapat mengaitkannya dengan potongan-potongan yang lebih kecil, yang juga berkaitan dengan perniagaan kita, dan penganalisis perniagaan kita dan pihak berkepentingan lain yang bekerja di atasnya.

Menamakan piawaian adalah sangat penting dan saya bercakap mengenainya dalam beberapa cara di sini. Menamakan piawaian dari segi cara kami menamakan sesuatu dalam model kami. Ia cukup mudah dilakukan dalam model logik, di mana kita mempunyai konvensyen penamaan yang baik dan kamus data yang baik untuk model kami, tetapi kemudian juga, kita melihat konvensyen penamaan berlainan untuk banyak model fizikal yang kita bawa masuk. jurutera terbalik, kita sering melihat nama yang disingkat dan jenis perkara yang akan saya bicarakan. Dan kita perlu menterjemahkannya kembali ke dalam nama Inggeris yang bermakna yang bermakna kepada perniagaan supaya kita dapat memahami apa semua data ini adalah yang kita ada dalam alam sekitar. Dan kemudian pemetaan sejagat adalah bagaimana kita menyusunnya bersama-sama.

Di samping itu, kami kemudiannya akan mendokumen dan mentakrifkan lagi dan di situlah kami dapat mengklasifikasikan data kami dengan lebih lanjut dengan sesuatu yang disebut Lampiran, bahawa saya akan menunjukkan kepada anda beberapa slaid. Dan kemudian menutup gelung itu, kami ingin menerapkan maksud perniagaan itu, di mana kami mengikat dalam glosari perniagaan kami dan boleh menghubungkannya dengan artifak model kami yang berbeza, jadi kami tahu, ketika kami bercakap tentang istilah perniagaan tertentu, di mana itu dilaksanakan dalam data kami sepanjang organisasi. Dan kemudian, saya sudah membicarakan fakta bahawa kita memerlukan semua ini sebagai repositori yang berdasarkan banyak kerjasama dan kemampuan penerbitan, jadi pihak berkepentingan kita boleh menggunakannya. Saya akan bercakap tentang kejuruteraan terbalik dengan cepat. Saya sudah sememangnya memberikan anda satu kemuncak yang sangat cepat itu. Saya akan menunjukkan kepada anda dalam demo sebenar hanya untuk menunjukkan kepada anda beberapa perkara yang boleh kami bawa di sana.

Dan saya ingin bercakap mengenai beberapa jenis model dan diagram yang berbeza yang akan kami hasilkan dalam senario jenis ini. Jelas sekali kita akan melakukan model konseptual dalam banyak keadaan; Saya tidak akan menghabiskan banyak masa untuk itu. Saya benar-benar mahu bercakap mengenai model logik, model fizikal dan model khusus yang boleh kita buat. Dan pentingnya kita dapat membuat semua ini dalam platform pemodelan yang sama supaya kita boleh menyusunnya bersama. Ini termasuk model dimensi dan juga model yang menggunakan beberapa sumber data baru, seperti NoSQL yang akan saya tunjukkan kepada anda. Dan kemudian, apakah model garis keturunan data kelihatan seperti? Dan bagaimana kita membuat data tersebut ke dalam model proses perniagaan, adalah apa yang akan kita bincangkan seterusnya.

Saya akan beralih ke persekitaran pemodelan di sini untuk memberi anda gambaran keseluruhan yang sangat tinggi dan cepat. Dan saya percaya anda sepatutnya dapat melihat skrin saya sekarang. Pertama sekali saya ingin membincangkan hanya jenis model data tradisional. Dan cara kami mahu menganjurkan model apabila kami membawanya, adakah kami mahu dapat menguraikannya. Jadi apa yang anda lihat di sini di sebelah kiri adalah kami mempunyai model logik dan fizikal dalam fail model tertentu ini. Perkara seterusnya ialah, kita boleh memecahkannya sepanjang penguraian perniagaan, jadi itu sebabnya anda melihat folder. Yang berwarna biru muda adalah model logik dan model hijau adalah model fizikal. Dan kita juga boleh melakukan percubaan, jadi dalam ER / Studio, jika anda mempunyai penguraian perniagaan, anda boleh pergi seberapa banyak tahap dalam atau sub-model yang anda suka, dan perubahan yang anda buat pada tahap yang lebih rendah secara automatik mencerminkan pada yang lebih tinggi tahap. Jadi ia menjadi persekitaran pemodelan yang sangat kuat dengan cepat.

Sesuatu yang saya juga ingin menunjukkan bahawa sangat penting untuk mula menarik maklumat ini bersama-sama adalah kita boleh mempunyai beberapa model fizikal yang sesuai dengan satu model logik juga. Seringkali anda mungkin mempunyai model logik tetapi anda mungkin mempunyai model fizikal pada platform yang berbeza dan jenis perkara itu. Mungkin seseorang itu contoh SQL Server itu, mungkin orang lain adalah contoh Oracle. Kami mempunyai keupayaan untuk mengikat semua itu bersama dalam persekitaran pemodelan yang sama. Dan di sana lagi, apa yang saya dapati di sini adalah model gudang data yang sebenarnya yang boleh, sekali lagi, berada dalam persekitaran pemodelan yang sama atau kita boleh memilikinya dalam repositori dan menghubungkannya dalam pelbagai perkara juga.

Apa yang saya benar-benar mahu menunjukkan kepada anda tentang ini adalah beberapa perkara lain dan varian lain model yang kita masuki. Jadi, apabila kita masuk ke dalam model data tradisional seperti ini, kita digunakan untuk melihat entiti yang biasa dengan lajur dan metadata dan jenis perkara itu, tetapi sudut pandangan itu berbeza dengan cepat apabila kita mula berurusan dengan beberapa teknologi NoSQL yang lebih baru, atau sesetengah orang masih mahu memanggil mereka, teknologi data besar.

Jadi sekarang mari kita katakan kami juga mendapat sarang di persekitaran kita. Jika kita membalikkan jurutera dari persekitaran Sarang - dan kita boleh maju dan membalikkan jurutera dari Hive dengan alat pemodelan yang sama - kita melihat sesuatu yang sedikit berbeza. Kami masih melihat semua data yang dibina di sana, tetapi TDL kami berbeza. Bagi anda yang biasa melihat SQL, apa yang akan anda lihat sekarang ialah Hive QL, yang sangat seperti SQL tetapi dari alat yang sama, anda kini dapat mula bekerja dengan bahasa skrip yang berbeza. Jadi, anda boleh membuat model dalam persekitaran ini, menjana persekitaran sarang, tetapi yang paling penting, dalam senario yang telah saya nyatakan, anda boleh membalikkan semua insinyur dan memahaminya dan mula menyusunnya bersama-sama juga .

Mari kita ambil yang lain yang sedikit berbeza. MongoDB adalah satu lagi platform yang kami menyokong secara asli. Dan apabila anda mula masuk ke dalam jenis persekitaran JSON di mana anda mempunyai kedai dokumen, JSON adalah haiwan yang berbeza dan ada yang membinanya, yang tidak sesuai dengan model relasi. Anda tidak lama lagi akan berurusan dengan konsep seperti objek tertanam dan tatasusunan tertanam objek apabila anda mula menyoal JSON dan konsep-konsep tersebut tidak wujud dalam notasi hubungan tradisional. Apa yang telah kami lakukan di sini ialah kami telah memperluaskan notasi dan katalog kami untuk mengendalikannya dalam persekitaran yang sama.

Jika anda melihat di sebelah kiri di sini, daripada melihat perkara seperti entiti dan jadual, kami memanggil mereka objek. Dan anda melihat notasi yang berbeza. Anda masih melihat jenis tipikal notasi rujukan di sini, tetapi entiti-entiti biru yang saya tunjukkan dalam gambarajah ini sebenarnya adalah objek yang terbenam. Dan kami menunjukkan kisah yang berbeza. Kardinalitas berlian bermaksud bahawa ia adalah objek pada satu hujung, tetapi kardinaliti satu bermakna bahawa kita ada, dalam penerbit jika kita mengikuti hubungan itu, kita mempunyai objek alamat yang terbenam. Dalam menyoal siasat JSON kami mendapati ia betul-betul struktur objek yang sama yang tertanam dalam penaung, tetapi itu sebenarnya tertanam sebagai pelbagai objek. Kami melihat bahawa, bukan sahaja melalui penyambung sendiri, tetapi jika anda melihat entiti sebenar, anda akan melihat bahawa anda melihat alamat di bawah penaung yang juga diklasifikasikan sebagai pelbagai objek. Anda mendapat gambaran yang sangat deskriptif tentang bagaimana anda boleh membawanya.

Dan sekali lagi, sekarang apa yang kita lihat setakat ini dalam beberapa saat adalah model relasional tradisional yang pelbagai peringkat, kita boleh melakukan perkara yang sama dengan Hive, kita boleh melakukan perkara yang sama dengan MongoDB, dan sumber data besar lain seperti baik. Apa yang boleh kita lakukan, dan saya akan menunjukkan kepada anda ini dengan cepat, saya bercakap mengenai hakikat membawa perkara dari kawasan lain yang berbeza. Saya akan menganggap saya akan mengimport model dari pangkalan data atau jurutera terbalik, tetapi saya akan membawanya dari metadata luaran. Hanya untuk memberi anda pandangan yang sangat cepat mengenai semua jenis perkara yang boleh kita mulakan.

Seperti yang anda lihat, kami mempunyai segudang perkara yang sebenarnya boleh membawa metadata ke dalam persekitaran pemodelan kami. Bermula dengan perkara-perkara seperti Amazon Redshift, Cassandra, banyak platform data besar lain, jadi anda lihat banyak yang disenaraikan. Ini adalah dalam susunan abjad. Kami melihat banyak sumber data besar dan jenis perkara itu. Kami juga melihat banyak persekitaran pemodelan tradisional atau lebih tua yang sebenarnya boleh membawa metadata itu melalui. Jika saya pergi ke sini - dan saya tidak akan meluangkan masa pada setiap daripada mereka - kita melihat banyak perkara yang berbeza yang boleh kita bawa dari, dari segi model pemodelan dan platform data. Dan sesuatu yang sangat penting untuk disedari di sini adalah bahagian lain yang boleh kita lakukan apabila kita mula bercakap mengenai keturunan data, di Enterprise Team Edition kita juga boleh menyoal sumber ETL, sama ada perkara seperti Talend atau pemetaan Perkhidmatan Maklumat SQL Server, kita boleh sebenarnya membawa masuk untuk memulakan rajah garis keturunan data kami serta menarik gambaran tentang apa yang berlaku dalam transformasi tersebut. Secara keseluruhannya, kami mempunyai lebih daripada 130 jambatan yang berbeza yang sebenarnya merupakan sebahagian daripada produk Enterprise Team Edition, jadi ia benar-benar membantu kami untuk menggabungkan semua artifak ke dalam satu persekitaran pemodelan dengan sangat cepat.

Akhir sekali, saya juga ingin bercakap mengenai hakikat bahawa kita tidak boleh lupa hakikat bahawa kita memerlukan jenis lain yang dibina jika kita melakukan pergudangan data atau apa-apa jenis analitik. Kami masih ingin mempunyai keupayaan untuk melakukan perkara seperti model dimensi di mana kita mempunyai jadual fakta dan kita mempunyai dimensi dan jenis perkara. Satu perkara yang saya ingin tunjukkan kepada anda juga ialah kami juga boleh mempunyai sambungan kepada metadata kami yang membantu kami untuk mengkategorikan apakah jenis dimensi dan segala yang lain. Jadi, jika saya melihat tab data dimensi di sini, misalnya, pada salah satu daripada ini, ia akan secara automatik mengesan, berdasarkan corak model yang dilihatnya, dan memberi anda titik permulaan sama ada ia menganggap ia dimensi atau jadual fakta. Tetapi di luar itu, apa yang boleh kita lakukan adalah dalam dimensi dan jenis perkara itu kita juga mempunyai pelbagai jenis dimensi yang boleh kita gunakan untuk mengklasifikasikan data dalam persekitaran jenis pergudangan data juga. Jadi keupayaan yang sangat kuat yang kita jahitan ini sama sekali.

Saya akan melompat ke dalam satu ini sejak saya berada di persekitaran demo sekarang dan menunjukkan kepada anda beberapa perkara lain sebelum saya kembali kepada slaid. Salah satu perkara yang kami telah baru-baru ini ditambahkan kepada ER / Studio Data Architect adalah kami telah menghadapi situasi - dan ini adalah kes penggunaan yang sangat biasa apabila anda sedang menjalankan projek - pemikir berfikir dari segi objek, sedangkan data kami Pemodelan cenderung untuk berfikir dari segi jadual dan entiti dan jenis perkara itu. Ini adalah model data yang sangat sederhana, tetapi ia mewakili beberapa konsep asas, di mana pemaju atau penganalisis perniagaan atau pengguna perniagaan, mungkin memikirkannya sebagai objek atau konsep perniagaan yang berlainan. Sudah menjadi sangat sukar untuk mengklasifikasikan ini sehingga sekarang tetapi apa yang sebenarnya kami lakukan dalam ER / Studio Enterprise Edition Edition, dalam siaran 2016, kini kami mempunyai konsep yang dikenali sebagai Objek Data Perniagaan. Dan apa yang membolehkan kita lakukan adalah membolehkan kita merangkum kumpulan entiti atau jadual ke objek perniagaan yang benar.

Sebagai contoh, apa yang kami dapati di sini pada pandangan baru ini ialah tajuk Pesanan Pembelian dan Talian Pesanan telah ditarik bersama sekarang, mereka dikemas sebagai objek, kita akan memikirkannya sebagai satu unit kerja apabila kita mengekalkan data, dan kami membawanya bersama sehingga kini sangat mudah untuk mengaitkannya dengan khalayak yang berlainan. Mereka boleh diguna semula sepanjang persekitaran pemodelan. Mereka adalah objek yang benar, bukan hanya membina lukisan, tetapi kita juga mempunyai manfaat tambahan yang apabila kita sebenarnya berkomunikasi dari perspektif pemodelan kita boleh merosot secara selektif atau mengembangkannya supaya kita boleh menghasilkan pandangan yang diringkaskan untuk dialog dengan penonton pihak berkepentingan tertentu, dan kami juga boleh memastikan pandangan yang lebih terperinci seperti yang kita lihat di sini untuk lebih banyak penonton teknikal. Ia benar-benar memberikan kita komunikasi yang sangat baik. Apa yang kita lihat sekarang adalah menggabungkan pelbagai jenis model yang berbeza, dengan menambah konsep objek data perniagaan, dan sekarang saya akan bercakap tentang bagaimana kita sebenarnya menggunakan lebih banyak arti kepada jenis perkara ini dan bagaimana kita menyusunnya bersama-sama dalam persekitaran keseluruhan.

Saya hanya cuba mencari kembali WebEx saya di sini supaya saya dapat melakukannya. Dan di sana kita pergi, kembali ke slaid Tech Tech. Saya akan terus maju beberapa slaid di sini kerana anda sudah melihatnya dalam demonstrasi model itu sendiri. Saya ingin bercakap mengenai standard penamaan dengan cepat. Kami mahu memohon dan menguatkuasakan piawaian penamaan yang berbeza. Apa yang ingin kita lakukan ialah, kita mempunyai keupayaan untuk benar-benar menyimpan templat piawaian penamaan dalam repositori kami untuk membina makna tersebut melalui, melalui perkataan atau frasa atau singkatan, dan mengikatnya kembali kepada jenis perkataan Inggeris yang bermakna. Kami akan menggunakan istilah perniagaan, singkatan untuk masing-masing, dan kami boleh menentukan perintah, kes-kes dan menambah awalan dan sufiks. Kes penggunaan biasa untuk ini biasanya apabila orang telah membina model logik dan kemudian pergi ke hadapan untuk membuat model fizikal di mana mereka mungkin telah menggunakan singkatan dan segala yang lain.

Perkara yang indah adalah sama kuat, bahkan lebih kuat lagi, jika kita hanya dapat memberitahu apa yang beberapa piawai penamaan itu ada pada beberapa pangkalan data fizikal yang kita telah membalikkan kejuruteraan, kita boleh mengambil singkatan itu, menjadikannya lebih lama kata-kata, dan membawa mereka ke dalam bahasa Inggeris. Kami sebenarnya boleh mendapatkan nama yang betul untuk apa yang kelihatan seperti data kami. Seperti yang saya katakan, kes penggunaan biasa ialah kita akan bergerak maju, logik kepada fizikal, dan memetakan kedai data dan jenis perkara itu. Jika anda melihat tangkapan skrin di sebelah kanan, anda akan melihat bahawa terdapat nama yang disingkat dari nama sumber dan apabila kami telah menggunakan templat standard penamaan, kami sebenarnya telah mendapat lebih banyak nama penuh. Dan kita boleh meletakkan ruang dan semua perkara seperti itu jika kita mahu, bergantung kepada templat standard penamaan yang kita gunakan. Kami boleh membuatnya kelihatan tetapi kami mahu melihatnya untuk membawa masuk model kami. Hanya apabila kita tahu apa yang dipanggil, kita sebenarnya boleh mula memasukkan definisi kepadanya, kerana melainkan jika kita tahu apa itu, bagaimana kita dapat menerapkan maksudnya?

Perkara yang baik adalah, sebenarnya kita boleh menggunakan ini apabila kita melakukan pelbagai perkara. Saya bercakap tentang kejuruteraan terbalik, kita sebenarnya boleh menggunakan templat piawaian menamakan secara serentak apabila kita melakukan kejuruteraan terbalik. Jadi dalam satu set langkah melalui wizard, apa yang dapat kita lakukan ialah, jika kita tahu apa konvensinya, kita boleh membalikkan jurutera pangkalan data fizikal, ia akan membawa kembali sebagai model fizikal dalam persekitaran pemodelan dan ia juga akan memohon mereka penamaan konvensyen. Oleh itu, kita akan melihat bagaimana representasi nama bahasa Inggeris dalam model logik yang sepadan dalam persekitaran. Kami juga boleh melakukannya dan menggabungkannya dengan penanda skema XML supaya kami dapat mengambil model dan bahkan menolaknya dengan singkatan kami, sama ada kami melakukan rangka kerja SOA atau jenis perkara itu, maka kami juga boleh menolak konvensyen penamaan berbeza bahawa kita sebenarnya telah tersimpan dalam model itu sendiri. Ia memberi kita banyak keupayaan yang sangat kuat.

Sekali lagi, inilah contoh bagaimana ia kelihatan seperti jika saya mempunyai templat. Ini sebenarnya menunjukkan bahawa saya mempunyai EMP untuk "pekerja, " SAL untuk "gaji, " PLN untuk "merancang" dalam konvensyen piawaian penamaan. Saya juga boleh memohon mereka untuk menjalankannya secara interaktif kerana saya membina model dan meletakkan perkara-perkara. Jika saya menggunakan singkatan ini dan saya menaip dalam "Rancangan Gaji Pekerja" pada nama entiti, ia akan bertindak dengan templat piawai penamaan Saya telah menentukan di sini, ia akan memberi saya EMP_SAL_PLN kerana saya mencipta entiti dan memberikan saya nama-nama fizikal yang sepadan dengan segera.

Sekali lagi, sangat baik untuk ketika kami merancang dan meneruskan kejuruteraan juga. Kami mempunyai konsep yang sangat unik dan ini adalah di mana kita benar-benar mula membawa persekitaran ini bersama-sama. Dan ia dipanggil Universal Mappings. Setelah kami membawa semua model ini ke dalam persekitaran kami, apa yang dapat kami lakukan, dengan mengandaikan bahawa kami telah menggunakan konvensyen penamaan ini dan mereka mudah dicari, kini kami boleh menggunakan pembinaan yang dipanggil Universal Mappings di ER / Studio. Kita boleh menghubungkan entiti merentasi model. Di mana sahaja kita melihat "pelanggan" - kita mungkin mempunyai "pelanggan" dalam banyak sistem yang berbeza dan banyak pangkalan data yang berbeza - kita boleh mula menghubungkan semua itu bersama-sama supaya apabila saya bekerja dengannya dalam satu model saya boleh melihat di mana manifestasi pelanggan dalam model lain. Dan kerana kita mempunyai lapisan model yang mewakili itu, kita juga boleh mengikatnya ke sumber data dan membawanya ke dalam tempat kami menggunakan pertanyaan yang digunakan oleh pangkalan data ini. Ia benar-benar memberikan kita keupayaan untuk mengikat semua ini bersama-sama dengan sangat kohesi.

Saya telah menunjukkan kepada anda objek data perniagaan. Saya juga ingin membincangkan mengenai sambungan metadata, yang kami panggil Lampiran, dengan cepat. Apa yang dilakukan itu memberi kami keupayaan untuk membuat metadata tambahan untuk objek model kami. Sering kali saya akan menubuhkan jenis sifat ini untuk memacu banyak perkara yang berbeza daripada perspektif tadbir urus data dan kualiti data, dan juga untuk membantu kami dengan pengurusan data induk dan dasar pengekalan data. Idea asas adalah anda membuat klasifikasi ini dan anda boleh melampirkannya ke mana sahaja anda mahu, di peringkat jadual, peringkat lajur, jenis perkara itu. Kes penggunaan yang paling umum, tentu saja, ialah entiti itu adalah jadual, dan kemudian saya dapat menentukan: apakah objek data tuan saya, apakah jadual rujukan saya, apakah jadual transaksi saya? Dari perspektif kualiti data, saya dapat melakukan klasifikasi dari segi kepentingan perniagaan sehingga kami dapat memprioritaskan usaha pembersihan data dan jenis perkara itu.

Sesuatu yang sering diabaikan adalah, apakah dasar pengekalan untuk pelbagai jenis data dalam organisasi kami? Kita boleh menetapkan ini dan kita sebenarnya boleh melampirkannya kepada pelbagai jenis artifak maklumat dalam persekitaran pemodelan kita dan, tentu saja, repositori kita juga. Kecantikan adalah, lampiran ini hidup dalam kamus data kami sehingga ketika kita menggunakan kamus data perusahaan dalam lingkungan, kita dapat melampirkannya ke beberapa model. Kita hanya perlu mentakrifkannya sekali dan kita boleh memanfaatkannya berulang-ulang merentas model yang berbeza dalam persekitaran kita. Ini hanyalah tangkapan skrin cepat untuk menunjukkan bahawa anda sebenarnya boleh menentukan apabila anda melakukan lampiran, apa semua keping yang anda mahu melampirkannya. Dan contoh ini di sini sebenarnya adalah senarai nilai-nilai, jadi apabila mereka masuk, anda boleh memilih dari senarai nilai-nilai, anda mempunyai banyak kawalan dalam persekitaran pemodelan apa yang dipilih, dan anda juga boleh menetapkan apa yang lalai nilai adalah jika nilai tidak dipilih. Jadi banyak kuasa di sana. Mereka tinggal dalam kamus data.

Sesuatu yang saya ingin tunjukkan sedikit ke bawah pada skrin ini, selain itu anda melihat lampiran jenis muncul di bahagian atas, di bawahnya anda melihat maklumat keselamatan data. Sebenarnya kita boleh menggunakan dasar keselamatan data untuk maklumat yang berbeza di dalam persekitaran. Untuk pemetaan pematuhan yang berbeza, klasifikasi keselamatan data, kami menghantar beberapa daripada mereka keluar dari kotak yang anda boleh menjana dan mula digunakan, tetapi anda boleh menentukan pemetaan pematuhan dan piawaian anda sendiri juga. Sama ada anda melakukan HIPAA atau mana-mana inisiatif lain di luar sana. Dan anda boleh mula membina set metadata yang sangat kaya ini dalam persekitaran anda.

Dan kemudian Glossary dan Terma - ini adalah di mana makna perniagaan terikat. Kita sering mempunyai kamus data di luar sana yang sering digunakan oleh organisasi sebagai titik permulaan untuk memulakan kata-kata glosari, tetapi istilah dan verbiage itu selalunya sangat teknikal. Jadi apa yang boleh kita lakukan ialah kita boleh, jika kita mahu, gunakan mereka sebagai titik permulaan untuk mengusir glosari, tetapi kita benar-benar mahukan perniagaan memiliki ini. Apa yang telah kami lakukan dalam persekitaran pelayan pasukan adalah kami telah memberi keupayaan untuk orang membuat definisi perniagaan dan kemudian kami dapat menghubungkannya dengan artifak model yang berbeza yang sesuai dengan lingkungan pemodelannya. Kami juga mengenali titik yang telah dibincangkan sebelum ini, semakin ramai orang yang anda menaip, semakin berpotensi ada kesalahan manusia. Apa yang kami lakukan juga dalam struktur glosari kami ialah, kami menyokong hierarki glosari, jadi kami boleh mempunyai jenis glosari yang berlainan atau pelbagai jenis perkara dalam organisasi, tetapi yang paling penting adalah jika anda sudah mempunyai beberapa sumber di luar sana dengan terma dan segala yang ditakrifkan, kami sebenarnya boleh melakukan import CSV untuk menariknya ke persekitaran pemodelan kami, dan pelayan pasukan kami atau glosari kami juga, dan kemudian mula menghubungkan dari sana. Dan setiap kali sesuatu yang berubah ada jejak audit sepenuhnya tentang apa sebelum dan selepas imej, dari segi definisi dan segala-galanya, dan apa yang akan anda lihat pada masa akan datang juga lebih banyak daripada alur kerja kebenaran jadi kita benar-benar boleh mengawal siapa yang bertanggungjawab terhadapnya, kelulusan oleh jawatankuasa atau individu, dan jenis perkara itu, untuk menjadikan proses tadbir urus lebih mantap apabila kita maju.

Apa ini juga bagi kami adalah apabila kami mempunyai istilah glosari dalam glosari pelayan pasukan kami, ini merupakan contoh penyuntingan dalam entiti dalam model itu sendiri yang saya dibesarkan di sini. Ia mungkin mempunyai istilah yang berkaitan, tetapi apa yang kita juga lakukan adalah jika terdapat kata-kata yang dalam glosari yang terdapat dalam nota atau perihalan apa yang kita ada di entiti kita di sini, ia secara automatik ditunjukkan dalam warna hyperlink yang lebih ringan, dan jika kita tetikus ke atas mereka, kita sebenarnya boleh melihat takrif dari glosari perniagaan juga. Ia bahkan memberikan kita maklumat yang lebih kaya apabila kita memakan maklumat itu sendiri, dengan semua istilah glosari yang ada di sini. Ia benar-benar membantu memperkayakan pengalaman dan menerapkan makna kepada semua yang kami bekerjasama.

Jadi, sekali lagi, itu adalah flyby yang sangat cepat. Jelas sekali kita boleh menghabiskan hari ini apabila kita menyelidiki bahagian-bahagian yang berlainan, tetapi ini adalah flyby yang sangat cepat di permukaan. Apa yang sedang kita usahakan ialah memahami apa persekitaran data kompleks seperti ini. Kami ingin meningkatkan keterlihatan semua artifak data dan bekerjasama untuk mengusir mereka dengan ER / Studio. Kami mahu membolehkan pemodelan data yang lebih cekap dan automatik. Dan itulah semua jenis data yang kita bincangkan, sama ada data besar, data hubungan tradisional, kedai dokumen atau apa-apa lagi. Dan sekali lagi, kami berjaya melakukannya kerana kami mempunyai keupayaan kejuruteraan ke hadapan dan terbalik yang kuat untuk platform yang berlainan dan alat lain yang mungkin anda ada di sana. Dan ini semua tentang perkongsian dan komunikasi di seluruh organisasi dengan semua pemegang kepentingan yang terlibat. Di sinilah kita menerapkan makna melalui piawaian penamaan. Kami kemudiannya menerapkan definisi melalui glosari perniagaan kami. Dan kemudian kami boleh melakukan klasifikasi lanjut untuk semua keupayaan tadbir urus kami yang lain dengan sambungan metadata seperti sambungan kualiti data, klasifikasi untuk pengurusan data induk, atau sebarang klasifikasi jenis lain yang ingin anda gunakan untuk data tersebut. Dan kemudian kita boleh merumuskan lagi dan meningkatkan komunikasi dengan lebih banyak lagi dengan objek data perniagaan, dengan khalayak pemangku kepentingan yang berbeza, khususnya antara model dan pemaju.

Dan sekali lagi, apa yang sangat penting tentang hal ini, di belakang semuanya adalah repositori bersepadu dengan keupayaan pengurusan perubahan yang sangat mantap. Saya tidak mempunyai masa untuk menunjukkannya hari ini kerana ia menjadi agak rumit, tetapi repositori mempunyai keupayaan pengurusan perubahan yang sangat kuat dan laluan audit. Anda boleh buat nama siaran, anda boleh buat versi bernama, dan kami juga mempunyai keupayaan untuk anda yang melakukan pengurusan perubahan, kami boleh mengikat hak ke dalam tugas anda. Kami mempunyai keupayaan hari ini untuk meletakkan tugas dan mengaitkan perubahan model anda dengan tugas, sama seperti pemaju akan mengaitkan perubahan kod mereka dengan tugas atau cerita pengguna yang mereka bekerjasama juga.

Sekali lagi, itu adalah gambaran yang sangat cepat. Saya harap sudah cukup untuk membangkitkan selera makan anda supaya kami dapat melibatkan diri dalam perbualan yang jauh lebih mendalam untuk memecahkan beberapa topik ini ketika kami maju ke depan. Terima kasih atas waktunya, dan kembali kepada awak, Rebecca.

Rebecca Jozwiak: Terima kasih, Ron, yang hebat dan saya mempunyai beberapa soalan dari penonton, tetapi saya mahu memberikan penganalisis kami peluang untuk menyingkirkan gigi mereka kepada apa yang anda katakan. Eric, saya akan pergi ke sana dan mungkin jika anda mahu menangani slaid ini, atau yang lain, kenapa tidak anda pergi dahulu? Atau apa-apa soalan lain.

Eric Little: Sudah tentu. Maaf, apa soalannya, Rebecca? Anda mahu saya bertanya sesuatu yang tertentu atau …?

Rebecca Jozwiak: Saya tahu anda mempunyai beberapa soalan pada mulanya untuk Ron. Sekiranya anda ingin bertanya sekarang kepadanya untuk menangani mana-mana orang itu, atau sebahagian daripada mereka dari slaid anda atau apa-apa lagi yang menarik perhatian anda yang anda ingin bertanya? Mengenai fungsi pemodelan IDERA.

Eric Little: Ya, begitu salah satu daripada perkara itu, Ron, jadi bagaimana anda semua, kelihatan seperti gambar rajah yang anda tunjukkan adalah jenis rajah hubungan entiti umum seperti yang anda biasanya gunakan dalam pembinaan pangkalan data, betul?

Ron Huizenga: Ya, secara amnya, tetapi sudah tentu kita mempunyai jenis yang diperluaskan untuk kedai dokumen dan jenis perkara itu juga. Kami sebenarnya bervariasi dari notasi relasi yang tulen, kami sebenarnya telah menambah notasi tambahan untuk kedai-kedai lain juga.

Eric Little: Adakah ada cara yang anda boleh gunakan jenis pemodelan berdasarkan grafik, jadi ada satu cara untuk mengintegrasikan, contohnya, katakan bahawa saya mempunyai sesuatu seperti kuadran atas, alat pengarang TopBraid atau saya telah melakukan sesuatu di Protégé atau, anda tahu, seperti orang kewangan di FIBO, mereka melakukan banyak kerja dalam semantik, barang-barang RDF - adakah cara untuk membawa pemodelan jenis graf hubungan entiti itu ke dalam alat ini, dan menggunakan ia?

Ron Huizenga: Kami sebenarnya melihat bagaimana kita boleh mengendalikan grafik. Kami tidak mengendalikan pangkalan data grafik dan jenis perkara hari ini, tetapi kami melihat cara yang dapat kami lakukan untuk memperluaskan metadata kami. Maksud saya, kita boleh membawa perkara-perkara melalui XML dan jenis perkara itu sekarang, jika kita sekurang-kurangnya boleh melakukan beberapa jenis pengatur XML untuk membawanya sebagai titik permulaan. Tetapi kita melihat lebih banyak cara yang elegan untuk membawa masuk itu.

Dan saya juga menunjukkan kepada anda senarai jambatan kejuruteraan terbalik yang kami ada di sana juga, jadi kami sentiasa mencari mendapatkan sambungan kepada jambatan tersebut untuk platform tertentu juga. Ini adalah usaha berterusan, jika itu masuk akal, untuk mula merangkul banyak pembinaan baru ini dan platform yang berbeza di luar sana. Tetapi saya boleh mengatakan bahawa kita pasti berada di barisan hadapan untuk melakukan itu. Perkara yang saya tunjukkan, sebagai contoh, MongoDB dan jenis perkara itu, kami adalah vendor pemodel data pertama untuk benar-benar melakukan itu secara asli dalam produk kami sendiri.

Eric Little: Baiklah, ya. Oleh itu, persoalan lain yang saya miliki untuk anda ialah, dari segi tadbir urus dan pemeliharaan - seperti ketika anda menggunakan contoh itu, apabila anda menunjukkan contoh orang yang "pekerja", saya percaya ia adalah " gaji "dan kemudian anda mempunyai" pelan, "ada cara, bagaimana anda menguruskan, contohnya, pelbagai jenis orang yang mungkin ada - katakan anda mempunyai seni bina besar, betul, katakan anda mempunyai perusahaan besar dan orang mula menarik perkara bersama-sama dalam alat ini dan anda mempunyai satu kumpulan di sini yang mempunyai perkataan "pekerja" dan satu kumpulan di sini yang mempunyai perkataan "pekerja." Dan seorang di sini mengatakan "gaji" dan orang lain mengatakan "Gaji."

Bagaimanakah anda mendamaikan dan menguruskan dan mentadbir pelbagai perbezaan? Kerana saya tahu bagaimana kita akan melakukannya di dunia grafik, anda tahu, anda akan menggunakan senarai sinonim atau anda akan mengatakan ada satu konsep dan mempunyai beberapa atribut, atau anda boleh katakan dalam model SKOS Saya mempunyai label pilihan dan saya mempunyai banyak label alternatif yang boleh saya gunakan. Bagaimana anda berbuat demikian?

Ron Huizenga: Kami melakukannya dalam beberapa cara yang berbeza, dan terutamanya mari kita bercakap tentang istilah pertama. Salah satu perkara yang kita lakukan, tentu saja, ialah kita ingin mempunyai istilah yang ditakrifkan atau yang dibenarkan dan dalam glosari perniagaan jelas adalah di mana kita mahu mereka. Dan kami membenarkan pautan kepada sinonim dalam glosari perniagaan dan juga apa yang anda boleh lakukan ialah anda boleh katakan, di sini istilah saya, tetapi anda juga boleh menentukan apa semua sinonim bagi mereka.

Sekarang perkara yang menarik, tentu saja, adalah apabila anda mula melihat landskap data yang luas ini dengan semua sistem yang berbeza yang anda ada di sana, anda tidak boleh pergi ke sana dan menukar jadual yang sepadan dan jenis perkara untuk sesuai dengan piawaian penamaan kerana ia mungkin satu pakej yang anda beli, jadi anda tidak mempunyai kawalan untuk mengubah pangkalan data atau apa-apa sahaja.

Apa yang boleh kita lakukan di sana, di samping dapat mengaitkan definisi glossary, adalah melalui pemetaan sejagat yang saya bicarakan, apa yang akan kita lakukan, dan jenis pendekatan yang disyorkan, adalah untuk mempunyai model logik menyeluruh yang menyatakan apa konsep perniagaan yang berbeza ini adalah yang anda sedang bicarakan. Ikat istilah glosari perniagaan ke dalamnya, dan perkara yang bagus sekarang ialah bahawa anda mempunyai pembinaan ini yang mewakili entiti logik kerana ia, anda boleh mula menghubungkan dari entiti logik itu kepada semua pelaksanaan entiti logik itu sistem yang berbeza.

Kemudian di mana anda perlu untuk itu, anda boleh lihat, oh, "orang" di sini dipanggil "pekerja" dalam sistem ini. "Gaji" di sini dipanggil "upah" di sini dalam sistem lain ini. Kerana anda akan melihatnya, anda akan melihat semua manifestasi yang berbeza daripada itu kerana anda telah menghubungkannya bersama-sama.

Eric Little: Baiklah, ya, dapatkannya. Dalam erti kata itu, adakah ia selamat untuk mengatakan bahawa seperti beberapa pendekatan berorientasi objek?

Ron Huizenga: Agaknya. Ia sedikit lebih intensif daripada, saya rasa anda boleh katakan. Maksud saya, anda boleh mengambil pendekatan menghubungkan dan melancarkan secara manual dan memeriksa serta melakukan semuanya. Satu perkara yang saya tidak mempunyai peluang untuk dibincangkan - kerana sekali lagi, kita mempunyai banyak keupayaan - kita juga mempunyai antara muka automasi penuh dalam alat Data Architect itu sendiri. Dan keupayaan makro, yang benar-benar bahasa pengaturcaraan dalam alat itu. Jadi kita boleh melakukan perkara-perkara seperti menulis makro, memilikinya keluar dan menyoal perkara dan membuat pautan untuk anda. Kami menggunakannya untuk mengimport dan mengeksport maklumat, kami boleh menggunakannya untuk menukar perkara atau menambah atribut, peristiwa yang berpangkalan di model itu sendiri, atau kami boleh menggunakannya untuk menjalankan dalam kumpulan untuk benar-benar keluar dan menginterogasi perkara dan benar-benar mengisi pembentukan yang berbeza dalam model. Jadi terdapat antara muka automasi penuh yang boleh dimanfaatkan oleh orang ramai. Dan menggunakan pemetaan universal dengan mereka akan menjadi cara yang sangat berkuasa untuk melakukannya.

Rebecca Jozwiak: Baiklah, terima kasih Ron, dan terima kasih Eric. Mereka adalah soalan yang hebat. Saya tahu kami berlari sedikit ke puncak jam, tetapi saya ingin memberi Malcolm satu peluang untuk melemparkan beberapa soalan kepada Ron. Malcolm?

Malcolm Chisholm: Terima kasih, Rebecca. Jadi, Ron, sangat menarik, saya nampak ada banyak keupayaan di sini. Salah satu perkara yang saya sangat berminat adalah, katakan jika kita mempunyai projek pembangunan, bagaimana anda melihat pemodelan data menggunakan keupayaan ini dan bekerja mungkin lebih bersama-sama dengan penganalisis perniagaan, dengan profiler data, dengan penganalisis kualiti data, dan dengan penaja perniagaan yang akhirnya akan bertanggungjawab untuk keperluan maklumat sebenar dalam projek itu. Bagaimanakah pemodelan data benar-benar, anda tahu, membuat projek lebih berkesan dan cekap dengan keupayaan yang kita lihat?

Ron Huizenga: Saya fikir bahawa salah satu perkara pertama yang perlu anda lakukan adalah sebagai pemodelan data - dan saya tidak bermaksud untuk memilih beberapa pemodel, tetapi saya juga akan - sesetengah orang masih mempunyai tanggapan bahawa pemodel data benar-benar pengawal jenis peranan seperti, kita menentukan bagaimana ia berfungsi, kita pengawal yang memastikan bahawa semuanya adalah betul.

Kini terdapat aspek itu, yang perlu anda pastikan bahawa anda menentukan seni bina data yang baik dan segala yang lain. Tetapi perkara yang lebih penting adalah sebagai pemodel data - dan saya dapati ini agak jelas apabila saya berunding - adakah anda perlu menjadi fasilitator, jadi anda perlu menarik orang-orang ini bersama-sama.

Ia tidak akan menjadi reka bentuk di hadapan, menjana, membina pangkalan data lagi - apa yang perlu anda lakukan adalah anda perlu dapat bekerja dengan semua kumpulan pemegang kepentingan yang berbeza ini, melakukan perkara seperti kejuruteraan terbalik, mengimport maklumat, mempunyai orang lain bekerjasama, sama ada pada glosarium atau dokumentasi, semuanya seperti itu - dan menjadi fasilitator untuk menarik ini ke dalam repositori, dan menghubungkan konsep-konsep bersama dalam repositori, dan bekerjasama dengan orang-orang itu.

Ia benar-benar lebih banyak daripada jenis persekitaran kolaboratif di mana walaupun melalui definisi tugas atau thread perbincangan atau jenis perkara yang ada dalam server pasukan, orang sebenarnya dapat berkolaborasi, bertanya dan sampai pada produk akhir yang mereka keperluan untuk senibina data dan organisasi mereka. Adakah jawapan itu?

Malcolm Chisholm: Ya, saya setuju. Anda tahu, saya fikir bahawa kemahiran pemudah cara adalah sesuatu yang sangat wajar dalam pemodelan data. Saya bersetuju bahawa kita tidak selalu melihatnya, tetapi saya fikir itu perlu dan saya cadangkan ada kecenderungan kadang-kadang tinggal di sudut anda melakukan pemodelan data anda, tetapi anda benar-benar perlu berada di luar sana bekerja dengan kumpulan pemangku kepentingan yang lain atau anda hanya tidak memahami persekitaran data yang anda hadapi, dan saya fikir model mengalami akibatnya. Tetapi itu hanya pendapat saya.

Ron Huizenga: Dan ini menarik kerana anda telah menyebut sesuatu yang lebih awal dalam slaid anda tentang sejarah tentang bagaimana perniagaan semacam berpaling dari IT kerana mereka tidak menyampaikan penyelesaian dengan tepat pada masanya dan jenis perkara tersebut.

Sangat menarik bahawa dalam perundingan saya kemudian, sebelum menjadi pengurus produk, kebanyakan projek yang saya lakukan dalam dua tahun terakhir sebelum itu, adalah perniagaan yang ditaja, di mana ia benar-benar perniagaan yang memandu dan arkitek data dan pemodelan bukan sebahagian daripada IT. Kami adalah sebahagian daripada kumpulan yang ditaja perniagaan dan kami berada di sana sebagai fasilitator yang bekerja dengan seluruh pasukan projek.

Malcolm Chisholm: Jadi saya fikir itu titik yang sangat menarik. Saya fikir kita mula melihat peralihan di dunia perniagaan di mana perniagaan bertanya, atau berfikir mungkin, tidak seperti apa yang saya lakukan, sedang memproses seperti, tetapi mereka juga mula memikirkan apa data yang saya bekerjasama, apa yang saya perlukan data, apa data yang saya berurusan sebagai data, dan sejauh mana kita boleh mendapatkan produk dan keupayaan IDERA untuk menyokong sudut pandangan itu, dan saya fikir keperluan perniagaan, walaupun walaupun ia masih agak baru.

Ron Huizenga: Saya bersetuju dengan anda dan saya fikir kita melihatnya lebih banyak lagi. Kami telah melihat kebangkitan dan anda menyentuhnya terlebih dahulu dari segi kepentingan data. Kami melihat pentingnya data awal dalam IT atau dalam evolusi pangkalan data, maka seperti yang anda katakan, kita semacam masuk ke seluruh kitaran pengurusan proses ini - dan prosesnya sangat penting, jangan salah saya di sana - tetapi sekarang apa yang terjadi adalah apabila ia berlaku, jenis tumpuan data.

Dan sekarang organisasi menyedari bahawa data benar-benar adalah titik fokus. Data mewakili semua yang kami lakukan dalam perniagaan kami, jadi kami perlu memastikan bahawa kami mempunyai data yang tepat, sehingga kami dapat mencari maklumat yang tepat yang kami perlukan untuk membuat keputusan kami. Kerana tidak semuanya datang dari proses yang ditentukan. Sesetengah maklumat adalah hasil sampingan dari perkara lain dan kita masih perlu dapat mencarinya, tahu apa artinya, dan dapat menerjemahkan data yang kita lihat di sana akhirnya menjadi pengetahuan yang boleh kita gunakan untuk memacu perniagaan kita dengan lebih baik.

Malcolm Chisholm: Betul, dan kini satu lagi bidang yang saya hadapi adalah apa yang saya panggil kitaran hayat data iaitu, anda tahu, jika kita melihat jenis rantaian bekalan data melalui perusahaan, kita akan bermula dengan pengambilalihan data atau penangkapan data, yang mungkin kemasukan data tetapi mungkin sama, saya mendapat data dari luar perusahaan dari beberapa vendor data.

Dan kemudian dari penangkapan data kita pergi ke penyelenggaraan data di mana saya berfikir tentang menyeragamkan data ini dan menghantarnya ke tempat di mana ia diperlukan. Dan kemudian menggunakan data, mata sebenar di mana data, anda akan mendapat nilai daripada data.

Dan pada zaman dahulu ini semua dilakukan dalam satu gaya individu, tetapi hari ini mungkin, anda tahu, satu persekitaran analisis, misalnya, dan kemudian seterusnya, sebuah arkib, sebuah kedai, di mana kita meletakkan data apabila kita tidak lagi memerlukannya dan akhirnya proses pembersihan. Bagaimanakah anda melihat pemodelan data yang sesuai dengan pengurusan keseluruhan kitaran hayat data ini?

Ron Huizenga: Itu satu soalan yang sangat baik dan satu perkara yang saya tidak mempunyai masa untuk menyelidiki apa-apa terperinci di sini hari ini sama sekali, adalah apa yang kita benar-benar mula bercakap mengenai keturunan data. Jadi apa yang sebenarnya boleh kita lakukan ialah kita mempunyai keupayaan garis keturunan data dalam alat kami dan, seperti yang saya katakan, kita sebenarnya boleh mengeluarkan beberapa dari alat ETL, tetapi anda juga boleh memetakannya hanya dengan menarik garis keturunan juga. Mana-mana model data atau pangkalan data yang kami telah ditangkap dan dibawa ke dalam model, kami boleh merujuk pembinaannya daripada rajah garis keturunan data kami.

Apa yang dapat kami lakukan ialah menarik aliran data, seperti yang anda katakan, dari sumber kepada sasaran, dan melalui keseluruhan kitaran hayat bagaimana data yang ditransmisikan melalui sistem yang berbeza dan apa yang akan anda cari adalah, mari kita ambil pekerja 'data - itu salah satu kegemaran saya berdasarkan projek yang saya lakukan bertahun-tahun lalu. Saya bekerja dengan organisasi yang mempunyai data pekerja dalam 30 sistem yang berbeza. Apa yang akhirnya kami lakukan di sana - dan Rebecca muncul slaid garis keturunan data - ini adalah slaid garis keturunan data yang agak sederhana di sini, tetapi apa yang dapat kami lakukan ialah membawa semua struktur data, merujuknya dalam rajah, dan kemudian kami sebenarnya boleh mula melihat apa arus di antara, dan bagaimanakah entiti data yang berbeza itu dihubungkan dalam aliran? Dan kita boleh melampaui hal itu juga. Ini adalah sebahagian daripada aliran data atau gambarajah garis keturunan yang kita lihat di sini. Jika anda mahu melampaui itu kami juga mempunyai bahagian arkitek perniagaan suite ini dan perkara yang sama berlaku di sana.

Sebarang struktur data yang kami dapati dalam persekitaran pemodelan data, mereka boleh dirujuk dalam alat pemodelan perniagaan supaya walaupun dalam rajah model perniagaan anda atau rajah proses perniagaan anda, anda boleh merujuk kepada kedai data individu jika anda mahu keluar persekitaran pemodelan data, dan semasa anda menggunakannya dalam folder dalam model proses perniagaan anda, anda juga boleh menentukan CRUD mengenai mereka, tentang bagaimana maklumat itu dimakan atau dihasilkan, dan kemudian kita boleh mula menghasilkan perkara seperti laporan kesan dan analisis dan gambar rajah daripada itu.

Apa yang kami sedang berusaha untuk mencapai, dan kami mempunyai banyak keupayaan, tapi satu daripada perkara yang kami miliki sebagai jenis tiang gol yang kami lihat, sambil terus mengembangkan alat kami ke depan, sedang dapat memaparkan bahawa garis keturunan data organisasi dan hayat data penuh hujung-ke-akhir.

Malcolm Chisholm: Baiklah. Rebecca, adakah saya dibenarkan satu lagi?

Rebecca Jozwiak: Saya akan membenarkan anda satu lagi, Malcolm, teruskan.

Malcolm Chisholm: Terima kasih banyak. Berpikir tentang tadbir urus data dan memikirkan pemodelan data, bagaimanakah kita dapat mendapatkan kedua-dua kumpulan ini untuk bekerja dengan berkesan dan memahami antara satu sama lain?

Eric Little: Baiklah, saya fikir ia benar-benar bergantung kepada organisasi, dan ia kembali kepada konsep terdahulu saya, dalam organisasi-organisasi yang inisiatif-inisiatif itu didorong oleh perniagaan kita terikat di dalamnya. Misalnya, saya mengetuai arsitektur data pasukan tetapi kami terikat dengan pengguna perniagaan dan kami sebenarnya membantu mereka untuk berdiri program tadbir urus data mereka. Sekali lagi, lebih banyak pendekatan perundingan tetapi ia sebenarnya lebih daripada fungsi perniagaan.

Apa yang anda perlukan untuk melakukannya ialah anda memerlukan pemodelan data dan arkitek yang benar-benar memahami perniagaan, boleh berhubung dengan pengguna perniagaan dan kemudian membantu mereka menentang proses tadbir urus di sekelilingnya. Perniagaan ingin melakukannya, tetapi pada amnya kita mempunyai pengetahuan teknologi untuk membantu mereka menonjolkan jenis program tersebut. Ia benar-benar harus menjadi kerjasama, tetapi ia perlu menjadi perniagaan yang dimiliki.

Malcolm Chisholm: Baiklah, itu hebat. Terima kasih.

Dr. Eric Little: Baiklah.

Rebecca Jozwiak: Baiklah, terima kasih banyak. Ahli-ahli khalayak, saya takut kami tidak dapat menjawab soalan anda, tetapi saya akan memastikan bahawa ia akan diteruskan kepada tetamu yang sesuai kami pada hari ini. Saya ingin berterima kasih kepada Eric, Malcolm dan Ron kerana menjadi tetamu kami hari ini. Ini adalah barangan yang hebat. Dan jika anda menikmati siaran web IDERA hari ini, IDERA juga akan menggunakan Teknologi Hot pada hari Rabu depan jika anda mahu menyertai, membincangkan cabaran pengindeksan dan Oracle, jadi satu lagi topik menarik.

Terima kasih banyak, orang ramai, berhati-hati, dan kami akan berjumpa dengan anda pada masa akan datang. Selamat tinggal.