Paket servisi: Ev sahibi Eric Kavanagh, çevik kalkınmada veri modellemenin önemini Robin Bloor, Dez Blanchfield ve IDERA'dan Ron Huizenga ile tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya kaydolun.
Eric Kavanagh: Tamam bayanlar baylar. Bir kez daha tekrar hoşgeldiniz. Çarşamba saat 4: 00'te. Bu Sıcak Teknolojiler için zamanı demektir. Evet kesinlikle. Benim adım Eric Kavanagh, ev sahibiniz olacağım.
Bugünün konusu için, bir ihtiyar ama bir yiyecek. Her geçen gün daha da iyiye gidiyor, çünkü veri yönetimi dünyamızı, “Çevik Bir Ortamda Veri Modellemesi” ni şekillendiriyor. Sizinkiyle ilgili bir slayt var, @eric_kavanagh. Gerçekten o slayta koymalıyız. Buna katlanmak zorundayım.
Yani yıllar sıcak. Veri modelleme sonsuza kadar olmuştur. Gerçekten de bilgi yönetimi işinin kalbi ve ruhu, veri modelleri tasarlama, iş modellerini anlamaya ve bunları veri modellerinizle aynı hizaya getirmeye çalıştı. Gerçekten yapmaya çalıştığın şey bu, değil mi?
Veri modeli işletmeyi temel bir şekilde temsil eder, peki bütün bu yeni veri kaynakları oyunu nasıl değiştiriyor? Bunu öğrenecektik. Çevik bir şekilde şeylerin üstünde nasıl kalacağınızı bulacağız. Ve elbette, yılın sözü bu.
Robin Bloors bizimle, baş analistimiz Dez Blanchfield Sidney, Avustralya'dan arıyor ve IDERA Kıdemli Ürün Müdürü Ron Huizenga - uzun zamandır bir arkadaşım olan bu alanda mükemmel bir konuşmacı olan eşyalarını biliyor, bu yüzden utanma, ona sor zor sorular, millet, zor sorular. Bununla, Robin'i sunucu yapıp alıp götüreceğim.
Robin Bloor: Tamam. Bunun için teşekkürler Eric. Bence modellemeyle ilgili olarak şunu söylemeliyim ki, aslında var olmadan önce BT dünyasındaydım, çalıştığım sigorta şirketinden hatırladığım, bir erkek gelip hepimize bir şeyler verdiğimizi Verilerin nasıl modelleneceğine dair çalıştay. Yani yaklaşık 30 yıla bakıyorlardı, 30 yıl mı? Belki bundan daha uzun, belki 35 yıl önce. Uzun, uzun zamandır modelleme aslında endüstrinin bir parçası olmuştur ve elbette podyumdaki bayanlarla hiçbir ilgisi yoktur.
Söylemek istediğim şey, çünkü normalde yaptığımız şey, ben ve Dez'in farklı şeyler hakkında konuşması ve ben de sadece modellemeye genel bir genel bakış verdiğini düşündüm, ama bunun bir gerçekliği var ki, şimdi ortaya çıkıyor.
Biliyoruz ki, büyük veri gerçekliğine sahibiz, daha fazla veriye, daha fazla veri kaynağına sahibiz, son üç veya dört yılda denkleme giren veri akışlarını aldık ve daha büyük bir bölümünü almaya başladık. veriyi anlamak için daha fazla ihtiyaç ve daha fazla veri eklenecek ve ayrıca daha fazla veri yapısı kullanılan değişim oranındaki bir artış.
Bu zor bir dünya. Heres, yaklaşık üç yıl önce çizdiğimiz bir resim ama temelde, bir kez karışıma akış eklediğinizde ve bu veri rafinerisi, veri merkezi, veri bağlantısı ya da her neyse, bu veri olduğunu görüyorsunuz. gerçekten istirahat halinde, fazla hareket etmediği anlamında. Ve sonra, veriler, akışlar ve sizler tüm işlem uygulamalarını elde ettiler, artı bugünlerde olaylara, uygulamalarda meydana gelen olay veri akışlarına ve ihtiyaç duydukları olaylara ve bugünlerde söz konusu olan lambda mimarilerine sahip olmanızın gerçekten üzerinde etkisi olduğu sadece tüm veri alanı.
Ve günümüzde orada bir veri katmanı olduğunu düşünüyorum. Veri katmanı bir tür sanal yoldan var olur, bunun iyi bir parçasının bulutta olabileceği ve veri merkezlerine yayılabileceği anlamında iş istasyonlarında var olabilir. Veri katmanı, bir dereceye kadar, her yerde ve bu anlamda, verileri işlemek ve verileri hareket ettirmek için bir şekilde veya başka bir şekilde deneyen her yerde işlem vardır. Ama aynı zamanda hareket ettirirken ne olduğunu bilmek de çok önemli.
Veri modellemesine en genel anlamda bakarsak, bu tür bir yığının altında dosya ve veritabanları vardır. Anahtarlara, eleman tanımlarına, takma adlara, eş anlamlılara, belirli fiziksel formatlara sahip veri öğelerine sahipsiniz ve sonra bu meta veri katmanına sahibiz.
Meta verilerle ilgili ilginç olan şey, meta verilerin, verilerin tamamen anlamını nasıl kazandığıdır. Aslında meta verileriniz yoksa, en iyi ihtimalle verilerin anlamını tahmin edebilirsiniz, ancak çok fazla zorluk yaşayacaksınız. Meta verilerin orada olması gerekir, ancak anlam bir yapıya sahiptir. Anlam felsefesine girmek istemiyorum, ancak verilerle başa çıkmamıza rağmen, insan düşüncesi ve insan dilinde veride kendini kolayca ifade etmeyen çok fazla karmaşıklık var. Ancak, dünyada işlediğimiz veriler açısından bile, meta verinin anlamı ve meta verinin yapısı vardır - bir başkasıyla ilgili bir veri parçası ve bir araya getirildiğinde bunun ne anlama geldiği ve bunun ne zaman diğerine katıldığı anlamına gelir veri, onu modellememizi talep ediyor. Sadece meta veri etiketlerini şeyler kaydetmek için yeterince iyi değil, aslında yapılar başına anlam ve yapılar arasındaki ilişkiyi kaydetmeniz gerekiyor.
Daha sonra en üst katmana, normalde metadatalar arasında anlam aktarmaya çalışan bir katman olan iş tanımları var; bu, verilerin bilgisayarda düzenlenme biçimini ve insan anlamını barındıran bir veri tanımlaması biçimi. Demek ki bu katmanda var olan ticari terimleriniz, tanımlarınız, ilişkileriniz, varlık düzeyinde kavramlarınız var. Ve eğer bu katmanlar arasında bir tutarsızlığa sahip olacaksa, o zaman veri modellememiz gerekir. Gerçekten isteğe bağlı değil. Bunu otomatikleştirmek açısından ne kadar çok şey yapabilirseniz o kadar iyidir. Fakat bunun anlamı ile ilgisi olduğu için değişmesi gerçekten zor. Meta verileri bir kayıt içinde yakalamak ve onu bir dizi anlamdan elde etmek yeterince kolaydır, ancak kayıtların yapısını veya kayıtların kaydın ne anlama geldiğini veya kayıdını söyleyemez.
Bu yüzden, veri modellemesinin bence, hakkında olduğunu düşünüyorum. Dikkat edilmesi gereken noktalar: Veri evreni ne kadar karmaşık olursa, onu modellemek için o kadar çok ihtiyacınız olur. Başka bir deyişle, biraz daha fazla şey, dünyaya veri kayıtlarına tekabül eden daha fazla örnek eklemekle kalmayıp, aslında daha fazla şey hakkında veri toplayarak dünyaya daha fazla anlam katıyordu. Anlamamız gereken daha karmaşık bir his haline geliyor.
Teoride bir veri evreni vardır ve bunun bir manzarasına ihtiyacımız var. Uygulamada, gerçek meta veriler veri evreninin bir parçasıdır. Yani, basit bir durum değil. Başlangıç modellemesi yukarıdan aşağıya ve aşağıdan yukarıya doğrudur. Her iki yönde de inşa etmeniz gerekir ve bunun nedeni, verilerin bilgisayar ve süreç için anlam ifade etmesi, onu işlemesi gereken, ancak kendi başına bir anlamı vardır. Bu nedenle, verilere erişmesi gereken yazılımı karşılayan aşağıdan yukarıya bir anlama ihtiyacınız var ve insanların bunu anlayabilmesi için yukarıdan aşağıya anlamlara ihtiyacınız var. Meta veri modellerinin oluşturulması bir proje değildir ve asla olamaz; devam eden bir faaliyettir - var oldukları her ortamda devam eden bir faaliyet olmalıdır. Neyse ki, durum böyle olmadığı ve işler buna bağlı olarak kontrolden çıktığı birçok ortam var.
İleriye doğru, teknoloji ilerledikçe modelleme önem kazanıyor. Bu benim düşüncem. Ancak IoT'ye bakarsanız, yeni boyutlar getirmesine rağmen mobili eskisinden daha fazla anlayabiliriz: mobil olan yerin boyutu. IoT'ye ulaştığınızda, aslında daha önce hiç yapmak zorunda olmadığımız olağanüstü veri sorunlarına bakıyorduk ve tam olarak ne elde ettiğimizi, nasıl toplayabileceğimizi, ne yapabileceğimizi tam olarak anlayabilmemiz için bir yol ya da diğer Toplanmadan anlam kazanma ve elbette, işlediğimiz zaman onunla ne yapabiliriz.
Sanırım yeterince söylemiştim. Tamamen başka bir şey söyleyecek olan Dez Blanchfield'e geçeceğim.
Dez Blanchfield: Teşekkür ederim. Her zaman takip edilmesi zor bir eylem, ancak bu konu hakkında kısa bir süre önce preshow şaka yapan ve bunun hakkında kısa bir süre bahsettiğimiz bir konudur ve eğer erken aranırsanız, muhtemelen bir sürü harika mücevher almışsınızdır. Paket servislerden biri ve bu belirli birinin gökgürültüsünü çalmak istemiyorum, ancak yakalamak istemiyorsanız, paylaşmak istediğim şov programımızdan gelen paket servislerden biri, veri toplama yolculuğunun konusunu oluşturuyordu. ve veriyi nesiller boyu farklı bir çevrede geçirdiği yolculuk hakkında - yıl, ay, hafta, gün, saat, dakika, saniye - ve verilerin etrafındaki konunun bu konunun içine yerleştirildiği yolculuğu düşünerek yazmamı sağladı. . Bir kod çalıştıran bir geliştirici Im veya bir veri uzmanı olup olmadığımı ve her bir öğenin etrafındaki yapıyı, biçimi ve meta verileri veya sistemlerin ve işletmenin onunla etkileşim kurma şeklini düşünüyorum.
Sadece not etmek için ilginç bir küçük paket, ama yine de, dalmama izin verin. Özellikle veri tasarımı, her şeyden bahsetmek için kullandığım ve özellikle uygulamaların veya veritabanı altyapısının geliştirilmesinde kullandığım bir cümledir. Veri tasarımının sadece aklımdaki her şeyi çok iyi yakalayan bir terim olduğunu düşünüyorum. Veri tasarımı hakkında konuştuğumuz günlerde, modern çevik veri tasarımı hakkında konuşuyoruz ve görüşüme göre, uzun zaman önce geliştiriciler ve veri uzmanlarının tek başlarına çalıştıkları değildi; kendi silolarındaydılar ve tasarım parçaları bir silodan diğerine geçti. Ama bugünlerde görüşlerin çoğunu yapıyorum, bu sadece değişen durum değil, değişmesi gereken; bu bir zorunluluktur ve işte bu uygulama - geliştiriciler ve verilerle ilgilenen geliştirme ile ilgili her şey, şema ve alanların ilgili tasarım öğelerini yapan tasarımcılar ve kayıtlar ve konum ve veritabanı sistemleri ve altyapıları, modelleme ve tüm yönetim Bunun etrafında meydan. Bu şimdi bir takım sporu ve bu nedenle, gökyüzüne düşen insanların görsel olarak ilginç görüntüsünü ortaya çıkarmak için bir takım olarak hareket eden bir uçaktan atlayan bir grup insanın resmi.
Üçüncüsü, bunun getirilmesine ne oldu? Pekala, 1986 yılında isimleri adaleti yapmak için çaresizce denediğim birkaç beyefendi tarafından yazılan bir yazı var, Hirotaka Takeuchi ve Ikujiro Nonaka, "Scrum Downfield'ı Hareket Ettiler" başlıklı bir makale hazırladıklarını düşünüyorum. Herkesin tek bir yerde toplandığı ve iki takımın topun kontrolünü ele geçirmek ve oyun oynamak için esasen scrum denilen bir şeye kafa attığı bir rugby oyunu kazanma metodolojisi fikri. Deneme çizgisine gidin ve topla yere dokunun ve trine adı verilen bir puan alın ve bu işlemi tekrarlayın ve takım için daha fazla puan kazanın.
Bu makale 1986 yılında Harvard Business Review'de yayınlandı ve merakla çok dikkat çekti. Çok dikkat çekti, çünkü şaşırtıcı yeni konseptler ortaya koydu ve işte önündeki ekran görüntüsü. Bu yüzden bu oyun kavramını oyun rugby'sinden çıkardılar ve özellikle proje sunumu olmak üzere özellikle tasarım ve proje teslimi oyununda işe soktular.
Yaptığımız iş, bize daha önce kullandığımız PRINCE2 ya da PMBOK gibi şelale metodolojisi olarak adlandırdığımız şeylere kıyasla yeni bir metodoloji kazandırdı. etrafındaki tüm noktalar, ki bunlar sahip olduğunuza bağlıdır ya da birinci kısmı yapana kadar ikinci kısmı yapmayın, çünkü birinci kısmı bağlıydı. Bize verdiği şey, biraz daha çevik olmak için yeni bir metodoloji, yani terimin nereden geldiği, bir şeyleri nasıl sunduğumuz ve özellikle de tasarım ve geliştirme tabanları proje sunumu ile ilgili.
Anahtar kiracılardan bazıları - sadece bununla başa çıkmak için - scrumun ana kiracıları etrafında.İstikrarsızlık inşa etme fikrini ortaya koydu, etkili bir şekilde kaos korkusu hakkında düşünürseniz, dünya bir kaos halinde var olur, ancak ilginç olan gezegen oluştu, bu yüzden dengesizliği inşa etme, biraz zıplama yeteneği ve hala işleri işler hale getirir, proje ekiplerini organize eder, çok sorumlu gelişim ile örtüşen iyilikler, proje teslim yolculuğu boyunca farklı öğrenme türleri ve kontroller, öğrenmenin örgütsel aktarımı. Öyleyse, işin bir bölümünden nasıl bilgi ediniriz ve bir fikri olan ancak kod geliştirmeyen veya veritabanları ve altyapıları geliştirmeyen, ancak bu kişilere veri geliştiren insanlardan başkasına nasıl aktarabiliriz? Ve özellikle zaman içeren sonuçlar. Başka bir deyişle, bunu 24 saat gibi bir gün veya bir hafta veya birkaç hafta boyunca bir süre yapalım ve ne yapabileceğimizi görelim ve sonra geriye dönüp bakın.
Ve eğer, şovu affederseniz, bu gerçekten proje tesliminde yeni bir oyundur ve bu süreçte biraz daha ileriye gideceğimiz için mantıklı olacak üç temel bileşen - ürün var: tüm bu insanların fikri var ve bir şey yapılması ve onları çevreleyen bir hikaye edinme ihtiyacı. Hikayelerini almak için çevik bir modelde çalışan ve tartışmak ve ne yapmaları gerektiğini anlamak için scrum metodolojisini kullanarak günlük standuplar aracılığıyla faaliyet gösteren geliştiriciler, sonra da devam edip devam edin. O zaman insanlar, tüm bunları denetleyen ve metodolojiyi sürecek kadar iyi anlayan scrum ustalarını duyduk. Burada sağ tarafta elde ettiğim ve Post-It notlarıyla dolu yazı tahtalarının ve yazı tahtalarının bulunduğu bu görüntüleri hepimiz gördük ve Kanban duvarı olarak görev aldılar. Kanban’ın kim olduğunu bilmiyorsanız, sizi Google’a Bay Kanban’ın kim olduğunu ve neden bir şeyi diğer tarafa taşırken bir değiş tokuş etmemizin bir değişiklik olduğunu bir proje olarak davet ediyorum.
Bir bakışta, scrum iş akışı bunu yapar: bir örgütün yapmak istediği şeylerin bir listesini alır, bunları 24 saat, ay boyunca süren ve ayrılan bir dizi işlemden geçirir. Bu artımlı çıkış serisini elde edin. Projelerin teslim edilme şeklindeki önemli bir değişiklik, o aşamaya kadar teslim edildi; çünkü bunun bir kısmı PMBOK adlı bir şeyi geliştirmenin büyük bir bölümünü oluşturan ABD ordusu gibi aktı, bu tankları sahaya almayan bir fikir gibi Maddenin içine bir mermi koyarsanız, çünkü tarladaki bir tankta mermi yoksa, işe yaramaz. Bu yüzden birinci kısım tankın içine mermiler, ikinci kısım ise tankın sahaya atılmasıdır. Ne yazık ki, yine de, geliştirme dünyasındaki geliştiricilerin başına gelenler, bir şekilde bu çevik metodolojiyi ele geçirdi ve bir kez daha pardonu affederseniz, onunla düz çıktı.
Değişmez bir şekilde olan şey, çevik olduğumuzu düşündüğümüzde genellikle veritabanlarını değil, veritabanlarının dünyasıyla ilgisi olan geliştiricileri düşünürüz. Talihsiz bir sonuçtu çünkü gerçek şu ki çevik geliştiricilerle sınırlı değil. Aslında, benim görüşüme göre çevik terimi, genellikle veritabanı tasarımcıları ve mimarları ile değil, yalnızca yazılım geliştiricileriyle ilişkilidir. Her zaman, yazılım ve uygulama geliştirmede karşılaştığınız zorluklar, tasarım ve geliştirme ve işletme ve bakım ile ve dolayısıyla veri altyapısı ve özellikle veritabanları ile ilgili her şeyle karşı karşıya. Bu veri dökümündeki aktörler arasında veri mimarlarının, kalıpçıların, yöneticilerin, veri tabanı altyapılarının yöneticilerinin ve gerçek veri tabanlarının iş ve sistem analistleri ve mimarlarına, sitelerin nasıl oturduğunu ve sistemlerin nasıl olduğunu düşünen insanlara sahip oldukları yer alıyor. ve iş dünyası ve bunlardan veri akışını nasıl sağladığımızı.
Bu, düzenli olarak ortaya attığım bir konudur, çünkü veri uzmanlarının benim - sürekli yapmamalı - kesinlikle, proje tesliminin her bir bileşenine, özellikle de geliştirmeye dahil olması gerektiği görüşündeyim. Yapmamamız için, o zaman gerçekten iyi bir sonuç için kendimize en iyi şansı vermeyiz. Sık sık geri dönüp bunları düşünmek zorundayız, çünkü bir senaryo var, inşa edilen bir uygulamaya geçiyoruz ve geliştiricilerin her zaman veri uzmanı olmadığını keşfediyoruz. Veritabanlarıyla çalışmak, özellikle verilerle ilgili çok özel beceriler gerektirir ve bir deneyim oluşturur. Anında bir gecede bir veritabanı gurusu ya da veri bilgisi uzmanı olmazsınız; Bu genellikle ömür boyu sürecek bir deneyime dayanarak gelen ve kesinlikle Kitabı Kod Üzerine Yazan Dr. Robin Bloor'un, oldukça zengin bir şekilde kitap yazdığı gibi.
Pek çok durumda - ve bu talihsiz bir durum ama bu bir gerçek - bu madalyonun iki bölümü var, yani yazılım geliştiriciler veritabanı uzmanı olarak bir karartmaya sahipler ve veritabanı tasarımı modelleme için ihtiyacınız olan becerileri geliştirmişler, model geliştirme sadece Verilerin nasıl geldiği ve yolculuğun organizasyonu ve nasıl olması gerektiği veya neye benzemesi gerektiği ya da hiç kuşkusuz, geliştiği ve temel olarak yazılım geliştiriciler için belirlenmiş yerel becerilerde edinildiğini anladığı için guru mühendisliği için temel. Ve bununla karşılaştığımız ortak zorluklardan bazıları, yalnızca şunu söylemek gerekirse, temel veritabanı tasarımının kendisinin temel yaratma ve bakım ve yönetimini, verileri ve veritabanı altyapısını belgelemeyi ve ardından bu veri varlıklarını, şema tasarımlarını yeniden kullanmayı sever. şema kuşakları, şemanın yönetimi ve bakımı ve bunların kullanımı, bu şemanın neden özel bir şekilde tasarlandığı konusundaki bilginin paylaşılması ve zaman içinde ortaya çıkan güçlü ve zayıf yönler zaman içinde verilerin değişmesine, veri modellemesine ve türlerine neden olur. Modellere uyguladıkları sistemlere ve bunların içinden geçirdiğimiz verilere. Veritabanı kodu oluşturma ve entegrasyona devam eder ve daha sonra bunların etrafındaki verileri modellenir ve ardından veri etrafındaki güvenliği kontrol etmeye daha hızlı bir şekilde erişir, verilerin bütünlüğü, verileri bütünlüğünü korudukça dolaştırır, etrafta yeterince meta veri var mıdır? satışlar tablodaki tüm kayıtları görmeli mi yoksa sadece postada girdiğiniz adresi, adı ve soyadı mı görmeli? Ve sonra elbette ki, hepsinden büyük zorluk, tamamen farklı bir sohbet olan veritabanı platformlarını modellemektir.
Bu nirvananın herhangi birini mümkün kılmak için, tüm bunların akılda tutulmasıyla, hem veri uzmanlarının hem de geliştiricilerin uygun araçlara sahip olmaları ve bu araçların ekip odaklı proje sunma yeteneğine sahip olmaları kesinlikle kritik öneme sahip. tasarım, geliştirme ve devam eden işletme bakımı. Veri uzmanları ve yazılım geliştiricileri arasındaki projeler arasında işbirliği yapmak gibi şeyler, veritabanlarının kendileri, veriler, şemalar, kayıtların nereden geldiği, bu kayıtların sahipleri, veriler, şemalar, belgelendirme konusundaki her şey için tek bir doğruluk noktası . Bence bu gün ve yaşta kesinlikle çok kritik, bu verilerin nirvanasına kral olacağına, doğru araçların yerinde olması gerektiğine inanacağız, çünkü bu sorun bizim için elle yapmamız için çok büyük ve insanlar ise Bir kuruluşun içine ve dışına taşınmak, bir kişinin kurabileceği aynı süreci ya da metodolojiyi izlemememiz için çok kolay ve ileriye dönük olan bu yetenek ve yetenekleri transfer etmeyebilir.
Bunu göz önünde bulundurarak, IDERA'daki iyi arkadaşımıza gideceğim ve bu aracı ve bunların nasıl işlediğini anlayacağım.
Ron Huizenga: Çok teşekkür ederim ve hem sahneyi hem de Dez'e sahneyi gerçekten iyi bir şekilde ayarladığınız için teşekkürler ve konuştuğum birkaç şeyde biraz örtüşme göreceksiniz. Ancak, veri modelleme perspektifinden bahsedeceğim bazı kavramlar için gerçekten sağlam bir temel oluşturdular. Ve söyledikleri pek çok şey, veri modelleme ve veri mimarisinde çalışan bir danışman olduğumda kendi ekiplerimin yanı sıra, hem ilk günlerde şelale olan hem de çevik kullandığımız projelerle daha modern ürünlere dönüşen danışman olduğumda kendi tecrübelerimi yansıtıyor. çözümler üretmek için metodolojiler.
Bu yüzden bugün konuşacağım şey, bu deneyimlere, araçların ve bu yolculukta bize yardımcı olmak için kullandığımız araçlardaki bazı yeteneklerin bir bakış açısına dayanıyor. Çok kısaca anlatacağım şey şu; çok fazla ayrıntıya girmeyeceğim; Sadece bunun ne olduğuna dair gerçekten iyi bir bakış açısı vardı. Bunun hakkında konuşacağım, veri modeli nedir ve bizim için ne anlama geliyor? Organizasyonlarımızda çevik veri modelleyicisi kavramını nasıl mümkün kılıyoruz: veri modelleyicileri nasıl bağlarız, modelciler ve mimarların s sırasında katılımı nedir, ne tür etkinliklerde bulunmaları gerekir? ve bunun arkaplanı olarak, bu işi gerçekten kolaylaştırmak için kullandığımız önemli modelleme aracı yeteneklerinden bazıları nelerdir? O zaman biraz toparlanacağım ve bir veri modelleyicisine dahil olmanın bazı iş değerleri ve faydaları hakkında ya da aslında hikayeyi anlatacağım şekilde biraz konuşacağım. Bir veri modelleyicisinin projelere tamamen dahil olmamasının problemleri ve size yıllar önce katılmış olduğum gerçek bir projenin görüntüsünün önceki ve sonraki deneyimlerine ve kusur çizelgelerine dayanarak göstereceğim. Sonra birkaç noktayı daha özetleyeceğiz ve sonra buna ek olarak sorularımız ve cevaplarımız olacak.
Kısaca, ER Studio, çok farklı bileşenleri olan çok güçlü bir süittir. Veri modelleyicileri ve mimarların zamanlarının çoğunu veri modelleme yaparak geçirdikleri yer olan Veri Mimarı. Bugün UML modellemesinin bir kısmı için süreç modellemesi yaptığımız İş Mimarı ve Yazılım Mimarı gibi bugün hiç konuşmayacağımız başka bileşenler de var. Ardından, teslim aldığımız ve modelleri paylaştığımız bir Depo var, ekiplerin bunlar üzerinde işbirliği yapmasına ve bunları ekip sunucusunda yayınlamasına izin veriyoruz, böylece bir projede yer alan birden fazla paydaş kitlesi aslında bizim yaptığımız eserleri görebiliyor. Veri tesliminde proje tesliminde yaptığımız diğer şeylerin yanı sıra yaratma.
Bugün odaklanacağım şey, Veri Mimarisinden göreceğimiz birkaç şey olacak ve çünkü bunun Depo temelli yönleriyle işbirliğine sahip olmamız gerçekten önemli. Özellikle, sadece çevik kalkınma projeleri için değil, ileriye yönelik her türlü gelişme için zorunlu olan değişim yönetimi gibi kavramlardan bahsetmeye başladığımızda.
Öyleyse bir an için Çevik Veri Modelleyici hakkında konuşalım. Sunumda daha önce bahsettiğimiz gibi, çevik kalkınma süreçlerinde tam anlamıyla meşgul olan veri modelleyicileri ve / veya mimarlarımız olması şart. Şimdi, tarihsel olarak gerçekleşen şey, evet, gelişim perspektifinden çeviklik hakkında gerçekten düşündük ve bunun gerçekleşmesine neden olan birkaç şey var. Bunun bir kısmı, gelişimin kendisinin ortaya çıkma şeklinin doğasından kaynaklanıyordu. Çevik gelişme başladığında ve bu kendi kendini organize eden ekipler konseptiyle başladığımızda, Kool-Aid'i biraz saf içtiyseniz ve şeylerin aşırı programlama tarafındaysanız, bunun gibi şeylerin gerçek bir yorumu oldu. Pek çok insanın demek istediği kendi kendini düzenleyen ekipler, ihtiyacımız olan tek şey bütün bir çözümü inşa edebilecek bir grup geliştirici. Kodun geliştirilmesi, veritabanları veya arkasındaki veri depoları anlamına gelip gelmediği ve geliştiricilerine her şey verildi. Ancak bununla birlikte, insanların sahip olduğu özel yeteneklerden mahrum kalıyorsunuz. En güçlü takımların farklı geçmişlerden insanlardan oluşan takımlar olduğunu buldum. Güçlü bir yazılım geliştiricileri, veri mimarları, veri modelleyicileri, iş analistleri ve iş paydaşlarının bir araya gelmesi gibi, hepsi birlikte bir çözüm bulmak için birlikte çalışıyor.
Bugün de bahsettiğim şudur, bunu açıkça, kendisiyle ilişkilendirilmiş veri bileşenine sahip olacak bir uygulama geliştirdiğimiz bir geliştirme projesi kapsamında yapacağım. Bunu yapmadan önce geriye doğru bir adım atmamız gerekiyor, çünkü orada yalnızca çok az sayıda Greenfield geliştirme projesi olduğumuzu anlamamız gerekir, burada yalnızca bu geliştirme projesinin kendisinde sınırlı olan verilerin yaratılması ve tüketilmesine odaklanılır. . Geriye doğru bir adım atmalı ve genel örgütsel bakış açısına veri perspektifinden ve süreç perspektifinden bakmalıyız. Çünkü bulduklarımız, kullandığımız bilgilerin kuruluşlarda bir yerde var olabileceğidir. Modelleyiciler ve mimarlar olarak bunu ışığa çıkardık, böylece bu bilgileri projelerin kendisinden nereden kaynaklayacağımızı biliyoruz. İlgili veri yapılarını da biliyoruz çünkü geliştiricilerin kodları için tasarım kalıpları gibi tasarım kalıplarımız var. Ayrıca bu genel örgütsel perspektifi almamız gerekiyor. Yaptığımız uygulamanın con'sındaki verilere yalnızca bakamayız. Verileri modellememiz ve belgelememiz gerektiğinden emin olmamız gerekiyor, çünkü uygulamaların çok ötesinde yaşıyor. Bu uygulamalar gelir ve gider, ancak verilere bakabilmemiz ve sağlam olması ve iyi yapılandırıldığından emin olmamız gerekir, yalnızca uygulama için değil, faaliyetleri rapor eden kararlar, iş zekası raporlama ve diğer uygulamalara entegrasyon, iç ve kuruluşlarımızın dışında da. Bu yüzden, verinin tüm bu büyük resmine ve bu verinin yaşam döngüsünün ne olduğuna bakmalı ve organizasyon boyunca beşikten mezara kadar bilgi parçalarının seyahatini anlamamız gerekir.
Şimdi asıl ekiplere geri döndük ve gerçekte nasıl çalışmamız gerektiği, şelale metodolojisinin sonuç veremeyecek kadar yavaş olduğu algılandı. Çünkü, tank örneğinde belirtildiği gibi, birbiri ardına bir adım oldu ve uygulanabilir bir sonuç elde etmek çok uzun sürdü. Şimdi yaptığımız şey, bileşenlerini aşamalı olarak geliştirdiğimiz ve her seferinde, kullanılabilir kod veya kullanılabilir eserler üretebileceğimiz, zaman içinde bunları kullanacağımız yinelemeli bir çalışma stiline ihtiyacımız var. Önemli olan, bu kullanıcı hikayelerini uygulanabilir bir kod vizyonuna ve bu kodu destekleyen verilere dönüştürmek için işbirliği yaptığımız için, ekibin teknik paydaşları ve iş paydaşları arasındaki işbirliğidir. Ayrıca Çevik Veri Modelleyicinin kendisi de organizasyonlarda yeterli sayıda modelleyiciye sahip olmadığımızı görecektir, böylece bir veri modelleyicisi veya mimar aynı anda birden fazla ekibi destekleyebilir.
Ve bunun diğer bir yönü, birden fazla modelleyicimiz olsa bile, aynı anda uçuşta olan birden fazla projenin birlikte çalışmasını ve bu projelerin paylaşılmasını sağlayan bir araç setimizin olduğundan emin olmalıyız. veri eserleri ve giriş ve çıkış yetenekleri. Bunu çok hızlı bir şekilde gözden geçireceğim çünkü önceki bölümde ele aldık. Çevikliğin asıl dayanağı, işleri biriktirmeden, öykülerden ya da gereksinimlerden mahrum bırakmanızdır. Yinelemelerde grup olarak işbirliği yapıyoruz. Genellikle, kuruluşa bağlı olarak iki hafta veya bir ay süre çok yaygındır. Ayrıca günlük inceleme ve standup toplantıları da engelleyicileri ortadan kaldırıyor ve yaşadığımız farklı alanlarda durmadan tüm yönleri ilerlettiğimize emin oluyoruz. Ve bunlarda, her birinin bir parçası olarak kullanılabilir teslimatlar yaptığımızdan emin olmak istiyoruz.
Sadece biraz daha farklı bir yaklaşım, onu daha da genişletmek, scrum, burada daha spesifik olarak konuşacağım metodolojidir ve temelde daha önceki birkaç resmi ile daha da güçlendirdik. Tipik olarak bir ürün biriktirme listesi vardır ve sonra bir biriktirme listesi vardır. Bu nedenle, her yinelemenin başlangıcında, “Bu şeyleri ne inşa edeceğiz?” Diyen bir planlama topluluğuna sahibiz. Daha sonra bununla ilişkili olan görevlerden ayrılırız ve günlük gözden geçirme ile bir ila dört hafta arasında gerçekleştiririz. Yaptığımız gibi, ilerleme hızımızı neye benzeyecek şeyler oluşturmak için inşa ettiğimize karşı temelde geriye kalanları izlemek için yanma çizelgeleri ve yanma çizelgeleri aracılığıyla ilerlememizi izliyoruz. program, tüm bu tür şeyler. Tüm bunlar yol boyunca birkaç ay gitmek yerine, kısa bir süre sonra çıkacağınızı ve proje zamanlamasını uzatmanız gerektiğini bulmak yerine, s boyunca sürekli hazırlanır. Ve çok önemli, bunun bir parçası olarak, tüm ekipler, sonunda bir inceleme ve geriye dönük olarak var, bu yüzden bir sonraki tekrarlamayı başlatmadan önce, yaptığınız şeyi gözden geçiriyorsunuz ve geliştirebileceğiniz yolları arıyorsunuz. Bir dahaki sefere.
Teslimatlar açısından, bu temelde ss'de devam eden tipik şeyleri özetleyen bir slayttır. Ve bu çok gelişim odaklı, bu yüzden burada gördüğümüz, fonksiyonel tasarımlar ve kullanım durumları, tasarım kodu testleri yapıyor, buradaki kutulara baktığımızda ve bunlardan geçmeyeceğim gibi birçok şey var. Herhangi bir detay düzeyinde, gelişim yönelimlidir. Buraya gömülmüş ve bu çabayı desteklemek için bununla el ele giden veri dağıtımlarına sahip olmamız gerektiği gerçeğidir. Bu nedenle, her zaman biriktirilenler, gereksinimler ve kullanıcı hikayeleri gibi şeyler görüyoruz, ilerledikçe yapmamız gereken geliştirme parçalarının neler olduğuna, yapmamız gereken analiz parçalarının ne olduğuna bakmalıyız. veri tasarımı veya veri modeli, peki iş sözlükleri gibi şeyler, peki iş anlamını ürettiğimiz tüm eserler ile ilişkilendirebiliriz? Çünkü her kullanımda bu kullanışlı çıktıları üretmemiz gerekiyor.
Bazı insanlar her kodun sonunda kullanılabilir kodlar üretmemiz gerektiğini söyleyeceklerdir. Bu zorunlu bir durum değil, en saf kalkınma perspektifinde, ancak oldukça sık - özellikle başlangıçta - s sıfır gibi bir şeye sahip olabiliriz, sadece ayakta durmaya odaklandığımız, test stratejilerimizi almak gibi şeyler yapıyoruz. yer, yerleştirmek.Ayrıntıları doldurmaya başlamadan önce başlayacağımız üst düzey bir tasarım ve diğer izleyicileri dahil etmeye başlamadan ve ileriye doğru ilerledikçe bir ekip olarak ilerlemeden önce temiz başlangıç hikayeleri veya gereklilikleri belirlediğimizden emin olun. Her zaman biraz hazırlık süresi vardır, bu yüzden sık sık bir sıfır veya bir sıfır olur. Çözümü sunarken tam bir uçuşa başlamadan önce bir başlangıç aşaması olabilir.
Bu bağlamda veri modellerinden çok kısaca bahsedelim. İnsanlar veri modelleri hakkında düşündüklerinde, genellikle bir veri modelini, farklı bilgi parçalarının nasıl bir araya geldiğinin bir resmi olarak düşünürler - bu buzdağının sadece görünen kısmıdır. Veri modellemeye gerçekten nasıl yaklaşmak istediğinizi tam anlamıyla somutlaştırmak için - çevik gelişimde ve diğer şeylerde olsun - doğru yapılıyorsa, veri modelinin organizasyonda bu verilerin ne anlama geldiğinin tam bir özelliği olduğunu fark etmeniz gerekir mi? arka uç veritabanlarında nasıl kullanıldığını. Veritabanları derken, sadece kullanabileceğimiz ilişkisel veritabanları değil, aynı zamanda büyük veriye sahip olduğumuz mimarilerde veya onları adlandırmayı tercih ettiğim NoSQL platformlarında kastediyorum. Ayrıca bu büyük veri depoları, bilgi tüketme ve bunları çözümümüze getirme ve bu bilgiyi çözümlerimizden nasıl sürdürme ve kaydetme konusunda bir çok farklı veri deposunu birleştirebiliriz.
Belirli bir uygulamanın kapsamında aynı anda birden fazla veritabanı veya veri kaynağıyla çalışıyor olabiliriz. Çok önemli olan, tam bir şartnameye sahip olmak istiyoruz, bu yüzden bunun örgütsel perspektif olarak ne anlama geldiğinin, fiziksel yapıların, verileri gerçekte nasıl tanımladığımız, sizin aranızdaki ilişkiler açısından ne anlama geldiğine dair mantıklı bir şartname. veritabanları, referans bütünlüğü kısıtlamalarınız, kısıtlamaları kontrol edin, tüm düşündüğünüz doğrulama parçalarının tümü. Açıklayıcı meta veriler son derece önemlidir. Verilerinizi uygulamalarınızda nasıl kullanacağınızı nasıl biliyorsunuz? Bunu tanımlayamaz ve ne anlama geldiğini veya bu uygulamalarda doğru verileri kullandığınızdan emin olmak için nereden geldiğini bilmediğiniz sürece - doğru adlandırma kurallarına, tam tanımlara sahip olduğumuzdan emin olmak, yani sadece tam veri sözlüğü anlamına gelmez. Bu tabloları içeren sütunlar ancak bu tabloları içeren sütunlar - ve bunun nasıl kullanılacağına dair ayrıntılı konuşlandırma notları, bu bilgi tabanını oluşturmamız gerektiğinden, bu uygulama yapıldığında bile, bu bilgilerin diğer girişimler için kullanılacağından emin olmamız gerekir. gelecekteki uygulamalar için belgelenenlere sahip olduğumuzu.
Yine veri türleri, anahtarlar, indeksler gibi şeylere ineriz, veri modelinin kendisi ortaya çıkan birçok iş kuralını içerir. İlişkiler sadece farklı tablolar arasındaki kısıtlamalar değildir; sık sık, gerçek iş kurallarının bu verinin nasıl davrandığı ve tutarlı bir birim olarak birlikte nasıl çalıştığı hakkında ne olduğunu tanımlamamıza yardımcı olurlar. Ve elbette, değer kısıtlamaları çok önemlidir. Şimdi elbette, sürekli olarak uğraştığımız şeylerden biri ve gittikçe daha yaygın hale gelen veri yönetimi gibi şeyler. Yani veri yönetimi açısından bakıldığında, burada neyi tanımladığımıza da bakmamız gerekiyor? Güvenlik sınıflamaları gibi şeyleri tanımlamak istiyoruz. Ne tür verilerle uğraşıyoruz? Ana veri yönetimi olarak kabul edilecekler nelerdir? Oluşturduğumuz işlem mağazaları nelerdir? Bu uygulamalarda hangi referans verilerini kullanıyoruz? Modellerimizde bunun doğru bir şekilde yakalandığından emin olmalıyız. Ayrıca veri kalitesiyle ilgili hususlar, bir kuruluş için diğerlerinden daha önemli olan belirli bilgiler vardır.
Bir düzine eski sistemin üzerine yeni iş süreçleriyle değiştirdiğimiz ve yerine yeni uygulamalar ve veri depoları tasarladığımız projelerde yer aldım. Bilginin nereden geldiğini bilmemiz gerekiyordu. Hangi en önemli bilgi parçaları için, iş perspektifinden, burada sahip olduğum bu belirli veri modeli slaydına bakarsanız, bu belirli varlıkların altındaki alt kutuların sadece küçük bir alt küme olduğunu göreceksiniz. aslında işletme değerini yakalamayı başarabildim. Örgüt içinde bu farklı yapılar için bu tür şeyler için yüksek, orta veya düşük olsun. Ayrıca, ana veri sınıfları, ana tablolar olup olmadıklarına, referans olup olmadıklarına, işlem yapılıp yapılmadıklarına bakmadım. Bu yüzden modellerimizdeki meta verilerimizi, bize verinin dışında birçok başka özellik sunacak şekilde genişletebiliriz; bu da orijinal projeler dışındaki diğer girişimlerle bize gerçekten yardımcı oldu ve ilerletti. Şimdi bu bir slaytta çok fazlaydı, bunların geri kalanını oldukça hızlı bir şekilde geçeceğim.
Şimdi bir veri modelleyicinin bu farklı ss'lerden geçerken ne yaptığını çok hızlı bir şekilde konuşacağım. Her şeyden önce, kullanıcı öykülerini aldığımız, o şeylerde ne sunacağımıza bağlı kaldığımız ve bunu nasıl yapılandıracağımıza ve nasıl sunacağımıza karar verdiğimiz planlama oturumlarına tam bir katılımcı. Veri modelleyicisi olarak yaptığım şey, farklı geliştiricilerle veya farklı kişilerle ayrı alanlarda çalışacağımı biliyorum. Dolayısıyla sahip olabileceğimiz en önemli özelliklerden biri, bir veri modeli yaparken, konu alan veya alt modeller olarak adlandırsanız da, bu veri modelini farklı görüşlere bölebiliriz, terminolojimizdir. Bu yüzden, modeli oluştururken, bu farklı alt model perspektiflerinde de gösteriyoruz, böylece farklı izleyiciler kendileriyle neyin ilgilendiğini görebiliyorlar, böylece geliştirdikleri ve öne sürdükleri şeylere konsantre olabiliyorlar. Bu yüzden, bir uygulamanın zamanlama kısmında çalışan birisine sahip olabilirim, tüm bunları tek bir saniyede yaptığımız bir sipariş girişi üzerinde çalışan başka birine de sahip olabilirim, ancak onlara yalnızca bu alt modeller aracılığıyla bakış açıları verebilirim. çalıştıkları alana uygulanır. Ve sonra bunlar, izleyicilere görmeleri gereken farklı izleyici görüşleri vermek için genel modele ve tüm alt modellerin yapısına geçiyor.
Sahip olmak istediğimiz bir veri modelleme perspektifinden temel, her zaman geri dönebileceğimiz bir temele sahip olmamızdır, çünkü yapmamız gereken şeylerden biri, sonunda mı yoksa sonunda mı olacağıdır. Birkaç ss, nerede başladığımızı bilmek istiyoruz ve her zaman deltanın ne olduğunu veya belirli bir s içinde ne ürettiğimizin farkını bilmek için bir temelimiz var. Ayrıca hızlı bir şekilde geri dönüş yapabileceğimize emin olmalıyız. Bir veri modelleyicisi olarak karşınıza çıkarsanız, ancak geleneksel kapı bekçisi rolünde “Hayır, hayır, bunu yapamazsınız, ilk olarak bunları yapmalıyız” deyince, gerçekten ihtiyacınız olduğunda takımdan dışlanacaksınız. Tüm bu çevik geliştirme ekiplerine aktif olarak katılmak. Bu, bazı şeylerin vagondan belirli bir s yaparak düştüğü ve daha sonra ss'de toplandığınız anlamına gelir.
Örnek olarak, bahsettiğim o sipariş giriş parçasını sadece gelişmeyi sürdürmek için veri yapılarına odaklayabilirsiniz. Daha sonra, geri gelip, yarattığınız bazı eserler etrafındaki veri sözlüğünün bazı belgelerinde olduğu gibi verileri doldurabilirsiniz. Bu tanımı hepsini bir arada tamamlamayacaksınız; geliştiricilerin uygulamaları ve bu veri depolarının etrafındaki sürekliliği sağlamakla meşgulken, iş analistleriyle çalışarak bu bilgileri doldurabileceğiniz zamanlar olacağından, aşamalı olarak dağıtımlarınıza devam etmeye devam edeceksiniz. Kolaylaştırmak ve darboğaz olmak istemiyorsunuz. Geliştiricilerle çalışmanın farklı yolları var. Bazı şeyler için tasarım kalıplarımız var, bu yüzden önümüzde tam bir katılımcıyız, bu yüzden onu modele koyacağımızı söyleyebileceğimiz bir tasarım kalıplarımız olabilir, geliştiricilerin sanal alan veritabanlarına iteceğiz ve sonra da onunla çalışmaya başla ve ondan değişiklik iste.
Geliştiricilerin üzerinde çalıştığı başka alanlar olabilir, üzerinde çalıştıkları bir şey var ve bazı şeyleri prototip ediyorlar, bu yüzden bazı şeyleri kendi geliştirme ortamlarında deniyorlar. Çalıştıkları veri tabanını kullanıyoruz, modelleme aracımıza getiriyor, sahip olduğumuz modellerle karşılaştırıyor ve sonra değişiklikleri tekrar çözüp itiyorlar, böylece kodlarını yeniden değerlendirebiliyorlar, böylece uygun veri yapılarını takip ediyorlar ihtiyacımız olan. Zaten başka bir yerde sahip olduğumuz bazı şeyler yaratmış olabilirler, bu yüzden doğru veri kaynaklarıyla çalıştıklarından emin oluyoruz. Tüm veri yolumuzu yinelemeye devam ediyoruz, böylece tüm veri dağıtımlarını, tam dokümantasyonu ve ürettiğimiz tüm bu veri yapılarının tanımını alabiliyoruz.
Çok iyi teslimatlar ile uğraştığım en başarılı projeler, bir felsefemiz vardı, tüm değişiklikleri tam fiziksel veritabanı spesifikasyonuna göre modelliyoruz. Temelde, veri modeli oluşturduğumuz yeni bir şey için üzerinde çalıştığınız konuşlandırılmış veri tabanları haline gelir ve diğer dış veri tabanlarından tüketiyorsak diğer veri depolarına tam referansları vardır. Bunun bir parçası olarak, her seferinde tam bir nesiller yapmak yerine artımlı senaryolar üretiyoruz. Ve birlikte çalıştığımız farklı geliştirme ekipleriyle işlerin yolunda gitmesi konusunda bize hızlı bir ilerleme sağlamak için tasarım modellerimizi kullanıyoruz.
Faaliyetlerinde de, tekrar birleştirmek / birleştirmek için temeldir, o yüzden her bir değişikliği modelleme fikrini ele alalım. Ne zaman bir değişiklik yapsak, ne yapmak istiyorsak, değişimi modellemek istiyoruz ve çok önemli olan şey, veri modellemesinde eksik olan şey, yakın zamana kadar, aslında, yeniden başlatana kadar, modellemeyi ilişkilendirme yeteneğidir. görevler ve teslimatlarınız, aslında bu değişikliklerin yapılmasına neden olan kullanıcı hikayeleri ve görevleriyle birlikte. Model değişikliklerimizi kontrol edebilmek, geliştiricilerin kodlarını kontrol etmeleri, sahip olduğumuz kullanıcı öykülerine referans vermemizi istiyoruz, böylece ilk başta neden yaptığımızı, yani yaptığımız şeyi biliyoruz. Bunu yaptığımızda, artımlı DDL komut dosyalarımızı oluşturuyor ve bunları diğer geliştirme sürümleriyle birlikte toplanıp derleme çözümümüzü kontrol edebilmeleri için gönderiyoruz. Yine, bir modelimiz olabilir veya birden fazla ekiple birlikte çalışabiliriz. Ve bahsettiğim gibi, bazı şeyler veri modelleyiciden kaynaklanıyor, diğer şeyler geliştiricilerden kaynaklanıyor ve genel olarak en iyi tasarımla gelip gelmek için ortaya çıktıktan sonra doğru şekilde tasarlandığından emin olmak için ortada buluşuyoruz. genel veri yapıları. Veri modelimizde ileriye doğru ilerledikçe tüm boş yapılara sahip olduğumuzdan emin olmamız gerekir; boş ve boş olmayan değerler, referans kısıtlamaları, temel olarak kısıtlamaları kontrol edin, tipik olarak düşüneceğimiz şeyler de dahil olmak üzere; .
Şimdi bunun hakkında konuşmamıza yardım eden araçların bazılarının ekran görüntülerinden bahsedelim. Önemli olduğunu düşündüğüm şey o işbirlikçi havuza sahip olmak, yani veri modelleyicileri olarak yapabileceğimiz şey - ve bu arka plandaki veri modelinin bir parçasını oluşturuyor - yapabildiğimizden emin olmak istediğimiz şeyler üzerinde çalışırken sadece değiştirebilmemiz, modifikasyonlar yapabilmemiz, DDL senaryolarımızı oluşturup değişiklikler için yaptığımız değişiklikler için üretmemiz gereken nesneler üzerinde çalışın. Yapabileceğimiz şey, ER Studio'da bir örnek. üzerinde çalışılacak nesneleri veya nesne gruplarını kontrol edebiliriz, bütün bir modeli veya alt modeli kontrol etmek zorunda değiliz, sadece bizim için önemli olan şeyleri kontrol edebiliriz. Bundan sonra istediğimiz şey check-out veya check-in saatinde gerçekleşiyor - her iki şekilde de yapıyoruz çünkü farklı geliştirme ekipleri farklı şekillerde çalışıyor. Bunu, bunun için gereklilikleri belirleyen kullanıcı öyküsü ya da görevi ile ilişkilendirdiğimizden ve geliştiricilerin kodlarını geliştirip kontrol ettiği aynı kullanıcı öyküsü ya da görevi olacağından emin olmak istiyoruz.
İşte değişim yönetimi merkezlerimizden birinin birkaç ekranının çok hızlı bir parçası. Bu ne yaparsa, burada çok ayrıntılı olarak geçmeyeceğim, fakat gördüğünüz şey kullanıcı hikayesi veya görevidir ve gerçek değişim kayıtlarını gördüğünüz her birinin altına girintilidir - ne zaman otomatik bir değişim kaydı oluşturduk? Giriş ve çıkış yapıyoruz ve bu değişiklik kaydında da daha fazla açıklama yapabiliriz. Görevle ilişkili, beklediğiniz gibi görev başına birden fazla değişiklik yapabiliriz. Ve bu değişim kaydına girdiğimizde ona bakabilir ve daha da önemlisi, aslında neyi değiştirdik? Bu özel anlatım için, orada vurgulanan hikayede, bir değişiklik yapıldı ve gerçek değişim kaydının kendisine baktığımda, değişen modeldeki bireysel parçaları tanımladı. Burada bir kaç özellik değiştirdim, onları yeniden sıraladım ve değişime ihtiyaç duyulan görüşleri, bunlara bağımlı olan görünümlerde getirdim, böylece artan DLL'de üretilebilsinlerdi. Yalnızca temel nesneler üzerinde modelleme yapmakla kalmaz, bunun gibi yüksek güçlü bir modelleme aracı da veritabanındaki bağımlı nesneler veya veri modelinde de karıştırılması gereken değişiklikleri algılar.
Geliştiricilerle çalışıyorsak ve bunu birkaç farklı şeyde yaparsak, bu onların kum havuzunda bir şeyler yapıyor ve farklılıkların nerede olduğunu karşılaştırmak ve görmek istiyoruz, sağda ve solda karşılaştırma / birleştirme yeteneklerini kullanıyoruz yan. “İşte sol taraftaki modelimiz, sağ taraftaki veritabanı burada, bana farklılıkları gösterelim” diyebiliriz. Daha sonra bu farklılıkları nasıl çözeceğimizi seçebiliriz, şeyleri veri tabanına itip çekmeyeceğimizi veya Veritabanında, modele geri getirdiğimiz bazı şeyler var. İki yönlü olarak gidebiliriz, böylece hem kaynağı hem de hedefi güncelleyerek her iki yöne aynı anda gidebiliriz ve bu değişiklikleri veritabanı ortamına dağıtmak için artımlı DDL komut dosyaları oluşturabiliriz ki bu son derece önemlidir. Yapabileceğimiz şey, bu karşılaştırmayı ve birleştirme özelliğini, herhangi bir zamanda kullanabiliriz, eğer yoldayken anlık görüntüler çekersek, bir başkasının başlangıcını veya sonunun başlamasını her zaman karşılaştırabiliriz. Belirli bir gelişmede veya bir dizi ss'de yapılanların tam artım değişikliği.
Bu bir alter betiğine çok hızlı bir örnektir, veritabanlarıyla çalışan herhangi biriniz bu tür bir şey görmüş olacak, bu bizim kodumuzu bir alter betiği olarak çıkarabileceğimiz şeydir. şeyleri burada sakla. Buradan çıkardığım şey, sadece karmaşayı azaltmak için, bu değiştirilmiş senaryolarla yaptığımız şeydir, bu tablolarda da veri olduğunu varsayıyoruz, bu yüzden geçici tabloların bilgisini çekecek olan DML'yi de oluşturacağız ve onu yeni veri yapılarına da geri itiyoruz, bu yüzden sadece yapılara değil, bu yapılarda zaten mevcut olan verilere de bakıyoruz.
Otomatik yapı sistemleri hakkında çok hızlı bir şekilde konuşacağız, çünkü çok sık çevik bir proje yaparken, yapılarımızı bozmadığımızdan emin olmak için farklı teslimatları birlikte kontrol etmemiz gereken otomatik yapı sistemleri ile çalışıyoruz. Bunun anlamı, teslimatları senkronize etmemiz, DDL betiği ile konuştuğum değişiklik komut dosyalarının kontrol edilmesi, karşılık gelen uygulama kodunun aynı anda kontrol edilmesi gerekiyor ve şu anda pek çok geliştiricinin gelişimi tabii ki değil. Veritabanlarına ve bu tür şeylere karşı doğrudan SQL ile yapılmaktadır. Sıklıkla, kalıcılık çerçeveleri kullanıyor veya veri hizmetleri oluşturuyoruz. Bu çerçeveler veya hizmetlerdeki değişikliklerin aynı anda kontrol edildiğinden emin olmalıyız. Bazı kuruluşlarda otomatik bir yapı sistemine giriyorlar ve yapı bozulursa, çevik bir metodolojide, daha ileri gitmeden önce çalışan bir çözüme sahip olduğumuzu bilmemiz için, ilerlemeden önce bu yapıyı güverte sabitlemeye devam ediyor. İçinde bulunduğum projelerden biri, bunu çok aşırı hale getirdik - yapı bozulduysa, aslında bölgemizdeki işletme kullanıcılarıyla birleştiğimiz bazı bilgisayarlara bağlı kaldık, sadece kırmızı yanıp sönen ışıklarımız vardı. Polis arabalarının üst kısmı gibi. Ve eğer yapı bozulursa, o kırmızı yanıp sönen ışıklar sönmeye başladı ve hepimizin güvertede olduğunu biliyorduk: yapıyı düzelt ve sonra yaptığımız işe devam et.
Diğer şeyler hakkında konuşmak istiyorum ve bu ER Studio için benzersiz bir yetenek, bu kalıcılık sınırları için geliştiriciler olarak bu eserleri oluşturmaya çalışırken gerçekten işe yarıyor, iş veri nesneleri ve bizim bize ne sağlayanlar diye bir konsepte sahibiz. bu çok basit veri modeline bir örnek olarak bakarsanız, kalıcılık sınırlarının bulunduğu varlıkları veya varlık gruplarını kapsamaya almamızı sağlar. Bir veri modelleyicisi olarak, bir satınalma siparişi başlığı ve sipariş hizalaması ve bunu oluşturduğumuz şekilde bağlayabilecek diğer ayrıntılı tablolar gibi düşünebiliriz ve veri hizmetleri geliştiricilerimizin işlerin bu farklı verilere nasıl devam ettiğini bilmeleri gerekir yapıları. Geliştiricilerimiz satınalma siparişi gibi şeyleri genel olarak bir nesne olarak düşünüyor ve bu belirli nesneleri nasıl yarattıkları ile ilgili sözleşmelerinin ne olduğunu düşünüyor. Bu teknik ayrıntıyı açığa çıkarabiliriz, böylece veri sunucularını oluşturan insanlar altında ne olduğunu görebilir ve diğer izleyicileri karmaşıklıklardan koruyabiliriz, böylece iş dünyasıyla iletişim kurmak için çok iyi çalışan farklı üst düzey nesneleri görebilirler. Farklı iş kavramlarının da etkileşimi hakkında konuşurken analistler ve iş paydaşları.
Bu konuda iyi olan şey, yapıcı bir şekilde genişletip daraltmamızdır; böylece, bu iş veri nesnelerinin içinde yer alan yapılarda ortaya çıksalar da, üst düzey nesneler arasındaki ilişkileri sürdürebiliriz. Şimdi bir modelleyici olarak, s'nin sonuna, s sarma işleminin sonunda, yapmam gereken çok şey var, ki bu da bir sonraki s için ev işimi yapıyorum. Adlandırılmış Yayınlama adını verdiğim her şeyi oluşturuyorum - bu, sürüm sonunda sahip olduğum şey için bana temel çizgimi veriyor. Yani bu benim temelim ileriye gidiyor, depolarımda oluşturup sakladığım tüm bu taban çizgileri veya Adlandırılmış Bültenleri karşılaştırmak / birleştirmek için kullanabiliyorum, böylece diğer herhangi birinden herhangi bir bitimden sonra her zaman karşılaştırabilirim. Değişikliklerinizin veri modelinizde yolculuğu boyunca ne olduğunu bilmek çok önemlidir.
Ben de s / başından sonuna kadar karşılaştır / birleştirme kullanarak bir delta DDL betiği oluşturdum. Bir sürü artımlı senaryoyu kontrol etmiş olabilirim, ancak eğer ihtiyacım olursa şimdi diğer sanal alanlara dayanmak için uygulayabileceğim bir senaryoya sahibim, bu yüzden şunu söyleyebilirim ki, birinin başlangıcında bu vardı. Bir sonraki adımlarla başlamak için bir veritabanı olarak bir veritabanı oluşturarak, bunları da stand up QA örnekleri gibi şeyler yapmak için kullanabiliriz ve nihayetinde tabii ki değişikliklerimizi prodüksiyona itmek istiyoruz. aynı zamanda. Yine, planlama ve retrospektiflere tamamen katılıyoruz, retrospektifler gerçekten öğrenilen derslerdir ve bu son derece önemlidir, çünkü çeviklik sırasında çok hızlı ilerleyebilir, başarıları durdurmanız ve şimdi kutlamanız gerekir. Neyin yanlış olduğunu anlayın, bir dahaki sefere daha iyi olun, ama bir sonraki adımda ilerlemeye devam ederken doğru giden şeyleri kutlayın ve üzerine inşa edin.
Şimdi çok hızlı bir şekilde iş değeri hakkında konuşacağım. Uzun yıllar önce çevik bir proje olarak başlayan bir proje vardı ve bu aşırı bir projeydi, bu yüzden her şeyi yapan geliştiricilerin olduğu saf, kendini organize eden bir ekipti. Uzun lafın kısası, bu proje durmaktaydı ve daha fazla işlevsellik ortaya koydukları tespit edilen kusurları düzeltmek ve düzeltmek için daha fazla ve daha fazla zaman harcadıklarını buluyorlardı. Yanma çizelgelerinde, projeyi altı ay boyunca büyük bir maliyetle uzatmak zorunda kalacaklardı. Ve ona baktığımızda, sorunu gidermenin yolu, projenin kendisinde yer alan yetenekli bir veri modelleyici ile uygun bir veri modelleme aracı kullanmaktı.
Bu belirli grafikte bu dikey çubuğa bakarsanız, bu kümülatif nesnelere karşı kümülatif kusurları gösteriyor ve ben, eğer kısıtlamaları olan tablolar ve bu tür şeyler gibi yaratılmış veri nesneleri veya yapıları hakkında konuşuyorum. veri modelleyicinin tanıtılmasından önce, kusurların sayısı gerçekten aşılıyordu ve zaman içinde o noktaya kadar üretilen gerçek nesne sayısı üzerinde bir miktar boşluk yaratmaya başladı. 21 haftasından sonra, veri modelleyicisi geldiğinde, bir çok şeyi düzeltmek için ne olduğuna bağlı olarak veri modelini yeniden düzenledi ve daha sonra ilerleyen proje ekibinin bir parçası olarak modellemeye başladı. . Ve yaklaşık bir buçuk saat içinde, geliştirici bir çubuk oluşturmaktan ziyade bir veri modelleme aracından ürettiğimizden, üretilen ve yapılan nesnelerin ve veri yapılarının sayısında büyük bir artış olduğunu gördük. Onları bir ortamda ve haklılardı çünkü doğru referans bütünlüğüne ve sahip olması gereken diğer yapılara sahiplerdi. Neredeyse düz olana karşı kusurların seviyesi. Bu uygun eylemi gerçekleştirerek ve veri modellemesinin tam olarak devreye alındığından emin olarak, proje zamanında çok daha yüksek kalitede teslim edildi ve aslında, bu adımlar atılmamış olsaydı, hiçbir şekilde teslim edilemezdi. Dışarıda bir sürü çevik başarısızlık var, doğru insanları bu rollere dahil etseniz çok çevik başarılar da var. Operasyonel bir disiplin olarak çok çevik bir savunucuyum, ancak çevik bir girişimde ilerlerken proje ekiplerinizle dahil olan tüm doğru grupların becerilerine sahip olduğunuzdan emin olmalısınız.
Özetlemek gerekirse, veri mimarları ve modelleyicileri tüm geliştirme projelerine dahil edilmelidir; onlar gerçekten her şeyi bir arada tutan yapıştırıcıdır, çünkü veri modelleyicileri ve mimarlar olarak anlıyoruz, yalnızca verilen geliştirme projesinin veri yapıları değil, aynı zamanda organizasyondaki verilerin var olduğu ve bu verileri nereden alabileceğimiz ve aynı zamanda bu verileri nasıl sağlayabileceğimiz üzerinde çalıştığımız uygulamanın kendisi dışında kullanılacak ve kullanılacaktır. Karmaşık veri ilişkilerini anlıyoruz ve belgeyi haritalandırmak ve tüm veri alanınızın nasıl göründüğünü anlamak için ileri ve aynı zamanda bir yönetim perspektifinden hareket edebilmek çok önemlidir.
İmalat gibidir; Bir üretim geçmişinden geldim. Sonunda kaliteyi kontrol edemezsiniz - tasarımınıza baştan başa dönerken kaliteyi sağlamalısınız ve veri modelleme bu kaliteyi tasarım boyunca verimli ve uygun maliyetli bir şekilde yapmanın bir yoludur . Ve yine, hatırlanacak bir şey - ve bu, titiz olmak değildir, ancak gerçek bu - uygulamalar gelir ve gider, veriler hayati önem taşıyan kurumsal varlıktır ve tüm bu uygulama sınırlarının ötesine geçer. Ne zaman bir başvuruda bulunuyorsanız, muhtemelen önceden gelen diğer uygulamalardan verileri korumanız istenir, bu yüzden zaman içinde tutmaya devam ettiğimiz hayati bir kurumsal varlık olduğunu hatırlamamız gerekir.
Ve bu kadar! Buradan daha fazla soru alacağız.
Eric Kavanagh: Tamam, güzel, önce onu Robin'e atalım. Ve sonra Dez, eminim birkaç sorum olacak. Al onu, Robin.
Robin Bloor: Tamam. Dürüst olmak gerekirse, çevik geliştirme yöntemleriyle hiçbir zaman bir sorunum olmadı ve bana burada ne yaptığınız büyük anlam ifade ediyor. 1980'lerde, gerçekten, kontrolden çıkmış bir proje bağlamında karşılaştığınız sorunun, bir hatanın belirli bir aşamadan sonra da devam etmesine izin verirseniz, normal olduğunu belirten bir şeye baktığımı hatırlıyorum. Eğer o sahneyi doğru yapmazsanız düzeltmek gittikçe daha da zorlaşıyor, burada yaptığınız şeylerden biri - ve bence bu slayt - ama burada yaptığınız şeylerden biri. s sıfırda, bence kesinlikle önemlidir, çünkü gerçekten oraya sabitlenmiş teslimatları almaya çalışıyorsunuz. Ve teslim edilebilecek kalemleri sabitlemiyorsanız, teslim edilebilecekler şekli değiştirir.
Bu, benim düşünceme göre. Aynı zamanda benim görüşüm - Geçmeden önce veri modellemesini belirli bir ayrıntı seviyesine getirmeniz gerektiğine dair bir fikrim yok. Tam olarak anlamadığım için, denemeni ve yapmayı istediğim şey, bu projelerden sadece büyüklüğü açısından, nasıl aktığını, kim olduğunu bilmeniz açısından tanımlamak. sorunlar nerede çözüldü, çözüldü mü? Çünkü bu slaydın hemen hemen onun kalbi olduğunu ve biraz daha fazla detaylandırabilirseniz çok minnettar olurum.
Ron Huizenga: Tabii ve birkaç örnek proje kullanacağım. Aslında, doğru kişilerin dahil olması ve veri modellemesinin gerçekleştirilmesiyle ortaya çıkan raylardan çıkmış ve her şey gerçekten tasarımın daha iyi anlaşıldığından ve açıkça daha iyi uygulama tasarımına sahip olduğumuzdan emin olmanın bir yoluydu. modelleyerek yolda. Çünkü bunu modellediğinizde, bildiğiniz gibi, insanlar genellikle düz bir veritabanı ortamına girerek yapabilecekleri gibi bir şey yapmak zorunda kalmak yerine, DDL'nizi ve her şeyi aletin dışında ve dışında çıkarabilirsiniz. Ve geliştiricilerle olacak tipik şeyler oraya girecekleri ve diyecekler ki, tamam, bu tablolara ihtiyacım var. Diyelim ki sipariş girişleri yapıyoruz. Böylece, sipariş başlığını ve sipariş detay tablolarını ve bu tür şeyleri yaratabilirler. Ancak, kısıtlamaların yabancı anahtar ilişkilerini temsil etmek için orada bulunduğundan emin olmak için sıklıkla unutur veya ihmal ederler. Anahtarlar doğru olmayabilir. Adlandırma kuralları da şüpheli olabilir. Kaç kez, bir ortama kaçtığımı bilmiyorum, örneğin, farklı isimlerle bir sürü farklı tablo gördüğünüzde, ama o zaman bu tablolardaki sütun isimleri ID, İsim ya da her neyse, Tam olarak ne olduğuna dair bir tablo olmadan con’u gerçekten kaybettim.
Bu nedenle, genellikle veri modellemesi yaptığımızda, DDL'de oluşturulan tüm eserler için uygun adlandırma kurallarını uyguladığımızdan emin olacağız. Ancak, projelerin doğası hakkında daha spesifik olmak gerekirse, genelde konuşuyorum, oldukça büyük girişimlerden bahsediyorum. Bunlardan biri, bir düzine eski sistemin yerine geçtiğimiz 150 milyon dolarlık iş dönüşüm projesiydi. Aynı anda beş farklı çevik ekibimiz vardı. Tam bir veri mimarisi ekibim vardı, bu yüzden ekibimden diğer uygulama alanı ekiplerinin her birine gömülü veri modelleyicileri vardı ve konuyu bilen, bu konuyu bilen kurum içi iş uzmanlarının bir kombinasyonu ile çalışıyorduk. gereksinimleri kendileri için kullanıcı hikayeleri. İş sürecini modelleyen ekiplerin her birinde, faaliyet diyagramları ya da iş süreci şemaları ile birlikte iş analistlerine sahip olduk, bu da takımın geri kalanı tarafından tüketilmeden önce kullanıcı hikayelerini kullanıcılarla daha fazla özümsemeye yardımcı oldu.
Ve sonra, tabii ki, uygulama kodunu bunun üzerine inşa eden geliştiriciler. Ve biz de çalışıyorduk, bence uygulamanın farklı bölümlerini oluşturan dört farklı sistem entegrasyonu sağlayıcısıydı, bir takımın veri hizmetlerini oluşturduğu, diğeri bir alanda uygulama mantığı oluşturuyordu, diğeri ise uzmanlığa sahipti. Başka bir iş alanında o alanda uygulama mantığı inşa edildi. Bu yüzden, bu proje üzerinde çalışan bir grup insanla işbirliği yaptık. Bu konuda özellikle takımda 150 kişiydik ve takımda açık denizde başka bir 150 kaynak vardı ve bu olayı ortadan kaldırmak için iki hafta çalıştı. Bunu yapmak için, tüm silindirlere ateş ettiğinizden emin olmanız gerekir ve herkes, teslim edilebilecekleri bakımından iyi bir şekilde senkronize edilir ve gerekli tüm eserlerin teslimatını tamamladığımızdan emin olmak için sık sık sıfırlanan durumlara sahipsiniz. Her s sonunda.
Robin Bloor: Bu etkileyici. Ve bununla ilgili biraz daha ayrıntılı bilgi için - bu projenin sonunda tüm veri alanının MDM haritasını, tam olarak ne denirdi?
Ron Huizenga: Farklı iş alanlarındaki ayrışmayla parçalanan tam bir veri modelimiz vardı. Tam tanımlamalar açısından veri sözlüğünün kendisi bir miktar kısaldı. Tanımlanan tabloların çoğuna sahiptik; sütunların çoğunun tam olarak ne anlama geldiği ile ilgili olarak tanımladık. Orada olmayanlar ve yeterince ilginç olanı, bunların çoğu, proje kapsamının sona ermesinden sonra, hala bir ileriye dönük dizi olarak belgelenmekte olan eski sistemlerden gelen bilgi parçalarıydı. eserler, olduğu gibi, projenin dışındaydı, çünkü ilerleyen organizasyon tarafından sürdürülmesi gereken bir şeydi. Böylece aynı zamanda, organizasyon veri yönetişiminin önemi konusunda çok daha geniş bir bakış açısı aldı, çünkü bu eski sistemlerde ve belgelenmedikleri için tüketmeye çalıştığımız eski veri kaynaklarında birçok eksiklik olduğunu gördük. Pek çok durumda, sadece mühendisimizi tersine çevirmek ve orada ne olduğunu ve bilgilerin ne için olduğunu bulmaya çalışmak zorunda olduğumuz veritabanlarımız vardı.
Robin Bloor: Bu, onun belirli bir yönü beni şaşırtmadı. Veri yönetişimi, diyelim ki, çok modern bir endişe ve bence, aslında, tarihsel olarak veri yönetişimi konusunda yapılması gereken birçok çalışma olduğunu düşünüyorum. Asla olmadı, çünkü yapmamaya başlayabilirsiniz. Ancak veri kaynağı büyüdükçe ve büyüdükçe, sonunda yapamazsınız.
Her neyse, Dez'e geçeceğim çünkü sanırım ayrılan zamanım oldu. Dez?
Dez Blanchfield: Evet teşekkür ederim. Bütün bu şeyler boyunca kendime izliyorum ve öfkeyle birçok yönden kullanılmış çevik görmekten bahsettiğimizi düşünüyorum. Olumsuz çağrışımları olmasına rağmen; Olumlu bir şekilde demek istedim. Bize sadece bir senaryo verebilir misiniz, demek istediğim, bunun mükemmel bir set olduğunu görebileceğim iki yer var: birincisi, ilk günden önce yapılması gereken yeni projeler, ama benim deneyimlerime göre, çoğu zaman sık sık düşünüyorum. Projeler bunun gerekli olduğu kadar büyüyecek kadar büyüdüğünde, iki dünyaya yapıştırmak arasında ilginç bir zorluk var, değil mi? Bir organizasyona girdiğiniz yerde gördüğünüz bazı başarı öykülerine dair bize her türlü içgörüyü verebilir misiniz, iki dünyadan hafif bir çatışmaya girdikleri ve başarılı bir şekilde ortaya koydukları açıktır. Bu yerinde ve büyük projeleri bir araya getirip, raylara mi sokacaklar? Bunun çok geniş bir soru olduğunu biliyorum ama sadece şunu söylediğinize işaret edebileceğiniz özel bir vaka incelemesi olup olmadığını merak ediyorum, bildiğiniz gibi, hepsini yerleştirdik ve geliştirme ekibinin hepsini bir araya getirdi. Veri ekibi ve tekneyi batırmış olabilecek bir şeyi ele aldık.
Ron Huizenga: Tabii ki, aslında bir boru hattı projesi olan proje, veri modelleyiciden önce ve sonra kusurlarla birlikte o çizelgeyi gösterdiğim yere itiraz ettiğim projeydi. Oldukça sık ve önyargılı nosyonlar var, özellikle işler tamamen gelişim perspektifinden yapıldıysa, uygulamaları sunmak için bu çevik projelerde yer alan geliştiricilerin sadece. Elbette, orada olan şey, elbette, raylardan ve özellikle veri artefaktlarından kurtuldukları ya da ürettikleri veri teslimatları, kalite açısından iz bıraktılar ve genel olarak gerçekten konulara değiniyorlardı. Sıklıkla veri modelleyicilerinin projeleri yavaşlattığı ve veri modelleyicisinin doğru bir tavır göstermemesi durumunda bu yanlış anlama olduğu sıkça görülüyor. Dediğim gibi, kaybetmek zorundasınız - bazen “kapıların nasıl göründüğünü kontrol etmek için buradayız” ve bu zihniyetin ortadan kalkması gereken geleneksel kapı bekçisi tutumuna sahip veri modelleyicileri vardır. Çevik geliştirmeye dahil olan herkes ve özellikle veri modelleyicileri, ekiplerin ilerlemesine gerçekten yardımcı olacak bir kolaylaştırıcı olarak rol üstlenmelidir. Bunu göstermenin en iyi yolu, ekiplere önce değişiklikleri modelleyerek ne kadar verimli olabileceklerini çok hızlı bir şekilde göstermek. Ve yine, işte bu yüzden işbirliği hakkında konuştum.
İlk olarak modelleyebileceğimiz ve geliştiricilere göndermek için DDL'yi oluşturabileceğimiz bazı şeyler var. Ayrıca, kısıtlanmış gibi hissetmediklerinden emin olmak istiyoruz. Bu nedenle, üzerinde çalıştıkları şeyler varsa, geliştirme sanal alanlarında çalışmaya devam etmelerine izin verin; çünkü geliştiricilerin, test ettikleri bazı değişiklikleri yapmak için kendi masaüstlerinde veya diğer veritabanlarında çalıştıkları yer. Ve onlarla işbirliği yapın ve “Tamam, bununla çalışın” deyin. Onu aracın içine getireceğiz, çözeceğiz ve sonra ileri iteceğiz ve sizi güncellemek için dağıtabileceğiniz komut dosyalarını vereceğiz. Veritabanları, ilerlemeye devam ettikçe, gerçek yaptırımların gerçek üretim görüşünün ne olduğuna yükseltmek için veritabanları. Ve bunu çok hızlı bir şekilde döndürebilirsiniz. Günlerimin sadece farklı geliştirme ekipleriyle yinelediğim ve ileri geri gittiğim yerlerle dolu olduğunu, değişikliklere baktığımda, karşılaştırdığımda, senaryoları oluşturduğumda, onları çalıştırdıklarında bulunduğumda bulunduğumu ve kendimi bir kez daha kolayca geliştirdiğim dört geliştirme ekibiyle takip edebildiğimi öğrendim bir ivme kazandı.
Dez Blanchfield: Akla gelen şeylerden biri, günlük bazda yaptığım konuşmaların çoğunun, makineden makineye bir çeşit bize gelen bu yük treni ile ilgili olduğu. IOT. Ve şu an kurumdaki mevcut ortamlarımız hakkında çok fazla veriye sahip olduğumuzu düşünürsek, tek boynuzlu atları bir an için ayırırsak, Googles ve s ve Ubers’in petabayt verilere sahip olduğunu biliyoruz. Geleneksel bir işletmede, hala yüzlerce terabayt ve çok fazla veriden bahsediyoruz. Fakat bence, bu yük treni organizasyonlara geliyor, bence ve Dr. Robin Bloor daha önce IoT'den bahsetti. Biliyorsunuz, çok fazla web trafiğimiz var, sosyal trafiğimiz var, şimdi mobilite ve mobil cihazlarımız var, bulut patladı, ama şimdi akıllı bir altyapıya sahibiz, akıllı şehirler ve patlayan bütün bu veri dünyası var.
Gündelik bir organizasyon için, orada oturan ve bu acı dünyasını gören orta ve büyük ölçekli bir organizasyon, onlara gelir ve derhal bir plan yapmazsınız; bu metodolojilerin bazılarını yerine koymak konusunda ne zaman ve nerede konuşarak konuşmaya başlayacakları konusunda. Neredeyse oturmak ve dikkat etmek için planlamaya başlamak için ne kadar erken bir zamana ihtiyaç duyuyorlar ve bazı araçları yerleştirmek ve ekibin eğitilmesini sağlamak ve bu zorluğun üstesinden gelmek için bir konuşma yapmak için doğru zaman olduğunu söylüyorlar? Hikayenin ne kadar geciktiği ya da çok erken olduğu zaman? Gördüğünüz bazı kuruluşlar için bu neye benziyor?
Ron Huizenga: Çoğu kuruluş için, daha önce yapmadılar ve veri modelleme ve veri mimarisini bu gibi güçlü araçlarla uyarladılarsa, yapmaları gereken zamanın dün olduğunu söyleyebilirim. Örgütlerdeki verilere baktığınız zaman bile, bugün bile organizasyonlarımızda çok fazla veriye sahip olduğumuz ve genel olarak konuşursak, gördüğümüz bazı anketlere dayanarak, bu verilerin yüzde beşten daha azını kullanmamız ilginçtir. örgütler arasında baktığımızda. Ve IoT ve hatta NoSQL ile büyük veri - sadece IoT olmasa da, genel olarak sadece büyük veri olsa bile - artık kuruluşlarımızın dışından kaynaklanan daha fazla bilgiyi tüketmeye başladığımız yerde, bu zorluk daha büyük ve daha büyük hale geliyor her zaman. Ve bununla başa çıkma şansımızın tek yolu, bu verilerin ne hakkında olduğunu anlamamıza yardımcı olmak.
Yani, kullanım durum biraz farklıdır. Kendimizi yaparken bulduğumuz şey, bu verilere baktığımızda, onu yakaladığımız, tersine mühendislik yapmamız, bunların içinde ne olduğunu, veri göllerimizde veya hatta şirket içi veritabanlarımızda olup olmadığını görmek, bunların ne olduğunu sentezlemektir. veri ise, anlamlar ve tanımları uygulayın, böylece verinin ne olduğunu anlayabiliyoruz. Çünkü ne olduğunu anlayana kadar, doğru ya da yeterince kullandığımızdan emin olamayız. Bu yüzden bu verinin ne olduğu ile ilgili gerçekten bir bilgiye ihtiyacımız var.Ve bunun diğer kısmı, yapmayın çünkü tüm bu harici verileri tüketme açısından, bu harici verileri tüketmeyi destekleyen bir kullanım durumunuz olduğundan emin olabilirsiniz. İhtiyacınız olan şeyleri, daha sonra ihtiyaç duyabileceğiniz şeyleri çekmeye ve kullanmaya çalışmak yerine odaklanın. Öncelikle önemli şeylere odaklanın ve yolunuz boyunca çalışırken, diğer bilgileri dışarıdan tüketip anlamaya çalışın.
Bunun mükemmel bir örneği, IoT ve sensörlerden bahsettiğimizi biliyorum, ancak aynı tür problem, IoT'den önce bile, yıllarca birçok organizasyonda olmuştur. Üretim kontrol sistemi olan herkes, ister bir boru hattı şirketi, ister üretim, ister kontrol otomasyonu ile çok fazla otomasyon yaptıkları, veri akışları ve benzeri şeyler kullanan süreç bazlı şirketler var. anlamaya çalışmak için içmeye çalıştıkları bu veri yangın hortumları, üretim ekipmanımda sinyal vermek için meydana gelen olaylar nelerdir - ne oldu ve ne oldu? Ve bu devasa veri akışı arasında, ilgilenmeleri, sentezlemeleri, modellemeleri ve anlamaları gereken özel bilgi ya da etiketler var. Ve bunu gerçekten anlamanın zamanı gelinceye kadar geri kalanını görmezden gelebilirler ve daha sonra bu mantıklı hale gelirse, kapsamı daha fazla çekmek için kapsamlarını genişletebilirler.
Dez Blanchfield: Gerçekten de öyle. Buna yol açacağım bir soru var, Eric adında bir beyefendiden geliyor ve özel olarak sohbet ettik. Sizden kendisine sormak için, kendisine verilen iznini sordum. Çünkü kibarca buna yol açıyor, sadece sararmak için, çünkü şimdi biraz zaman geçiyoruz ve Eric'e geri vereceğim. Ancak başka bir Eric'ten gelen soru, yeni başlayanların sahiplerinin terminolojiyi modelleme konusundaki benzersiz zorlukları bildiklerini ve anladıklarını varsaymak ve bunun için başka birine verilmeli mi? Yani bir başka deyişle, bir girişimin buna odaklanıp sunulmasına istekli ve istekli ve yetenekli ve hazır olması gerekir mi? Yoksa gemiye çıkıp uzmanları getirmeleri gereken bir şey mi?
Ron Huizenga: Sanırım kısa cevap gerçekten buna bağlı. Veritabanını gerçekten anlayan bir veri mimarı ya da modelleyicisi olan kurum içinde bir kimsenin bulunmadığı bir başlangıçsa, başlamanın en hızlı yolu, bu alanda çok iyi bilgilendirilmiş ve alabilecek bir danışmanlık geçmişine sahip birini getirmektir. gidiyorlar. Çünkü, bulacağınız şey - ve aslında, bunu ürün yönetiminde karanlık tarafa geçmeden önce yaptığım bir çok uğraşla yaptım - organizasyonlara danışman olarak gidip veri mimarisi ekiplerini yöneteceğim, böylece kendilerini bir şekilde yeniden odaklandırabilirler ve bu tür şeyleri nasıl yapacakları konusunda insanları eğitebilirler, böylece sürdürürler ve ilerleyen misyonu devam ettirirler. Ve sonra mantıklı olsaydı, bir sonraki angajmanıma giderdim. Dışarıda bunu yapan, onları harekete geçirebilecek çok iyi veri deneyimine sahip birçok insan var.
Dez Blanchfield: Harika bir paket servis noktası ve kesinlikle buna katılıyorum ve Dr. Robin Bloor'un da alacağından eminim. Özellikle bir başlangıçta, başlangıçtaki işinizin bir parçası olarak kurmak istediğiniz teklifin özel değeri üzerine bir KOBİ olmaya odaklanıyorsunuz ve muhtemelen her şeyde uzman olmanıza gerek kalmamalı, bu yüzden büyük bir tavsiye. Ama çok teşekkür ederim, harika bir sunum. Gerçekten harika cevaplar ve sorular. Eric, sana geri vereceğim çünkü muhtemelen zamanla 10 dakika geçtiğimizi biliyorum ve zaman pencerelerimize yakın durmayı sevdiğini biliyorum.
Eric Kavanagh: Sorun yok. En azından birkaç iyi sorumuz var. Sana bir tane atmama izin ver. Sanırım bazılarına cevap verdin. Ancak yazan bir katılımcıdan çok ilginç bir gözlem ve soru, bazen çevik projeler, veri modelleyicinin tüm uzun vadeli bir resme sahip olmamasını sağlar ve bu nedenle bir tanesinde bir şey tasarlayıp sonra da üç veya dörtte yeniden tasarlamaları gerekir. Bu üretken görünmüyor mu? Bu tür şeylerden nasıl kaçınabilirsin?
Ron Huizenga: Sadece çevikliğin doğasıdır, belirli bir konuda her şeyi kesinlikle doğru elde etmeyeceksiniz. Ve bu aslında çeviklik ruhunun bir parçası, şudur: onunla çalışmak - verilen bir kodda kod üzerinde çalıştığınız prototipleme yapacaksınız ve bunun üzerinde iyileştirmeler yapacaksınız. Ve bu sürecin bir parçası, son kullanıcının gördüğü şeyleri sunduğunuz ve “Evet, bu yakın, ama gerçekten de bu biraz daha fazla yapması gerekiyor” diyor. Bu, sadece işlevsel tasarımı etkilemiyor. Kodun kendisi ancak oldukça sık, kullanıcının istediği şeyi sağlamak için bu belirli şeylerin altına daha fazla veri yapısını değiştirmemiz veya eklememiz gerekiyor. Ve hepsi bu kadar adil bir oyundur ve bu yüzden gerçekten yüksek güçlü araçları kullanmak istersiniz, çünkü bir modelleme aracında bu değişikliği çok hızlı bir şekilde modelleyebilir ve yapabilirsiniz ve ardından geliştiricilerin bunu sağlamak için çalışabileceği veritabanı için DDL'yi oluşturabilirsiniz. daha hızlı bir şekilde değiştirin. Onları, veri yapılarında olduğu gibi, bu kodlamayı yapmak zorunda bırakmalarından ve en yetenekli oldukları programlama veya uygulama mantığına odaklanmalarına izin vermekten kurtarıyorsunuz.
Eric Kavanagh: Bu tamamen mantıklı. Bunun birçoğunun araca nasıl bağlandığı hakkında özel sorular soran birkaç kişi daha vardı. Örneklerle birlikte biraz zaman geçirdiğinizi ve bazı şeyleri nasıl yaptığınıza dair bazı ekran görüntüleri gösterdiğinizi biliyorum. Tüm bu süreçler açısından, organizasyonlarda oyunda ne kadar sık görüyorsunuz, olayların adil, kibarca düştüğü ve daha fazla zaman aldığı daha geleneksel süreçleri görüyorsunuz? S-tarzı yaklaşım sizin açınızdan ne kadar yaygın?
Ron Huizenga: Sanırım daha fazla görüyoruz. Biliyorum ki, muhtemelen son 15 yılda, özellikle daha hızlı teslimatı benimsemeleri gerektiğinin farkında olan insanların benimsenmesini çok daha fazla gördüm. Bu yüzden çevik grup vagonuna daha fazla organizasyon atladığını gördüm. Mutlaka tamamen değil; İşe yaradığını ispatlamak için birkaç pilot proje ile başlayabilirler, ancak hala çok geleneksel olan ve şelale yöntemine sadık kalanlar var. Şimdi, iyi haber şu ki, elbette, araçlar bu organizasyonlarda ve bu tür metodolojiler için de gayet iyi çalışıyor, ancak araçta uyarlanabilirliğe sahibiz, böylece gemiye atlayanlar araç kutusundaki araçlara sahip olacaklar. parmak uçları. Karşılaştırma ve birleştirme gibi şeyler, tersine mühendislik özellikleri gibi şeyler var, böylece mevcut veri kaynaklarının ne olduğunu görebiliyorlar, böylece artımlı DDL komut dosyalarını çok hızlı bir şekilde karşılaştırıp üretebiliyorlar. Ve bunu benimsemeye başladıklarında ve üretkenliğe sahip olduklarını gördükçe, çevikliği daha da arttırma eğiliminde oluyorlar.
Eric Kavanagh: Bu harika bir şey, millet. Sohbet penceresindeki slaytlara bir bağlantı gönderdim, o yüzden kontrol et; orada sizin için biraz Bitly var. Daha sonra izleyebilmek için tüm bu web yayınlarına sahibiz. Onları arkadaşlarınız ve meslektaşlarınızla paylaşmaktan çekinmeyin. Ron, bugünkü zamanın için çok teşekkür ederim, şovda her zaman hoşuna gidiyorsun - sahada gerçek bir uzman ve işlerini bildiğin açık. Öyleyse, size teşekkürler ve IDERA'ya ve elbette Dez'e ve kendi Robin Bloor'umuza teşekkürler.
Ve bununla size veda edeceğiz, millet. İlginiz ve ayırdığınız zaman için tekrar teşekkür ederiz. 75 dakika boyunca uğraştığınız için teşekkür ederiz, bu oldukça iyi bir işaret. İyi şov millet, bir dahaki sefere konuşuruz. Güle güle.