Kaynağa Dön

Kaynağa geri dön - eski ve kaynak sistemleri gösterir

Pek çok organizasyonda, örneğin yeni bir sistemi ana bilgisayara entegre etme işi yapıldıktan sonra, her seferinde entegrasyonu tekrarlamak yerine bu sistemle ana bilgisayar aracılığıyla etkileşim kurmak çok daha kolay hale gelir. Monolitik mimariye sahip birçok eski sistem için bu mantıklıydı, aynı sistemi aynı monolite birden çok kez entegre etmek savurgan ve muhtemelen kafa karıştırıcı olurdu. Zamanla, diğer sistemler bu verileri almak için eski sisteme ulaşmaya başlar ve kaynak entegre sistem genellikle “unutulur”.

Genellikle bu, eski bir sistemin birden fazla sistem için tek entegrasyon noktası haline gelmesine ve dolayısıyla bu verilere ihtiyaç duyan herhangi bir iş süreci için önemli bir yukarı akış veri kaynağı haline gelmesine yol açar. Bu yaklaşımı birkaç kez tekrarlayın ve örneğin aşağıdaki gibi sık gördüğümüz eski veri temsillerine sıkı bağlantı ekleyin. İstilacı Kritik Toplayıcıo zaman bu, eski yer değiştirme için önemli bir zorluk yaratabilir.

Eski mülkün “ötesindeki” veri kaynaklarını ve entegrasyon noktalarını izleyerek, eski yer değiştirme çabalarımız için genellikle “kaynağa geri dönebiliriz”. Bu, daha modern entegrasyon tekniklerini devreye sokabileceğimiz için verilerin kalitesini ve güncelliğini iyileştirme fırsatı sunmanın yanı sıra, eskilere olan bağımlılıkları erkenden azaltmamıza izin verebilir.

GDPR gibi ticari ve yasal nedenlerle gerçek veri kaynaklarını anlamanın giderek daha önemli hale geldiğini de belirtmekte fayda var. Kapsamlı bir mirasa sahip birçok kuruluş için, yalnızca bir arıza veya sorun ortaya çıktığında gerçek veri kaynağı daha net hale gelir.

Nasıl çalışır

Herhangi bir eski yer değiştirme çabasının bir parçası olarak, temel veri akışları için kaynak kaynakları ve havuzları izlememiz gerekir. Genel sorunu nasıl parçalara ayırmayı seçtiğimize bağlı olarak, bunu tüm sistemler ve veriler için aynı anda yapmamız gerekmeyebilir; yapılacak işin genel ölçeğini anlamak için ana akışları anlamak çok yararlıdır.

Amacımız bir tür veri akış haritası üretmektir. Kullanılan asıl format daha az önemlidir, bunun yerine kilit nokta, bu keşfin sadece eski sistemlerde kalmaması, aynı zamanda temel entegrasyon noktalarını görmek için daha derine inmesidir. Müşterilerimizle çalışırken birçok mimari diyagram görüyoruz ve bu mirasın arkasında yatanları ne sıklıkla görmezden geldiklerini görmek şaşırtıcı.

Sistemler aracılığıyla verileri izlemek için çeşitli teknikler vardır. Bunları genel olarak, yukarı veya aşağı yöndeki yolu izlemek olarak görebiliriz. Temelde yatan kaynak sistemlere hem veri hem de sistemden veri akışı olmasına rağmen, kuruluşların yalnızca veri kaynakları açısından düşünmeye eğilimli olduğunu görüyoruz. Belki de eski sistemlerin merceklerinden bakıldığında bu, herhangi bir entegrasyonun en görünür kısmıdır? Eski sistemlerden kaynak sistemlere veri akışının, herhangi bir entegrasyonun en az anlaşılan ve en az belgelenen kısmı olduğunu bulmak nadir değildir.

Yukarı akış için genellikle iş süreçleriyle başlarız ve ardından veri akışını eskiye ve sonra geriye doğru izlemeye çalışırız. Bu, özellikle birçok farklı entegrasyon teknolojisi kombinasyonuyla eski sistemlerde zorlayıcı olabilir. Kullanışlı bir teknik kullanmaktır. CRC kartları önemli iş süreci adımları için sıra diyagramlarının yanı sıra bir veri akışı diyagramı oluşturma hedefiyle. Hangi tekniği kullanırsak kullanalım, doğru insanları dahil etmek hayati önem taşır, ideal olarak başlangıçta eski sistemler üzerinde çalışmış ama daha yaygın olarak şimdi onları destekleyenler. Bu insanlar mevcut değilse ve işlerin nasıl yürüdüğüne dair bilgiler kaybolmuşsa, kaynaktan başlamak ve aşağı yönde çalışmak daha uygun olabilir.

Aşağı akış entegrasyonunu izlemek de son derece yararlı olabilir ve deneyimlerimize göre genellikle ihmal edilir, çünkü kısmen
Özellik Paritesi oyunda ise odak yalnızca mevcut iş süreçlerinde olma eğilimindedir. Aşağı akışı takip ederken, temel bir entegrasyon noktasıyla başlarız ve ardından desteklediği temel iş yetenekleri ve süreçlerine kadar izlemeye çalışırız. Bir nehir için olası bir kaynağa boya getiren ve daha sonra boyanın hangi akıntıların ve yan kolların sonunda akış aşağısında göründüğünü gören bir jeologdan farklı değil. Bu yaklaşım, özellikle eski entegrasyon ve ilgili sistemler hakkındaki bilgilerin yetersiz olduğu durumlarda yararlıdır ve özellikle yeni bir bileşen veya iş süreci oluştururken kullanışlıdır. Aşağı akışı takip ederken, bu verilerin ilk olarak izlediği yolu tam olarak bilmeden nerede devreye girdiğini keşfedebiliriz, burada muhtemelen yol boyunca bir şeylerin değişip değişmediğini doğrulamak için orijinal kaynak verilerle karşılaştırmak isteyeceksiniz.

Veri akışını anladığımızda, kaynakta verilerin bir kopyasını oluşturmanın veya engellemenin mümkün olup olmadığını görebiliriz, bu daha sonra yeni çözümümüze akabilir. Böylece, eskiye entegre etmek yerine, yeni bileşenlerimizin Kaynağa Dönmesine izin vermek için bazı yeni entegrasyonlar oluşturuyoruz. Hem yukarı hem de aşağı akışları hesaba kattığımızdan emin olmamız gerekiyor, ancak aşağıdaki örnekte gördüğümüz gibi bunların birlikte uygulanması gerekmez.

Yeni bir entegrasyon mümkün değilse kullanabiliriz Olay Durdurma
veya veri akışının bir kopyasını oluşturmak ve bunu yeni bileşenimize yönlendirmek için benzer şekilde, mevcut eski davranışlara bağımlılığı azaltmak için bunu mümkün olduğunca yukarı yönde yapmak istiyoruz.

Ne Zaman Kullanılır

Kaynağa Geri Dön, en çok, eski bir sistemin “arkasına saklanan” bir entegrasyon noktasından elde edilen verilere dayanan belirli bir iş kabiliyetini veya sürecini çıkardığımız durumlarda kullanışlıdır. Verilerin büyük ölçüde değişmeden geçtiği, tüketimden önce çok az işleme veya zenginleştirmenin gerçekleştiği yerlerde en iyi sonucu verir. Bu pratikte pek olası görünmese de, mirasın yalnızca bir entegrasyon merkezi işlevi gördüğü birçok durumla karşılaşıyoruz. Bu durumlarda verilerde gördüğümüz ana değişiklikler, veri kaybı ve verilerin zamanında azalmasıdır. Veri kaybı, çünkü alanlar ve öğeler genellikle yalnızca onları eski sistemde temsil etmenin bir yolu olmadığı için veya gereken değişiklikleri yapmak çok maliyetli ve riskli olduğu için filtreleniyor. Birçok eski sistem, veri içe aktarma için toplu işler kullandığından ve bu bölümde tartışıldığı gibi zamanında azalma Kritik Toplayıcı “güvenli veri güncelleme süresi” genellikle önceden tanımlanmıştır ve değiştirilmesi neredeyse imkansızdır.

Eski verilerde herhangi bir ek değişiklik olmadığını doğrulamak için Kaynağa Döndür’ü Paralel Çalıştırma ve Mutabakat ile birleştirebiliriz. Bu, genel olarak kullanılması doğru bir yaklaşımdır, ancak özellikle verilerin farklı yollardan farklı uç noktalara aktığı, ancak sonuçta aynı sonuçları vermesi gerektiği durumlarda kullanışlıdır.

Daha zengin ve daha zamanlı veriler genellikle mevcut olduğundan Kaynağa Dön’ü kullanmak için yapılacak güçlü bir iş gerekçesi de olabilir. Kaynak sistemlerin birkaç kez yükseltilmesi veya değiştirilmesi yaygındır ve bu değişiklikler etkin bir şekilde mirasın arkasında gizli kalır. Verilerdeki iyileştirmelerin aslında bu yükseltmeler için temel gerekçe olduğu birçok örnek gördük, ancak daha sık ve daha zengin güncellemeler eski yoldan sağlanamadığından faydaların hiçbir zaman tam olarak gerçekleşmediği görüldü.

Bu modeli, burada daha fazla dikkat gerekmesine rağmen, temel bir entegrasyon noktası ile iki yönlü bir veri akışının olduğu durumlarda da kullanabiliriz. Nihai olarak kaynak sisteme giden herhangi bir güncelleme, önce eski sistemlerden akmalıdır, burada diğer süreçleri tetikleyebilir veya güncelleyebilirler. Neyse ki, yukarı ve aşağı akışları bölmek oldukça mümkündür. Bu nedenle, örneğin, bir kaynak sisteme geri akan değişiklikler miras yoluyla akmaya devam edebilirken, güncellemeleri doğrudan kaynaktan alabiliriz.

Kaynak sistemde mevcut olabilecek herhangi bir çapraz fonksiyonel gereksinim ve kısıtlamaya dikkat etmek önemlidir, bu sisteme aşırı yüklenmek veya gerekli verileri doğrudan sağlamak için yeterince güvenilir veya kullanılabilir olmadığını öğrenmek istemiyoruz.

Perakende Mağaza Örneği

Bir perakende müşterisi için Kaynağa Dön’ü hem yeni bir bileşen çıkarmak hem de mevcut iş yeteneklerini geliştirmek için kullanabildik. Müşteri, geniş bir mağaza arazisine ve çevrimiçi alışveriş için daha yakın zamanda oluşturulmuş bir web sitesine sahipti. Başlangıçta yeni web sitesi tüm stok bilgilerini eski sistemden elde etti, sırayla bu veriler bir depo envanter takip sisteminden ve mağazaların kendisinden geldi.

Bu entegrasyonlar, bir gecede yapılan toplu işlerle gerçekleştirildi. Depo için bu işe yaradı, çünkü stok depodan günde yalnızca bir kez ayrıldı, bu nedenle işletme, her sabah alınan toplu güncellemenin yaklaşık 18 saat boyunca geçerli kalacağından emin olabilirdi. Mağazalar için bu bir sorun yarattı, çünkü stok iş günü boyunca herhangi bir noktada mağazalardan ayrılabiliyordu.

Bu kısıtlama göz önüne alındığında, web sitesi yalnızca depoda bulunan stokları satışa sundu. Ertesi gün alınan mağaza stok verileriyle birleştirilen siteden elde edilen analizler, sonuç olarak satışların kaybedildiğini açıkça ortaya koydu: bir mağazada gerekli stok tüm gün boyunca mevcuttu, ancak eski entegrasyonun toplu yapısı bundan yararlanmayı imkansız hale getirdi. nın-nin.

Bu durumda, başlangıçta yalnızca web sitesi tarafından kullanılmak üzere, ancak bir bütün olarak kuruluş için yeni kayıt sistemi olma hedefiyle yeni bir envanter bileşeni oluşturuldu. Bu bileşen, satış gerçekleştiğinde ve gerçekleştiğinde neredeyse gerçek zamanlı güncellemeler sağlayabilen mağaza içi kasa sistemleriyle doğrudan entegre edildi. Aslında işletme, elektronik ödemeleri desteklemek için mağazalarını birbirine bağlayan son derece güvenilir bir ağa, bol miktarda yedek kapasiteye sahip bir ağa yatırım yapmıştı. Depo stok seviyeleri başlangıçta eski sistemlerden çekildi ve daha sonraki bir aşamada bunu kaynağa döndürmek için daha uzun vadeli bir hedef vardı.

Sonuç olarak, hem mağaza içi rezervasyon hem de çevrimiçi satış için mağaza içi stokları güvenli bir şekilde sunabilen bir web sitesi ve stok hareketleri hakkında daha zengin ve daha zamanlı veriler sunan yeni bir envanter bileşeni ortaya çıktı. Kuruluş, yeni envanter bileşeni için kaynağa geri dönerek aynı zamanda çok daha zamanında satış verilerine erişebileceklerini fark etti; bu veriler o sırada yalnızca bir toplu işlem yoluyla eski sürüme güncellendi. Ürün grupları ve fiyatlar gibi referans verileri, ana bilgisayar aracılığıyla mağaza içi sistemlere akmaya devam etti, bu nadiren değiştiği için tamamen kabul edilebilirdi.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.