Skip to main content

> sosyoteknik_mimari:_conway_yasası,_ters_conway_manevrası_ve_takım_topolojileri_(team_topologies)

Sosyoteknik Mimari: Conway Yasası, Ters Conway Manevrası ve Takım Topolojileri (Team Topologies)

Fonksiyonel silolara bölünmüş ekiplerle bağımsız mikroservisler yazmaya çalışmak neden kesinlikle başarısızlığa mahkumdur; Ters Conway Manevrası organizasyon şemasını yazılım mimarisine nasıl hizalar?

Principal/Architect (L7+)

⚡ÖZET VE TEKNİK CEVAP

1967 yılında Melvin Conway yazılım sosyolojisinin en ünlü kuralını formüle etti—Conway Yasası: 'Sistem tasarlayan organizasyonlar, kaçınılmaz olarak kendi iç iletişim yapılarının bir kopyası olan yazılım mimarileri üretirler'. Eğer şirkette ayrı bir Frontend ekibi, ayrı bir Backend ekibi ve ayrı bir Veritabanı ekibi varsa, yazılımınız kaçınılmaz olarak takımlar arası bürokrasiye boğulmuş 3 katmanlı sıkı sıkıya bağlı bir monolite dönüşür. Ekiplerinizi yeniden yapılandırmadan 20 tane mikroservis yazmaya kalkarsanız, bu servisler birbirine bağımlı hale gelir ve ortaya Dağıtık Monolit (Distributed Monolith) felaketi çıkar. Ters Conway Manevrası (Reverse Conway Maneuver / Team Topologies) bu denklemi tersine çevirir: Ekiplerinizi, sahip olmak istediğiniz ideal yazılım mimarisine göre bilinçli olarak yeniden dizayn edin:
1
Akış Hizalı Ekipler (Stream-Aligned): Bir iş alanını (Bounded Context) uçtan uca yöneten tam yetkili çapraz fonksiyonel takımlar.
2
Platform Ekipleri: Geliştiricilere self-servis bulut ve CI/CD altyapısı sunan iç ürün takımları.
3
Karmaşık Alt Sistem Ekipleri: Özel matematik ve kripto uzmanları.
4
Yetkinleştirici Ekipler (Enabling): Takımlara yeni teknolojileri öğreten koçlar.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma
Team Topologies organizasyonel hizalaması 4 temel takım türü ve 3 etkileşim modeliyle çalışır:
1
Takım Türleri: Akış Hizalı (kullanıcı yolculuğunu yönetir), Platform (bilişsel yükü azaltmak için iç geliştirici platformu kurar), Karmaşık Alt Sistem (derin matematik/algoritmaları yönetir) ve Yetkinleştirici (geçici eğitim ve koçluk verir).
2
Etkileşim Modelleri: İşbirliği (iki takımın yeni bir API tasarlamak için geçici eşleşmesi), Servis Olarak Tüketim (X-as-a-Service - bir takımın diğerinin API'sini sıfır toplantıyla tüketmesi) ve Kolaylaştırma (koçluk).
3
Bilişsel Yük Boyutlandırması: Takım sınırları ekibin ortak hafızasının kaldırabileceği büyüklükle (maksimum 7-9 mühendis) sınırlandırılır.

🎯2. Doğru Kullanım Senaryosu

Kapsam
Monolitten mikroservise geçiş projeleri, kurumsal mühendislik yeniden yapılanmaları, 50 kişiyi aşan şirket büyümeleri ve Platform Mühendisliği mimarileri.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓
    Monolit kodu 30 mikroservise bölüp arka planda hala merkezi 'Veritabanı Ekibi' ve 'Frontend Havuzu' tutmak
  • ✓
    sonuçta 2 satırlık bir değişiklik için bile 6 takıma Jira açıp 4 toplantı yapmak zorunda kalarak dağıtık monolite saplanmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓
    Tek bir özelliğin canlıya çıkması için 5 farklı takımın aynı anda sürüm çıkarmasının gerekmesi
  • ✓
    mühendislerin zamanlarının yarısını takımlar arası bağımlılık toplantılarında harcaması
  • ✓
    mimari şemanın şirketin kurumsal organizasyon şemasıyla birebir aynı olması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓
    Ters Conway Manevrasını uygulayın: Ekipleri iş alanlarını (Bounded Context) uçtan uca yöneten bağımsız takımlara ayırın
  • ✓
    bilişsel yükü azaltmak için self-servis iç platform ekipleri kurun
  • ✓
    takımlar arası iletişimi API sözleşmelerine (X-as-a-Service) bağlayın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim
Takım yapılarını mimariye göre hizalamak otonom geliştirme hızını katbekat artırır ve bürokrasiyi yok eder; ancak kemikleşmiş fonksiyonel siloları yıkmak için güçlü bir yönetim iradesi gerektirir.
📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ
Bir bankacılık yazılımında 4 ayrı silo ekip vardı: Mobil, Web, Java Backend ve Veritabanı. Yeni bir kredi kartı özelliği çıkarmak 6 ay sürüyordu çünkü Web ekibi Java ekibini, Java ekibi ise veritabanı ekibini bekliyordu. Mikroservise geçmeyi denediler ancak ekipler hala birbirine bağımlı olduğu için proje tıkandı. CTO Ters Conway Manevrasını başlattı: Silo ekipleri kapattı ve içinde frontend, backend ve veri mühendislerinin olduğu 3 Akış Hizalı Takım (Ödemeler, Kayıt, Kartlar) kurdu; arkalarına da self-servis altyapı sağlayan bir Platform Ekibi koydu. Takımlar kendi özelliklerini sıfır dış bağımlılıkla uçtan uca geliştirebildiği için teslim süresi 6 aydan 4 güne indi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Yazılım mühendisliğinde Conway Yasası (Conway's Law) nedir?

Bir sistem tasarlayan herhangi bir organizasyonun, kaçınılmaz olarak kendi iç iletişim yapısını ve departman sınırlarını birebir kopyalayan bir yazılım mimarisi üreteceğini belirten sosyolojik kuraldır.
Q2

'Ters Conway Manevrası' (Reverse Conway Maneuver) nedir?

Sahip olmak istediğiniz bağımsız ve otonom yazılım mimarisini elde etmek için, mühendislik organizasyon şemanızı ve takım sınırlarınızı bilinçli olarak bu mimariye göre yeniden yapılandırma stratejisidir.

Sosyoteknik Mimari: Conway Yasası, Ters Conway Manevrası ve Takım Topolojileri (Team Topologies) — Sıkça Sorulan Sorular

Team Topologies modelinde 'Akış Hizalı Takım' (Stream-Aligned Team) nedir?

Belirli bir müşteri yolculuğuna veya iş alanına (Bounded Context) odaklanmış; dışarıdan hiçbir takıma bağımlı olmadan yazılımı uçtan uca geliştirecek, dağıtacak ve işletecek tüm yetkinliklere sahip çapraz fonksiyonel takımdır.

Şirket içi bir Platform Ekibinin temel misyonu nedir?

Akış Hizalı takımların bilişsel yükünü azaltmak için self-servis geliştirici araçları (CI/CD, Kubernetes, izleme) sunarak; ekiplerin altyapıyla uğraşmadan sadece iş mantığı geliştirmelerini sağlamaktır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸
    Conway Yasası: Yazılım mimarisi organizasyonun iç iletişim yapısını doğrudan kopyalar.
  • ▸
    Fonksiyonel silolar (Frontend vs Backend vs Veritabanı) kaçınılmaz olarak hantal monolitler üretir.
  • ▸
    Ters Conway Manevrasını uygulayın: Ekipleri hedeflediğiniz yazılım mimarisine göre kurun.
  • ▸
    Team Topologies modelini benimseyin: Self-servis Platform takımlarıyla desteklenen otonom ekipler.

Yaygın Yanılgılar

  • ✗
    Yanılgı: Ekipleri değiştirmeden mikroservise sadece teknik bir geçiş olarak geçebiliriz (Gerçek: Silo ekipleri korumak dağıtık monolit felaketini garantiler).
  • ✗
    Yanılgı: Platform ekipleri altyapı biletlerini onaylayan kapı bekçileridir (Gerçek: Platform ekipleri sıfır bürokrasiyle self-servis API sunan iç ürün takımlarıdır).

Karar Kılavuzu & Önceliklendirme

Takımlar arası bağımlılık darboğazlarını yok etmek ve otonom geliştirmeyi sağlamak için ekipleri iç Platform takımlarıyla desteklenen Akış Hizalı takımlara dönüştüren Ters Conway Manevrasını uygulayın.

Doğrulanmış Kaynaklar & Referanslar