Eski Yazılım Nasıl Modernize Edilir? Veri Kaybını Önleyen, Operasyonu Koruyan Bir Geçiş Planı

Eski yazılım modernizasyonu, çalışan bir sistemin iş kurallarını, verisini ve entegrasyonlarını koruyarak bakımını ve geliştirilmesini sürdürülebilir hâle getirmektir. Başarısı yeni ekranların açılmasıyla değil, siparişin kaybolmaması, stok rezervasyonunun iki kez yapılmaması ve sorun çıktığında hangi kaydın doğru olduğunun bilinebilmesiyle ölçülür.

Çoğu kurumun asıl sorusu “Hangi framework’e geçelim?” değildir: “İş devam ederken bu sistemi nasıl değiştirebiliriz?” Cevap; önce bağımlılıkları ve veri sahipliğini çıkarmak, sınırları belirli bir işlev seçmek, veriyi doğrulayarak taşımak ve yazma yetkisini kontrollü devretmektir. Kesinti ve veri kaybı hedefleri bunun ardından teknik bir plana dönüşür; başlangıçta koşulsuz vaat edilmez.

TankDev’in operasyonel sistem modernizasyonu yaklaşımındaki analiz, sistem tasarımı, veri tabanı ve entegrasyon ilişkisini bu yazıda bir depo operasyonuyla somutlaştırıyoruz. Örnek temsili bir mühendislik senaryosudur; müşteri projesi veya gerçekleşmiş performans sonucu değildir. Şemalar ve kontrol şablonları senaryoya aittir, kendi sisteminizin sınırlarına göre uyarlanmalıdır.

1. Sorun yazılımın yaşı mı, değiştirilememesi mi?

On yıllık bir uygulama güvenilir biçimde çalışabilir. İki yıllık bir uygulama ise her değişiklikte stokları bozabilir. Legacy system, yalnızca eski teknoloji demek değildir; davranışı yeterince bilinmeyen, değişiklik maliyeti yükselmiş veya işletilmesi zorlaşmış sistem de bu kapsama girer.

Kararı gözlenebilir sorunlarla başlatın: bir iş kuralı değişikliğinin teslim süresi, manuel düzeltme sayısı, geri yükleme provasında ölçülen süre, desteklenmeyen bileşenler ve kritik işlemlerdeki hata oranı. Teknik borç, bu sorunların nedenini açıklayabilir; tek başına “kod kötü” değerlendirmesi yatırım gerekçesi değildir.

• Refactor: İşlev ve veri modeli uygundur; kod içindeki bağımlılıklar veya test eksikleri değişikliği zorlaştırıyordur. Davranış korunarak iç yapı iyileştirilir.
• Replatform: Asıl sorun işletim sistemi, veri tabanı sürümü veya dağıtım ortamıdır. İşlev büyük ölçüde korunur; altyapı taşınır. Yeni sunucu, yanlış iş kuralını düzeltmez.
• Kademeli yenileme: Belirli yetenekler ayrıştırılabilir ve eski sistem bir süre güvenle işletilebilir. İşlevler sırayla yeni uygulamaya devredilir.
• Paket yazılımla değiştirme: İhtiyaç standarttır ve ürünün süreç, veri dışa aktarımı, API ve yetki modeli gereksinimleri karşılıyordur. Lisans bedeline uyarlama ve çıkış maliyeti de eklenir.
• Baştan yazma: Sistem küçük, kurallar doğrulanmış ve geçiş penceresi kabul edilebilirdir; ya da eski sistemi sürdürmek daha büyük risk yaratıyordur. Bunun da veri taşıma ve geri dönüş planı gerekir.

Seçim yalnızca geliştirme bütçesiyle yapılmaz. Geçici olarak iki sistemi işletmenin maliyeti, veri temizliği, eğitim, lisanslar, destek yükü ve eski sistemi kapatamama riski aynı kararda değerlendirilir.

2. Temsili senaryo: sevkiyat modülünü yenilemek

Bir dağıtım işletmesinde siparişler eski bir masaüstü uygulamasına giriliyor. Gece çalışan görevler stok raporu üretiyor; ERP faturalamayı, depo uygulaması rezervasyon ve sevkiyatı yönetiyor. Bazı kullanıcılar hataları doğrudan veri tabanında düzeltiyor. Yeni hedef, tarayıcıdan çalışan bir sevkiyat modülü; ilk aşamada muhasebe ve ürün ana verisi değişmeyecek.

Örnek siparişimiz SO-1842 olsun: SKU-A ürününden 10 birim isteniyor. Depoda 20 birim var, 10 birim rezerve edildi ve henüz sevkiyat yapılmadı. Geçiş sırasında ekranda “10” görmek yeterli değildir. Bunun istenen, ayrılan veya sevk edilen miktar olduğunu; hangi depoya ve ölçü birimine ait olduğunu korumak gerekir.

İlk sınır “sevkiyat ekranı” değil, sipariş kalemi için rezervasyon oluşturma, serbest bırakma ve sevkiyatı kaydetme yeteneği olarak tanımlanır. Stok havuzu birden fazla depoda ortaksa tek depoluk pilot bile bağımsız değildir. Bu durumda önce stok tahsis sınırı ayrıştırılır veya daha az bağımlı bir işlev seçilir.

3. Modernizasyon öncesi keşif şablonu

Kaynak kod, operasyonun tamamını anlatmaz. Saklı yordamlar, tetikleyiciler, Excel dışa aktarımları, zamanlanmış görevler, servis hesapları ve doğrudan tablo okuyan raporlar da sisteme dahildir. Kullanıcı görüşmesi gerçek kayıtlar ve çalışma zamanı gözlemleriyle birlikte yürütülür.

• İş yeteneği: Hangi operasyon taşınıyor, hangisi kapsam dışında? Karar sahibi ve günlük kullanıcı kim?
• Yazma envanteri: Bu veriyi değiştiren API, ekran, görev, tetikleyici, entegrasyon ve manuel erişim hangileri?
• Veri sözlüğü: Alanın iş anlamı, birimi, para birimi, saat dilimi, boş değer davranışı ve doğruluk kaynağı nedir?
• Tüketiciler: Hangi rapor, ERP işlemi ve dış müşteri eski alanlara veya durum kodlarına bağımlı?
• Değişmezler: İşlemden önce ve sonra hangi koşullar mutlaka doğru kalmalı?
• Geçiş sözleşmesi: Kabul edilebilir duruş, veri kaybı hedefi, durdurma ölçütleri, karar sahibi ve geri dönüş yolu nedir?

SO-1842 için bir değişmez, kısmi sevkiyat desteklenen bu örnekte, “10 birimlik siparişte 4 birim sevk edildiyse en fazla kalan 6 birim için açık rezervasyon bulunur” olabilir. İptal, fazla teslim veya alternatif ürün kuralları varsa bunlar ayrı tanımlanır. Eski sistemdeki istisnaları bilmeden genel bir stok eşitliğini herkese uygulamak veri temizliği değildir.

Mevcut davranışı kayıt altına alan characterization test’leri, eski sistemin bugün ne yaptığını gösterir. Eski ve yeni sonuç farklıysa iş sahibi bunun eski hata mı, yeni hata mı, bilinçli kural değişikliği mi olduğunu kararlaştırır. Her eski davranışı otomatik olarak doğru kabul etmeyiz.

4. Geçici mimari: Strangler Fig ve tek yazma otoritesi

Strangler Fig, mevcut sistemin belirli işlevlerini bir yönlendirme katmanı arkasında aşamalı olarak değiştirme desenidir. Her modülü mikroservise dönüştürmeyi gerektirmez; iyi ayrılmış bir modüler monolit de hedef olabilir. Yönlendirme katmanının kapasitesi, erişilebilirliği ve kaldırılma planı ayrıca tasarlanmalıdır. Microsoft’un desen açıklaması bu geçici mimarinin sınırlarını ele alır.

Bu senaryoda yönlendirme depo ve iş yeteneği bazındadır. Eski sistem ilk aşamada rezervasyonların tek yazarıdır. Yeni sistem veriyi alır ve sonuçları karşılaştırır; sevkiyat emri veya stok hareketi üretmez. Pilot başladığında seçilen kapsamın yazma yetkisi yeni sisteme geçer, eski yazma yolları aynı kapsam için kapatılır.

Bir feature flag yalnızca trafiği yönlendiriyorsa yeterli değildir. Eski zamanlanmış görev hâlâ stok değiştirebiliyorsa iki otorite vardır. Sahiplik kaydı, geçiş sürümü ve yazmayı reddeden kontroller; eski görevler, servis hesapları ve doğrudan veri tabanı erişimi dahil bütün yazma yollarında uygulanır. Eski uygulama bunu desteklemiyorsa kapsamlı erişim kısıtlaması veya planlı yazma duruşu gerekir.

Eski uygulamadaki status=7 değerini yeni modele aynen taşımak yerine anlamını bir uyarlama katmanında çözün: örneğin “kısmen sevk edildi”. Bu anti-corruption layer, eski kodların yeni domain modeline yayılmasını önler. Kimliği doğrulanmış kullanıcı yine depo ve işlem yetkisi açısından kontrol edilir; geçiş adaptörü yetkilendirmeyi atlayan bir arka kapı olmamalıdır.

5. Veri taşıma: snapshot, değişiklik akışı ve iş anlamı

Veri migration’ı için önce kaynak-hedef eşleme hazırlanır. legacy_order_id ile yeni kimlik arasındaki bağ korunur; farklı şirketlerde aynı numara kullanılabildiği için anahtar şirket ve kaynak sistemi de kapsar. Belirsiz müşteri eşleşmeleri tahminle birleştirilmez, inceleme kuyruğuna alınır. Hangi dönüşümün hangi kayıtları etkilediği tekrar üretilebilir olmalıdır.

Çalışan sistemde sık kullanılan yaklaşım, tutarlı bir başlangıç kopyası almak ve ardından CDC (Change Data Capture) ile bu kopyadan sonraki değişiklikleri uygulamaktır. Buradaki kritik nokta kopyanın başlangıcıyla değişiklik günlüğü konumunu koordine etmektir. Aksi hâlde kopyalama sürerken oluşan bir rezervasyon iki aşamanın arasında kaybolabilir.

CDC “veriyi otomatik olarak doğru taşır” garantisi değildir. Ekleme kadar güncelleme ve silmeler; işlem sırası, kaynak işlem sınırları, tekrar teslim ve şema değişiklikleri de ele alınır. Bir değişiklik birden fazla hedef tabloya dağılıyorsa hedefteki atomiklik veya geçici tutarsızlığın nasıl gizleneceği belirlenir. İlerleme işareti, hedefteki veri değişiklikleriyle aynı transaction içinde güvenle kaydedilebilmeli veya eşdeğer bir yeniden oynatma güvencesi sağlanmalıdır.

SO-1842’nin 10 birimlik rezervasyon olayı yeniden gelirse ikinci kez 10 eklemek yanlıştır. Kaynak olay kimliği ya da güvenilir log konumu ile tekrar tespiti yapılır. Aynı kaydın eski sürümü sonradan gelirse yeni durumu ezmesine izin verilmez. Bir kaydın kimliğiyle olayın kimliği farklıdır: aynı sipariş birçok geçerli değişiklik üretebilir.

Kaynak ve hedef PostgreSQL ise yerleşik logical replication değerlendirilebilir. Ancak DDL değişiklikleri ve sequence değerleri otomatik olarak replike edilmez; hedef yazmaya açılmadan önce bunlar ayrıca hazırlanır. Farklı bir veri tabanından PostgreSQL’e geçiş ise kaynakla uyumlu başka bir aktarım mekanizması gerektirir. PostgreSQL logical replication sınırları.

Değişiklik günlüğünün saklama süresi ve disk bütçesi de geçiş planının parçasıdır. Tüketici uzun süre durursa gerekli log kayıtları kaybolabilir veya kullanılan mekanizmaya bağlı olarak kaynakta birikerek disk baskısı oluşturabilir. Prova; yeniden başlatmanın yanında bu gecikme sınırını, alarmı ve yeniden başlangıç kopyası gerektiren durumu da kapsar.

CDC kurulamadığında güvenilir değişiklik tabloları veya kontrollü bir yazma duruşuyla son farkın aktarılması seçenek olabilir. Yalnızca updated_at alanını taramak; silmeleri, geriye tarihli düzeltmeleri veya aynı zaman damgasındaki kayıtları kaçırabilir. Kaynağın değişiklik sözleşmesi bilinmeden “son senkronizasyondan sonrasını al” yaklaşımına güvenilmez.

6. Şema ve API değişikliği: expand, migrate, contract

Yeni sürümün beklediği alanı ekleyip eski alanı aynı dağıtımda silmek, eski worker’ları ve raporları kırabilir. Expand–migrate–contract yaklaşımı önce uyumlu genişletme yapar, sonra veriyi ve tüketicileri taşır, son olarak kullanılmayan sözleşmeyi kaldırır. Parallel Change açıklaması bu ayrımı temellendirir.

Örneğin quantity alanı gerçekte farklı yerlerde “istenen” ve “rezerve edilen” anlamında kullanılıyorsa sadece yeniden adlandırılmaz. Yeni requested_quantity ve reserved_quantity alanları oluşturulur; her biri doğrulanmış kaynaktan doldurulur. Eski alanı okuyan raporların yeni anlamlara geçirilmesi izlenir. Geri dönüş penceresi kapanmadan eski alan ve dönüştürme kodu kaldırılmaz.

API’de de yeni alan eklemek bütün istemcilerin güvenle çalışacağını varsaydırmaz. Sıkı şema doğrulayan istemciler, enum değerleri ve hata yanıtları sözleşme testleriyle kontrol edilir. Stok hareketi oluşturan çağrılarda işlem anahtarı korunur; yeni endpoint aynı talebi yeniden geldi diye ikinci sevkiyata çevirmemelidir. Entegrasyon ayrıntıları için API ve sistem entegrasyonu rehberine bakabilirsiniz.

7. Mutabakat: kayıt sayısı eşitse iş doğru mu?

Hayır. Kaynakta ve hedefte 100.000 satır bulunması, aynı 100.000 iş olayını temsil ettikleri anlamına gelmez. SO-1842 yanlış depoya bağlanmışsa satır sayısı değişmez. Bir eksik rezervasyon ile bir fazla rezervasyon toplamı da tesadüfen dengeleyebilir.

Karşılaştırma aynı mantıksal kesitte yapılmalıdır: kaynakta seçilen log konumuna kadar tamamlanan işlemler ile hedefin aynı konuma kadar uyguladığı işlemler. Hareket hâlindeki kaynağı gecikmeli hedefle karşılaştırmak sahte farklar üretir. İlk yüklemenin bitmesi ile doğrulamanın bitmesi ayrı durumlardır; AWS DMS doğrulama belgeleri de taşınan ve doğrulanan kayıtları ayrı izler.

• Yapısal kontrol: Anahtar tekilliği, zorunlu alanlar, referans bütünlüğü ve kimlik eşleme kapsamı.
• Kayıt kontrolü: İş alanları bazında karşılaştırma; tarih, boş değer, ondalık hassasiyet ve sıralama için açık normalizasyon kuralları.
• İş kontrolü: Depo ve SKU bazında açık rezervasyonlar, sipariş bazında sevk edilen miktar ve belge bağlantıları.
• İstisna kontrolü: Karantinadaki, karşılaştırılamayan ve bilinçli dönüştürülen kayıtların ayrı sayılması; her birinin sahibi ve gerekçesi.
• Yan etki kontrolü: ERP’ye gönderilen hareketlerin hedef sistemde gerçekten bulunması ve mükerrer olmaması.

Örneğimizde SO-1842’nin önceki durumuyla 4 birimlik sevkiyat sonrası durumu aynı kesitte karşılaştırıldığında, fiziksel stok 16, açık rezervasyon 6, sevk edilen miktar 4 olmalıdır; kullanılabilir miktar 10 kalır. Bu hesap, negatif stok ve başka eşzamanlı hareket olmadığı varsayımıyla açıklayıcıdır. Gerçek mutabakat kendi stok politikanızı uygular.

8. Gölge çalışma ve pilot: iki kere işlem yapmak değildir

Shadow run sırasında yeni uygulama gerçek girdilerden karar hesaplar; dış dünyada işlem gerçekleştirme yetkisi yoktur. Sevkiyat etiketi basmaz, e-posta göndermez, ERP’ye hareket yazmaz. Yan etki üreten istemciler test adaptörüne bağlanır veya teknik olarak engellenir. “Operatör o düğmeye basmasın” bir izolasyon mekanizması değildir.

Karşılaştırmalar mutlu yolun dışına taşmalıdır: kısmi sevkiyat, iptal, aynı isteğin tekrarı, süresi dolmuş rezervasyon, ERP zaman aşımı, yetkisiz depo erişimi ve CDC tüketicisinin yeniden başlaması. Saat veya rastgele kimlik içeren çıktılar normalize edilir; iş açısından önemli farklar gizlenmez.

Pilot için örnek kapsam, bağımsız stok havuzu olan bir depodur. Yeni sistem o kapsamda otorite olurken diğer depolar eskide kalır. Aynı siparişin depolar arası taşınması pilot sınırını ihlal ediyorsa bu akış açıkça engellenir veya ayrıca tasarlanır. Rastgele kullanıcıların yüzde beşini yönlendirmek, paylaşılan stok için güvenli bir canary stratejisi sayılmaz.

9. Canlıya geçiş için uygulanabilir karar şablonu

Cutover, yalnızca bir dağıtım değildir; yazma otoritesinin devridir. Aşağıdaki JSON, örnek pilot için doldurulmuş bir karar kaydıdır. Çalıştırılabilir konfigürasyon veya evrensel eşik değildir. Ölçüler, operasyon sahibiyle kararlaştırılır ve geçiş provasında doğrulanır.

{
  "scope": "warehouse-W1-reservations-and-dispatch",
  "source_of_truth_before": "legacy",
  "source_of_truth_after": "new-system",
  "write_pause_budget_minutes": 15,
  "data_loss_target": "zero-acknowledged-business-operations",
  "required_checks": {
    "legacy_writers_fenced": true,
    "in_flight_commands_resolved": true,
    "target_applied_through_cutover_checkpoint": true,
    "critical_reconciliation_mismatches": 0,
    "unresolved_in_scope_quarantine_records": 0,
    "restore_rehearsal_passed": true
  },
  "decision_owner_role": "operations-lead",
  "after_new_writes": "freeze-and-reconcile-before-any-failback"
}

Önce pilot kapsamına yeni komut kabulü durdurulur; kullanıcıya bakım durumu bildirilir. Devam eden komutlar ve ERP’de sonucu belirsiz işlemler çözülür. Eski yazarlar kapatılır, son kaynak konumu kaydedilir ve hedefin bu konuma kadar uyguladığı doğrulanır. Son mutabakat ve yetki kontrolleri geçerse yeni yazma otoritesi açılır. Süre bütçesi aşılırsa karar sahibi geçişi durdurur; aceleyle kontrol atlanmaz.

“Sıfır veri kaybı hedefi”, bu örnekte kullanıcıya kabul edildiği bildirilen iş işlemlerinin korunmasıdır. Sadece tarayıcıda hazırlanmış, henüz gönderilmemiş taslak aynı sözleşmeye girmez. RPO kabul edilebilir veri kaybı aralığını, RTO kabul edilebilir toparlanma süresini ifade eder; migration yazma duruşu bütçesiyle aynı ölçü değildir. Yedek dosyasının varlığı bu hedefleri kanıtlamaz, geri yükleme ve mutabakat provası gerekir.

10. Geri dönüşün sınırı: yeni sistem veri yazdı mı?

Yeni sistem henüz hiçbir iş yazımı yapmadıysa ve eski veriler değişmediyse, eski yazarı yeniden açmak görece basittir. Yeni sistem SO-1842 için 4 birim sevkiyat kaydettiyse eski sistem artık geridedir. Trafiği geri çevirmek, o sevkiyatı ve ERP’deki etkisini geri almaz.

Bu noktada iki uygulanabilir yol vardır: yeni sistemi yerinde düzeltmek veya yazmayı durdurup yeni kayıtları eski modelin temsil edebileceği biçimde geri taşımak. İkinci yol için ters dönüşüm, olay sırası, işlem anahtarları ve dış sistem mutabakatı önceden denenmiş olmalıdır. Yeni modeldeki bir durum eskide temsil edilemiyorsa otomatik geri dönüş sınırı aşılmıştır.

ERP’ye gönderilmiş bir sevkiyatın teknik olarak tekrar oynatılması, fiziksel sevkiyatın tekrar yapılması demek olmamalıdır. Düzeltme gerekiyorsa iş sürecinin desteklediği iptal veya telafi kaydı kullanılır. Son yedeği geri yüklemek ise o yedekten sonra kabul edilen bütün işlemler için ayrıca yeniden oynatma planı gerektirir. Kod rollback’i, veri rollback’i ve iş etkisinin telafisi üç ayrı karardır.

11. Üretim takibi ve eski sistemi gerçekten kapatmak

İlk gün sadece CPU ve HTTP hata oranına bakmayın. Pilot kapsamına göre CDC gecikmesi, en eski bekleyen entegrasyon işi, çözümsüz mutabakat farkı, reddedilen eski-yazar denemesi ve tamamlanamayan sevkiyat sayısı izlenir. Geçiş sırasında eski süreçlerle aynı anda ay sonu raporu üretilebiliyor mu? Operatör bir hatayı doğrudan SQL düzeltmesi olmadan çözebiliyor mu?

Bir üretim panosunda teknik ve iş göstergeleri aynı kayıt kimliği üzerinden izlenebilir olmalıdır. Audit log; veri dönüşüm sürümünü, aktaran görevi, manuel istisna kararını ve sahiplik değişimini kaydeder. Kişisel veya hassas veriler uygulama loglarına topluca kopyalanmaz; geçiş dosyaları ve servis hesapları sınırlı yetkiyle tutulur.

Eski sistemin kapanış ölçütleri baştan yazılır: bağımlı tüketiciler taşınmış, gerekli raporlama dönemleri doğrulanmış, arşiv erişimi denenmiş, saklama gereksinimleri karşılanmış ve geri dönüş penceresi resmen kapanmış olmalıdır. Ardından eski görevler ve erişim anahtarları kaldırılır; artık ihtiyaç duyulmayan kopyalar saklama politikasına göre temizlenir. Her iki sistemi süresiz açık bırakmak teknik borcu ikiye katlayabilir.

Sık sorulan sorular

Eski yazılımı sıfırdan yazmak her zaman daha mı iyidir?

Hayır. Davranışı yeterince bilinmeyen büyük bir sistemi yeniden yazmak, görünmeyen iş kurallarını kaybetme riskini taşır. Küçük ve iyi sınırlandırılmış sistemde toplu değişim mantıklı olabilir. Karar; ayrıştırılabilirlik, doğrulanmış kurallar, veri hacmi, eski sistemi işletme riski ve geçiş kapasitesiyle verilir.

Gerçekten kesintisiz veri taşıma mümkün mü?

Bazı mimarilerde mümkündür; her sistem için garanti edilemez. CDC, doğrulanmış tekrar işleme ve yazma otoritesinin güvenli devri gerekir. Birçok operasyon için kısa ve planlı yazma duruşu, karmaşık çift yönlü senkronizasyondan daha yönetilebilir bir tercih olabilir. Kesintisiz erişim ile kesintisiz yazma aynı şey değildir.

Modernizasyon için mikroservis veya AI şart mı?

Hayır. Modüler bir uygulama ve ilişkisel veri tabanı ihtiyacı karşılayabilir. AI; kod envanteri veya belge sınıflandırması gibi yardımcı işlerde değerlendirilebilir, ancak stok doğruluğunu ve veri mutabakatını garanti eden mekanizma değildir. Geçişin kabul kararı deterministik kontroller ve sorumlu insanların onayıyla verilir.

Projenin süresi ve maliyeti nasıl belirlenir?

Ekran sayısından önce bağımlılık sayısı, veri kalitesi, entegrasyon sözleşmeleri, iş kurallarının belirsizliği ve geçiş provaları değerlendirilir. İlk keşfin çıktısı tek bir iyimser tarih değil; kapsam, varsayımlar, aşamalar, riskler ve kabul ölçütleri olmalıdır. Temsili bir yazıdan güvenilir proje fiyatı veya takvimi çıkarılamaz.

Modernizasyonun teslimatı yeni koddan daha büyüktür

TankDev açısından yazılım modernizasyonunun mühendislik çıktısı; hedef mimari kadar bağımlılık haritası, veri eşleme sözleşmesi, otomatik doğrulamalar, API uyumluluğu, geçiş planı ve işletilebilir bir toparlanma yoludur. Yeni sistem yalnızca çalışmamalı; hangi verinin otoritesi olduğu ve hata durumunda nasıl korunacağı da açık olmalıdır.

Yeni bir süreci ilk kez dijitalleştiriyorsanız iş sürecinden yazılıma dönüşüm rehberi, hedef sistemi tasarlıyorsanız kurumsal yazılım mimarisi yazısı tamamlayıcıdır. Çalışan bir sistemi yenilerken belirleyici soru şudur: Yeni sürümü açabiliyor muyuz değil, işin doğruluğunu koruyarak sorumluluğu devredebiliyor muyuz?