Endüstriyel sistemler, kurumsal dönüşüm ve elektronik fatura entegrasyonları üzerinde çalışırken benzer bir mühendislik sorusuyla farklı ortamlarda karşılaştım: Farklı kurallarla çalışan sistemleri, kendi özelliklerini kaybetmeden nasıl ortak bir yapıda buluşturabiliriz?
SCADA ve endüstriyel entegrasyonlarda bu farklılık çoğunlukla cihazlar, protokoller ve sahadaki çalışma koşulları üzerinden karşıma çıkıyordu. Elektronik fatura çalışmalarımda ise ülke standartları, mevzuat ve tarafların hukuki sorumlulukları tasarım kararlarında daha fazla öne çıkıyor.
Bu deneyimler beni, mimariyi tasarlarken önce değişebilecek noktaları anlamaya yöneltti. Bugünkü bağlantıyı kurarken yarın hangi gereksinimin değişebileceğini ve bu değişikliğin sistemin neresinde karşılanacağını da düşünüyorum.
Farklı Sistemleri Ortak Bir Yapıda Buluşturmak
Entegrasyon çalışmalarında hedeflerden biri, sisteme bağlanan tarafın her yeni bağlantı için yeniden geliştirme yapma ihtiyacını azaltmak.
Elektronik faturada bunun karşılığı, bir firmanın kendi mevcut formatını kullanarak farklı ülkelere ve ağlara ulaşabilmesi. Platformun görevi ise gelen belgeyi işlemek, hedefin gereksinimlerine uyarlamak ve ilgili süreçleri yürütmek.
Bu yaklaşımı bazı yönleriyle ETL sistemlerine benzetiyorum. Veri alınıyor, dönüştürülüyor ve hedefe aktarılıyor. Ancak elektronik faturada iletim sonrasındaki yanıtların ve durum değişikliklerinin de takip edilmesi gerekiyor. Bir belgenin teknik olarak iletilmesiyle iş sürecinde kabul edilmesi aynı durum olmayabilir. Bu yüzden tasarlarken ve kodlarken dönüşüm fonksiyonuyla birlikte işlemin nasıl tamamlanacağına da odaklanıyorum.
Endüstriyel entegrasyonlarda farklı kaynaklardan gelen veriyi ortak bir yapıda işlemek üzerine çalışmak da bu yaklaşımımı besledi. Kaynağa özgü bağlantı detaylarını ayırmak, ortak işleme adımlarının tekrar kullanılmasını kolaylaştırıyor.
Buradaki amaç, müşterinin entegrasyon yükünü mümkün olduğunca azaltmak. Ülkeye özgü ek bilgiler yine gerekebilir; fakat bu bilgilerin işlenmesi ve iletilmesi için her defasında ayrı bir entegrasyon kurulması gerekmemeli.
Ortak Standartların Yanında Farklılıkları Korumak
Ortak standartlar, birlikte çalışabilirlik için önemli bir temel sağlıyor. Bununla birlikte, aynı belge formatını kullanmak bütün sürecin aynı şekilde işleyeceği anlamına gelmiyor.
Kimlik doğrulama, taşıma mekanizması, sertifikalar, yanıtlar ve iş kuralları farklılaşabiliyor. Sözleşmeler, veri koruma yükümlülükleri ve ülkeye özgü sorumluluklar da tasarımın kapsamına giriyor.
Bu nedenle bir entegrasyonu değerlendirirken önce tarafların rollerini ve beklenen iş akışını anlamaya çalışıyorum. Hangi bilgi ortak, hangisi kaynağa veya hedefe özgü? Hangi adımlar tekrar kullanılabilir, hangileri ayrı ele alınmalı?
Ortak veri modelini de bu sorular üzerinden değerlendiriyorum. Tekrar eden işlemleri aynı yapı üzerinde çözmek değerli; ancak ülkeye veya ağa özgü anlamları korumak gerekiyor. Bütün farklılıkları tek modele zorla sığdırmak, başlangıçta sağlanan kolaylığı ileride bir kısıta dönüştürebilir.
Mevzuattan Mühendislik Kararına
Regülasyon yoğun sistemler üzerinde çalışmak, teknik gereksinimlerin her zaman bir API belgesinde açıkça yer almadığını gösteriyor.
Verinin nerede işleneceği, nasıl saklanacağı, hangi tarafın erişebileceği ve hangi işlemin ne anlama geldiği gibi konuların teknik karşılığını çıkarmak gerekiyor. Sözleşmelerin, güvenlik gereksinimlerinin ve sertifikasyon koşullarının anlaşılması da bu çalışmayı besliyor.
Ben bu aşamada gereksinimin hangi bileşeni, veri akışını veya işletim kararını etkilediğini belirlemeye odaklanıyorum. Soyut bir koşulu, geliştirilebilecek ve doğrulanabilecek bir davranışa dönüştürmek mühendisliğin önemli bir parçası.
Genel bir örnek olarak, belirli bir veri grubuna erişim kısıtı olduğunu düşünelim. Bunun teknik karşılığı yalnızca ekrandaki bir alanı gizlemek olmayabilir; API yetkileri, arka plan işlemleri ve kayıt mekanizmaları da değerlendirilmelidir. Gereksinimi doğru anlamak, değişikliğin kapsamını belirler.
Bu nedenle mevzuat analizini geliştirme öncesinde tamamlanan tek seferlik bir aşama olarak görmüyorum. Gereksinimler netleştikçe ve değiştikçe teknik tasarımın da bunlarla birlikte değerlendirilmesi gerekiyor.
Değişikliği İlgili Yerde Karşılamak
Bu çeşitliliği yönetirken modüler bir yapı kurmaya ve gerektiğinde bileşenleri bağımsız geliştirilip işletilebilecek şekilde ayırmaya önem veriyorum.
Kurumsal dönüşüm ve dağıtık sistem çalışmalarında, bu ayrımın değerini uygulama ve işletim tarafında da gördüm. Bir parçayı ayırmış olmak kadar, o parçanın hangi bilgiye bağımlı olduğu ve değiştiğinde kimleri etkilediği de önemli.
Elektronik fatura gibi bir alanda belgeyi alma, doğrulama, dönüştürme, iletme ve yanıtları işleme adımları farklı sorumluluklar olarak düşünülebilir. Bu sınırlar, ülkeye veya ağa özgü değişikliklerin ilgili alanda karşılanmasını kolaylaştırır.
Örneğin taşıma yöntemindeki bir değişikliğin dönüşüm kurallarına yayılmasını mümkün olduğunca sınırlamak isterim. Benzer şekilde yerel bir doğrulama kuralını, bütün platformun ortak davranışına dönüştürmemeye çalışırım.
Burada esnekliği servis sayısıyla ölçmüyorum. Modülerlik, bağımlılıkların ve sorumlulukların nasıl düzenlendiğiyle ilgili. Dağıtık yapı ise bağımsız çalıştırma, ölçekleme veya işletim ihtiyacı olduğunda bu yaklaşımı destekliyor.
Teknoloji ve Yetkinliği Birlikte Düşünmek
Farklı protokoller, veri formatları ve güvenlik yöntemleriyle çalışmak, mühendislik ekibinin bilgi alanını genişletiyor. Bu yüzden teknoloji seçerken mevcut ihtiyacı nasıl karşıladığı kadar, geliştirme ve işletim sürecine nasıl oturacağını da değerlendiriyorum.
Kod yazarken, entegrasyon geliştirirken ve sorun giderirken edinilen bilgi, mimari kararları doğrudan besliyor. Örneğin bir doğrulama kuralının neden yalnızca belirli bir ülke için uygulandığını bilmek, sonraki değişiklikte o kuralı ortak yapıya taşıyıp taşımayacağımızı değerlendirmemize yardımcı oluyor.
Bu çeşitlilik içinde her teknolojiyi baştan bilen bir ekip beklemek gerçekçi değil. Öğrenme isteği, farklı sistemleri anlayabilme ve kararların gerekçelerini paylaşabilme becerisi önem kazanıyor.
Bir yaklaşımın neden seçildiğini birlikte tartışabilmek, ekibin yeni gereksinimler karşısında daha bağımsız hareket etmesini de kolaylaştırıyor. Hangi kararın teknik bir tercihten, hangisinin ülkeye veya ağa özgü bir zorunluluktan kaynaklandığını bilmek, değişikliğin kapsamını belirlerken yol gösteriyor. Mimariyle birlikte bu bilgi birikiminin gelişmesini önemsiyorum.
Temel Yaklaşımım
Bu deneyimlerin bende güçlendirdiği prensip şu: Regülasyonu doğru anlamak ve teknolojiyi regülasyona adapte olabilecek kadar esnek tutmak.
Bunun için önce gereksinimleri ve sorumlulukları netleştirmek, ardından ortaklaştırılabilecek alanlarla farklılaşması gereken parçaları ayırmak gerekiyor. Teknoloji seçimi de bu çerçeve içinde anlam kazanıyor.
Bir sistemi tasarlarken kendime sorduğum sorulardan biri şu: Yeni bir kural geldiğinde nerede değişiklik yapacağız ve bu değişiklik başka neleri etkileyecek?
Bu soruya açık bir cevap verebilmek, benim için mimarinin değişime ne kadar hazır olduğunu gösteren önemli ölçütlerden biri.