Membangun arsitektur data yang digerakkan oleh bisnis

Oleh Staf Techopedia, 28 September 2016

Takeaway: Host Rebecca Jozwiak membahas solusi arsitektur data dengan Eric Little dari OSTHUS, Malcolm Chisholm dari First San Francisco Partners dan Ron Huizenga dari IDERA.

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

Rebecca Jozwiak: Hadirin sekalian, halo, dan selamat datang di Hot Technologies 2016. Hari ini kita membahas "Membangun Arsitektur Data Berbasis Bisnis, " jelas merupakan topik hangat. Nama saya Rebecca Jozwiak, saya akan menjadi tuan rumah Anda untuk siaran web hari ini. Kami melakukan tweet dengan tagar # HotTech16 jadi jika Anda sudah berada di Twitter, silakan bergabung juga. Jika Anda memiliki pertanyaan kapan saja, silakan kirim ke panel Tanya Jawab di kanan bawah layar Anda dan kami akan memastikannya dijawab. Jika tidak, kami akan memastikan bahwa tamu kami mendapatkannya untuk Anda.

Jadi hari ini kami memiliki barisan yang sangat menarik. Banyak pemukul berat dengan kami hari ini. Kami memiliki Eric Little, Wakil Presiden bidang sains data dari OSTHUS. Kami memiliki Malcolm Chisholm, kepala petugas inovasi, yang merupakan gelar yang sangat keren, untuk First San Francisco Partners. Dan kami memiliki Ron Huizenga, manajer produk senior dari IDERA. Dan, Anda tahu, IDERA benar-benar sangat lengkap dengan solusi manajemen data dan pemodelan. Dan hari ini dia akan memberi kita demo tentang bagaimana solusinya bekerja. Tetapi sebelum kita sampai pada itu, Eric Little, saya akan mengoper bola kepada Anda.

Eric Little: Oke, terima kasih banyak. Jadi saya akan membahas beberapa topik di sini yang saya pikir akan sedikit berhubungan dengan pembicaraan Ron dan semoga mengatur panggung untuk beberapa topik ini juga, beberapa T&J.

Jadi hal yang membuat saya tertarik dengan apa yang dilakukan IDERA adalah saya pikir mereka dengan tepat menunjukkan bahwa lingkungan yang kompleks benar-benar mendorong banyak nilai bisnis saat ini. Yang kami maksud dengan lingkungan yang kompleks adalah lingkungan data yang kompleks. Dan teknologi benar-benar bergerak cepat dan sulit untuk mengikuti perkembangan lingkungan bisnis saat ini. Jadi orang-orang yang bekerja di ruang teknologi akan sering melihat bahwa Anda memiliki pelanggan yang bekerja dengan masalah, "Bagaimana saya menggunakan data besar? Bagaimana cara saya menggabungkan semantik? Bagaimana saya menautkan beberapa hal baru ini dengan data lama saya? ”Dan seterusnya, dan hal-hal seperti itu membawa kita sekarang ke dalam empat data besar yang banyak orang kenal, dan saya mengerti mungkin ada lebih dari empat kadang-kadang - saya telah melihat sebanyak delapan atau sembilan - tetapi biasanya, ketika orang berbicara tentang hal-hal seperti data besar atau jika Anda berbicara tentang data besar maka Anda biasanya melihat sesuatu yang semacam skala perusahaan. Dan orang-orang akan berkata, oke, baiklah, pikirkan tentang volume data Anda, yang biasanya fokus - itu adalah berapa banyak yang Anda miliki. Kecepatan data berkaitan dengan seberapa cepat saya dapat memindahkannya atau seberapa cepat saya dapat menanyakannya atau mendapatkan jawabannya, dan seterusnya. Dan secara pribadi saya pikir sisi kiri dari itu adalah sesuatu yang sedang diselesaikan dan ditangani relatif cepat oleh banyak pendekatan yang berbeda. Tetapi di sisi kanan saya melihat banyak kemampuan untuk perbaikan dan banyak teknologi baru yang benar-benar datang ke latar depan. Dan itu benar-benar berkaitan dengan kolom ketiga, variasi data.

Jadi dengan kata lain, sebagian besar perusahaan saat ini melihat data terstruktur, semi-terstruktur dan tidak terstruktur. Data gambar mulai menjadi topik hangat, sehingga dapat menggunakan visi komputer, melihat piksel, dapat mengikis teks, NLP, ekstraksi entitas, Anda memiliki informasi grafik yang keluar dari model statistik atau keluar dari semantik model, Anda memiliki data relasional yang ada di tabel, dan sebagainya. Jadi, mengumpulkan semua data itu bersama-sama dan semua jenis yang berbeda ini benar-benar mewakili tantangan besar dan Anda akan melihat ini, Anda tahu, di Gartner dan orang-orang lain yang mengikuti tren di industri ini.

Dan kemudian hal terakhir yang dibicarakan orang dalam data besar sering kali adalah gagasan kejujuran, yang sebenarnya adalah ketidakpastian data Anda, kekaburannya. Seberapa baik Anda tahu tentang data Anda, seberapa baik Anda memahami apa yang ada di sana dan, Anda tahu? Kemampuan untuk menggunakan statistik dan kemampuan untuk menggunakan beberapa jenis informasi di sekitar apa yang mungkin Anda ketahui atau menggunakan beberapa konteks, dapat menjadi nilai di sana. Jadi kemampuan untuk melihat data dengan cara ini dalam hal berapa banyak yang Anda miliki, seberapa cepat Anda perlu bergerak atau mendapatkannya, semua jenis data yang Anda miliki di perusahaan Anda dan seberapa yakin Anda tentang di mana itu, apa itu, apa kualitasnya, dan sebagainya. Ini benar-benar membutuhkan upaya besar dan terkoordinasi sekarang antara banyak individu untuk mengelola data mereka secara efektif. Pemodelan data, oleh karena itu, semakin penting di dunia saat ini. Jadi model data yang baik benar-benar mendorong banyak kesuksesan dalam aplikasi perusahaan.

Anda memiliki sumber data dari berbagai sumber, seperti yang kami katakan, yang benar-benar membutuhkan banyak jenis integrasi. Jadi menyatukan semuanya benar-benar berguna untuk dapat menjalankan kueri, misalnya, di berbagai jenis sumber data, dan menarik informasi kembali. Tetapi untuk melakukan itu, Anda memerlukan strategi pemetaan yang baik dan karenanya memetakan jenis-jenis data itu dan mengikuti pemetaan itu bisa menjadi tantangan nyata. Dan kemudian Anda memiliki masalah ini, bagaimana saya menautkan data lama saya ke semua sumber data baru ini? Jadi misalkan saya punya grafik, apakah saya mengambil semua data relasional saya dan memasukkannya ke dalam grafik? Biasanya itu bukan ide yang bagus. Jadi bagaimana mungkin orang dapat mengelola semua model data yang sedang terjadi? Analisis benar-benar harus dijalankan pada banyak sumber dan kombinasi data yang berbeda ini. Jadi jawaban yang keluar dari ini, jawaban yang orang butuhkan untuk benar-benar membuat keputusan bisnis yang baik sangat penting.

Jadi ini bukan hanya tentang membangun teknologi demi teknologi, itu benar-benar, apa yang akan saya lakukan, apa yang bisa saya lakukan dengan itu, analisis apa yang bisa saya jalankan, dan kemampuan, karena itu, seperti yang sudah saya lakukan telah berbicara tentang, untuk menyatukan hal-hal ini, untuk mengintegrasikannya benar-benar penting. Dan salah satu dari jenis analisis ini kemudian berjalan pada hal-hal seperti pencarian dan permintaan gabungan. Itu benar-benar menjadi suatu keharusan. Pertanyaan Anda biasanya harus di utas di berbagai jenis sumber dan menarik kembali informasi yang andal.

Satu elemen kunci yang sering, terutama orang akan melihat hal-hal penting seperti teknologi semantik - dan ini adalah sesuatu yang saya harap Ron akan berbicara sedikit tentang pendekatan IDERA - adalah bagaimana Anda memisahkan atau mengelola modelkan lapisan data Anda dari lapisan data itu sendiri, dari data mentah itu? Jadi di lapisan data Anda mungkin memiliki database, Anda mungkin memiliki data dokumen, Anda mungkin memiliki data spreadsheet, Anda mungkin memiliki data gambar. Jika Anda berada di area seperti industri farmasi, Anda memiliki banyak data ilmiah. Dan di atas ini orang biasanya mencari cara untuk membangun model yang memungkinkan mereka untuk dengan cepat mengintegrasikan data itu dan benar-benar ketika Anda sedang mencari data sekarang Anda tidak ingin menarik semua data ke dalam lapisan model Anda, apa yang Anda lihat pada layer model untuk dilakukan adalah memberi Anda representasi logis yang bagus tentang hal-hal apa, kosakata umum, jenis entitas dan hubungan yang umum, dan kemampuan untuk benar-benar menjangkau ke dalam data di mana ia berada. Jadi harus mengatakan apa itu, dan harus mengatakan di mana itu, dan harus mengatakan bagaimana cara mengambilnya dan membawanya kembali.

Jadi ini merupakan pendekatan yang telah cukup berhasil dalam mendorong teknologi semantik ke depan, yang merupakan area di mana saya banyak bekerja. Jadi pertanyaan yang ingin saya ajukan untuk Ron, dan yang saya pikir akan berguna di bagian Tanya Jawab, adalah untuk melihat bagaimana hal ini dapat dilakukan oleh platform IDERA? Jadi apakah layer model sebenarnya terpisah dari layer data? Apakah mereka lebih terintegrasi? Bagaimana cara kerjanya dan apa beberapa hasil dan manfaat yang mereka lihat dari pendekatan mereka? Oleh karena itu data referensi menjadi sangat penting. Jadi, jika Anda akan memiliki model data seperti ini, jika Anda akan dapat menyatukan dan mencari di berbagai hal, Anda benar-benar harus memiliki data referensi yang baik. Tetapi masalahnya adalah data referensi bisa sangat sulit untuk dipelihara. Jadi seringkali penamaan standar dalam dan dari diri mereka sendiri adalah tantangan yang sulit. Satu kelompok akan memanggil sesuatu X dan satu kelompok akan memanggil sesuatu Y dan sekarang Anda memiliki masalah tentang bagaimana seseorang menemukan X dan Y ketika mereka mencari jenis informasi ini? Karena Anda tidak ingin hanya memberi mereka sebagian dari data, Anda ingin memberi mereka semua yang terkait. Pada saat perubahan istilah yang sama, perangkat lunak menjadi usang, dan seterusnya, bagaimana Anda menjaga dan mempertahankan data referensi dari waktu ke waktu?

Dan, sekali lagi, teknologi semantik, khususnya menggunakan hal-hal seperti taksonomi dan kosa kata, kamus data, telah menyediakan cara ruang standar untuk melakukan ini, yang benar-benar sangat kuat, menggunakan jenis standar tertentu, tetapi komunitas basis data telah melakukan ini untuk lama juga, hanya dengan cara yang berbeda. Saya pikir salah satu kunci di sini adalah untuk berpikir tentang bagaimana menggunakan mungkin model hubungan entitas, bagaimana menggunakan mungkin model grafik atau beberapa jenis pendekatan di sini yang benar-benar akan memberi Anda mudah-mudahan cara standar spasi penanganan data referensi Anda. Dan tentu saja setelah Anda memiliki data referensi, strategi pemetaan harus mengelola berbagai nama dan entitas. Jadi ahli materi pelajaran sering suka menggunakan istilah mereka sendiri.

Jadi tantangan dalam hal ini selalu, bagaimana Anda memberikan informasi kepada seseorang tetapi membuatnya relevan dengan cara mereka membicarakannya? Jadi satu kelompok mungkin memiliki satu cara untuk melihat sesuatu, misalnya, Anda mungkin seorang ahli kimia yang bekerja pada obat, dan Anda mungkin seorang ahli biologi struktural yang bekerja pada obat yang sama, dan Anda mungkin memiliki nama yang berbeda untuk jenis entitas yang sama yang berhubungan dengan bidang Anda. Anda harus mencari cara untuk menyatukan terminologi yang dipersonalisasi itu, karena pendekatan lainnya adalah, Anda harus memaksa orang untuk membatalkan masa jabatannya dan menggunakan istilah orang lain, yang sering tidak mereka sukai. Poin lain di sini adalah menangani sejumlah besar sinonim menjadi sulit, sehingga ada banyak kata berbeda dalam data banyak orang yang dapat merujuk pada hal yang sama. Anda memiliki masalah referensi di sana menggunakan serangkaian hubungan banyak ke satu. Istilah khusus bervariasi dari satu industri ke industri jadi jika Anda akan menemukan semacam solusi menyeluruh untuk jenis manajemen data ini, seberapa mudah portabelnya dari satu proyek, atau satu aplikasi ke yang lain? Itu bisa menjadi tantangan lain.

Otomasi itu penting dan itu juga tantangan. Mahal untuk menangani data referensi secara manual. Biayanya harus terus memetakan secara manual dan mahal jika ahli materi pelajaran berhenti melakukan pekerjaan sehari-hari mereka dan harus masuk dan terus memperbaiki kamus data dan memperbarui definisi dan seterusnya, dan sebagainya. Kosakata yang dapat direplikasi benar-benar menunjukkan banyak nilai. Jadi itu adalah kosakata yang seringkali dapat Anda temukan di luar organisasi Anda. Jika Anda melakukan pekerjaan dalam minyak mentah, misalnya, akan ada beberapa jenis kosakata yang dapat Anda pinjam dari ruang sumber terbuka, sama dengan obat-obatan, sama dengan industri perbankan dan keuangan, sama dengan banyak bidang seperti ini. Orang-orang menempatkan kosa kata yang dapat digunakan kembali, umum, dan dapat ditiru di luar sana untuk digunakan orang.

Dan, sekali lagi, melihat alat IDERA, saya ingin tahu bagaimana mereka menangani ini dalam hal menggunakan jenis standar. Dalam dunia semantik Anda sering melihat hal-hal seperti model SKOS yang memberikan standar untuk setidaknya lebih luas daripada / lebih sempit dari hubungan dan hal-hal itu bisa sulit dilakukan dalam model ER tetapi, Anda tahu, bukan tidak mungkin, itu tergantung pada seberapa banyak dari itu mesin dan penghubung yang dapat Anda tangani dalam jenis sistem tersebut.

Jadi yang terakhir, saya hanya ingin membuat perbandingan dengan beberapa mesin semantik yang saya lihat di industri, dan meminta Ron dan memberinya sedikit bincang-bincang tentang mungkin bagaimana sistem IDERA telah digunakan dalam hubungannya dengan teknologi semantik apa pun. Apakah ini dapat diintegrasikan dengan tiga toko, basis data grafik? Seberapa mudahnya untuk menggunakan sumber eksternal karena hal-hal semacam itu di dunia semantik sering dapat dipinjam menggunakan SPARQL Endpoints? Anda dapat mengimpor model RDF atau OWL langsung ke dalam model Anda - merujuk kembali kepada mereka - jadi, misalnya, ontologi gen atau ontologi protein, yang dapat hidup di suatu tempat di ruangnya sendiri dengan struktur tata kelola sendiri dan saya dapat mengimpor semua atau bagian dari itu karena saya membutuhkannya ke dalam model saya sendiri. Dan saya ingin tahu bagaimana IDERA mendekati masalah ini. Apakah Anda harus memelihara semuanya secara internal, atau adakah cara untuk menggunakan jenis model standar lainnya dan menariknya dan bagaimana cara kerjanya? Dan hal terakhir yang saya sebutkan di sini adalah berapa banyak pekerjaan manual yang benar-benar terlibat untuk membangun glosarium dan repositori metadata?

Jadi saya tahu Ron akan menunjukkan kepada kita beberapa demo tentang hal-hal semacam ini yang akan sangat menarik. Tetapi masalah yang sering saya lihat berkonsultasi dengan pelanggan adalah bahwa banyak kesalahan terjadi jika orang menulis dalam definisi mereka sendiri atau metadata mereka sendiri. Jadi, Anda salah mengeja, Anda mendapatkan kesalahan besar, itu satu hal. Anda juga mendapatkan orang yang dapat mengambil sesuatu dari, Anda tahu, hanya Wikipedia atau sumber yang belum tentu berkualitas yang Anda inginkan dalam definisi Anda, atau definisi Anda hanya dari perspektif satu orang sehingga tidak lengkap, dan tidak jelas kemudian bagaimana proses tata kelola bekerja. Tata kelola, tentu saja, menjadi masalah yang sangat, sangat besar setiap kali Anda berbicara tentang data referensi dan setiap kali Anda berbicara tentang bagaimana hal ini cocok dengan data master seseorang, bagaimana mereka akan menggunakan metadata mereka, dan begitu seterusnya.

Jadi saya hanya ingin meletakkan beberapa topik ini di luar sana. Ini adalah item yang saya lihat di ruang bisnis di banyak jenis konsultasi yang berbeda dan banyak ruang berbeda, dan saya benar-benar tertarik untuk melihat apa yang akan ditunjukkan Ron kepada kami dengan IDERA untuk menunjukkan beberapa topik ini . Jadi, terima kasih banyak.

Rebecca Jozwiak: Terima kasih banyak, Eric, dan saya sangat suka komentar Anda bahwa banyak kesalahan dapat terjadi jika orang menulis definisi atau metadata mereka sendiri. Saya tahu di dunia jurnalisme ada mantra bahwa "banyak mata membuat sedikit kesalahan, " tetapi ketika datang ke aplikasi praktis, terlalu banyak tangan dalam wadah kue cenderung meninggalkan Anda dengan banyak cookie yang rusak, kan?

Eric Little: Ya, dan kuman.

Rebecca Jozwiak: Ya. Dengan itu saya akan melanjutkan dan memberikannya kepada Malcolm Chisholm. Malcolm, lantai adalah milikmu.

Malcolm Chisholm: Terima kasih banyak, Rebecca. Saya ingin melihat sedikit tentang apa yang Eric bicarakan, dan menambahkan, semacam, beberapa pengamatan yang, Anda tahu, Ron mungkin ingin menanggapi juga, dalam berbicara tentang "Menuju Arsitektur Data Berbasis Bisnis “- apa artinya didorong oleh bisnis dan mengapa itu penting? Atau itu hanya semacam hype? Saya kira tidak.

Jika kita melihat apa yang terjadi sejak itu, Anda tahu, komputer mainframe benar-benar tersedia bagi perusahaan - katakanlah, sekitar tahun 1964 - hingga hari ini, kita dapat melihat bahwa ada banyak perubahan. Dan perubahan-perubahan ini akan saya simpulkan sebagai pergeseran dari proses-sentrisitas ke data-sentrisitas. Dan itulah yang membuat arsitektur data berbasis bisnis sangat penting dan sangat relevan untuk hari ini. Dan saya pikir, Anda tahu, itu bukan hanya kata kunci, itu adalah sesuatu yang benar-benar nyata.

Tapi kita bisa menghargainya sedikit lebih banyak jika kita terjun ke dalam sejarah, jadi kembali ke masa lalu, jauh ke tahun 1960-an dan untuk beberapa waktu sesudahnya, mainframe mendominasi. Ini kemudian memberi jalan bagi PC di mana Anda benar-benar memberontak pengguna ketika PC masuk. Pemberontakan terhadap IT terpusat, yang mereka pikir tidak memenuhi kebutuhan mereka, tidak cukup gesit. Itu dengan cepat memunculkan komputasi terdistribusi, ketika PC dihubungkan bersama. Dan kemudian internet mulai terjadi, yang mengaburkan batas-batas perusahaan - sekarang bisa berinteraksi dengan pihak-pihak di luar itu sendiri dalam hal pertukaran data, yang belum pernah terjadi sebelumnya. Dan sekarang kita telah memasuki era cloud dan data besar di mana cloud adalah platform yang benar-benar mengkomodifikasi infrastruktur dan jadi kita akan pergi, seolah-olah, kebutuhan untuk menjalankan pusat data besar karena, Anda tahu, kami Sudah tersedia kapasitas cloud untuk kami, dan seiring dengan data besar yang Eric, Anda tahu, begitu fasih dibahas. Dan secara keseluruhan, seperti yang kita lihat, ketika pergeseran teknologi terjadi, itu telah menjadi lebih data-sentris, kami lebih peduli tentang data. Seperti halnya internet, bagaimana data dipertukarkan. Dengan data besar, empat atau lebih dari data itu sendiri.

Pada saat yang sama, dan mungkin yang lebih penting, kasus penggunaan bisnis bergeser. Ketika komputer pertama kali diperkenalkan, mereka digunakan untuk mengotomatisasi hal-hal seperti buku dan catatan. Dan segala sesuatu yang merupakan proses manual, yang melibatkan buku besar atau hal-hal seperti itu, diprogram, pada dasarnya, di rumah. Itu bergeser di tahun 80-an ke ketersediaan paket operasional. Anda tidak perlu menulis daftar gaji Anda sendiri lagi, Anda bisa membeli sesuatu yang melakukannya. Itu mengakibatkan perampingan besar pada saat itu, atau restrukturisasi, di banyak departemen TI. Tapi kemudian intelijen bisnis, dengan hal-hal seperti gudang data muncul, sebagian besar di tahun 90-an. Diikuti oleh model bisnis dotcom yang tentu saja merupakan kegilaan besar. Lalu MDM. Dengan MDM Anda mulai melihat bahwa kami berpikir bukan tentang otomasi; kami hanya benar-benar fokus pada kurasi data sebagai data. Dan kemudian analytics, mewakili nilai yang bisa Anda dapatkan dari data. Dan dalam analitik Anda melihat perusahaan yang sangat sukses yang model bisnis intinya berputar di sekitar data. Google, Twitter, Facebook akan menjadi bagian dari itu, tetapi Anda bisa berdebat juga bahwa Walmart adalah.

Dan bisnis sekarang benar-benar memikirkan data. Bagaimana kami bisa mendapatkan nilai dari data? Bagaimana data dapat menggerakkan bisnis, strategi, dan kita berada di zaman keemasan data. Jadi mengingat itu, apa yang terjadi dalam hal arsitektur data kami, jika data tidak lagi dianggap hanya sebagai knalpot yang keluar dari bagian belakang aplikasi, tetapi benar-benar penting bagi model bisnis kami? Nah, bagian dari masalah yang kita miliki dalam mencapai itu adalah IT benar-benar terjebak di masa lalu dengan siklus hidup pengembangan sistem yang merupakan konsekuensi dari harus berurusan dengan cepat dengan fase otomatisasi proses di awal usia TI, dan bekerja di proyek adalah hal yang serupa. Untuk IT - dan ini sedikit karikatur - tetapi yang ingin saya katakan adalah bahwa beberapa hambatan untuk mendapatkan arsitektur data yang digerakkan oleh bisnis adalah karena kita, semacam, telah menerima budaya di IT secara tidak kritis. yang berasal dari zaman dulu.

Jadi semuanya proyek. Ceritakan persyaratan Anda secara rinci. Jika semuanya tidak berhasil, itu karena Anda tidak memberi tahu saya persyaratan Anda. Baik itu tidak berfungsi hari ini dengan data karena kita tidak memulai dengan proses manual yang tidak otomatis atau, Anda tahu, konversi teknis dari proses bisnis, kami mulai sangat sering dengan data produksi yang sudah ada yang kami coba untuk mendapatkan nilai dari. Tetapi tidak seorang pun yang mensponsori proyek data-sentris benar-benar memahami data tersebut secara mendalam. Kita harus melakukan penemuan data, kita harus melakukan analisis data sumber. Dan itu tidak benar-benar cocok dengan pengembangan sistem, Anda tahu - air terjun, siklus hidup SDLC - yang Agile, akan saya pertahankan, adalah semacam versi yang lebih baik dari itu.

Dan yang sedang difokuskan adalah teknologi dan fungsionalitas, bukan data. Misalnya, ketika kami melakukan pengujian dalam fase pengujian biasanya, apakah fungsi saya berfungsi, katakanlah ETL saya, tetapi kami tidak menguji data. Kami tidak menguji asumsi kami tentang data sumber yang masuk. Jika kami melakukannya, kami mungkin berada dalam kondisi yang lebih baik dan sebagai seseorang yang telah melakukan proyek gudang data dan menderita melalui perubahan hulu, menghancurkan ETL saya, saya akan menghargai itu. Dan pada kenyataannya, apa yang ingin kita lihat adalah pengujian sebagai langkah awal untuk pemantauan kualitas data produksi berkelanjutan. Jadi kita sudah sampai di sini banyak sikap di mana sulit untuk mencapai arsitektur data yang digerakkan oleh bisnis karena kita dikondisikan oleh era proses-sentrisitas. Kita perlu melakukan transisi ke data-sentrisitas. Dan ini bukan transisi total, Anda tahu, masih ada banyak proses yang harus dilakukan di sana, tapi kami tidak benar-benar berpikir dalam hal data-sentris ketika kami perlu, dan keadaan yang terjadi ketika kami benar-benar wajib melakukan itu.

Sekarang bisnis menyadari nilai data, mereka ingin membuka kunci data, jadi bagaimana kita akan melakukannya? Jadi bagaimana kita melakukan transisi? Kami menempatkan data sebagai jantung dari proses pembangunan. Dan kami membiarkan bisnis memimpin dengan persyaratan informasi. Dan kami memahami bahwa tidak ada yang memahami data sumber yang ada pada awal proyek. Anda dapat berargumen bahwa struktur data dan data itu sendiri sampai di sana melalui TI dan operasi, masing-masing, jadi kita harus tahu itu, tetapi sungguh, kita tidak. Ini adalah pengembangan data-sentris. Jadi kita harus, dalam memikirkan di mana kita dan bagaimana kita melakukan pemodelan data dalam dunia data-sentris, kita harus memiliki loop umpan balik kepada pengguna dalam hal menyempurnakan persyaratan informasi mereka, seperti kita melakukan penemuan data dan profil data, meramalkan analisis data sumber, dan saat kami secara bertahap mendapatkan semakin banyak kepastian tentang data kami. Dan sekarang saya berbicara tentang proyek yang lebih tradisional seperti hub MDM atau data warehouse, belum tentu proyek big data, meskipun ini masih, saya pertahankan, cukup dekat dengan itu. Dan loop umpan balik tersebut termasuk pemodel data, Anda tahu, secara bertahap memajukan model data mereka dan berinteraksi dengan pengguna untuk memastikan persyaratan informasi disempurnakan berdasarkan apa yang mungkin, apa yang tersedia, dari sumber data karena mereka lebih memahaminya, jadi itu bukan kasus lagi dari model data yang, Anda tahu, dalam keadaan yang tidak ada atau sepenuhnya dilakukan, itu adalah bertahap yang menjadikannya fokus.

Demikian pula, lebih hilir dari itu kami memiliki jaminan kualitas di mana kami mengembangkan aturan untuk pengujian kualitas data untuk memastikan bahwa data berada di dalam parameter yang kami asumsikan. Masuk, Eric mengacu pada perubahan dalam data referensi, yang mungkin terjadi. Anda tidak ingin menjadi korban hilir dari, semacam, perubahan yang tidak dikelola di daerah itu, sehingga aturan jaminan kualitas dapat masuk ke pemantauan kualitas data berkelanjutan pasca-produksi. Jadi Anda dapat mulai melihat apakah kami akan menjadi data-sentris, bagaimana kami melakukan pengembangan data-sentris sangat berbeda dengan SDLC dan Agile berbasis fungsionalitas. Dan kemudian kita harus memperhatikan pandangan bisnis juga. Kami memiliki - dan sekali lagi ini menggemakan apa yang dikatakan Eric - kami memiliki model data yang mendefinisikan cetak biru cerita data untuk basis data kami, tetapi pada saat yang sama kami membutuhkan model konseptual tersebut, pandangan bisnis data yang secara tradisional belum dilakukan di masa lalu. Kami kadang-kadang, saya pikir, berpikir bahwa model data dapat melakukan semuanya, tetapi kita perlu memiliki pandangan konseptual, semantik, dan melihat ke dalam data, merendernya melalui lapisan abstraksi yang menerjemahkan model penyimpanan ke dalam bisnis melihat. Dan, sekali lagi, semua hal yang Eric bicarakan dalam hal semantik, menjadi penting untuk melakukan itu, jadi kami sebenarnya memiliki tugas pemodelan tambahan. Saya pikir itu, Anda tahu, menarik jika Anda berada di peringkat sebagai pemodel data seperti yang saya lakukan, dan sekali lagi, sesuatu yang baru.

Dan akhirnya saya ingin mengatakan bahwa arsitektur yang lebih besar juga harus mencerminkan kenyataan baru ini. MDM pelanggan tradisional, misalnya, adalah jenis, oke, mari kita dapatkan data pelanggan kami ke hub di mana kami dapat, Anda tahu, masuk akal dalam hal kualitas data yang benar-benar adil untuk aplikasi back office. Yang dari sudut pandang strategi bisnis agak menguap. Namun hari ini, kami melihat hub MDM pelanggan yang memiliki data profil pelanggan tambahan di dalamnya, bukan hanya data statis, yang kemudian benar-benar memiliki antarmuka dua arah dengan aplikasi transaksi pelanggan. Ya, mereka masih mendukung back office, tetapi sekarang kita tahu tentang perilaku pelanggan kita juga. Ini lebih mahal untuk dibangun. Ini lebih kompleks untuk dibangun. Tetapi ini didorong oleh bisnis dengan cara yang tidak dimiliki oleh pelanggan tradisional MDM. Anda menukar orientasi bisnis dengan desain yang lebih sederhana yang lebih mudah diterapkan, tetapi untuk bisnis, inilah yang ingin mereka lihat. Kami benar-benar berada di era baru dan saya pikir ada sejumlah tingkatan yang harus kami tanggapi untuk arsitektur data penggerak bisnis dan saya pikir ini adalah waktu yang sangat menyenangkan untuk melakukan sesuatu.

Jadi terima kasih, kembali padamu Rebecca.

Rebecca Jozwiak: Terima kasih Malcolm, dan saya benar-benar menikmati apa yang Anda katakan tentang model data harus memberi makan pandangan bisnis, karena, agak tidak seperti apa yang Anda katakan, di mana IT memegang kendali begitu lama dan itu hanya semacam tidak lagi dan lagi bahwa budaya memang perlu bergeser. Dan saya cukup yakin bahwa ada seekor anjing di latar belakang yang setuju dengan Anda 100%. Dan dengan itu saya akan mengoper bola kepada Ron. Saya sangat senang melihat demo Anda. Ron, lantai itu milikmu.

Ron Huizenga: Terima kasih banyak dan sebelum kita membahasnya, saya akan melalui beberapa slide dan kemudian sedikit demo karena, seperti yang Eric dan Malcolm tunjukkan, ini adalah topik yang sangat luas dan mendalam, dan dengan apa yang kita bicarakan hari ini kita hanya mengupas permukaannya karena ada begitu banyak aspek dan begitu banyak hal yang benar-benar perlu kita pertimbangkan dan lihat dari arsitektur yang digerakkan oleh bisnis. Dan pendekatan kami adalah untuk benar-benar membuat model berdasarkan dan mendapatkan nilai sebenarnya dari model karena Anda dapat menggunakannya sebagai kendaraan komunikasi serta lapisan untuk mengaktifkan sistem lain. Apakah Anda melakukan arsitektur berorientasi layanan, atau hal-hal lain, model ini benar-benar menjadi sumber kehidupan dari apa yang terjadi, dengan semua metadata di sekitarnya dan data yang Anda miliki dalam bisnis Anda.

Namun, apa yang ingin saya bicarakan adalah mengambil langkah mundur, karena Malcolm telah menyentuh beberapa sejarah tentang cara solusi berkembang dan hal-hal semacam itu. Salah satu cara untuk benar-benar menunjukkan betapa pentingnya memiliki arsitektur data yang baik adalah kasus penggunaan yang sering saya temui ketika saya berkonsultasi sebelum saya berperan dalam manajemen produk, dan itu adalah, saya akan masuk ke organisasi apakah mereka melakukan transformasi bisnis atau hanya mengganti beberapa sistem yang ada dan hal-hal semacam itu, dan terbukti dengan sangat cepat bagaimana buruknya organisasi memahami data mereka sendiri. Jika Anda menggunakan kasus penggunaan tertentu seperti ini, apakah Anda seorang konsultan atau mungkin orang yang baru saja memulai dengan suatu organisasi, atau organisasi Anda telah dibangun selama bertahun-tahun dengan mengakuisisi perusahaan yang berbeda, apa yang Anda akhiri dengan lingkungan yang sangat kompleks dengan sangat cepat, dengan sejumlah teknologi baru yang berbeda, serta teknologi lama, solusi ERP dan yang lainnya.

Jadi salah satu hal yang benar-benar dapat kita lakukan dengan pendekatan pemodelan kita adalah untuk menjawab pertanyaan, bagaimana saya memahami semua ini? Kami benar-benar dapat mulai mengumpulkan informasi, sehingga bisnis dapat memanfaatkan informasi yang kami miliki dengan benar. Dan ternyata, apa yang kita miliki di lingkungan itu? Bagaimana saya dapat menggunakan model untuk mengusir informasi yang saya butuhkan dan memahami informasi itu dengan lebih baik? Dan kemudian kita memiliki tipe tradisional metadata untuk semua hal yang berbeda seperti model data relasional, dan kita terbiasa melihat hal-hal seperti definisi dan kamus data, Anda tahu, tipe data dan jenis hal itu. Tetapi bagaimana dengan metadata tambahan yang ingin Anda tangkap untuk benar-benar memberi makna lebih padanya? Seperti, entitas mana yang benar-benar kandidat yang harus menjadi objek data referensi, yang harus menjadi objek manajemen data master dan hal-hal semacam itu dan mengikatnya bersama. Dan bagaimana informasi mengalir melalui organisasi? Data mengalir dari bagaimana mereka dikonsumsi dari kedua sudut pandang proses, tetapi juga garis silsilah data dalam hal perjalanan informasi melalui bisnis kami dan bagaimana hal itu berjalan melalui sistem yang berbeda, atau melalui penyimpanan data, jadi kami tahu ketika kita sedang membangun solusi-I, atau hal-hal semacam itu, bahwa kita sebenarnya mengkonsumsi informasi yang benar untuk tugas yang ada.

Dan yang sangat penting adalah, bagaimana kita bisa membuat semua pemangku kepentingan berkolaborasi, dan khususnya para pemangku kepentingan bisnis karena merekalah yang memberi kita arti sebenarnya dari data itu. Bisnis, pada akhirnya, memiliki data. Mereka memberikan definisi untuk kosa kata dan hal-hal yang dibicarakan Eric, jadi kita perlu tempat untuk mengikat semuanya. Dan cara kita melakukannya adalah melalui pemodelan data dan arsitektur repositori data.

Saya akan menyentuh beberapa hal. Saya akan berbicara tentang ER / Studio Enterprise Team Edition. Terutama saya akan berbicara tentang produk arsitektur data di mana kita melakukan pemodelan data dan hal semacam itu, tetapi ada banyak komponen lain dari suite yang saya hanya akan menyentuh secara singkat. Anda akan melihat satu cuplikan dari Arsitek Bisnis, di mana kami dapat melakukan model konseptual, tetapi kami juga dapat melakukan model proses bisnis dan kami dapat mengikat model proses tersebut untuk menghubungkan data aktual yang kami miliki dalam model data kami. Ini benar-benar membantu kita untuk menyatukan ikatan itu. Arsitek Perangkat Lunak memungkinkan kami melakukan konstruksi tambahan seperti beberapa pemodelan UML dan hal-hal semacam itu untuk memberikan logika pendukung ke beberapa sistem dan proses lain yang sedang kita bicarakan. Tetapi yang sangat penting ketika kita bergerak ke bawah, kita memiliki repositori dan server tim, dan saya akan membicarakannya sebagai dua bagian dari hal yang sama. Repositori adalah tempat kami menyimpan semua metadata yang dimodelkan serta semua metadata bisnis dalam istilah glosarium dan istilah bisnis. Dan karena kita memiliki lingkungan berbasis repositori ini, kita kemudian dapat menyatukan semua hal yang berbeda ini dalam lingkungan yang sama dan kemudian kita benar-benar dapat membuat yang tersedia untuk konsumsi, tidak hanya untuk orang-orang teknis tetapi juga untuk para pebisnis. Dan itulah bagaimana kita benar-benar mulai mendorong kolaborasi.

Dan bagian terakhir yang akan saya bicarakan secara singkat adalah, ketika Anda berjalan ke lingkungan ini, bukan hanya database yang Anda miliki di luar sana. Anda akan memiliki sejumlah basis data, penyimpanan data, Anda juga akan memiliki banyak, apa yang akan saya sebut, artefak warisan. Mungkin orang telah menggunakan Visio atau diagram lain untuk memetakan beberapa hal. Mungkin mereka memiliki alat pemodelan lain dan hal semacam itu. Jadi apa yang bisa kita lakukan dengan MetaWizard sebenarnya adalah mengekstrak beberapa informasi itu dan membawanya ke model kita, menjadikannya terkini dan dapat menggunakannya, mengkonsumsinya, dengan cara yang sekarang lagi, daripada hanya dengan duduk di sana. Sekarang menjadi bagian aktif dari model kerja kami, yang sangat penting.

Ketika Anda memasuki sebuah organisasi, seperti yang saya katakan, banyak sistem yang berbeda di luar sana, banyak solusi ERP, solusi departemen yang tidak cocok. Banyak organisasi juga menggunakan solusi SaaS, yang juga dikendalikan dan dikelola secara eksternal, jadi kami tidak mengontrol basis data dan hal-hal di host pada mereka, tetapi kita masih perlu tahu seperti apa data itu terlihat dan, tentu saja, metadata di sekitar itu. Apa yang kami juga temukan adalah banyak sistem warisan usang yang belum dibersihkan karena pendekatan berbasis proyek yang dibicarakan Malcolm. Sungguh menakjubkan bagaimana dalam beberapa tahun terakhir organisasi akan meningkatkan proyek, mereka akan mengganti sistem atau solusi, tetapi seringkali tidak ada cukup anggaran proyek yang tersisa untuk menonaktifkan solusi usang, jadi sekarang mereka hanya di jalan. Dan kita harus mencari tahu apa yang sebenarnya bisa kita singkirkan di lingkungan kita serta apa yang berguna di masa depan. Dan itu terkait dengan strategi dekomisioning yang buruk. Itu bagian tak terpisahkan dari hal yang sama.

Apa yang kami temukan juga, karena banyak organisasi telah dibangun dari semua solusi yang berbeda ini, adalah kami melihat banyak antarmuka point-to-point dengan banyak data bergerak di sejumlah tempat. Kita harus dapat merasionalisasi hal itu dan mencari tahu garis data yang saya sebutkan sebelumnya sehingga kita dapat memiliki strategi yang lebih kohesif seperti pemanfaatan arsitektur berorientasi layanan, bus layanan perusahaan dan hal-hal semacam itu, untuk memberikan informasi yang benar untuk jenis penerbitan dan berlangganan model yang kami gunakan dengan benar di seluruh bisnis kami. Dan kemudian, tentu saja, kita masih perlu melakukan beberapa jenis analitik, apakah kita menggunakan gudang data, data mart dengan ETL tradisional atau menggunakan beberapa danau data baru. Semuanya bermuara pada hal yang sama. Itu semua data, apakah itu data besar, apakah itu data tradisional dalam basis data relasional, kita perlu menyatukan semua data itu sehingga kita bisa mengelolanya dan tahu apa yang kita hadapi di seluruh model kita.

Sekali lagi, kompleksitas yang akan kita lakukan adalah kita memiliki sejumlah langkah yang ingin kita lakukan. Pertama-tama, Anda masuk dan mungkin tidak memiliki cetak biru seperti apa lanskap informasi itu. Dalam alat pemodelan data seperti ER / Studio Data Architect Anda pertama kali akan melakukan banyak rekayasa terbalik dalam hal mari kita tunjukkan sumber data yang ada di luar sana, bawa mereka dan kemudian benar-benar menjahitnya menjadi lebih representatif model yang mewakili seluruh bisnis. Yang penting adalah, kita ingin dapat mendekomposisi model-model itu juga di sepanjang lini bisnis sehingga kita dapat menghubungkannya dalam potongan-potongan yang lebih kecil, yang juga dapat dihubungkan oleh para pelaku bisnis kita, dan analis bisnis kita serta para pemangku kepentingan lain yang bekerja di atasnya.

Penamaan standar sangat penting dan saya membicarakannya dalam beberapa cara berbeda di sini. Penamaan standar dalam hal bagaimana kita menamakan sesuatu dalam model kita. Ini cukup mudah dilakukan dalam model logis, di mana kami memiliki konvensi penamaan yang baik dan kamus data yang baik untuk model kami, tetapi kemudian juga, kami melihat konvensi penamaan yang berbeda untuk banyak model fisik yang kami bawa. Ketika kami reverse engineer, cukup sering kita melihat nama yang disingkat dan jenis hal yang akan saya bicarakan. Dan kita perlu menerjemahkannya kembali menjadi nama-nama bahasa Inggris yang bermakna yang bermakna bagi bisnis sehingga kita dapat memahami apa semua potongan data ini yang kita miliki di lingkungan. Dan kemudian pemetaan universal adalah cara kita menyatukannya.

Selain itu kami kemudian akan mendokumentasikan dan mendefinisikan lebih lanjut dan di situlah kami dapat mengklasifikasikan data kami lebih jauh dengan sesuatu yang disebut Lampiran, yang akan saya tunjukkan pada Anda beberapa slide. Dan kemudian menutup loop, kami ingin menerapkan makna bisnis itu, yang merupakan tempat kami mengikat glosarium bisnis kami dan dapat menghubungkannya dengan berbagai artefak model kami, jadi kami tahu, ketika kami berbicara tentang istilah bisnis tertentu, di mana itu adalah diimplementasikan dalam data kami di seluruh organisasi. Dan terakhir, saya sudah bicara tentang fakta bahwa kita perlu semua ini menjadi tempat penyimpanan dengan banyak kolaborasi dan kemampuan penerbitan, sehingga para pemangku kepentingan kita dapat memanfaatkannya. Saya akan berbicara tentang reverse engineering dengan cukup cepat. Saya sudah memberi Anda sorotan yang sangat cepat. Saya akan menunjukkan kepada Anda dalam demo yang sebenarnya hanya untuk menunjukkan kepada Anda beberapa hal yang dapat kami bawa ke sana.

Dan saya ingin berbicara tentang beberapa jenis model dan diagram yang akan kami hasilkan dalam jenis skenario ini. Jelas kami akan melakukan model konseptual dalam banyak contoh; Saya tidak akan menghabiskan banyak waktu untuk itu. Saya benar-benar ingin berbicara tentang model logis, model fisik dan jenis model khusus yang dapat kita buat. Dan penting bagi kita untuk membuat semua ini dalam platform pemodelan yang sama sehingga kita bisa menjahitnya bersama. Itu termasuk model dimensi dan juga model yang memanfaatkan beberapa sumber data baru, seperti NoSQL yang akan saya tunjukkan. Dan kemudian, seperti apa model garis silsilah data itu? Dan bagaimana kita menjahit data itu menjadi model proses bisnis, adalah apa yang akan kita bicarakan selanjutnya.

Saya akan beralih ke lingkungan pemodelan di sini hanya untuk memberi Anda gambaran yang sangat tinggi dan cepat. Dan saya percaya Anda harus dapat melihat layar saya sekarang. Pertama-tama saya ingin berbicara tentang tipe model data tradisional saja. Dan cara kami ingin mengatur model ketika kami membawanya, adalah kami ingin dapat menguraikannya. Jadi apa yang Anda lihat di sini di sebelah kiri adalah kami memiliki model logis dan fisik dalam file model khusus ini. Hal berikutnya adalah, kita dapat memecahnya di sepanjang dekomposisi bisnis, jadi itu sebabnya Anda melihat folder. Yang biru muda adalah model yang logis dan yang hijau adalah model fisik. Dan kami juga dapat menelusuri, jadi di dalam ER / Studio, jika Anda memiliki dekomposisi bisnis, Anda dapat masuk ke level atau sub-model sebanyak yang Anda inginkan, dan perubahan yang Anda buat di level bawah secara otomatis mencerminkan di semakin tinggi level. Jadi itu menjadi lingkungan pemodelan yang sangat kuat dengan sangat cepat.

Sesuatu yang saya juga ingin tunjukkan yang sangat penting untuk mulai menarik informasi ini bersama adalah kita dapat memiliki beberapa model fisik yang sesuai dengan satu model logis juga. Cukup sering Anda mungkin memiliki model logis tetapi Anda mungkin memiliki model fisik pada platform berbeda dan hal semacam itu. Mungkin itu contoh SQL Server, mungkin contoh Oracle. Kami memiliki kemampuan untuk mengikat semua itu bersama-sama di lingkungan pemodelan yang sama. Dan lagi, apa yang saya dapat di sini adalah model data warehouse aktual yang dapat, sekali lagi, berada dalam lingkungan pemodelan yang sama atau kita dapat memilikinya di repositori dan menghubungkannya di berbagai hal yang berbeda juga.

Apa yang saya benar-benar ingin tunjukkan pada Anda adalah beberapa hal lain dan varian model yang kami masuki. Jadi ketika kita masuk ke model data tradisional seperti ini kita terbiasa melihat entitas khas dengan kolom dan metadata dan hal semacam itu, tetapi sudut pandang itu sangat bervariasi ketika kita mulai berurusan dengan beberapa teknologi NoSQL yang lebih baru ini., atau karena beberapa orang masih suka menyebutnya, teknologi big data.

Jadi sekarang katakanlah kita juga punya Hive di lingkungan kita. Jika kita merekayasa balik dari lingkungan Hive - dan kita dapat memajukan dan merekayasa balik dari Hive dengan alat pemodelan yang sama persis ini - kita melihat sesuatu yang sedikit berbeda. Kami masih melihat semua data sebagai konstruk di sana, tetapi TDL kami berbeda. Anda yang terbiasa melihat SQL, yang akan Anda lihat sekarang adalah Hive QL, yang sangat mirip SQL tetapi dari alat yang sama Anda sekarang dapat mulai bekerja dengan berbagai bahasa scripting. Jadi Anda dapat memodelkan dalam lingkungan ini, menghasilkannya ke lingkungan Hive, tetapi yang sama pentingnya, dalam skenario yang saya jelaskan, Anda dapat membalik semuanya, masuk akal, dan mulai menjahitnya juga. .

Mari kita ambil yang lain yang sedikit berbeda. MongoDB adalah platform lain yang kami dukung secara bawaan. Dan ketika Anda mulai masuk ke jenis lingkungan JSON di mana Anda memiliki toko dokumen, JSON adalah binatang yang berbeda dan ada konstruksi di dalamnya, yang tidak sesuai dengan model relasional. Anda segera mulai berurusan dengan konsep-konsep seperti objek tertanam dan array objek tertanam ketika Anda mulai menginterogasi JSON dan konsep-konsep itu tidak ada dalam notasi relasional tradisional. Apa yang kami lakukan di sini adalah kami benar-benar memperluas notasi dan katalog kami untuk dapat mengatasinya di lingkungan yang sama.

Jika Anda melihat ke kiri di sini, alih-alih melihat hal-hal seperti entitas dan tabel, kami menyebutnya objek. Dan Anda melihat notasi yang berbeda. Anda masih melihat tipikal jenis notasi referensi di sini, tetapi entitas biru yang saya perlihatkan dalam diagram khusus ini sebenarnya adalah objek yang disematkan. Dan kami menunjukkan kardinalitas yang berbeda. Kardinalitas intan berarti bahwa itu adalah objek di satu sisi, tetapi kardinalitas dari salah satu berarti bahwa kita memiliki, di dalam penerbit jika kita mengikuti hubungan itu, kita memiliki objek alamat tertanam. Dalam menginterogasi JSON, kami menemukan bahwa itu persis sama dengan struktur objek yang tertanam dalam pelindung, tetapi sebenarnya tertanam sebagai array objek. Kami melihat itu, tidak hanya melalui konektor itu sendiri, tetapi jika Anda melihat entitas yang sebenarnya, Anda akan melihat bahwa Anda melihat alamat di bawah pelindung yang juga mengklasifikasikannya sebagai array objek. Anda mendapatkan sudut pandang yang sangat deskriptif tentang bagaimana Anda bisa memasukkannya.

Dan lagi, sekarang apa yang telah kita lihat sejauh ini hanya dalam beberapa detik adalah model relasional tradisional yang multi-level, kita dapat melakukan hal yang sama dengan Hive, kita dapat melakukan hal yang sama dengan MongoDB, dan sumber data besar lainnya seperti baik. Apa yang bisa kami lakukan juga, dan saya akan menunjukkan ini dengan sangat cepat adalah, saya berbicara tentang fakta membawa barang-barang dari area lain yang berbeda. Saya akan berasumsi saya akan mengimpor model dari database atau merekayasa baliknya, tetapi saya akan membawanya dari metadata eksternal. Hanya untuk memberi Anda sudut pandang yang sangat cepat dari semua jenis hal yang bisa kita mulai bawa.

Seperti yang Anda lihat, kami memiliki segudang hal yang benar-benar dapat membawa metadata ke lingkungan pemodelan kami. Dimulai dengan hal-hal seperti Amazon Redshift, Cassandra, banyak platform data besar lainnya, sehingga Anda melihat banyak di antaranya yang terdaftar. Ini dalam urutan abjad. Kami melihat banyak sumber data besar dan hal semacam itu. Kami juga melihat banyak lingkungan pemodelan tradisional atau lebih lama yang benar-benar dapat kita bawa melalui metadata itu. Jika saya pergi ke sini - dan saya tidak akan menghabiskan waktu untuk masing-masing dari mereka - kita melihat banyak hal berbeda yang dapat kita bawa, dalam hal platform pemodelan dan platform data. Dan sesuatu yang sangat penting untuk disadari di sini adalah bagian lain yang dapat kita lakukan ketika kita mulai berbicara tentang garis keturunan data, pada Enterprise Team Edition kita juga dapat menginterogasi sumber ETL, apakah itu hal-hal seperti pemetaan Talend atau SQL Server Information Services, kita dapat sebenarnya membawa itu untuk memulai diagram garis silsilah data kami juga dan menggambar apa yang terjadi dalam transformasi tersebut. Secara keseluruhan di luar kotak kami memiliki lebih dari 130 jembatan berbeda ini yang sebenarnya merupakan bagian dari produk Enterprise Team Edition, sehingga sangat membantu kami untuk menggabungkan semua artefak ke dalam satu lingkungan pemodelan dengan sangat cepat.

Last but not least, saya juga ingin berbicara tentang fakta bahwa kita tidak dapat melupakan fakta bahwa kita memerlukan jenis konstruksi lainnya jika kita melakukan pergudangan data atau segala jenis analitik. Kami masih ingin memiliki kemampuan untuk melakukan hal-hal seperti model dimensi di mana kami memiliki tabel fakta dan kami memiliki dimensi dan hal-hal semacam itu. Satu hal yang ingin saya tunjukkan juga kepada Anda adalah kami juga dapat memiliki ekstensi untuk metadata kami yang membantu kami untuk mengkategorikan jenis dimensi dan segala hal lainnya. Jadi jika saya melihat tab data dimensi di sini, misalnya, pada salah satu dari ini, sebenarnya akan secara otomatis mendeteksi, berdasarkan pada pola model yang dilihatnya, dan memberi Anda titik awal, apakah menurutnya itu dimensi atau dimensi. tabel fakta. Tetapi di luar itu, apa yang dapat kita lakukan adalah di dalam dimensi dan jenis benda yang bahkan kita miliki berbagai jenis dimensi yang dapat kita gunakan untuk mengklasifikasikan data dalam jenis lingkungan pergudangan data juga. Kemampuan yang sangat kuat yang kita gunakan untuk menjahit ini.

Saya akan melompat ke yang ini karena saya berada di lingkungan demo sekarang dan menunjukkan kepada Anda beberapa hal lain sebelum saya melompat kembali ke slide. Salah satu hal yang baru-baru ini kami tambahkan ke ER / Studio Data Architect adalah kami mengalami situasi - dan ini adalah kasus penggunaan yang sangat umum ketika Anda mengerjakan proyek - pengembang berpikir dalam hal objek, sedangkan data kami pemodel cenderung berpikir dalam hal tabel dan entitas dan hal semacam itu. Ini adalah model data yang sangat sederhana, tetapi ini mewakili beberapa konsep dasar, di mana para pengembang atau bahkan analis bisnis atau pengguna bisnis, mungkin menganggap mereka sebagai objek atau konsep bisnis yang berbeda. Sudah sangat sulit untuk mengklasifikasikan ini sampai sekarang tetapi apa yang sebenarnya telah kita lakukan di ER / Studio Enterprise Team Edition, dalam rilis 2016, adalah kita sekarang memiliki konsep yang disebut Business Data Objects. Dan apa yang memungkinkan kita lakukan adalah memungkinkan kita untuk merangkum kelompok entitas atau tabel menjadi objek bisnis yang sebenarnya.

Sebagai contoh, apa yang kami dapatkan di sini pada tampilan baru ini adalah header Purchase Order dan Order Line telah digabungkan sekarang, mereka dienkapsulasi sebagai objek, kami akan menganggapnya sebagai unit kerja ketika kami mempertahankan data, dan kami menyatukan mereka sehingga sekarang sangat mudah untuk menghubungkannya dengan audiens yang berbeda. Mereka dapat digunakan kembali di seluruh lingkungan pemodelan. Mereka adalah objek yang benar, bukan hanya konstruksi gambar, tetapi kami juga memiliki manfaat tambahan bahwa ketika kita benar-benar berkomunikasi dari perspektif pemodelan kita dapat secara selektif runtuh atau memperluas mereka sehingga kita dapat menghasilkan tampilan ringkasan untuk dialog dengan audiens pemangku kepentingan tertentu, dan kami juga dapat, tentu saja, menjaga tampilan yang lebih terperinci seperti yang kami lihat di sini untuk lebih banyak audiensi teknis. Itu benar-benar memberi kita kendaraan komunikasi yang sangat bagus. Apa yang kita lihat sekarang adalah menggabungkan beberapa tipe model yang berbeda, menambahnya dengan konsep objek data bisnis, dan sekarang saya akan berbicara tentang bagaimana kita sebenarnya menerapkan lebih banyak makna pada jenis-jenis hal ini dan bagaimana kita menjalinnya bersama di lingkungan keseluruhan.

Saya hanya mencoba menemukan WebEx saya di sini sehingga saya dapat melakukannya. Dan begitulah, kembali ke slide Hot Tech. Saya hanya akan memajukan beberapa slide di sini karena Anda sudah melihat ini dalam demonstrasi model itu sendiri. Saya ingin berbicara tentang penamaan standar dengan sangat cepat. Kami ingin menerapkan dan menegakkan standar penamaan yang berbeda. Apa yang ingin kita lakukan adalah, kita memiliki kemampuan untuk benar-benar menyimpan templat standar penamaan di repositori kita untuk pada dasarnya membangun makna itu melalui, melalui kata-kata atau frasa atau bahkan singkatan, dan mengikatnya kembali ke jenis kata bahasa Inggris yang bermakna. Kita akan menggunakan istilah bisnis, singkatan untuk masing-masing, dan kita dapat menentukan urutan, kasing dan menambahkan awalan dan sufiks. Kasus penggunaan khas untuk ini biasanya ketika orang telah membangun model logis dan kemudian benar-benar maju untuk membuat model fisik di mana mereka mungkin menggunakan singkatan dan yang lainnya.

Hal yang indah adalah itu sama kuatnya, bahkan lebih kuat lagi secara terbalik, jika kita bisa mengatakan apa saja standar penamaan itu pada beberapa database fisik yang telah kita rekayasa balik, kita dapat mengambil singkatan itu, mengubahnya menjadi lebih panjang kata-kata, dan membawanya kembali ke frasa bahasa Inggris. Kami sebenarnya sekarang dapat memperoleh nama yang tepat untuk seperti apa data kami. Seperti yang saya katakan, kasus penggunaan yang umum adalah kita akan bergerak maju, logis ke fisik, dan memetakan penyimpanan data dan hal semacam itu. Jika Anda melihat tangkapan layar di sisi kanan, Anda akan melihat ada nama-nama yang disingkat dari nama sumber dan ketika kami telah menerapkan templat standar penamaan, kami sebenarnya punya lebih banyak nama lengkap. Dan kita bisa meletakkan spasi dan semuanya seperti itu jika kita mau, tergantung pada templat standar penamaan yang kita gunakan. Kita dapat membuatnya terlihat namun kami ingin terlihat untuk membawa ke dalam model kami. Hanya ketika kita tahu apa sesuatu yang disebut kita dapat benar-benar mulai melampirkan definisi padanya, karena kecuali kita tahu apa itu, bagaimana kita bisa menerapkan artinya?

Yang menyenangkan adalah, apakah kita benar-benar dapat memohon ini ketika kita melakukan segala macam hal. Saya berbicara tentang reverse engineering, kita sebenarnya dapat memanggil templat standar penamaan secara bersamaan ketika kita melakukan reverse engineering. Jadi dalam satu set langkah melalui penyihir, apa yang dapat kita lakukan adalah, jika kita tahu apa konvensi itu, kita dapat merekayasa balik database fisik, itu akan membawanya kembali sebagai model fisik dalam lingkungan pemodelan dan itu juga akan menerapkan konvensi penamaan tersebut. Jadi kita akan melihat apa representasi nama seperti bahasa Inggris dalam model logis yang sesuai di lingkungan. Kami juga dapat melakukannya dan menggabungkannya dengan pembuatan Skema XML sehingga kami dapat mengambil model dan bahkan mendorongnya dengan singkatan kami, apakah kami sedang melakukan kerangka kerja SOA atau hal-hal semacam itu, jadi kami kemudian dapat mendorong keluar berbagai konvensi penamaan yang berbeda. bahwa kita sebenarnya telah disimpan dalam model itu sendiri. Ini memberi kita banyak kemampuan yang sangat kuat.

Sekali lagi, ini adalah contoh dari apa yang akan terlihat jika saya memiliki templat. Yang ini sebenarnya menunjukkan bahwa saya memiliki EMP untuk “karyawan, ” SAL untuk “gaji, ” PLN untuk “rencana” dalam konvensi standar penamaan. Saya juga bisa menerapkannya agar dijalankan secara interaktif karena saya sedang membangun model dan memasukkan berbagai hal. Jika saya menggunakan singkatan ini dan saya mengetik "Rencana Gaji Karyawan" pada nama entitas, itu akan bertindak dengan templat standar penamaan Saya telah mendefinisikan di sini, itu akan memberi saya EMP_SAL_PLN karena saya membuat entitas dan memberi saya nama fisik yang sesuai segera.

Sekali lagi, sangat bagus untuk ketika kita sedang merancang dan memajukan teknik juga. Kami memiliki konsep yang sangat unik dan di sinilah kami benar-benar mulai menyatukan lingkungan ini. Dan itu disebut Pemetaan Universal. Setelah kami membawa semua model ini ke lingkungan kami, apa yang dapat kami lakukan, dengan asumsi bahwa kami sekarang telah menerapkan konvensi penamaan ini dan mudah ditemukan, kami sekarang dapat menggunakan konstruk yang disebut Pemetaan Universal di ER /Studio. Kami dapat menautkan entitas di seluruh model. Di mana pun kita melihat "pelanggan" - kita mungkin akan memiliki "pelanggan" di banyak sistem yang berbeda dan banyak basis data yang berbeda - kita dapat mulai menghubungkan semua itu bersama-sama sehingga ketika saya bekerja dengannya dalam satu model I dapat melihat di mana manifestasi pelanggan dalam model lain. Dan karena kami memiliki lapisan model yang mewakili hal itu, kami bahkan dapat mengikatnya ke sumber data dan membawanya ke dalam pertanyaan kami di mana digunakan di mana basis data melakukan ini juga berada. Ini benar-benar memberi kita kemampuan untuk mengikat semua ini dengan sangat kohesif.

Saya telah menunjukkan kepada Anda objek data bisnis. Saya juga ingin berbicara tentang ekstensi metadata, yang kami sebut Lampiran, dengan sangat cepat. Apa yang dilakukannya adalah memberi kita kemampuan untuk membuat metadata tambahan untuk objek model kita. Cukup sering saya akan mengatur jenis properti ini untuk mendorong banyak hal yang berbeda dari tata kelola data dan perspektif kualitas data, dan juga untuk membantu kami dengan manajemen data master dan kebijakan penyimpanan data. Ide dasarnya adalah Anda membuat klasifikasi ini dan Anda dapat melampirkannya di mana pun Anda mau, di level tabel, level kolom, hal-hal semacam itu. Kasus penggunaan yang paling umum, tentu saja, adalah bahwa entitas adalah tabel, dan kemudian saya dapat mendefinisikan: apa objek data master saya, apa tabel referensi saya, apa tabel transaksional saya? Dari perspektif kualitas data, saya dapat melakukan klasifikasi dalam hal kepentingan bisnis sehingga kami dapat memprioritaskan upaya pembersihan data dan hal-hal semacam itu.

Sesuatu yang sering diabaikan adalah, apa kebijakan retensi untuk berbagai jenis data dalam organisasi kita? Kami dapat mengatur ini dan kami benar-benar dapat melampirkannya ke berbagai jenis artefak informasi di lingkungan pemodelan kami dan, tentu saja, repositori kami juga. Keindahannya adalah, apakah lampiran ini hidup di kamus data kami sehingga saat kami menggunakan kamus data perusahaan di lingkungan, kami dapat melampirkannya ke beberapa model. Kita hanya perlu mendefinisikannya sekali dan kita dapat memanfaatkannya berulang-ulang di berbagai model di lingkungan kita. Ini hanyalah tangkapan layar cepat untuk menunjukkan bahwa Anda benar-benar dapat menentukan kapan Anda melakukan lampiran, semua bagian yang ingin Anda lampirkan. Dan contoh ini di sini sebenarnya adalah daftar nilai, jadi ketika mereka masuk Anda dapat memilih dari daftar nilai, Anda memiliki banyak kontrol dalam lingkungan pemodelan dari apa yang dipetik, dan Anda bahkan dapat mengatur apa yang default nilai adalah jika nilai tidak dipilih. Begitu banyak kekuatan di sana. Mereka tinggal di kamus data.

Sesuatu yang saya ingin tunjukkan sedikit lebih jauh pada layar ini, selain itu Anda melihat lampiran muncul di bagian atas, di bawahnya Anda melihat informasi keamanan data. Kami benar-benar dapat menerapkan kebijakan keamanan data ke berbagai informasi di lingkungan juga. Untuk pemetaan kepatuhan yang berbeda, klasifikasi keamanan data, kami mengirimkan beberapa dari mereka di luar kotak yang bisa Anda hasilkan dan mulai digunakan, tetapi Anda juga bisa menentukan pemetaan kepatuhan dan standar Anda sendiri. Apakah Anda sedang melakukan HIPAA atau inisiatif lain di luar sana. Dan Anda benar-benar dapat mulai membangun set metadata yang sangat kaya ini di lingkungan Anda.

Dan kemudian Glosarium dan Ketentuan - di sinilah makna bisnis terkait. Kami cukup sering memiliki kamus data di luar sana yang cukup sering digunakan oleh organisasi sebagai titik awal untuk mulai mengeluarkan glosarium, tetapi terminologi dan kata kerjanya adalah seringkali sangat teknis. Jadi yang bisa kita lakukan adalah kita bisa, jika mau, menggunakan itu sebagai titik awal untuk mengusir glosarium, tetapi kita benar-benar ingin bisnis memiliki ini. Apa yang telah kami lakukan di lingkungan server tim adalah kami telah memberikan kemampuan bagi orang-orang untuk membuat definisi bisnis dan kemudian kami dapat menautkannya ke berbagai artefak model yang sesuai dengan mereka di lingkungan pemodelan juga. Kami juga mengenali poin yang telah dibahas sebelumnya yaitu, semakin banyak orang yang Anda ketik, semakin banyak potensi kesalahan manusia. Apa yang juga kami lakukan dalam struktur glosarium kami adalah, satu, kami mendukung hierarki glosarium, sehingga kami dapat memiliki berbagai jenis glosarium atau berbagai jenis hal dalam organisasi, tetapi yang sama pentingnya, adalah jika Anda telah memiliki beberapa sumber ini di luar sana dengan ketentuan dan semua yang didefinisikan, kita sebenarnya dapat melakukan impor CSV untuk menarik ini ke dalam lingkungan pemodelan kita, dan server tim kita atau glosarium kita juga, dan kemudian mulai menghubungkan dari sana. Dan setiap kali sesuatu diubah ada jejak audit penuh tentang apa gambar sebelum dan sesudah itu, dalam hal definisi dan segala sesuatu yang lain, dan apa yang akan Anda lihat dalam waktu dekat juga lebih merupakan alur kerja otorisasi jadi kita benar-benar dapat mengendalikan siapa yang bertanggung jawab atas hal itu, persetujuan oleh komite atau individu, dan hal semacam itu, untuk membuat proses tata kelola semakin kuat saat kita melangkah maju.

Apa yang ini juga lakukan untuk kami adalah ketika kami memiliki istilah-istilah ini dalam daftar server server kami, ini adalah contoh mengedit dalam entitas dalam model itu sendiri yang saya bawa ke sini. Ini mungkin memiliki istilah yang ditautkan, tetapi yang kami lakukan adalah jika ada kata-kata di glosarium yang muncul di catatan atau deskripsi tentang apa yang kami miliki di entitas kami di sini, yang secara otomatis ditampilkan dalam warna hyperlink yang lebih ringan, dan jika kami arahkan mouse ke mereka, kita juga bisa melihat definisi dari glosarium bisnis. Itu bahkan memberi kita informasi yang lebih kaya ketika kita mengonsumsi informasi itu sendiri, dengan semua istilah glosarium yang ada di luar sana. Sangat membantu untuk memperkaya pengalaman dan menerapkan artinya untuk semua yang kami kerjakan.

Jadi, sekali lagi, itu sangat cepat. Jelas kami bisa menghabiskan waktu berhari-hari untuk hal ini karena kami mempelajari bagian-bagian yang berbeda, tetapi ini adalah jalan cepat yang sangat cepat ke permukaan. Apa yang benar-benar ingin kami lakukan adalah memahami seperti apa lingkungan data yang kompleks itu. Kami ingin meningkatkan visibilitas semua artefak data tersebut dan berkolaborasi untuk mengusirnya dengan ER / Studio. Kami ingin mengaktifkan pemodelan data yang lebih efisien dan otomatis. Dan itu semua jenis data yang sedang kita bicarakan, apakah itu data besar, data relasional tradisional, penyimpanan dokumen, atau yang lainnya. Dan lagi, kami mencapai itu karena kami memiliki kemampuan rekayasa maju dan mundur yang kuat untuk platform yang berbeda dan alat-alat lain yang mungkin Anda miliki di luar sana. Dan ini semua tentang berbagi dan berkomunikasi di seluruh organisasi dengan semua pemangku kepentingan yang terlibat. Di situlah kami menerapkan makna melalui standar penamaan. Kami kemudian menerapkan definisi melalui daftar istilah bisnis kami. Dan kemudian kita dapat melakukan klasifikasi lebih lanjut untuk semua kemampuan tata kelola kami yang lain dengan ekstensi metadata seperti ekstensi kualitas data, klasifikasi untuk manajemen data master, atau jenis klasifikasi lain yang ingin Anda terapkan pada data itu. Dan kemudian kita dapat merangkum lebih jauh dan meningkatkan komunikasi bahkan lebih dengan objek data bisnis, dengan audiens pemangku kepentingan yang berbeda, terutama antara pemodel dan pengembang.

Dan lagi, yang sangat penting tentang hal ini adalah, di balik itu semua adalah repositori terintegrasi dengan kemampuan manajemen perubahan yang sangat kuat. Saya tidak punya waktu untuk menunjukkannya hari ini karena itu menjadi cukup rumit, tetapi repositori memiliki kemampuan manajemen perubahan yang sangat kuat dan jejak audit. Anda dapat melakukan rilis yang dinamai, Anda dapat melakukan versi yang dinamai, dan kami juga memiliki kemampuan bagi Anda yang melakukan manajemen perubahan, kami dapat mengikat itu langsung ke dalam tugas Anda. Kami memiliki kemampuan hari ini untuk memasukkan tugas dan mengaitkan perubahan model Anda dengan tugas, sama seperti pengembang akan mengaitkan perubahan kode mereka dengan tugas atau cerita pengguna yang mereka kerjakan juga.

Sekali lagi, itu adalah gambaran yang sangat cepat. Saya harap sudah cukup untuk membangkitkan selera Anda sehingga kami dapat terlibat dalam percakapan yang lebih mendalam tentang membagi beberapa topik ini saat kami melangkah maju di masa depan. Terima kasih atas waktu Anda, dan kembali kepada Anda, Rebecca.

Rebecca Jozwiak: Terima kasih, Ron, itu luar biasa dan saya punya beberapa pertanyaan dari para hadirin, tetapi saya ingin memberi para analis kami kesempatan untuk menekuni apa yang Anda katakan. Eric, saya akan pergi ke depan dan mungkin jika Anda ingin mengatasi slide ini, atau yang berbeda, mengapa Anda tidak pergi dulu? Atau pertanyaan lain.

Eric Little: Tentu. Maaf, apa pertanyaannya, Rebecca? Anda ingin saya menanyakan sesuatu yang spesifik atau …?

Rebecca Jozwiak: Saya tahu Anda awalnya memiliki beberapa pertanyaan untuk Ron. Jika Anda ingin bertanya sekarang kepadanya untuk mengatasi salah satu dari mereka, atau beberapa dari mereka dari slide Anda atau hal lain yang menggelitik minat Anda yang ingin Anda tanyakan? Tentang fungsionalitas pemodelan IDERA.

Eric Little: Ya, jadi salah satu hal, Ron, jadi bagaimana kalian, sepertinya diagram yang Anda perlihatkan adalah jenis umum diagram hubungan entitas seperti yang biasanya Anda gunakan dalam konstruksi basis data, benar?

Ron Huizenga: Ya, secara umum, tapi tentu saja kami memiliki tipe yang diperluas untuk toko dokumen dan hal semacam itu juga. Kami sebenarnya bervariasi dari hanya notasi relasional murni, kami sebenarnya menambahkan notasi tambahan untuk toko-toko lain juga.

Eric Little: Apakah ada cara agar kalian dapat menggunakan jenis pemodelan berbasis grafik, jadi apakah ada cara untuk mengintegrasikan, misalnya, mari kita misalkan saya memiliki sesuatu seperti kuadran teratas, alat komposer TopBraid atau saya telah melakukan sesuatu di Protégé atau, Anda tahu, seperti orang keuangan di FIBO, mereka melakukan banyak pekerjaan dalam semantik, hal-hal RDF - apakah ada cara untuk memasukkan jenis pemodelan tipe grafik hubungan-entitas ke dalam alat ini, dan memanfaatkan Itu?

Ron Huizenga: Kami benar-benar melihat bagaimana kami dapat menangani grafik. Kami tidak secara eksplisit menangani basis data grafik dan hal semacam itu hari ini, tetapi kami sedang mencari cara yang dapat kami lakukan untuk memperluas metadata kami. Maksud saya, kita bisa membawa hal-hal melalui XML dan hal semacam itu sekarang, jika kita setidaknya bisa melakukan semacam rendition XML untuk membawanya sebagai titik awal. Tapi kami sedang mencari cara yang lebih elegan untuk membawanya.

Dan saya juga menunjukkan kepada Anda bahwa daftar jembatan rekayasa terbalik yang kami miliki di sana juga, jadi kami selalu mencari untuk mendapatkan ekstensi ke jembatan itu untuk platform tertentu juga. Ini adalah upaya yang berkelanjutan dan berkelanjutan, jika itu masuk akal, untuk mulai merangkul banyak konstruksi baru dan platform yang berbeda di luar sana. Tetapi saya dapat mengatakan bahwa kami jelas berada di garis depan dalam melakukan itu. Hal-hal yang saya perlihatkan, misalnya, MongoDB dan hal semacam itu, kami adalah vendor pemodelan data pertama yang benar-benar melakukannya secara asli di produk kami sendiri.

Eric Little: Oke, ya. Jadi pertanyaan lain yang saya miliki untuk Anda, kemudian, adalah dalam hal tata kelola dan pemeliharaan - seperti ketika Anda menggunakan contoh, ketika Anda menunjukkan contoh orang yang merupakan "karyawan, " saya percaya itu adalah " gaji "dan kemudian Anda memiliki" rencana, "apakah ada cara, bagaimana Anda mengelola, misalnya, berbagai jenis orang yang mungkin memiliki - misalkan Anda memiliki arsitektur besar, benar, anggaplah Anda memiliki perusahaan besar dan orang-orang mulai mengumpulkan hal-hal bersama dalam alat ini dan Anda punya satu kelompok di sini yang memiliki kata "karyawan" dan satu kelompok di sini yang memiliki kata "pekerja." Dan satu orang di sini mengatakan "gaji" dan orang lain mengatakan "upah."

Bagaimana kalian mendamaikan dan mengelola serta mengatur perbedaan-perbedaan itu? Karena saya tahu bagaimana kami akan melakukannya di dunia grafik, Anda tahu, Anda akan menggunakan daftar sinonim atau Anda akan mengatakan ada satu konsep dan memiliki beberapa atribut, atau Anda dapat mengatakan dalam model SKOS saya memiliki label pilihan dan saya punya banyak label alternatif yang bisa saya gunakan. Bagaimana kalian melakukan itu?

Ron Huizenga: Kami melakukannya dengan beberapa cara berbeda, dan terutama mari kita bicara tentang terminologi terlebih dahulu. Salah satu hal yang kami lakukan, tentu saja, adalah kami ingin memiliki ketentuan yang ditetapkan atau disetujui dan dalam glosarium bisnis jelas adalah di mana kami menginginkannya. Dan kami juga mengizinkan tautan ke sinonim dalam glosarium bisnis sehingga yang dapat Anda lakukan adalah Anda dapat mengatakan, inilah istilah saya, tetapi Anda juga dapat menentukan apa semua sinonim untuk semua itu.

Sekarang hal yang menarik, tentu saja, adalah ketika Anda mulai mencari di seluruh lanskap data yang luas ini dengan semua sistem berbeda yang telah Anda dapatkan di sana, Anda tidak bisa hanya pergi ke sana dan mengubah tabel yang sesuai dan jenis-jenis hal yang menjadi sesuai dengan standar penamaan karena itu mungkin paket yang Anda beli, jadi Anda tidak punya kendali untuk mengubah database atau apa pun.

Apa yang bisa kita lakukan di sana, selain dapat mengaitkan definisi glosarium, adalah melalui pemetaan universal yang saya bicarakan, apa yang akan kita lakukan, dan semacam pendekatan yang direkomendasikan, adalah memiliki model logis menyeluruh yang menjabarkan apa konsep bisnis yang berbeda ini adalah yang Anda bicarakan. Ikatkan istilah glosarium bisnis ke dalam istilah-istilah tersebut, dan yang menyenangkan adalah sekarang Anda telah mendapatkan konstruk yang mewakili entitas logis seperti sebelumnya, Anda kemudian dapat mulai menautkan dari entitas logis itu ke semua implementasi entitas logis itu di sistem yang berbeda.

Maka di mana Anda perlu melakukannya, Anda dapat melihat, oh, "orang" di sini disebut "karyawan" dalam sistem ini. "Gaji" di sini disebut "upah" di sini di sistem lain ini. Karena Anda akan melihat itu, Anda akan melihat semua manifestasi yang berbeda karena Anda telah menghubungkannya bersama.

Eric Little: Oke bagus, ya, mengerti. Dalam pengertian itu, apakah aman untuk mengatakan bahwa itu seperti beberapa pendekatan berorientasi objek?

Ron Huizenga: Agaknya. Ini sedikit lebih intensif daripada, saya kira Anda bisa mengatakannya. Maksud saya, Anda bisa mengambil pendekatan menghubungkan secara manual dan melalui dan memeriksa dan melakukan semuanya juga. Satu hal yang saya tidak punya kesempatan untuk dibicarakan - karena sekali lagi, kami memiliki banyak kemampuan - kami juga memiliki antarmuka otomatisasi penuh pada alat Arsitek Data itu sendiri. Dan kemampuan makro, yang benar-benar bahasa pemrograman dalam alat ini. Jadi kita benar-benar dapat melakukan hal-hal seperti menulis makro, minta keluar dan menginterogasi hal-hal dan membuat tautan untuk Anda. Kami menggunakannya untuk mengimpor dan mengekspor informasi, kami dapat menggunakannya untuk mengubah hal-hal atau menambahkan atribut, peristiwa berdasarkan dalam model itu sendiri, atau kita dapat menggunakannya untuk berjalan dalam batch untuk benar-benar keluar dan menginterogasi hal-hal dan benar-benar mengisi konstruksi yang berbeda dalam model. Jadi ada antarmuka otomatisasi penuh yang dapat dimanfaatkan orang. Dan memanfaatkan pemetaan universal dengan itu akan menjadi cara yang sangat kuat untuk melakukan itu.

Rebecca Jozwiak: Oke, terima kasih Ron, dan terima kasih Eric. Itu adalah pertanyaan bagus. Aku tahu kita berlari sedikit melewati jam paling atas, tapi aku ingin memberi Malcolm kesempatan untuk melemparkan beberapa pertanyaan dengan cara Ron. Malcolm?

Malcolm Chisholm: Terima kasih, Rebecca. Jadi, Ron, ini sangat menarik, saya melihat ada banyak kemampuan di sini. Salah satu bidang yang saya sangat tertarik adalah, katakanlah jika kita memiliki proyek pengembangan, bagaimana Anda melihat pemodel data menggunakan kemampuan ini dan bekerja mungkin lebih kolaboratif dengan analis bisnis, dengan profiler data, dengan analis kualitas data, dan dengan sponsor bisnis yang pada akhirnya akan bertanggung jawab atas persyaratan informasi aktual dalam proyek. Bagaimana pemodel data benar-benar, Anda tahu, membuat proyek lebih efektif dan efisien dengan kemampuan yang kami lihat?

Ron Huizenga: Saya pikir salah satu hal pertama yang harus Anda lakukan di sana adalah sebagai pemodel data - dan saya tidak bermaksud memilih beberapa pemodel, tetapi saya tetap akan melakukannya - beberapa orang masih memiliki kesan bahwa pemodel data benar-benar jenis peran penjaga gerbang seperti, kami mendefinisikan cara kerjanya, kami adalah penjaga yang memastikan bahwa semuanya benar.

Sekarang ada aspek dari itu, bahwa Anda harus memastikan bahwa Anda mendefinisikan arsitektur data suara dan yang lainnya. Tetapi yang lebih penting adalah sebagai pemodel data - dan saya menemukan ini agak jelas ketika saya berkonsultasi - adalah Anda harus menjadi fasilitator, jadi Anda harus menyatukan orang-orang ini.

Ini tidak akan menjadi desain di muka, menghasilkan, membangun database lagi - apa yang perlu Anda lakukan adalah Anda harus dapat bekerja dengan semua kelompok pemangku kepentingan yang berbeda ini, melakukan hal-hal seperti rekayasa terbalik, mengimpor informasi, memiliki orang lain berkolaborasi, baik itu di glosarium atau dokumentasi, semuanya seperti itu - dan menjadi fasilitator untuk menarik ini ke dalam repositori, dan menghubungkan konsep-konsep bersama-sama dalam repositori, dan bekerja dengan orang-orang itu.

Ini benar-benar lebih dari jenis lingkungan kolaboratif di mana bahkan melalui definisi tugas atau bahkan utas diskusi atau jenis hal yang kita miliki di server tim, bahwa orang dapat benar-benar berkolaborasi, mengajukan pertanyaan dan tiba di produk akhir yang mereka butuhkan untuk arsitektur data dan organisasi mereka. Apakah itu semacam jawaban?

Malcolm Chisholm: Ya, saya setuju. Anda tahu, saya pikir keterampilan fasilitasi adalah sesuatu yang sangat diinginkan oleh para pemodel data. Saya setuju bahwa kita tidak selalu melihat itu, tetapi saya pikir itu perlu dan saya akan menyarankan bahwa ada kecenderungan untuk tetap di sudut Anda melakukan pemodelan data Anda, tetapi Anda benar-benar perlu berada di luar sana bekerja dengan kelompok pemangku kepentingan lain atau Anda hanya tidak mengerti lingkungan data yang Anda hadapi, dan saya pikir modelnya menderita. Tapi itu hanya pendapat saya.

Ron Huizenga: Dan itu menarik karena Anda menyebutkan sesuatu sebelumnya dalam slide Anda tentang sejarah tentang bagaimana bisnis agak berpaling dari TI karena mereka tidak memberikan solusi secara tepat waktu dan hal-hal semacam itu.

Sangat menarik bahwa dalam keterlibatan konsultasi saya selanjutnya, sebelum menjadi manajer produk, sebagian besar proyek yang saya lakukan dalam dua tahun terakhir sebelum itu, disponsori oleh bisnis, di mana sebenarnya bisnislah yang menggerakkannya dan arsitek data dan pemodel bukanlah bagian dari IT. Kami adalah bagian dari kelompok yang disponsori bisnis dan kami ada di sana sebagai fasilitator yang bekerja dengan tim proyek lainnya.

Malcolm Chisholm: Jadi saya pikir itu poin yang sangat menarik. Saya pikir kita mulai melihat perubahan dalam dunia bisnis di mana bisnis itu bertanya, atau berpikir mungkin, tidak sebanyak apa yang saya lakukan, seperti proses, tetapi mereka juga mulai berpikir tentang apa data yang saya kerjakan, apa kebutuhan data saya, apa data yang saya tangani sebagai data, dan sejauh mana kita bisa mendapatkan produk dan kemampuan IDERA untuk mendukung sudut pandang itu, dan saya pikir itu kebutuhan bisnis, bahkan meskipun agak masih baru lahir.

Ron Huizenga: Saya setuju dengan Anda dan saya pikir kami melihatnya semakin dan semakin seperti itu. Kami telah melihat kebangkitan dan Anda menyentuhnya sebelumnya dalam hal pentingnya data. Kami melihat pentingnya data di awal TI atau dalam evolusi basis data, lalu seperti yang Anda katakan, kami masuk ke dalam seluruh siklus manajemen proses ini - dan prosesnya sangat penting, jangan salah paham di sana - tetapi sekarang apa yang terjadi adalah ketika itu terjadi, data semacam kehilangan fokus.

Dan sekarang organisasi menyadari bahwa data benar-benar adalah titik fokus. Data mewakili semua yang kami lakukan dalam bisnis kami sehingga kami perlu memastikan bahwa kami memiliki data yang akurat, bahwa kami dapat menemukan informasi yang benar yang kami butuhkan untuk mengambil keputusan. Karena tidak semuanya berasal dari proses yang ditentukan. Beberapa informasi adalah produk sampingan dari hal-hal lain dan kami masih harus dapat menemukannya, mengetahui artinya, dan dapat menerjemahkan data yang kami lihat di sana pada akhirnya menjadi pengetahuan yang dapat kami gunakan untuk mendorong bisnis kami lebih baik.

Malcolm Chisholm: Benar, dan sekarang bidang lain yang telah saya perjuangkan adalah apa yang saya sebut siklus hidup data yang, Anda tahu, jika kita melihat jenis rantai pasokan data yang melalui suatu perusahaan, kita akan mulai dengan akuisisi data atau pengambilan data, yang mungkin merupakan entri data tetapi mungkin juga sama, saya mendapatkan data dari luar perusahaan dari beberapa vendor data.

Dan kemudian dari pengambilan data, kami pergi ke pemeliharaan data di mana saya berpikir tentang menstandarisasi data ini dan mengirimkannya ke tempat-tempat yang dibutuhkan. Dan kemudian menggunakan data, titik aktual di mana data berada, Anda akan mendapatkan nilai dari data.

Dan di masa lalu ini semua dilakukan dalam satu gaya individu, tetapi hari ini mungkin, Anda tahu, lingkungan analitik, misalnya, dan kemudian di luar itu, arsip, toko, tempat kami meletakkan data saat kami tidak lagi membutuhkannya dan akhirnya semacam proses pembersihan. Bagaimana Anda melihat pemodelan data yang cocok dengan pengelolaan seluruh siklus hidup data ini?

Ron Huizenga: Itu pertanyaan yang sangat bagus dan satu hal yang saya benar-benar tidak punya waktu untuk menyelidiki detail di sini hari ini sama sekali, adalah apa yang kita benar-benar mulai bicarakan adalah aliran data. Jadi apa yang sebenarnya bisa kita lakukan adalah kita memiliki kemampuan garis keturunan data dalam alat kita dan, seperti yang saya katakan, kita sebenarnya dapat mengekstraknya dari alat ETL, tetapi Anda juga dapat memetakannya hanya dengan menggambar garis silsilah juga. Model atau basis data mana saja yang telah kami tangkap dan bawa ke dalam model, kami dapat mereferensikan konstruk dari yang ada di diagram garis silsilah data kami.

Apa yang dapat kami lakukan adalah menggambar aliran data, seperti yang Anda katakan, dari sumber ke target, dan melalui siklus hidup keseluruhan tentang bagaimana data transit melalui sistem yang berbeda dan apa yang akan Anda temukan adalah, mari kita ambil karyawan 'data - ini adalah salah satu favorit saya berdasarkan proyek yang saya lakukan bertahun-tahun yang lalu. Saya bekerja dengan organisasi yang memiliki data karyawan di 30 sistem yang berbeda. Apa yang akhirnya kami lakukan di sana - dan Rebecca memunculkan slide garis silsilah data - ini adalah slide garis silsilah data yang cukup sederhana di sini, tetapi yang dapat kami lakukan adalah membawa semua struktur data, merujuknya dalam diagram, dan kemudian kami dapat benar-benar mulai melihat apa yang mengalir di antara, dan bagaimana entitas-entitas data yang berbeda dihubungkan bersama dalam aliran? Dan kita bisa melampaui itu juga. Ini adalah bagian dari diagram aliran atau aliran data yang kita lihat di sini. Jika Anda ingin melampaui itu, kami juga memiliki arsitek bisnis bagian dari suite ini dan hal yang sama berlaku di sana.

Setiap struktur data yang telah kami tangkap di lingkungan pemodelan data, yang dapat dirujuk dalam alat pemodelan bisnis sehingga bahkan dalam diagram model bisnis Anda atau diagram proses bisnis Anda, Anda dapat mereferensikan penyimpanan data individual jika Anda ingin keluar dari lingkungan pemodelan data, dan saat Anda menggunakannya di folder dalam model proses bisnis Anda, Anda bahkan dapat menentukan CRUD pada mereka juga, tentang bagaimana informasi tersebut dikonsumsi atau diproduksi, dan kemudian kita dapat mulai menghasilkan hal-hal seperti laporan dampak dan analisis dan diagram dari itu.

Apa yang ingin kami capai, dan kami sudah memiliki banyak kemampuan, tetapi salah satu hal yang kami miliki memiliki semacam tiang gawang yang kami lihat, saat kami terus mengembangkan alat kami ke depan, mampu memetakan garis turunan data organisasi end-to-end dan siklus hidup penuh data.

Malcolm Chisholm: Oke. Rebecca, apakah aku diizinkan satu lagi?

Rebecca Jozwiak: Aku akan memberimu satu lagi, Malcolm, silakan.

Malcolm Chisholm: Terima kasih banyak. Berpikir tentang tata kelola data dan berpikir tentang pemodelan data, bagaimana kita membuat kedua kelompok bekerja secara efektif dan saling memahami?

Eric Little: Yah itu menarik, saya pikir itu benar-benar tergantung pada organisasi, dan kembali ke konsep saya sebelumnya adalah, dalam organisasi-organisasi di mana inisiatif didorong oleh bisnis, kami terikat. Misalnya, saya memimpin arsitektur data tim tetapi kami terikat langsung dengan pengguna bisnis dan kami benar-benar membantu mereka untuk mempertahankan program tata kelola data mereka. Sekali lagi, lebih merupakan pendekatan konsultatif tetapi sebenarnya lebih merupakan fungsi bisnis.

Apa yang benar-benar Anda butuhkan untuk dapat melakukan itu adalah Anda memerlukan pemodel data dan arsitek yang benar-benar memahami bisnis, dapat berhubungan dengan pengguna bisnis dan kemudian membantu mereka mempertahankan proses tata kelola di sekitarnya. Bisnis ingin melakukannya, tetapi secara umum kami memiliki pengetahuan teknologi untuk dapat membantu mereka menonjol dari jenis program tersebut. Ini benar-benar harus menjadi kolaborasi, tetapi harus dimiliki oleh bisnis.

Malcolm Chisholm: Oke, itu bagus. Terima kasih.

Eric Little: Oke.

Rebecca Jozwiak: Oke, terima kasih banyak. Anggota audiens, saya khawatir kami tidak menjawab pertanyaan Anda, tetapi saya akan memastikan bahwa mereka akan diteruskan ke tamu yang sesuai yang kami miliki di telepon hari ini. Saya ingin mengucapkan terima kasih banyak kepada Eric, Malcolm dan Ron karena telah menjadi tamu kami hari ini. Ini barang bagus, kawan. Dan jika Anda menikmati webcast IDERA hari ini, IDERA juga akan berada di Hot Technologies Rabu depan jika Anda ingin bergabung, membahas tantangan pengindeksan dan Orakel, jadi topik menarik lainnya.

Terima kasih banyak, semuanya, hati-hati, dan kami akan bertemu lagi lain kali. Sampai jumpa.