ITAM ve CMDB: Aynı Görünen Ama Temelden Farklı İki Sistem!
İçindekiler
Her ikisi de “varlık yönetimi” gibi görünür, ikisi de envanter tutar, ikisi de bir database’e dökümlenir. Ama amaçları, veri modelleri ve kullanım senaryoları birbirinden tamamen farklıdır. Bu yazıda ITAM ve CMDB arasındaki farkı teknik derinlikte açıklıyoruz.
Temel Fark: Ne Takip Ediyoruz?
Bu iki sistemi birbirine karıştırmanın en yaygın sebebi, her ikisinin de "IT ortamındaki şeyleri" kayıt altına almasıdır. Ama "şey" kelimesinin arkasında çok farklı sorular gizlidir:
Bu varlık kime ait, ne kadar maliyeti var ve lifecycle'ının neresinde?
Finansal ve hukuki sorumluluk. Lisans uyumluluğu. Amortisman. Kontrat süresi. Kim kullanıyor, ne zaman imha edilecek.
Bu CI nasıl çalışıyor, nelere bağlı ve değiştirilirse ne etkilenir?
Teknik bağımlılık. Servis etkisi. Change yönetimi. Incident root cause analizi. Ortam haritası.
Özet tek cümle: ITAM bir laptop'ın "ne" olduğunu bilir; CMDB o laptop'ın "neyle konuştuğunu" bilir.
ITAM — IT Asset Management Nedir?
ITAM; donanım, yazılım ve cloud kaynaklarının tüm yaşam döngüsü boyunca finansal, hukuki ve envanter kontrolünü sağlayan bir disiplindir. ISO 19770 standartları altında şekillenir ve genellikle finans, hukuk ve procurement ekipleriyle ortak çalışır.
BT Varlık ve Konfigürasyon Yönetimi- Donanım envanter takibi (serial, model, lokasyon)
- Yazılım lisans yönetimi (SAM — Software Asset Management)
- Cloud kaynak tüketimi ve maliyet optimizasyonu
- Amortisman ve finansal raporlama
- Vendor kontrat ve garanti yönetimi
- Lifecycle yönetimi (procurement → disposal)
- Compliance audit desteği (BSA, GDPR, SOX)
- License reconciliation ve entitlement
ITAM'ın veri nesnesi: Asset
ITAM'da her kayıt bir Asset'tir. Asset'in en kritik attribute'ları şunlardır:
SAM (Software Asset Management) ITAM'ın alt kümesidir. Microsoft EA, Adobe Creative Cloud, Oracle DB gibi kurumsal yazılımlarda yanlış lisanslama milyonlarca dolarlık audit cezasına yol açabilir. SAM tam burada devreye girer.
CMDB — Configuration Management Database Nedir?
CMDB; IT altyapısındaki bileşenlerin (CI — Configuration Item) teknik özelliklerini, birbirleriyle ilişkilerini ve servislerle olan bağlantılarını tutan bir veritabanıdır. ITIL v4'ün Service Configuration Management pratiğinin omurgasıdır.
CMDB'nin gücü tek başına tuttuğu kayıtlarda değil, kayıtlar arasındaki relationship'lerde yatar. Bir CI ne olduğunu söyler; CI + ilişki grafiği ise bir değişiklik yapıldığında ne etkileneceğini söyler.
- Infrastructure CI: Server, network device, storage array, hypervisor, container host
- Software CI: OS instance, middleware, database engine, uygulama versiyonu
- Service CI: Business service tanımları ve service mapping
- Virtual CI: VM, container, cloud instance, serverless function
- Document CI: Konfigürasyon dokümanları, baseline'lar, runbook referansları
CI kaydı nasıl görünür?
Bu relationship grafiği sayesinde: "prod-db-cluster-01'e yapılacak bir patch hangi servisleri etkiler?" sorusunun cevabını impact analizi olarak otomatik çıkarabilirsiniz.
Veri Modeli Karşılaştırması
| Boyut | ITAM (Asset) | CMDB (CI) |
|---|---|---|
| Birincil amaç | Finansal & lifecycle kontrolü | Teknik bağımlılık & change etkisi |
| Temel varlık | Asset (satın alınan her şey) | CI (yönetilmesi gereken her şey) |
| İlişki modeli | Düz kayıt / kullanıcıya atama | Directed graph / relationship tipi |
| Kapsam | Her satın alınan IT varlığı | Sadece yönetilen / kritik CI'lar |
| Güncelleme tetikleyicisi | Satın alma, atama, imha | Change, discovery, deployment |
| Veri kalitesi odağı | Finansal doğruluk, ownership | Relationship doğruluğu, güncellik |
| Tipik kullanıcı | IT Finance, Procurement, Compliance | Platform, Ops, Change Mgr, NOC |
| Tooling örnekleri | SPIDYA ITAM, Snow, Lansweeper, ServiceNow HAM | SPIDYA, iTop, Freshservice, Jira SM |
| Standart referans | ISO 19770 | ITIL v4 / TOGAF |
| Cloud karşılığı | Cloud cost mgmt (FinOps), tagging | CSPM, resource graph, AWS Config |
Overlap Alanı: İkisi Nerede Kesişir?
Pratikte bazı varlıklar hem ITAM hem CMDB'de yaşar. Ama dikkat: aynı fiziksel nesneyi temsil eden farklı veri objeleri söz konusudur. Asset ile CI aynı şey değildir.
Bir sunucu, ITAM'da Asset; CMDB'de CI'dır
Aynı fiziksel makine, iki farklı sistemde iki farklı amaçla temsil edilir. Aralarında 1:1 mapping olabilir, olmayabilir de.
serial, maliyet, garanti
bağımlılık, servis map
Birbirini içeren değil, birbirini tamamlayan sistemler
CMDB'deki her CI'ın bir ITAM kaydı olmayabilir. Örneğin bir virtual network interface veya bir Kubernetes namespace CMDB'de CI olarak tutulabilir ama ITAM'da bunların finansal kaydı olmaz.
Tersi de geçerlidir: ITAM'da her asset için CMDB kaydı tutmak anlamsızdır. Bir mouse, bir klavye veya sarf malzeme ITAM'da asset olarak geçer ama CMDB'de CI değildir — bunların değiştirilmesinin servis etkisi yoktur.
Hangisi, Ne Zaman, Neden?
Aşağıdaki senaryolar hangi sisteme başvurmanız gerektiğini netleştirir:
Microsoft audit ekibi geliyor. Şirkette kaç adet Office 365 E3 lisansı var, kaçı aktif kullanımda, kaçı atanmış ama kullanılmıyor? → ITAM / SAM
prod-db-01 üzerinde Oracle 19c'ye patch atmak istiyorsunuz. Bu değişiklikten hangi uygulamalar, hangi servisler etkilenir? Rollback süresi tahmini nedir? → CMDB
Payment servisi çöktü. Hangi CI'lar bu servisle ilişkili? Yakın zamanda hangisinde change yapıldı? → CMDB + Change kaydı
Önümüzdeki yıl kaç cihazın garantisi doluyor? Hangi donanımların amortisman süresi bitiyor? CapEx planı için liste hazırlayın. → ITAM
Bir çalışan şirketten ayrıldı. Üzerindeki hangi donanım ve yazılım lisansları geri alınmalı? → ITAM
Kritik bir CVE açıklandı. Ortamınızda etkilenen yazılım versiyonunu çalıştıran kaç CI var ve bu CI'lar hangi business servislerine hizmet veriyor? → CMDB + ITAM (SAM)
Birlikte Çalışma: Entegrasyon Mimarisi
Olgun IT organizasyonlarında ITAM ve CMDB ayrı tutulur ama senkronize çalışır. Tipik entegrasyon pattern'leri şunlardır:
Yaygın Hatalar ve Anti-Pattern'ler
1. "Her şeyi CMDB'ye atalım" hatası
CMDB'ye her CI'ı eklemek veri kalitesini düşürür. CMDB'nin değeri relationship'lerin doğruluğundan gelir. Yönetilemeyen kayıtlarla doldurmak grafı anlamsız kılar. Kural: Sadece "bir değişiklik yapıldığında kimin etkileneceğini bilmek istediğim" CI'lar CMDB'ye girer.
2. ITAM'ı sadece fiziksel donanımla sınırlamak
Modern ITAM SaaS abonelikleri, cloud resource entitlement'ı ve container image lisanslarını da kapsamalıdır. FinOps disipliniyle entegre edilmeyen ITAM, cloud maliyetlerinde kör nokta bırakır.
3. Discovery'yi her şeyin çözümü saymak
Otomatik discovery araçları CI'ları bulur ama relationship'leri çoğunlukla doğru kuramazlar. "Discovery çalıştırdık, CMDB hazır" yanılgısı yaygındır. Relationship kalitesi için service mapping ve manuel doğrulama süreçleri gereklidir.
4. ITAM ve CMDB'yi tek platformda birleştirmek (amaçsızca)
SPIDYA (Cheetah Low-Code Developement Platform) gibi platformlar her ikisini de sunar, ama bu iki disiplinin governance'ını, veri sahipliğini ve süreçlerini ayrı tutmak gerekir. Tek DB = tek süreç yanılgısına düşmeyin.
Sonuç: Decision Framework
Hangi soruya cevap aradığınızı bilirseniz, hangi sisteme bakacağınızı da bilirsiniz:
| Soru | Sistem |
|---|---|
| Bu yazılımı kullanmaya hakkımız var mı? | ITAM / SAM |
| Bu sunucuya patch atarsam ne etkilenir? | CMDB |
| Bu çeyrek ne kadar HW aldık, maliyeti ne? | ITAM |
| Önümüzdeki hafta hangi change'ler çakışıyor? | CMDB + Change Mgmt |
| Garantisi bitmek üzere kaç cihaz var? | ITAM |
| Payment servisi çöktü, hangi CI'lar ilgili? | CMDB |
| Şirkette kaç lisanssız uygulama var? | ITAM / SAM |
| Bu CVE kaç kritik sistemi etkiliyor? | ITAM + CMDB |
Önerilen yaklaşım: ITAM ve CMDB'yi ayrı disiplinler olarak kurun, ayrı veri sahipleri atayın (Asset Owner vs CI Owner), ama ortak bir ITSM platformu üzerinde birbirine bağlı çalıştırın. İkisi birbirinin yerine değil, birbirinin tamamlayıcısıdır.