Küçük bir sayımla başlayalım. Son bir yılda devreye aldığınız projelerden dördünü açın ve tek bir alanı arayın: müşteri numarası. Kaç ayrı yerde tanımlandığını not edin. Çoğu kurumda çıkan sayı üçten büyüktür.
İlk üç proje hızlı gider, sorun orada görünmez. Dördüncüde kaynak sistemde bir alan uzar ya da bir kod listesine yeni değer eklenir; o an değişikliğin kaç yere dokunması gerektiğini önce bulmanız gerekir. Aramada genellikle bir tanesi atlanır ve eksiği üretim bulur.
Hangi tanım hangi tartışmayı kapatıyor?
Ürün, modüllerin ortak kullandığı tanımlar için merkezî bir alan tutuyor. Asıl soru hangi nesnelerin var olduğu değil, her birinin hangi tartışmayı bir daha açılmayacak şekilde kapattığı:
- Alan kümeleri. Bir tablonun hangi kolonlarının hangi başlıkla çıkacağı bir kez cevaplanır; rapor, servis ve dosya çıktısı aynı cevabı kullanır.
- Parametre başlıkları ve satırları. “Açık siparişler” tam olarak ne demek — hangi statüler, hangi tarih aralığı? Bir kez tanımlandığında sonraki projede aynı tartışma yeniden açılmaz.
- Değer kümeleri. Kod ve değer listeleri merkezde durur ve zamanlanmış görevlerle senkronize edilir; kaynak sistemde yeni bir kod açıldığında listeyi elle güncelleyecek birini aramanız gerekmez.
Maskeleme kural setleri ile metin ve tablo şablonları da aynı mantıkla çalışır: hassas bir alanın çıktıda nasıl göründüğü ve bir raporun biçimi, her projede yeniden karar verilen konular olmaktan çıkar. Aktif nesne kataloğu ise SAP ve haricî kaynak nesnelerini, alanlarını ve seçim parametrelerini tek yerde tutar; böylece “bu tablo daha önce aktive edilmiş mi?” sorusu aranabilir hâle gelir.
Aktif bir iDataView’ın üç farklı işi
Aktif bir iDataView rapor tanımı yalnız rapor olarak kalmak zorunda değil. Aynı tanım bir giden API servisinin, bir SQL aktarım projesinin ya da bir e-posta varyantının kaynağı olabilir. Buradaki mekanizma kopyalama değil, aynı tanımın farklı yürütme akışlarında referans edilmesidir — bu da her hedefte aynı çıktı biçimini vereceği anlamına gelmez; hedef başına kontrol gerekir.
Pratik sonucu şu: alan adlarını ve metinleri ilk turda ciddiye almak gerekiyor. Rapor için “yeterince iyi” olan bir alan adı, altı ay sonra bir entegrasyon sözleşmesinde açıklaması zor bir isim olarak geri gelir.
Ortak tanımların sahibi kim?
Ortak tanımların tek gerçek riski sahipsiz kalmalarıdır. Bir alan kümesini herkes değiştirebiliyorsa kısa sürede kimse ona güvenmez ve ekipler yeniden kendi kopyalarını açar. İşleyen düzen sade: ortak tanımların sahibini belirlemek, değişiklik gerekçesini kaydetmek ve bir tanıma dokunmadan önce onu başka hangi akışın kullandığını sormak.
Kazancın göründüğü yer de burası. Kaynak sistemde bir alan uzadığında dokunulacak tek bir yer olur; tanım kopyalanmışsa önce kaç projede aynı değişikliğin gerektiğini bulmanız gerekir.
O sayımı yapın ve sonucu bir sonraki proje başlangıç toplantısının ilk maddesi olarak masaya koyun. Hangi tanımların tek bir yere taşınabileceğini birlikte çıkarmak isterseniz, en çok tekrarlanan üç alanınızla başlamak yeterli.