Akıllı şehir platformları: bütünleşik ticari, açık standart, özel geliştirme

"Akıllı şehir platformu" ifadesi, birbirinden çok farklı üç tedarik kararını aynı torbaya koyar. Birincisi bütünleşik ticari platform: sensör bağlantısı, veri saklama, kural motoru, panolar ve dikey uygulamalar tek üreticiden gelir. İkincisi açık standartlara dayalı mimari: veriyi ortak bir bağlam katmanında toplayıp standart arayüzlerle paylaşan, bileşenleri değiştirilebilir bir yapı — Avrupa kamu tarafında en yaygın iki referansı FIWARE ve oneM2M’dir. Üçüncüsü özel geliştirme: belediyenin kendi süreçlerine göre yazılan, kaynak kodu ve verisi kurumda kalan sistem. Bu üç yol farklı fiyat etiketleri değil, farklı uzun vadeli pozisyonlar üretir: on yıl sonra veriye kimin eriştiğini, tedarikçiyi değiştirebilir olup olmadığınızı ve yeni bir kullanım alanını kaç haftada ekleyebileceğinizi bu karar belirler.

Türkiye’de çerçeve de boşlukta değil. Çevre, Şehircilik ve İklim Değişikliği Bakanlığı Coğrafi Bilgi Sistemleri Genel Müdürlüğü’nün yürüttüğü Akıllı Şehirler Portalı, 2020-2023 Ulusal Akıllı Şehirler Stratejisi ve Eylem Planı’nın ardından 2024-2030 dönemi için hazırlanan strateji ve eylem planı taslağını duyurdu; Bakanlığın duyurusuna göre taslak 4 stratejik amaç, 10 stratejik hedef, 12 misyon alanı, 30 eylem ve 271 üst seviye uygulama adımı içeriyor ve "İleri toplum, ileri teknoloji, sürdürülebilir ve dirençli dünya" vizyonuyla yerli ve millî akıllı şehir teknolojilerinin geliştirilmesini öne çıkarıyor. Belediye için pratik sonucu şudur: platform kararı artık yalnız teknik değil, ulusal olgunluk çerçevesine ve açık veri hedeflerine uyum kararıdır.

Karşılaştırma kriterleri

Üç yaklaşımı aynı terazide tartmak için sekiz kriter kullanıyoruz: veri sahipliği ve saklama yeri, veri modeli ve arayüz standardı, satıcıya bağımlılık ve çıkış maliyeti, entegrasyon yeteneği (MOBESE, IoT sayaç, CBS), maliyet yapısı, devreye alma süresi, kurum içi yetkinlik gereksinimi ve kamu ihalesi/şartname uygunluğu. Tablodaki hücreler yaklaşımların yapısal özellikleridir; belirli bir ürünün performans iddiası değildir. Kamuya açık kaynaktan doğrulayamadığımız her alan "—" ile işaretlenmiştir.

Bütünleşik ticari platformlar: güçlü ve zayıf yanlar

Güçlü yanları: Bütünleşik platformların en büyük avantajı zamandır. Cihaz kaydı, veri toplama, uyarı kuralları, kullanıcı yönetimi ve yönetici panoları birbirine uyumlu biçimde hazır gelir; belediye ilk görselleştirmeyi haftalar içinde alabilir. Destek tek elden yürür, sorumluluk sınırı nettir ve işletmenin büyük kısmı üreticide olduğu için dar bilgi işlem kadrosuna sahip belediyeler için pratik bir başlangıç sunar. Altyapı katmanında da hazır bileşen bolluğu vardır; örneğin AWS IoT Core gibi bulut servislerinin bağlantı ve mesajlaşma birim fiyatları resmî fiyat sayfasında kamuya açık biçimde yayımlanır — bölgeye göre değişen bu fiyatlar, hesap yapmayı mümkün kılar (fiyatlar üretici tarafından güncellenebilir; kontrol tarihi: Ağustos 2026).

Zayıf yanları: Zaman kazancının bedeli genellikle veri modelidir. Sensör verisi üreticiye özgü bir şemada birikmeye başladığında, üç yıl sonra o veriyi başka bir sisteme taşımak "dışa aktar" düğmesiyle bitmez; kavramsal eşleme, tarihçe ve ilişkiler yeniden kurulmalıdır. İkinci risk kapsam genişlemesidir: yeni bir kullanım alanı (örneğin park doluluk veya gürültü ölçümü) her seferinde ek modül kalemi olarak fiyatlanır ve pazarlık gücü zamanla belediyenin aleyhine döner. Üçüncüsü, panoların gösterişiyle kararın niteliği karıştırılabilir: ekranda güzel görünen bir harita, arkasındaki veri güncel değilse yönetsel değer üretmez. Bu risklerin tamamı, sözleşmeye açık format dışa aktarım garantisi, API erişim hakkı ve fiyat artış tavanı yazılarak yönetilebilir — platformun kendisi değil, bu maddelerin varlığı belirleyicidir.

Açık standartlara dayalı mimari: FIWARE, oneM2M, MIMs

İkinci yol, platformu bir ürün olarak değil bir arayüz sözleşmesi olarak düşünür. FIWARE, resmî tanıtımına göre akıllı çözümlerin geliştirilmesini hızlandırmak için derlenmiş açık kaynak platform bileşenlerinden oluşan bir çerçevedir; standartlaştırılmış veri modelleri ve API’lerle birlikte çalışabilirliği sağlamayı ve satıcıya bağımlılığı önlemeyi hedefler (fiware.org). Mimarinin kalbindeki bağlam yöneticisi Orion-LD, GitHub deposundaki tanıma göre hem NGSI-LD hem NGSI-v2 API’lerini destekleyen bir bağlam veri yönetimi bileşenidir ve AGPL v3 lisansıyla dağıtılır (github.com/FIWARE/context.Orion-LD). NGSI-LD’nin kendisi ETSI bünyesindeki ISG CIM çalışma grubu tarafından sürdürülen bir spesifikasyondur; yani belediyenin bağlanacağı arayüz, bir şirketin ürün kararına değil bir standardizasyon sürecine bağlıdır.

oneM2M ise farklı bir katmanı adresler: cihaz ve uygulama arasındaki makineler arası iletişimi standartlaştırır. 2012’de kurulan oneM2M, ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA ve TTC olmak üzere sekiz standardizasyon kuruluşunun küresel ortaklığı olarak başlatıldı; kendi tanıtımına göre farklı iş alanlarından 200’den fazla paydaşı bir araya getirerek makineler arası iletişim ve nesnelerin interneti sistemlerinin verimli kurulumunu sağlayan spesifikasyonlar üretir. Üçüncü bir referans olarak Open & Agile Smart Cities (OASC) Minimal Birlikte Çalışabilirlik Mekanizmaları (MIMs), şehirlerin veri, sistem ve hizmetler arasında asgari düzeyde birlikte çalışabilirliği sağlamasını amaçlar; MIM biçimi ITU tarafından Y.4505 olarak standartlaştırılmıştır.

Güçlü yanları: Lisans kalemi ortadan kalkar; veri belediyenin seçtiği ortamda ve açık bir modelde tutulur; yeni bir kullanım alanı eklemek, ilk kurulumdan sonra tekrarlanabilir bir işe dönüşür. Tedarikçi değiştirmek sistemin çöküşü anlamına gelmez — bu, on yıllık bir yatırım ufkunda en değerli özellik olabilir. Zayıf yanları: "Üretici garantisi" yoktur; sürüm yükseltme, güvenlik yamaları ve yedekleme birinin işi olmak zorundadır. Bileşenleri bir araya getiren mimari kararlar (hangi veri modeli, hangi kimlik doğrulama, hangi saklama politikası) kurumda ya da sözleşmeli hizmet sağlayıcıda yetkinlik ister. Standart uyumu da kendiliğinden gelmez: "NGSI-LD destekliyoruz" cümlesi, hangi sürüm ve hangi işlemler için desteklendiği yazılı olarak sorulmadan kabul edilmemelidir.

Belediyeye özel geliştirme: nerede anlamlı?

Özel geliştirme, tüm akıllı şehir yığınını sıfırdan yazmak demek değildir — böyle bir kapsam çoğu belediye için ne gerekli ne gerçekçidir. Anlamlı olduğu yer, belediyenin farklılaştığı katmandır: kendi mevzuat yorumuna göre işleyen denetim akışları, vatandaşa açık özel sorgu ekranları, mevcut tahakkuk ve imar sistemleriyle sıkı bağlı iş kuralları, ilçeye özgü raporlama. Bu katmanlar hazır üründe ya hiç yoktur ya da "özelleştirme" adı altında her yıl yeniden faturalandırılır. Özel geliştirmenin ölçülebilir değeri iki maddededir: kaynak kodunun ve veritabanı şemasının belediyede kalması ve sistemin, tedarikçi değişse bile yaşamaya devam edebilmesi. Bedeli ise daha uzun bir ilk kurulum süresi ve kurumda asgari bir sahiplik kapasitesi gerektirmesidir. Doğru kurgu genellikle şudur: veri toplama ve bağlam katmanı açık standart üzerinde, belediyeye özgü uygulama katmanı özel geliştirme.

Entegrasyon cephesi: MOBESE, IoT sayaç ve CBS

Akıllı şehir projelerinin gerçek zorluğu sensörde değil, birbirine benzemeyen üç veri dünyasını buluşturmaktadır. MOBESE ve kent güvenliği tarafında video akışları yüksek bant genişliği, uzun saklama süresi ve sıkı erişim kaydı gerektirir; pratikte bu veri kendi video yönetim sisteminde kalır ve akıllı şehir katmanına yalnız olay düzeyinde bağlanır (bu ayrımı MOBESE ve video yönetim sistemi çözüm sayfamızda ayrıntılandırıyoruz). IoT sayaç tarafında su ve atık yönetimi telemetrisi küçük ama sık gelen paketlerden oluşur; burada kritik olan sayaç üreticisinden bağımsız bir protokol katmanı kurmaktır, aksi hâlde her marka değişikliği yeni bir entegrasyon projesine dönüşür (ayrıntı: akıllı sayaç ve su/atık yönetimi). CBS tarafında ise veri hem referans hem bağlam işlevi görür: her sensör bir adrese, parsele veya mahalleye oturur; mekânsal katmanların OGC servisleriyle yayımlanması bu bağı standart hâle getirir (bkz. kent bilgi sistemi / CBS çözümü). Üç alanı tek üründe toplamak cazip görünür; ancak sağlıklı mimari, her alanın kendi uzman sisteminde kalması ve aralarındaki arayüzlerin belgelenmiş olmasıdır.

Kamu ihalesi ve şartname: hangi maddeler kararı korur?

Akıllı şehir ihalelerinde en sık yapılan hata, şartnamenin bir ürün broşüründen türetilmesidir. 4734 sayılı Kamu İhale Kanunu çerçevesinde marka-model tarifi rekabeti daraltır ve itiraz riski doğurur; bu yüzden şartname işlevsel tanım üzerinden yazılmalıdır. Pratikte kararı koruyan maddeler şunlardır: (1) arayüz standardı — hangi API ile veri okunup yazılacağı ve hangi sürüm/işlem kümesinin destekleneceği; (2) veri modeli — hangi varlık tiplerinin hangi alanlarla tutulacağı; (3) veri sahipliği ve devir — sözleşme bittiğinde verinin hangi formatta, kaç günde, hangi bedelle teslim edileceği; (4) kimlik ve yetkilendirme — rol bazlı erişim ve loglama; (5) KVKK uyumu — özellikle görüntü ve konum verisinde işleme envanteri ve saklama süreleri; (6) kabul kriterleri — hangi testten geçilince kabul edileceği, örnek veriyle çalıştırılacak senaryolar; (7) fiyat artış ve kapsam genişleme kuralları. Bu yedi madde yazıldığında hangi model gelirse gelsin belediye korunur; yazılmadığında en iyi platform bile birkaç yıl içinde bir bağımlılığa dönüşür. Bakanlığın olgunluk değerlendirme ve yol haritası yaklaşımını şartnamenin ihtiyaç analizi bölümüne iliştirmek, hem gerekçeyi güçlendirir hem de değerlendirmeyi tarafsızlaştırır.

Hangi durumda hangisi?

• Tek bir acil problemi olan küçük/orta belediye: Su kaybı, çöp toplama rotası veya trafik yoğunluğu gibi tek bir kullanım alanıyla başlayın. Bu aşamada bütünleşik ticari bir dikey çözüm veya hazır bulut bileşenleri en hızlı yoldur; ancak sözleşmeye açık format dışa aktarım maddesini şimdiden yazın — ikinci alan geldiğinde bu madde sizi kurtarır.
• Üç ve üzeri kullanım alanını aynı anda planlayan belediye: Açık standart temelli bağlam katmanı burada ekonomik olarak da mantıklı hâle gelir; her yeni alan aynı arayüze bağlanır. Kurumda mimari yetkinlik yoksa, işletme ve SLA sorumluluğunu sözleşmeyle hizmet sağlayıcıya verin.
• Büyükşehir ve bağlı idareler: Çok birimli yapılarda veri paylaşımı asıl sorundur; burada arayüz standardı şart, tek platform şart değildir. Mevcut ticari yatırımların üstüne standart bir bağlam katmanı koyup kademeli geçiş yapmak, hepsini birden değiştirmekten hem ucuz hem düşük risklidir.
• Mevzuat veya süreç olarak farklılaşan her ölçek: Hazır ürün belediyenin denetim, başvuru veya raporlama sürecine uymuyorsa, zorlama özelleştirme yerine o katmanı özel geliştirmek genelde daha ucuz ve daha kalıcıdır. Biz bu katmanı açık standartlar üzerine, kaynak kodu ve veri belediyede kalacak şekilde kuruyoruz; genel çerçeveyi akıllı şehir ve belediye yönetimi çözüm sayfamızda anlatıyoruz.
• Bütçesi dar ve kadrosu sınırlı belediye: Platform yatırımını ertelemek meşru bir karardır. Önce veri toplama disiplinini ve tek bir panoyu kurun; olgunluk artmadan alınan geniş kapsamlı platform, çoğu örnekte kullanılmayan modüllerin lisansını ödemekle sonuçlanır.