Vendor Ekosistemini ve Rolleri Haritalama

Ön koşul: Arven'in portal, ERP, üretim, altyapı ve destek akışını; önceki mimari, BoM ve lisans derslerini okuyabilmelisin. Bu dersin sonunda bir ürün adını çözüm olarak söylemeden önce ekosistemdeki aktörleri, verdikleri sözü, ellerindeki kanıtı ve müşteriye karşı sorumlu tarafı haritalayacaksın. Yaklaşık 28 dakika anlatı, 28 dakika uygulama, 12 dakika kontrol önerilir. Bir teknoloji teklifi yalnız ürünlerden oluşmaz. Üretici donanım veya yazılımı geliştirir; distribütör ticari kanalda tedarik ve lojistiği üstlenebilir; bayi ya da sistem entegratörü tasarımı, kurulumu veya birinci seviye hizmeti verebilir; ISV uygulama katmanını geliştirir; bulut sağlayıcısı platformu işletir; müşteri de kimlik, veri, süreç ve kabul kararlarının sahibidir. Bu roller somut sözleşmeye göre değişir; logodaki isimden sözleşme kapsamı çıkarılmaz. Aynı firma birkaç rol oynayabilir, fakat her rolün yükümlülüğü ayrı yazılmalıdır.

Ekosistem haritası ancak arayüzlerde işe yarar. Her bileşen çifti için bağlantı protokolünü yazmak başlangıçtır; veri sahibi, değişiklik bildirimi, desteklenen sürüm, test ortamı, izleme noktası ve arıza teşhis sırası da gerekir. Arven portalından ERP'ye sipariş çağrısı başarısız olduğunda portal ekibi yalnız 'ERP çalışmıyor' diyemez; istek kimliği, zaman damgası, hata türü ve tekrar deneme davranışı sağlamalıdır. ERP ekibi de API sağlık durumu, kota ve iş kuralı reddini ayırmalıdır. Müşteri operasyonu kritik siparişi hangi geçici yolla işleyeceğini bilmelidir. Tedarikçilerin her biri kendi ürününü doğru çalıştırsa bile aradaki hizmet aksayabilir. Bu nedenle çözümün uçtan uca çıktısını ve tanısal veriyi taraflar arasında paylaşılabilir biçimde tanımla.

RACI tablosu yararlı olabilir, ancak her hücreye yalnız harf yazıp bitirme. Tasarım onayı, entegrasyon testi, güvenlik bulgusu, yama, lisans yenileme, kapasite artışı, olay yönetimi ve veri silme için gerçek teslim nesnesini ve kabul eden kişiyi belirt. Bir etkinlikte tek hesap verebilir owner belirle; danışılan ve bilgilendirilen tarafların zamanı açık olsun. Üretici tarafından desteklenen kombinasyon ile entegratörün sahada doğruladığı kombinasyonu ayrı kanıtlar olarak tut. 'Uyumlu' sözcüğü hangi sürüm, hangi topoloji, hangi sınır ve hangi test için geçerlidir? Bir tarafın genel veri sayfası diğerinin arayüz taahhüdü değildir. Değişiklik olduğunda yeniden test ve yeniden onay tetiklerini kaydet.

Vendor seçimi yalnız fiyat veya marka güveniyle yapılmaz. NIST SP 800-161 Rev. 1 tedarik zinciri riskini ürün ve hizmet yaşam döngüsündeki görünürlük, değerlendirme ve azaltma işi olarak ele alır. NIST SP 1326 ise ICT tedarikçisi için due diligence incelemesinde köken, dayanıklılık, temel siber uygulamalar ve tedarik zinciri katmanları gibi boyutlar önerir. Bunlar 'bu vendor güvenlidir' damgası vermez; müşterinin riskine uygun soruları düzenler. Pre-sales'in görevi güvenlik veya satın alma uzmanının yerine nihai karar vermek değildir. Teknik çözümün hangi tedarikçiye, hangi alt sağlayıcıya, hangi destek ve güncelleme kanalına dayandığını göstermek, açık riskleri doğru owner'a taşımaktır. Veri işleme yeri, uzaktan erişim, güncelleme doğrulaması, destek için veri paylaşımı ve hizmet kesintisinde devam planı gibi sorular müşteri bağlamına göre seçilir.

Her iddiayı 'beyan', 'resmî belge', 'test', 'müşteri sözleşmesi' ve 'operasyon gözlemi' olarak sınıflandır. Pazarlama sayfası bir özelliğin varlığına işaret edebilir; belirli sürüm/topoloji desteği, servis seviyesi veya mevzuat uyumu için tek başına yeterli değildir. Ürün destek matrisi belirli bir kombinasyonu kapsasa bile entegratörün bunu kurma yetkinliği ve müşteri ortamında çalışması ayrıca sınanır. Belge tarihi, ürün sürümü, coğrafya ve lisans programı değiştiğinde kaydı yeniden aç. Kanıt yoksa varsayımı kabul edilmiş gerçek gibi mimari diyagrama yazma. Risk kaydında etki, olasılık, erken uyarı, alternatif, karar sahibi ve doğrulama tarihi bulunmalı; yalnız 'orta risk' etiketi karar verdirmez.

Dersin çıktısı vendor listesi değil, Arven'in karar verebileceği bir bağımlılık ve sorumluluk haritasıdır. Her satırda iş sonucu, teknik bileşen, sağlayıcı, sözleşme tarafı, destek kanalı, kanıt, açık varsayım, owner ve sonraki doğrulama adımı bulunur. Bu haritayı HLD, BoM, lisans defteri ve operasyon tasarımıyla ilişkilendir. Bir bileşen değişirse yalnız ürün satırını değil, arayüz testini, lisans hakkını, destek yetkisini, veri akışını, eğitim ihtiyacını ve geri dönüş planını yeniden değerlendir. Kaynak kitapta veya vendor dokümanında boşluk varsa farklı üreticinin alışkanlığından kesin kural türetme; resmî belge, müşteri anlaşması ve ilgili uzman kararıyla kapat. NIST rehberleri risk yaklaşımına dayanak verir, belirli satın alma seçimini veya sözleşme hükmünü müşterinin yerine vermez.

Arven için üç seçenek kurulabilir: mevcut üretici ekosistemini genişletmek, belirli katmanda ikinci bir sağlayıcı kullanmak veya ilgili hizmeti yönetilen platforma taşımak. Bu derste hangisinin üstün olduğu belirlenmez. Önce her seçenekte hangi rol ve destek arayüzlerinin değişeceğini, kimlerin yeni beceri gerektireceğini ve çıkış yolunu göster. Birden çok üretici esneklik getirebilir, fakat entegrasyon ve ortak olay yönetimi yükü doğurabilir; tek üretici bazı temas noktalarını azaltabilir, fakat bağımlılık yoğunlaşabilir. Gerçek avantaj müşteri hedefi, sözleşme, veri taşınabilirliği, işletim kapasitesi ve kanıtla ölçülür. Bu değerlendirme sonraki portföy, çoklu vendor ve koşullu karar derslerinin girdisidir.