Önceki makalede, BT dünyasının karşı karşıya olduğu iki asırlık sorunlara baktık. Birincisi, iyi tanınan ancak nadiren iyi yönetilen, yani “iş” ve BT arasındaki boşluğu dolduran bir sorunla ilgilidir. İkincisi, büyük resim idealist düşüncesini, genellikle teknik borcu olarak adlandırılan silolar oluşturan kısa süreli çözümlerin pragmatik olarak verilmesiyle dengelemeye çalışmakla ilgilidir.
Bu kıyamet ve gloom başlangıç noktasından, şehirler için “şehir planlaması” nın olgun uygulamalarından neler öğrenebileceğimize ve veri kasaba planlarının oluşturulması için neler uygulayabileceğimizi görmeye başladık.
“Veri Kasabası Planı” nda gizlice göz atın
Veri için şehir planlaması hakkında konuştum. Bir veri kasabası planının nasıl görünebileceği konusunda biraz fikir istemeniz çok makul olur. Bir veri kasabası planından bazı parçacıkları paylaşmaya başlamadan önce küçük bir uyarı vereceğim. Birçoğu (haklı olarak), “Hey John, bu sadece bir veri modeli değil mi?” Diyecek. Evet, ama o kadar basit değil. Lütfen okumaya devam edin. Ama önce, bazı örneklere bakalım.
Bir su yardımcı programı için biraz iş yaptım. İş halkının kuruluşlarının verilerini nasıl gördüğüne dair aşırı basitleştirilmiş bir bakış.
Ayrıntılara girmeden, bazı yapboz parçalarına hızlı bir şekilde bakalım. Çalışanlar iş yaparlar. İş alt tipleri, belirli bir yere su sayaçlarının monte edilmesini ve ayrıca su sayaçlarını okumayı içerir. Bunun için oldukça kolay bir his alıyor musun? Teknel olmayan iş yöneticileri de öyle, özellikle de herkesin verilerini nasıl görmelerini istedikleri görüşünü bir araya getirmede kilit oyuncular oldukları için.
Bu sayfa üzerinde model. Bu aşırı basitleştirilmiş model, iş kavramlarını sınıflandıran bir hiyerarşi ipuçları içerir. “İş” alt tiplerine baktık (sayaçlar yükleme ve okuma). Bu örnekte, “varlık” kavramının sadece bir alt tip olan su sayaçları vardır. Wildfire acil durumlarına yanıt vermek için kullanılan varlıklarla ilgili başka bir gerçek hayat örneğinde, varlık kavramı bir hiyerarşide iç içe 200 alt tip vardı. Örneğin, aracın alt tipi arazi araçları ve uçakları içeriyordu ve uçakların alt tipinde sabit kanatlı uçak ve helikopter vardı. Daha teknik okuyucular bu sınıflandırma hiyerarşilerine “taksonomiler” (veya kalıtım hiyerarşileri veya veri modeli süperpitleri ve alt tipleri veya…) diyebilirler. İş, işletmenin önemli gördüğünü açıkladıkları sürece onlara ne dediğimiz hakkında daha az önemsiyor.
Ve sonra detayları yakalarız. Su Ölçerimiz şu şekilde tanımlanabilir:
… Ve özellikleri şunları içerebilir:
… Ayrıca, işin ilgisini çeken diğer şeylerle bazı ilişkiler:
- Her su sayacı tek bir yerde bulunmalıdır
- Her konum birçok su sayaçının alanı olabilir.
Evet, bu tür ayrıntılar bir “veri modelini” yansıtıyor, ancak yakalamak istedikleri şeylere odaklanarak iş adamlarını daha rahat hale getirebiliriz ve “kardinalite”, “seçeneklik” ve “referans bütünlüğü” gibi terimlerden uzak durabiliriz, bırakın Boyce-Codd normal form!
Bir veri kasaba planı oluşturmak için bir çerçeve
Bir sayfadaki tek modelden başlayarak, ardından bu diyagramdaki öğeler hakkında daha fazla ayrıntı yakalayarak, bir detaylandırma biçimine değindik.
Başka bir tatbikat türü var ve görüşünü yakaladığımızla ilgilidir. Veri Town planı bir iş grubunu (imalat, finans, insan kaynakları vb.) Your mu yoksa hepsini mi yansıtıyor? Bir iş işlevini mi yoksa hepsini mi temsil ediyor? Bir iş sürecini mi yoksa hepsini mi temsil ediyor? Merkezi mi yoksa tüm ülkeleri mi temsil ediyor? Bir endişe verici ağrı noktasını mı yoksa tüm önemli sorunları mı ele almayı amaçlıyor? Ve daha fazlası.
Basit cevap, tüm önemli görüşleri benimsemeyi amaçlıyor, ancak hafifçe. Sonuçta bir kasaba planıdır ve mühendislik detaylarını içermez. David Hay, BT endüstrisinde Buzzwords hakkında bir kitap yayınladı. Üç seviyeli kitabından küçük bir parçacık:
Genel Bakış Modeli (sayfa üzerinde model olarak adlandırdığım) bir veri kasabası planı için iyi bir başlangıç noktasıdır. Organizasyonun dört bir yanından temsili bir grubun, farklı gruplar arasında en azından biraz paylaşılan bir görüş olarak görebileceğini yansıtmaktadır. Daha sonra, her biri kendi sözleriyle ifade edilen, kuruluş aracılığıyla dilimlerin “anlambilimini” yansıtacak çok sayıda farklı görüş oluşturulur. Sonra zorlu (ve eğlenceli) bit – tek bir yakınsak görüşün yaratılması geliyor. Bunu Esperanto'nun kullanımına benzetiyorum – (ideal olarak) herkesin ana dilini artı bir dilini konuşmasına ve dünyadaki herkesle iletişim kurmasına izin vermek için yaratılan bir dil. Benzer bir hedefimiz var – işletmenin tüm bölümlerinin kendi veri paylaşımı için ortak bir çerçeve üzerinde anlaşma yaparken kendi veri “dillerini” korumasını sağlayan bir veri kasabası planı geliştirmek.
Bazı hikayeler
Siyah Cumartesi
Avustralya'da Black Friday, tarihsel olarak perakendecilerin alışveriş günkü indirimleri değildi. Bunun yerine, yangınların birçok insanı öldürdüğü bir günün ailemin döneminden karanlık bir anıdır. Sonra kişisel geçmişimden, Ailemin öldüğünden korktuğum Ash Çarşamba da dahil olmak üzere başka günler de var ama kesinlikle yapabileceğim hiçbir şey yoktu.
Bu kişisel. Sonra yine kişisel etkileri olan siyah Cumartesi var, aynı zamanda benim için de profesyonel çıkarımlar var.
Arka plan olarak, neyin öğrenilebileceğini görmek için yangınlar hakkında bir soruşturma vardı. Belirli bir yerde kaç tane “itfaiye aracı” olduğuna dair sorularla ilgili bir hikaye. İlgili bir ajans, itfaiye araçları olmadığını, “aletleri” olduğunu – tercih ettikleri isimleri olduğunu söyledi. Kaç itfaiye aracısının mevcut olabileceğini görmeye çalışan kişi ikinci bir ajansa döndü ve hayal kırıklığı not ederek “Kaç tane itfaiye veya 'cihaz' var mı?” Diye sordu. Cevap? “Ne de. Tankerlerimiz ve kaymalarımız var-hangisini kastediyorsun?” (Slip-ons, pompa ve püskürtme ünitesi “kaymış” olan daha küçük araçlar için adıdır).
Öfkelenmiş işçi, “Onlara ne dediğin umrumda değil. Kaç aracın suya sahip olabilir?” Gibi bir şey söyledi.
Hayat ve ölüm ortamından başka bir şeyde, bu hikaye komik olabilir. Ancak, katılımcı ajanslar arasında, hem insandan insana iletişim ve BT sistem-sistem iletişimi için ortak bir dil ihtiyacını vurguladı. Ortak bir bilgi modeli geliştirmekle meşgul oldum (isterseniz bir veri kasabası planı). İlk çerçeve birkaç hafta içinde oluşturuldu.
Banka
Bir veri kasabası planına ihtiyaç duyan diğer kuruluşlardan anlatabileceğim birçok hikaye var. Tekrar tekrar, genellikle iki, üç veya dört haftada yeterli ayrıntı aldılar. Ama aşırı derecede eğlenelim.
Bir banka bir iş süreci yeniden yapılandırma (BPR) egzersizinin ortasındaydı – BPR'nin birkaç on yıl önce öfke olduğunu hatırlayabilirsiniz? Bir barikata çarptılar ve “süreç” girişiminin ilerlemesi için bir “veri” çözümüne ihtiyaç duyduklarını fark ettiler. Belirli bir alana ayrıntılı bir şekilde takip edilen tüm kuruluş için bir veri kasabası planı geliştirmem istendi ve bunu yapması için bir gün verildi.
Len Silverston'ın bankacılık kalıplarını kullandım ve beyaz tahtalardan elle çizilmiş görüntüler sundum. 8 saat içinde! (Ama geri gelmek ve daha resmi olarak veri kasabası planını araştırmak ve belgelemek için birkaç hafta daha sürdüm).
Mesaj basit: Başlangıç değerini sağlamak için bir veri kasabası planı geliştirmek için aylar veya yıllar ihtiyacınız yok. Zamanla cilalayabilir ve rafine edebilirsiniz, ancak o zaman bile çaba minimum olmalıdır.
Final (ama Önemli) Yorumlar
Yerel haberlerimiz, potansiyel olarak pahalı bir hatanın kurbanı olan bir toprak sahibinin hikayesini anlattı. Mevcut bir evi önerilen bir geliştirme sitesinden taşımak ve boş arazisine yerleştirmek için bir organizasyona bazı dönüşümlerle ödemişti.
Tek sorun, şirketin komşunun boş bloğuna teslim edilmesiydi! (Çok kötü yasal savaşlar olabilirdi, ancak komşular dostane bir anlaşmaya vardılar – arazi unvanlarını değiştirdiler.)
Peki bunun verilerle ne ilgisi var? Basit bir örnek alalım. Bir veri deponuz olduğunu düşünelim. Önemli bir unsur “müşteriler” ile ilgilidir. Ancak, müşteri verilerinin birden fazla kaynak sistemden kaldırılmasından, kaymasından ve taşınmasından sorumlu kişiler, yanlış verileri yanlış yere sunar. “Müşteri” öğesinde oraya ait olmayan veriler var ve orada olması gereken ancak olmayan veriler var. Bir müşteri sayısı kadar basit bir şey, işin ihtiyaç duyduğu cevapları vermeyecektir. Nereye gidenleri ifade etmek için veri kasaba planlarını tanımlamaya katılmak için işletmeye ihtiyacımız var.
“Müşteriye” hangi verilerin yükleneceği konusunda karışıklık bile olabilir mi? İki gerçek hayat hikayesi düşünün. Birincisi bir sağlık sigortası kuruluşudur. Bir senaryoda, bir büyükbaba sigorta primini ödüyor, bir ebeveyn çocuklarını diş hekimine getiriyor ve çocuk diş hekiminin sandalyesinde oturuyor. Üçünden hangisi “müşteri”? Buna cevap veremezsek, doğru verileri doğru konuma yükleyemeyiz. Ya da bir mezarlık için benzer bir hikaye. Orijinal müşteri bir cenaze planı satın aldı. Daha sonra, karar vermek için zihinsel yetenekleri kaybettikleri için onlar için bir avukat gücü eylemi vardı. Sonra öldüler. Ölü kişi hala müşteri miydi? Veri mühendislerinin veri yüklemelerini sağlamak yerine cevap vermemiz gereken zor sorular.
Şimdi, bazı iyi haberler. Bir veri kasabası planı oluşturursak, sadece bir veri ambarı oluşturmaya yardımcı olmakla kalmaz (yukarıdaki hikayeler gibi), aynı zamanda diğer birçok BT girişimine katkıda bulunabilir. Örnek bir liste, iş hedefine karşı kıyaslama aday yazılım paketlerini içerebilir veya bir ana veri yönetimi çözümünü sunabilir. Ya da belki birden fazla paydaş (tedarikçiler, tüketiciler…) arasında birlikte çalışabilirlik veri yapılarını tanımlamaya yatırım yapmak istiyorsunuz? Veri kumaş (veya veri ağ) çözümleri sunmak isteyip istemiyorsa ne olacak? Veya bazı stratejik planlama için son devlet vizyonunu ifade ediyor mu? Liste uzayıp gidiyor.
… ve Gerçekten İyi haber? Tüm bu girişimler aynı veri kasaba planından yararlanıyorsa, veri paylaşımına ulaşma çabası çok daha azdır.
Yeni kitabım “Yönetim Kurulu Odasındaki Veri Fili: Enterprise çapında veri kasaba planından veri entegrasyonunu sürüş”, işletmeniz için bir veri kasaba planının başlatılmasını kolaylaştırmak için “Nasıl Yapılır” yönergeleri sunuyor. “İş” insanlar vizyonlarını dile getirmeye başlarlar ve bununla bir temel olarak iş değeri sunmak daha iyidir.
Özet olarak, veri kasabası planları şunlar olmalıdır:
- Yukarıdan aşağıya monte edilmek. Büyük resim esastır. Veri alanı uzunlukları (veya gerçek kasaba durumunda, belediye binasının mutfak kiremit renklerini düşünün) gibi ayrıntıları ele alabiliriz.
- Güvenilir kalıplara dayanmakister “müşteri” veya “ürün” veri yapıları (ya da şehir için, üniversiteler ve hastaneler için kalıplar) için olsun. Bu üst düzey desenler uygulanabilir ve genişletilebilir.
- “Sistem Düşüncesini” kucaklayın Desen tabanlı öğelerin işletme (veya şehir için) için entegre bir bütün olarak birlikte çalışmasını sağlamak için.
- Geleceğe Bak Bugünün ihtiyaçlarını ele alırken. Veri Town planı için, sadece neyin var olduğunu değil, ne olabileceğini de modelliyoruz.
- İşletmenin ihtiyaçlarını yansıtın. Veri kasaba planı teknoloji hususlarına odaklanmamalıdır (olabildiğince önemli).
- Son fakat en az değil, onlar olmalı Tüm taraflar arasındaki iletişim iletişim.
Bazı insanlar hayati girişim düzeyinde girişimlerden uzak dururlar, çünkü çok uzun sürdüklerine, çok pahalıya mal olduklarına veya sadece ulaşılamaz olduklarına inanırlar. Veri Town planları, bir servete eklemeyi veya maliyeti sonsuza dek sürmemelidir. Ancak katkıları sonsuza dek sürmeli (uzun bir süre) ve bir servet kurtarmalıdır.
Bir yanıt yazın