Kurumların Kendi Yazılım Platformlarını Kurabilmesi İçin Teknik Kılavuz

Giriş

Uzun yıllar boyunca kurumsal yazılım dünyası oldukça öngörülebilir bir model üzerine kuruluydu. Bir kurum ihtiyaç duyduğu sistemleri farklı üreticilerden satın alırdı. Örneğin;

• ERP bir yerden
• PDKS başka bir yerden
• Doküman yönetimi başka bir yerden
• IoT platformu başka bir yerden
• Varlık yönetimi başka bir yerden

Zaman içinde kurumların dijital yapısı onlarca farklı sistemden oluşan bir ekosisteme dönüştü. Bu sistemler çoğu zaman birbirinden bağımsız çalışıyor, entegrasyonlar sonradan ekleniyor ve her güncelleme yeni bir risk oluşturuyordu.

AI destekli yazılım geliştirme araçlarının ortaya çıkması bu dengeyi değiştirmeye başladı. Bugün kurumlar için yeni bir soru ortaya çıkıyor:

Kurumlar artık kendi dijital servislerini geliştirebilir mi?

Cevap çoğu durumda evet. Ancak bu yalnızca "AI ile kod yazmak" anlamına gelmez. Kurumların sürdürülebilir bir geliştirme kapasitesi oluşturabilmesi için belirli bir platform mimarisi, SDLC disiplini ve operasyon modeli kurması gerekir.

Bu makale bu yapının nasıl kurulabileceğine dair teknik bir rehber sunmayı amaçlar.

1. Platform Yaklaşımı

Kurum içi yazılım geliştirme "tek tek uygulama geliştirmek" olarak düşünülmemelidir.

Doğru yaklaşım bir Kurumsal Dijital Platform kurmaktır. Bu platform üzerinde farklı dijital servisler geliştirilebilir:

• GRC sistemleri
• İş süreçleri platformları
• Varlık yönetimi
• IoT uygulamaları
• Sürdürülebilirlik sistemleri
• Operasyonel uygulamalar

Platform yaklaşımı şu avantajları sağlar:

• Ortak kimlik yönetimi
• Standart entegrasyon modeli
• Tekrar kullanılabilir servisler
• Merkezi gözlemlenebilirlik
• Sürdürülebilir mimari

Kurumsal Identity Platform Tasarımı

Kurumsal dijital platformların en kritik bileşenlerinden biri identity platformudur. Çoğu kurumda kullanıcı bilgileri farklı sistemlerde ve farklı kimlik kaynaklarında dağınık halde bulunur.

Örneğin:

• Birden fazla Active Directory domain
• HR sistemleri
• Öğrenci veya eğitim sistemleri
• Uygulamaya özel kullanıcı kayıtları
• Merkezi kimliği olmayan çalışanlar (örneğin mavi yaka)

Bu nedenle kurumsal platformun identity sistemi yalnızca bir authentication servisi olmamalıdır. Aynı zamanda kurumun dijital kimlik grafiğini tutan bir servis olmalıdır.

Identity Platformunun Temel Sorumlulukları

Bir kurumsal identity platformu aşağıdaki sorumlulukları üstlenmelidir:

• Authentication (kimlik doğrulama)
• Authorization (yetkilendirme)
• Kullanıcı yaşam döngüsü yönetimi
• Rol ve yetki yönetimi
• Delegasyon (vekalet)
• Audit ve erişim kayıtları

Çoklu Kimlik Kaynakları

Kurumsal platformlar genellikle birden fazla kimlik kaynağı ile çalışmak zorundadır. Örnek kaynaklar:

• Active Directory / LDAP
• HR sistemleri
• Uygulama içi kullanıcı kayıtları

Identity platformu bu kaynaklardan veri toplayabilmeli ve gerektiğinde kendi kullanıcılarını oluşturabilmelidir.

Organizasyon Grafı

Bir kullanıcı kimliği yalnızca bir kullanıcı adı değildir. Kurumsal bağlamda her kullanıcı bir organizasyon yapısının parçasıdır. Identity platformu şu bilgileri ilişkilendirebilmelidir:

• Kullanıcı
• Organizasyon
• Departman
• Pozisyon
• Rol

Bu sayede platform şu sorulara cevap verebilir:

• Bu kullanıcı kimdir
• Hangi organizasyonda çalışır
• Hangi rollerle işlem yapabilir

Rol ve Delegasyon Modeli

Kurumsal platformlarda kullanıcılar tek bir rol ile sınırlı değildir.

Bir kullanıcı:

• Birden fazla rol üstlenebilir
• Geçici vekalet alabilir
• Belirli sürelerle farklı yetkilerle işlem yapabilir

Identity platformu bu tür dinamik rol değişimlerini desteklemelidir.

Tenant Farkındalığı

Kurumsal platformlar çoğu zaman çoklu organizasyon yapıları içerir.

Örneğin:

• Ana kurum
• Bağlı iştirakler
• Farklı organizasyon birimleri

Identity platformu bu yapıyı tenant bazında modelleyebilmelidir.

İnsan ve Dijital Varlıklar Servisi

Kurumsal dijital platformlarda çoğu zaman "kullanıcı" kavramı gereğinden fazla dar tanımlanır. Oysa platform içindeki birçok süreç yalnızca sistem hesaplarını değil, insanları ve dijital varlıkları hedef alır.

Örneğin:

• Bir çalışana e‑posta gönderilir
• Bir kişiye SMS ile bilgilendirme yapılır
• Bir kioska "bu adreste elektrik kesilecek" mesajı iletilir
• Bir IoT cihazına durum bilgisi gönderilir

Bu nedenle platform mimarisinde yalnızca "account" veya "user" kavramı yeterli değildir. Platformun insanları ve dijital hedefleri birlikte modelleyebilen bir servis içermesi gerekir.

Temel Kavramlar

Bu modelde iki ana varlık bulunur:

İnsan

Gerçek dünyadaki bireyi temsil eder. Örnek bilgiler:

• Ad / soyad
• İletişim bilgileri
• Organizasyon ilişkileri

İnsan her zaman bir sistem hesabına sahip olmak zorunda değildir.

Dijital Varlık

Platform tarafından hedef alınabilen dijital bir varlığı temsil eder.

Örnekler:

• Kiosk
• IoT cihazı
• Bilgilendirme sistemi
• Robot veya makine
• Uygulama endpointi

Bu varlıkların her biri bir adreslenebilir hedef olabilir.

Neden Ayrı Bir Servis?

Kurumsal süreçlerin çoğu "account" üzerinden değil hedef varlıklar üzerinden çalışır.

Örneğin:

• Bir çalışan bilgilendirilebilir
• Bir departman ekranına duyuru gönderilebilir
• Bir kioska uyarı iletilebilir

Bu nedenle platform şu soruları cevaplayabilmelidir:

• Bu mesaj kime gidecek?
• Bu bildirim hangi dijital varlığa iletilecek?

Identity ile İlişkisi

Identity platformu hesapları (account) ve erişim yetkilerini yönetir.

İnsan ve Dijital Varlıklar servisi ise sistemde yer alan aktörleri tanımlar. Bu aktörler bazen bir account sahibi olabilir, bazen de yalnızca sistemin hedef aldığı bir varlık olabilir. Bu modelde önemli olan nokta şudur:

• Bir insan bir veya daha fazla account sahibi olabilir.
• Bir insanın hiç accountu olmayabilir ancak süreçlerde hedef alınabilir.
• Bir dijital varlık (örneğin kiosk veya cihaz) bir account sahibi olabilir.

Örneğin:

• Bir kiosk içerdeki bir servise çağrı yaparak "bir kullanıcı harita istedi" bilgisini iletebilir.
• Bir insan belirli bir serviste yapılacak bir işi gerçekleştirmek üzere görevlendirilebilir.

Bu durumda servislerle etkileşime giren şey doğrudan account değil, insan veya dijital varlığın kendisi olabilir.

Dolayısıyla mimari model şu şekilde düşünülebilir:

• İnsan / Dijital Varlık → sistemdeki aktör
• Account → bu aktörün sistemlerde işlem yapabilen kimliği

Bir aktörün birden fazla accountu olabilir veya hiç accountu olmayabilir. Bu ayrım platformun gerçek dünyadaki süreçleri daha doğru modellemesini sağlar.

2. Kurumsal Dijital Platformun Temel Servisleri

Kendi yazılım platformunu kurmak isteyen kurumların belirli fundamental servisleri oluşturması gerekir.

2.1 Identity & Access Platform

Tüm uygulamaların ortak kimlik ve yetki altyapısıdır. Bu servis aşağıdaki fonksiyonları sağlamalıdır:

• Merkezi authentication
• SSO
• Rol ve yetki yönetimi
• Delegasyon (vekalet)
• Kullanıcı yaşam döngüsü
• Audit

Birçok kurumda kullanıcı bilgileri farklı Active Directory domainlerinde bulunabilir. Ayrıca bazı kullanıcıların hiç merkezi kimlik kaynağı olmayabilir (örneğin mavi yaka çalışanlar).

Bu nedenle IAM sistemi farklı kaynaklardan veri toplayabilmeli ve gerekirse kendi kullanıcılarını oluşturabilmelidir.

2.2 Organization & Tenant Model

Kurumsal platformun merkezinde organizasyon modeli bulunmalıdır.

Bu model şu kavramları içermelidir:

• Tenant
• Organizasyon
• Departmanlar
• Pozisyonlar
• Çalışan ilişkileri

Bir kullanıcı için şu soruların cevaplanabilmesi gerekir:

• Kimdir
• Hangi organizasyonda çalışır
• Hangi rolü vardır
• Hangi uygulamalara erişebilir

2.3 Contract Registry

Kurumsal platformlarda uygulamalar birbirlerini doğrudan bilmemelidir.

Servisler arası iletişim kontratlar üzerinden tanımlanmalıdır. Contract registry aşağıdaki bilgileri tutmalıdır:

• API kontratları
• Event şemaları
• Kontrat versiyonları
• Kontrat sahipliği

Bu yaklaşım servislerin birbirinden bağımsız gelişebilmesini sağlar.

2.4 Event Bus

Servisler arası iletişimin önemli bir kısmı event-driven olmalıdır.

Örnek eventler:

• Employee.updated
• Organization.changed
• Asset.created
• Workflow.completed

Event-driven mimari servisler arasında gevşek bağlılık sağlar.

2.5 Application Registry

Platformdaki tüm uygulamaların merkezi katalogudur. Her uygulama için şu bilgiler tutulmalıdır:

• Uygulama sahibi
• Hangi kontratları yayınlıyor
• Hangi kontratları tüketiyor
• Hangi tenantlarda aktif

2.6 Observability Platform

Operasyonel güvenilirlik için güçlü bir gözlemlenebilirlik altyapısı gerekir.

Temel bileşenler:

• Merkezi loglama
• Metrikler
• Distributed tracing
• Alarm sistemleri

Bu altyapı olmadan büyük sistemleri troubleshoot etmek neredeyse imkansızdır.

Kurumsal Dijital Platform Referans Mimarisi

Kendi dijital servislerini geliştirmek isteyen kurumlar için en kritik konulardan biri platform mimarisinin doğru kurulmasıdır. Aşağıdaki yapı pratikte birçok kurum için çalışabilir bir referans model sunar.

Platform Katmanları

Bir kurumsal dijital platform genellikle aşağıdaki katmanlardan oluşur:

1. Identity Platform

Tüm sistemlerin kimlik ve yetkilendirme merkezi.

• Authentication
• Authorization
• Kullanıcı yaşam döngüsü
• Rol ve delegasyon yönetimi

2. Organization & Tenant Graph

Kurumun dijital organizasyon modelini tutar.

• Tenant yapısı
• Organizasyon birimleri
• Pozisyonlar
• Çalışan ilişkileri

Bu model tüm uygulamalar tarafından referans alınmalıdır.

3. Contract Registry

Servislerin birbirleriyle nasıl konuştuğunu tanımlar.

• API kontratları
• Event şemaları
• Kontrat versiyonları

Servisler birbirlerini doğrudan değil kontratlar üzerinden tanır.

4. Event Bus

Servisler arası asenkron iletişimi sağlar. Örnek olaylar:

• Employee.updated
• Asset.created
• Workflow.completed

Bu yapı servisler arasında gevşek bağlılık sağlar.

5. Service Layer

Kurumsal iş servislerinin bulunduğu katmandır. Örnek servisler:

• Varlık yönetimi
• İş süreçleri
• Sürdürülebilirlik
• IoT veri toplama

Bu servisler mümkün olduğunca bağımsız geliştirilmelidir.

6. Data Layer

Her servis kendi veri modeline sahip olmalıdır.

Temel prensip:

Veri sahipliği servise aittir.

Servisler mümkün olduğunca başka servislerin veritabanına doğrudan erişmemelidir.

7. Observability Layer

Tüm platformun gözlemlenebilirliğini sağlar.

• Log toplama
• Metrikler
• Distributed tracing

Bu katman büyük sistemlerde troubleshooting için kritik öneme sahiptir.

Önerilen Teknoloji Stack'i

Her kurum kendi teknoloji tercihlerini yapabilir. Ancak pratikte birçok platform aşağıdaki türde bileşenler kullanır:

• Containerization: Docker
• Orchestration: Docker Swarm veya Kubernetes
• Event Bus: Kafka, NATS veya benzeri mesajlaşma sistemleri
• Contract Definition: OpenAPI / AsyncAPI
• Observability: Prometheus, Grafana, Loki, Jaeger

Bu teknolojiler bir zorunluluk değildir ancak platform kurarken sık kullanılan bileşenlerdir.

3. Servis Mimarisi

Kurumsal platformların tamamı mikroservis olmak zorunda değildir. Çoğu kurum için başlangıç noktası modüler monolith olabilir. Bu yaklaşımın avantajları:

• Operasyonel basitlik
• Transaction yönetimi kolaylığı
• Hızlı geliştirme

Sistem büyüdükçe belirli modüller ayrı servislere ayrılabilir. Mikroservis mimarisi şu durumlarda anlamlı hale gelir:

• Farklı ekipler aynı sistem üzerinde çalışıyorsa
• Bağımsız ölçekleme gerekiyorsa
• Domain sınırları netleşmişse

Contract-Driven Architecture

Kurumsal platform mimarisinde servisler arası bağımlılığı azaltmanın en etkili yollarından biri contract-driven architecture yaklaşımıdır.

Bu yaklaşımın temel prensibi şudur:

Servisler birbirlerini doğrudan bilmez. Birbirlerini kontratlar üzerinden tanırlar.

Bir servisin başka bir servisle ilişki kurabilmesi için şu bilgilerin açıkça tanımlanması gerekir:

• Hangi API'leri sunuyor
• Hangi eventleri yayınlıyor
• Hangi kontratları tüketiyor

Bu bilgiler merkezi bir Contract Registry içinde tutulabilir.

API Kontratları

Servislerin sunduğu API'ler açık bir kontrat ile tanımlanmalıdır. Bu kontratlar şu bilgileri içerir:

• Endpoint tanımları
• Request / response şemaları
• Hata kodları

OpenAPI bu tür kontratlar için yaygın kullanılan bir standarttır.

Event Kontratları

Event-driven mimaride yayınlanan olayların da açık bir şeması olmalıdır.

Örnek:

employee.updated

Bu event aşağıdaki bilgileri içerebilir:

• employeeId
• organizationId
• updatedFields

AsyncAPI bu tür event kontratları için kullanılabilir.

Versiyon Yönetimi

Kontratların versiyonlanması kritik öneme sahiptir.

Temel prensipler:

• Backward compatibility korunmalıdır
• Eski kontratlar belirli süre desteklenmelidir

Bu yaklaşım platformdaki servislerin bağımsız gelişebilmesini sağlar.

4. Veri ve Transaction Yönetimi

AI ile geliştirilen sistemlere yönelik en sık eleştirilerden biri şudur:

"Transaction yönetimi doğru yapılmazsa sistem patlar."

Bu eleştiri doğrudur ancak sorun AI değildir. Transaction tasarımı mimari bir konudur.

Temel prensipler:

• Veri sahipliği net olmalıdır
• Transaction sınırları belirlenmelidir
• Servisler arası transactionlardan kaçınılmalıdır

Gerekli durumlarda event-driven eventual consistency kullanılabilir.

5. Container ve Deployment Stratejisi

Modern kurumsal platformların çoğu container tabanlı çalışır.

Docker

Servislerin paketlenmesi için standart yöntemdir.

Docker Swarm

Küçük ve orta ölçekli platformlar için oldukça yeterlidir.

Avantajları:

• Kurulum kolaylığı
• Düşük operasyonel karmaşıklık

Kubernetes

Daha büyük ölçekli platformlar için tercih edilir. Ancak operasyonel karmaşıklığı daha yüksektir. Birçok kurum için başlangıç noktası Docker Swarm olabilir.

6. Service Mesh Gerekli mi?

Service mesh çoğu zaman erken aşamada gereksiz karmaşıklık yaratır.

Service mesh şu durumlarda anlamlıdır:

• Çok sayıda mikroservis varsa
• Trafik yönetimi karmaşıksa
• Güvenlik politikaları merkezi yönetilmek isteniyorsa

Başlangıç aşamasında API gateway ve event bus çoğu ihtiyacı karşılar.

7. SDLC

Kurumsal geliştirme süreçleri güçlü bir SDLC disiplini gerektirir. Temel aşamalar:

1. Tasarım
2. Kontrat tanımı
3. Geliştirme
4. Test
5. Deployment
6. Operasyon

AI destekli geliştirme bu süreci hızlandırabilir ancak bu süreçlerin yerine geçmez.

8. DevOps ve CI/CD

Modern platformlar sürekli teslimat prensipleri ile çalışmalıdır.

Temel bileşenler:

• Otomatik build
• Otomatik test
• Container registry
• Otomatik deployment

9. AI Agent Destekli Geliştirme

AI ajanları geliştirme süreçlerinde farklı roller üstlenebilir:

• Mimari analiz
• Kod üretimi
• Test üretimi
• Güvenlik analizi
• Performans analizi

Bu model küçük ekiplerin üretim kapasitesini dramatik şekilde artırabilir.

10. Ölçeklenebilirlik Tartışması

AI ile geliştirilen sistemlerin ölçeklenemeyeceği sıkça dile getirilen bir eleştiridir.

Gerçekte ölçeklenebilirliği belirleyen faktörler şunlardır:

• Doğru veri modeli
• Doğru servis sınırları
• Doğru cache stratejisi
• Doğru observability

Bu prensipler uygulandığında AI destekli geliştirilmiş sistemler de yüksek yük altında çalışabilir.

AI-Native Development Organization

AI destekli geliştirme yalnızca araçların değişmesi anlamına gelmez. Aynı zamanda yazılım geliştirme organizasyonunun yapısını da değiştirir.

Geleneksel yazılım ekipleri genellikle sabit rollerden oluşur:

• Geliştiriciler
• Test mühendisleri
• Mimarlar
• Operasyon ekipleri

AI çağında bu yapı daha esnek bir modele evrilebilir.

İnsan + AI Hibrit Ekipler

Birçok projede üretken bir geliştirme kapasitesi için büyük ekipler gerekmeyebilir. Bunun yerine küçük bir çekirdek ekip yeterli olabilir:

• Bir insan mimar veya kıdemli geliştirici
• Bir veya daha fazla AI kod üretim ajanı
• Süreçleri ve kaliteyi izleyen AI ajanları

Farklı AI sağlayıcılarından ajanlar aynı projede birlikte çalışabilir.

AI Rollerinin Uzmanlaşması

Zaman içinde AI ajanları belirli konularda uzmanlaşabilir.

Örneğin bir projede şu tür ajanlar bulunabilir:

• Mimari analiz yapan AI
• Veri modeli inceleyen AI
• Güvenlik kontrolü yapan AI
• Performans analizi yapan AI
• Test senaryoları üreten AI

Bu tür uzmanlıklar çoğu kurum için insan kaynağı olarak bulması zor olan yetkinliklerdir.

Stateless Geliştirme Ortamı

AI-native organizasyonlarda önemli bir prensip şudur:

Projede çalışan herhangi biri için bugün ilk gün olabilir.

Bu kişi:

• Projeye yeni katılmış bir geliştirici olabilir
• Başka bir ekipten geçici olarak gelmiş olabilir
• Bir AI ajanı olabilir

Bu nedenle proje bilgisi bireylerin hafızasında değil sistem artefaktlarında tutulmalıdır.

Bu artefaktlar şunları içerir:

• Mimari dokümanlar
• Servis kontratları
• Domain modelleri
• Test senaryoları

Agent Orchestration

Gelecekte geliştirme süreçlerinde AI ajanlarının birbirleriyle iletişim kurarak iş paylaşması daha yaygın hale gelebilir.

Bir ajan:

• Bir kontrat değişikliğini analiz edebilir
• Başka bir ajana test üretmesini isteyebilir
• Başka bir ajandan performans analizi talep edebilir

Bu model yazılım geliştirmeyi tek bir geliştiricinin bireysel üretimi olmaktan çıkarıp çok aktörlü bir sistem haline getirebilir.

Workflow ve Task Platformu

Kurumsal dijital platformlarda sıklıkla tekrar edilen bir problem vardır: Her uygulama kendi workflow motorunu geliştirmeye başlar.

Sonuç genellikle aynıdır:

• Her uygulamada farklı bir workflow modeli
• Birbirinden kopuk görev yönetimi
• Merkezi görünürlüğün olmaması

Bugün piyasadaki birçok konvansiyonel kurumsal yazılım da bu soruna farklı bir şekilde yaklaşmaktadır. Birçok üretici artık uygulamanın içine no‑code workflow araçları eklemektedir. Bunun temel nedeni çoğu zaman mimari bir tercih değil, mevcut uygulamanın kod tabanını değiştirmeden süreçleri uyarlayabilmektir.

Ancak bu yaklaşım uzun vadede yeni bir probleme yol açar:

Kurum içinde onlarca farklı workflow motoru oluşur.

Bu nedenle kurumsal dijital platformlarda workflow yeteneği uygulama içinde değil platform seviyesinde ele alınmalıdır.

Workflow Platformunun Rolü

Workflow platformu kurumsal süreçlerin yürütülmesini sağlar.

Temel fonksiyonları şunlardır:

• Süreç tanımı
• Görev oluşturma
• Görev atama
• Süreç durum takibi
• Otomasyon adımları

Bu platform hem insanlara hem de servislere görev atayabilmelidir.

Aktör Bazlı Görev Atama

Daha önce tanımlanan modelde platformdaki aktörler şunlardır:

• İnsan
• Dijital Varlık
• Servis

Workflow motoru görevleri bu aktörlere atayabilmelidir.

Örnekler:

• Bir insan bir belgeyi onaylamakla görevlendirilebilir
• Bir servis belirli bir veri işleme görevini gerçekleştirebilir
• Bir cihaz belirli bir durumu raporlamakla görevlendirilebilir

Bu yaklaşım süreçlerin yalnızca insan merkezli değil platform merkezli çalışmasını sağlar.

Süreçlerin Servislerle Entegrasyonu

Workflow platformu servislerle kontratlar üzerinden konuşmalıdır.

Örneğin bir süreç şu adımları içerebilir:

1. Bir servis veri üretir
2. Workflow yeni bir görev oluşturur
3. Görev bir insana atanır
4. İnsan işlemi tamamlar
5. Workflow başka bir servisi tetikler

Bu yapı servisler, insanlar ve dijital varlıklar arasında koordinasyon sağlar.

Neden Platform Seviyesinde?

Workflow yeteneği platform seviyesinde sunulduğunda şu avantajlar ortaya çıkar:

• Tüm süreçler tek yerden izlenebilir
• Görev yönetimi standart hale gelir
• Uygulamalar workflow motoru geliştirmek zorunda kalmaz

Kurum içinde onlarca farklı workflow uygulaması yerine tek bir güçlü workflow platformu oluşur.

Contract Governance ve Workflow Stabilitesi

Kurumsal platformlarda sık karşılaşılan kritik bir problem şudur: Bir servisin kontratı değiştiğinde ona bağlı workflow'ların kırılmaması gerekir. Platform büyüdükçe servisler, workflow'lar ve entegrasyonlar arasındaki ilişki ağı çok karmaşık hale gelir.

Bu nedenle kurumsal platformlarda contract governance (kontrat yönetişimi) mimarinin temel parçalarından biri olmalıdır.

Servis Kontratı ile Workflow Kontratı Ayrımı

Bir workflow doğrudan bir servisin API şemasına bağlanmamalıdır. Bunun yerine servis kontratı ile workflow arasında bir domain kontrat katmanı bulunmalıdır.

Önerilen katman yapısı:

Service Contract → Integration Adapter → Domain Contract → Workflow

Servis tarafında bir alanın anlamı değişse bile adapter katmanı gerekli dönüşümü yaparak workflow'un stabil kalmasını sağlar.

Canonical Domain Model

Kurumsal platformlarda workflow'ların servis şemalarına değil, platformun canonical domain modeline bağlanması önerilir.

Örnek domain kavramları:

• Employee
• Asset
• Organization
• WorkflowTask
• NotificationTarget

Servisler kendi veri modellerine sahip olabilir ancak workflow'lar bu canonical model üzerinden çalışır.

Versiyonlama ve Geriye Dönük Uyumluluk

Kontratların versiyonlanması zorunludur.

Örnek:

employee.updated.v1 employee.updated.v2

Temel prensip:

• Mevcut kontrat kırılmaz
• Breaking change yeni versiyon oluşturur
• Eski versiyonlar belirli süre desteklenir

Bu sayede eski workflow'lar çalışmaya devam eder.

Impact Analysis

Contract registry yalnızca kontrat şemalarını saklayan bir depo olmamalıdır. Aynı zamanda kontrat tüketicilerini de bilmelidir.

Örnek:

Contract: employee.updated.v1 consumers:

• workflow.leaveApproval
• notification.employee
• analytics.pipeline

Bir kontratta değişiklik yapılmadan önce etki analizi (impact analysis) yapılabilir.

Dynamic Workflow Sistemleri

n8n gibi dinamik workflow araçları kullanıldığında kontrat yönetimi daha da önem kazanır. Bu tür sistemlerde workflow node'larının servis API'lerine doğrudan bağlanması kırılgan mimarilere yol açar.

Bu nedenle önerilen yaklaşım:

• Workflow node'larının platform kontratlarına bağlanması
• Servis değişimlerinin adapter veya mediation katmanında çözülmesi

Contract Mediation Katmanı

Büyük platformlarda servis kontratları ile platform kontratları arasında bir contract mediation katmanı bulunabilir.

Bu katmanın görevleri:

• Schema doğrulama
• Versiyon yönlendirme
• Payload dönüşümü
• Backward compatibility

Bu yaklaşım platform büyüdükçe servislerin bağımsız evrim geçirmesine olanak tanır.

Kurumsal Dijital Platformun Minimum Çekirdeği

Birçok kurum kendi dijital platformunu kurmak istediğinde en büyük soru şudur:

Nereden başlamalıyız?

Kurumsal platformlar zaman içinde büyür ve olgunlaşır. Ancak başlangıç için tüm bileşenleri aynı anda kurmak gerekmez. Çoğu kurum için aşağıdaki minimum çekirdek platform yeterli bir başlangıç noktası oluşturur.

1. Identity Platform

Tüm sistemlerin ortak kimlik doğrulama ve yetkilendirme altyapısı.

Bu servis olmadan platform parçalanır.

2. İnsan ve Dijital Varlıklar Servisi

Platformun hedef alabileceği aktörleri tanımlar:

• İnsanlar
• Kiosklar
• Cihazlar
• Ekran sistemleri

Bu servis gerçek dünyadaki aktörleri dijital platformla ilişkilendirir.

3. Contract Registry

Servislerin birbirleriyle nasıl konuşacağını tanımlar.

• API kontratları
• Event şemaları
• Kontrat versiyonları

Bu servis platformun entegrasyon düzenini belirler.

4. Event Bus

Servisler arası asenkron iletişimi sağlar. Bu yapı servisler arasında gevşek bağlılık oluşturur.

5. Workflow Platformu

Kurumsal süreçlerin yürütülmesini sağlar.

Görevler:

• İnsanlara
• Servislere
• Dijital varlıklara

atanabilir.

6. Observability Platformu

Platformun sağlığını izlemek için gereklidir.

• Loglar
• Metrikler
• Tracing

Bu altyapı olmadan büyük sistemleri işletmek mümkün değildir.

Başlangıç İçin Önerilen Yol

Bir kurum bu platformu kurmaya aşağıdaki sırayla başlayabilir:

1. Identity Platform
2. İnsan ve Dijital Varlıklar Servisi
3. Contract Registry
4. Event Bus
5. Workflow Platformu
6. Observability

Bu çekirdek oluşturulduktan sonra diğer servisler zaman içinde platforma eklenebilir.

Kurumsal Platform Kurarken Yapılan 10 Büyük Hata

Kurumsal dijital platformlar kurmaya çalışan birçok organizasyon benzer hataları tekrar eder. Bu hatalar genellikle teknik eksikliklerden değil, mimari yaklaşımın eksik tanımlanmasından kaynaklanır.

1. Her Uygulamaya Ayrı Workflow Motoru Eklemek

Uygulama üreticileri çoğu zaman kendi workflow motorlarını geliştirir veya uygulamanın içine no‑code araçlar ekler. Bu yaklaşım kısa vadede pratik görünse de kurum içinde onlarca farklı workflow sistemi oluşmasına neden olur.

2. API Yerine Veritabanı Entegrasyonu Kullanmak

Sistemler doğrudan veritabanları üzerinden entegre edildiğinde bağımlılıklar artar. Bir veritabanı şemasındaki küçük bir değişiklik bile birçok sistemi etkileyebilir.

3. Contract Versioning Kullanmamak

Kontrat versiyonlama yapılmadığında servis değişiklikleri workflow'ları ve diğer sistemleri kırabilir. Breaking change her zaman yeni bir versiyon olarak yayınlanmalıdır.

4. Canonical Domain Model Tanımlamamak

Servislerin veri modelleri doğrudan diğer sistemler tarafından kullanıldığında platform zamanla kontrolsüz bir entegrasyon ağına dönüşür. Workflow'lar ve entegrasyonlar platformun canonical domain modeline bağlanmalıdır.

5. Çok Erken Microservice Mimarisine Geçmek

Birçok kurum daha ilk günden mikroservis mimarisine geçmeye çalışır. Çoğu durumda modüler bir monolith ile başlamak daha sağlıklı bir yaklaşımdır.

6. Observability Altyapısını Kurmamak

Log, metrik ve tracing altyapısı olmadan büyük sistemleri işletmek ve sorunları teşhis etmek çok zor hale gelir.

7. Identity Platformunu Platformun Merkezine Koymamak

Kimlik ve yetki yönetimi merkezi bir servis olarak tasarlanmazsa uygulamalar kendi kullanıcı yönetimlerini oluşturmaya başlar ve sistem hızla parçalanır.

8. İnsan ve Dijital Varlıkları Ayrı Modellememek

Kullanıcı, insan, cihaz ve account kavramlarını tek bir modelde birleştirmek birçok süreçte karmaşaya yol açar. İnsanlar ve dijital varlıklar platformun temel aktörleri olarak ayrı modellenmelidir.

9. Contract Governance Mekanizması Kurmamak

Contract registry yalnızca şema saklayan bir depo değil, aynı zamanda tüketicileri bilen ve değişikliklerde etki analizi yapabilen bir yönetişim mekanizması olmalıdır.

10. Platformu Sadece Teknoloji Projesi Olarak Görmek

Kurumsal dijital platformlar yalnızca teknik mimari değildir. Organizasyon yapısı, SDLC süreçleri ve geliştirme kültürü de bu platformun parçasıdır.

Bu hatalardan kaçınmak platformun uzun vadede sürdürülebilir olmasını sağlar.

AI Çağında Kurumsal Yazılım Geliştirme Gerçekten Mümkün mü?

Bu makalede anlatılan mimari ilk bakışta birçok kuruma oldukça karmaşık ve hatta gerçekçi olmayan bir hedef gibi görünebilir.

Bugün birçok organizasyonda mevcut durum çok daha parçalıdır:

• Bir Active Directory veya benzeri bir kimlik sistemi vardır
• Workflow ayrı bir ürün olarak satın alınmıştır
• Farklı uygulamalar birbirleriyle sınırlı entegrasyonlara sahiptir
• Sistemler arasında açıkça tanımlanmış kontratlar çoğu zaman bulunmaz

Bu nedenle burada anlatılan platform yaklaşımı başlangıçta "fazla ideal" veya "fazla büyük" bir hedef gibi algılanabilir.

Ancak dikkat edilmesi gereken nokta şudur: Kurumlar zaten bugün bu karmaşıklığın içinde yaşamaktadır. Sadece bu karmaşıklık çoğu zaman tasarlanmış bir mimari olarak değil, yıllar içinde oluşmuş bir yamalı yapı olarak ortaya çıkar.

AI destekli geliştirme araçları küçük ekiplerin üretim kapasitesini dramatik şekilde artırmaktadır. Bu durum geçmişte yalnızca büyük yazılım şirketlerinin kurabildiği mimari yapıların artık kurum içinde de kurulabilmesini mümkün hale getirmektedir.

Bu, kolay bir dönüşüm değildir. Ancak artık teknik olarak mümkündür.

Kurumlar tüm bu platformu tek bir projede kurmak zorunda değildir. Çoğu durumda bu dönüşüm aşağıdaki şekilde ilerler:

1. Kimlik altyapısı merkezi hale getirilir
2. Kontratlar tanımlanmaya başlanır
3. Servisler event tabanlı iletişim kurmaya başlar
4. Workflow platformu merkezi hale gelir

Zaman içinde parçalı sistemler yerini daha tutarlı bir platform mimarisine bırakır.

AI çağında asıl değişen şey şudur:

Kurumlar artık yalnızca yazılım tüketicisi olmak zorunda değildir.

Doğru mimari yaklaşım, güçlü bir SDLC disiplini ve AI destekli geliştirme araçları ile kurumlar kendi dijital platformlarını inşa edebilir.

Sonuç

AI çağında kurumlar yalnızca yazılım satın alan organizasyonlar olmak zorunda değil.

Doğru mimari, doğru platform servisleri ve güçlü bir SDLC disiplini ile kurumlar kendi dijital servislerini geliştirebilir.

Bu dönüşüm yalnızca teknolojik değil aynı zamanda organizasyonel bir dönüşüm.

Ve bu dönüşüm çoktan başladı ve hıza devam ediyor.