Aynı yazılımı birden çok şirket kullanacaksa ne gerekir?

Aynı yazılımı birden çok şirket kullanacaksa gereken ilk şey ayrı kurulum değil, her kaydın hangi şirkete ait olduğunu taşıyan bir kiracı kimliği ve bu kimliği hiçbir sorguda atlamayan bir erişim katmanıdır. İkinci şart, şirketlerin ortak kullandığı tanımlarla kendilerine özel tanımların birbirinden ayrılmasıdır. Holding yapıları, birden çok tüzel kişiliği olan işletmeler, franchise ağları ve bayi portalları aynı sorunla karşılaşır: tek yazılım, çok sahip. Bu yazıda kiracı modelinin nasıl seçildiğini, veri ayrımının nerede kurulduğunu ve hangi tasarım hatalarının sonradan düzeltilemediğini anlatıyoruz.

Çok kiracılı yapı ne zaman gerekir

Her çok şirketli ihtiyaç çok kiracılı mimari istemez. Ayrımı doğru tanımlamak için şu soruyu sormak gerekir: bu iki birim aynı verileri mi görmek zorunda, yoksa birbirinin verisini görmemesi mi gerekiyor?

• Aynı tüzel kişiliğin şubeleri genellikle tek kiracıdır; ayrım şube alanıyla yapılır
• Ayrı tüzel kişilikler ayrı kiracıdır; muhasebe ve belge numaralandırması ayrılır
• Franchise ve bayi yapılarında kiracı, kendi verisini yöneten bağımsız işletmedir
• Hizmet olarak sunulan yazılımda her müşteri bir kiracıdır

Şube ile kiracıyı karıştırmak en sık yapılan hatadır. Şube, aynı şirketin içinde bir organizasyon birimidir ve raporlar birleşik alınır. Kiracı ise ayrı bir dünyadır; birleşik rapor istenirse bu özel olarak tasarlanır.

Veri ayrımı için üç model

Ayrım tek bir yöntemle yapılmaz. Üç yaygın model ve her birinin getirdiği yük şöyledir.

Çoğu özel yazılım projesinde ortak tablo modeli seçilir, çünkü geliştirme ve güncelleme maliyeti en düşüktür. Ancak bu modelin bedeli disiplindir: kiracı koşulu uygulama kodunda değil, veriye erişen tek bir katmanda zorunlu kılınmalıdır. Elle yazılan her sorguya koşul eklemeyi geliştiricinin hafızasına bırakmak, eninde sonunda bir raporun başka şirketin verisini göstermesiyle sonuçlanır.

Ortak tanımlar ve kiracıya özel tanımlar

Kiracı ayrımı yalnızca hareket kayıtlarıyla ilgili değildir. Tanım kayıtlarının bir kısmı ortaktır, bir kısmı kiracıya özeldir ve bu ikisini ayırmayan yapı ya her kiracıya aynı listeyi dayatır ya da aynı tanımı onlarca kez çoğaltır.

• Ortak olması makul olanlar: il ve ilçe listesi, para birimi kodları, ölçü birimleri
• Kiracıya özel olması gerekenler: hesap planı, fiyat listesi, müşteri kartları, kullanıcılar
• Tartışmalı olanlar: ürün kataloğu ve kategori ağacı — merkezden mi yönetilecek, kiracı mı ekleyecek

Ürün kataloğu kararı bayi portallarında ayrı bir önem taşır. Merkez kataloğu yönetiyorsa kiracı yalnızca kendi fiyatını ve stoğunu görür; kiracı kendi ürününü ekleyebiliyorsa katalog zamanla ayrışır ve merkezi raporlama güçleşir. Bu karar yazılmadan kodlanmamalıdır.

Kullanıcı, yetki ve kiracı geçişi

Kullanıcı ile kiracı arasındaki ilişki tek yönlü değildir. Bir muhasebeci iki şirkete de bakıyorsa aynı kullanıcı birden çok kiracıya bağlanır ve arayüzde aktif kiracı seçimi bulunur. Bu durumda yetki, kullanıcıya değil kullanıcı-kiracı çiftine verilir: aynı kişi bir şirkette tam yetkili, diğerinde yalnızca görüntüleyici olabilir.

Kiracı geçişinin kayıt altına alınması da gerekir. Kullanıcının hangi kiracı bağlamında hangi işlemi yaptığı iz kaydında görünmezse, sonradan yapılan incelemede kaydı kimin değiştirdiği anlaşılır ama hangi şirket adına hareket ettiği anlaşılmaz. Rol ve yetki kurgusunun genel çerçevesini rol ve yetki yönetimi yazısında anlattık.

Kullanıcı davetinin hangi kiracıya ait olduğu da açık olmalıdır. Bir kiracının yöneticisi yeni kullanıcı tanımlayabiliyorsa, bu tanımın yalnızca kendi kiracısı için geçerli olduğu ve başka kiracıya erişim veremeyeceği sistem tarafından garanti edilir. Aynı e-posta adresinin iki ayrı kiracıda kullanıcı olabilmesi ise baştan karara bağlanır; aksi halde ilk tanımdan sonra ikinci kiracı aynı kişiyi ekleyemez.

Numaralandırma, dosya ve rapor tarafı

Çok kiracılı yapıda en çok gözden kaçan üç nokta şudur. Birincisi belge numaralandırması: sipariş, fatura ve fiş numaraları kiracı içinde kesintisiz artmalıdır, ortak bir sayaç kullanılırsa her kiracının numaraları boşluklu görünür ve bu muhasebe tarafında soru işareti yaratır.

İkincisi dosya ve ek yönetimi. Yüklenen belgeler kiracı klasörlerine ayrılmalı, dosya bağlantıları tahmin edilebilir sırayla üretilmemelidir; aksi halde bir kiracının kullanıcısı adres satırını değiştirerek başka kiracının belgesine ulaşabilir. Üçüncüsü raporlama: kiracı içi raporlar standarttır, ancak holding düzeyinde birleşik rapor isteniyorsa bunun ayrı bir yetki seviyesi ve ayrı bir veri yolu olmalıdır. Birleşik raporu normal kullanıcı ekranına eklemek, ayrımın anlamını ortadan kaldırır.

Kısa kontrol listesi

• Şube mi kiracı mı ayrımı yazılı olarak kararlaştırıldı mı
• Kiracı koşulu tek bir erişim katmanında zorunlu kılındı mı
• Hangi tanımlar ortak, hangileri kiracıya özel listelendi mi
• Aynı kullanıcı birden çok kiracıya bağlanabiliyor mu, yetki çift bazında mı
• Belge numaralandırması kiracı içinde kesintisiz mi
• Dosya ve ek erişimi kiracı bazında kontrol ediliyor mu
• Birleşik rapor ayrı yetki ve ayrı yolla mı veriliyor
• Yedekleme ve veri silme talebi tek kiracı için uygulanabiliyor mu

Özet: Çok kiracılı yazılımda kritik olan şey veritabanı seçimi değil, kiracı ayrımının kod disiplininden bağımsız biçimde garanti edilmesi ve ortak-özel tanım sınırının en başta çizilmesidir. Bu iki karar sonradan düzeltilirken veri taşıma gerektirir, o yüzden proje başında konuşulur. KAV Yazılım, çok şirketli ve bayi ağına açık yazılım projelerinde bu ayrımı veri modeli düzeyinde kurar.