Teknik rehber
Clean Core yaklaşımında bir genişletme kararı nasıl değerlendirilir?
Bir genişletme kararı, standart yeteneğin gerçekten yetersiz olduğunun gösterilmesiyle başlar. Ardından ihtiyacın iş gerekçesi, kullanılabilecek en kararlı genişletme yolu, bağımlılıkların yükseltmeye etkisi, genişletmenin yaşam döngüsü ve onay süreci birlikte değerlendirilir. Clean Core, özel geliştirmeyi yasaklayan bir kural değil, bu değerlendirmenin disiplinidir.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 9 dk okuma
- Kaynakça
Bu rehberde
Bölümler
Kapsam ve ürün bağlamı. Bu rehber, SAP® yazılımında genişletme kararları için genel bir değerlendirme çerçevesidir. Rehberde anlatılan A–D seviye modeli, SAP tarafından SAP Cloud ERP Private genişletilirken kullanılmak üzere tanımlanmıştır [2] ve seviyeler, ABAP® programlama diliyle yazılmış kod için ABAP Test Cockpit (ATC) bulgularıyla eşleştirilir [2][3]. Model başka ürün veya kurulumlara doğrudan uygulanmaz; kendi ortamınız için geçerliliği ürün ve sürüm kapsamına göre doğrulanmalıdır. Diğer bölümler üründen bağımsız karar ilkeleridir ve Castintech’in değerlendirme çerçevesini yansıtır.
Clean Core ne demektir, ne demek değildir?
SAP, clean core’u sürekli iş dönüşümünü ve modernleşmeyi destekleyen yol gösterici ilkeler bütünü olarak tanımlar [1]. Bu ilkeler, sistemin yükseltilebilir ve değiştirilebilir kalmasını amaçlar. Clean Core “hiç özel kod yazmayın” anlamına gelmez; hangi genişletmenin, hangi yolla ve hangi maliyet ve risk kabul edilerek yapıldığının bilinçli olarak seçilmesi anlamına gelir.
SAP’nin genişletme beyaz kitabı da genişletmeleri yalnız “temiz” ve “temiz değil” diye ikiye ayırmak yerine dört seviyeli, daha ayrıntılı bir sınıflandırma önerir [2]. Bu yaklaşım kararın siyah-beyaz olmadığını kabul eder: bazı iş gereksinimleri daha düşük bir seviyeyi gerektirebilir. Önemli olan, bunun etkisinin bilinerek ve kayda geçirilerek kabul edilmesidir.
Diyagramın metin açıklaması
Başlangıç: bir genişletme talebi. Yol yukarıdan aşağı altı numaralı duraktan geçer. Karar noktası 1: standart yetenek gerçekten yetersiz mi? Karşılıyorsa yol genişletme dışına çıkar: yapılandırma, süreç varyantı veya küçük bir süreç değişikliği. Kontrolün sonucu kanıt türüyle kaydedilir; belgelenmiş deneme kanıt, kanaat varsayım olarak işaretlenir. Karar noktası 2: iş gerekçesi test, belge ve yükseltme kontrolünden oluşan yaşam boyu yükü taşıyor mu? Taşımıyorsa standarda yakın bir çözüm daha doğru olabilir. Karar noktası 3: uygulanabilir en yüksek clean core seviyesi. A'dan D'ye dört duraklı ölçekte önce A (en yüksek) değerlendirilir; D önerilmeyen seviyedir. Daha düşük bir seviye gerekiyorsa kesikli istisna yolu, gerekçe ve etki kaydıyla doğrudan karar kaydına iner. Kapsam sınırı: A–D modeli SAP tarafından SAP Cloud ERP Private genişletilirken kullanılmak üzere tanımlanmıştır; başka ortamda kapsamı doğrulanır. Adım 4: bağımlılıkların yükseltmede neyi etkilediği; adım 5: yaşam döngüsü ve sahiplik. Bitiş, adım 6: karar ve istisna kaydı; seçilen yol ve seviye, gerekçe ve yaşam boyu yük, bağımlılıklar, yaşam döngüsü ve sahipler, onay rolü ve tarih, varsayımlar ve istisna gerekçesi. İstisnayı önceden tanımlı bir rol onaylar; talep eden ile onaylayan aynı kişi olmaz. Diyagramda döngü yoktur. Mobilde diyagram üç sıralı panelde okunur: 1/3 standart yetenek ve iş gerekçesi, 2/3 seviye, bağımlılık ve yaşam döngüsü, 3/3 karar ve istisna kaydı. Künye: Castintech, D1, Eylül 2026; teknik anlatım diyagramı, SAP® ürün arayüzü değildir.
Adım 1: Standart yetenek gerçekten yetersiz mi?
Genişletme talebi çoğu zaman hazır bir çözüm olarak gelir: “şu alana şu kontrol eklensin.” İlk adım, arkasındaki iş ihtiyacını bu çözümden ayırmaktır. İhtiyaç netleştiğinde standart yapılandırmanın, mevcut bir süreç varyantının veya sürecin küçük bir değişikliğinin bu ihtiyacı karşılayıp karşılamadığı kontrol edilir.
Bu adımda cevaplanan sorular:
- İhtiyaç hangi iş sonucunu korumak veya sağlamak için var?
- Standart yapılandırmayla karşılanabilir mi; bu kontrol kim tarafından ve hangi sürümde yapıldı?
- Süreçte yapılacak bir değişiklik, genişletmeden daha düşük toplam maliyetli olabilir mi?
- İhtiyaç geçici mi, örneğin bir geçiş dönemine özgü mü, yoksa kalıcı mı?
Bu adımın sonucu da kanıt türüyle kaydedilir. “Standart yetenek yetersiz” tespiti bir kişinin kanaatine mi, yoksa belgelenmiş bir denemeye mi dayanıyor? Kanaat, karar kaydında varsayım olarak durur ve doğrulanması planlanır.
Adım 2: Genişletmenin iş gerekçesi ne?
SAP, genişletmelerin iş açısından farklılaştırıcı süreçler için önceliklendirilmesini önerir [1]. Buna göre bir genişletmenin gerekçesi, teknik olarak mümkün olmasından değil, iş için yarattığı farktan gelmelidir. Gerekçe; hangi süreç, hangi fark ve bu fark olmadan neyin kaybedileceği sorularıyla, iş sahibinin anlayacağı dilde yazılır.
Yönetim açısından bu adım bir yatırım kararıdır. Genişletme yalnız bir kez geliştirilmez; test edilir, belgelenir, her yükseltmede kontrol edilir ve bir gün kaldırılır. Gerekçe bu toplam yükü taşıyacak kadar güçlü değilse standarda yakın bir çözüm daha doğru olabilir. Kararı kolaylaştırmak için gerekçenin yanına genişletmenin tahmini yaşam boyu yükü de nitel olarak yazılır: hangi testleri, hangi belgeleri ve hangi yükseltme kontrollerini gerektireceği.
Adım 3: Genişletme hangi seviyede yapılabilir?
Genişletme gerekliyse kullanılabilecek en kararlı yol seçilir. SAP, SAP Cloud ERP Private genişletilirken uygulanabilir en yüksek seviyenin kullanılmasını önerir [2]. Daha düşük bir seviye, belirli bir iş veya teknik gereksinim bunu zorunlu kıldığında ve yükseltme kararlılığı ile clean core uyumu üzerindeki etkisi kabul edilerek seçilebilir [2].
| Seviye | Kısa açıklama | ATC davranışı |
|---|---|---|
| Level A | Yalnız yayımlanmış (released) arayüzler ve genişletme noktaları kullanılır; SAP bunları teknik anlamda bir kararlılık sözleşmesiyle (stability contract) sunar; bu ifade ticari bir anlaşma değildir | Bulgu yok |
| Level B | Klasik API’ler ve klasik genişletme noktaları kullanılır; kararlılık bir sözleşmeye değil, SAP ürün uzmanlarının bu API’leri önermesine dayanır | Öncelik 3 bulgu (bilgi) |
| Level C | SAP iç nesnelerine erişilir; koşullu olarak clean kabul edilir. SAP nesneleri için değişiklik günlüğü, yeni sürümdeki uyumsuz değişiklikleri görmeye yardımcı olur | Öncelik 2 bulgu (uyarı) |
| Level D | Önerilmeyen nesne veya teknikler kullanılır; örneğin modifikasyonlar ve SAP tablolarına doğrudan yazma | Öncelik 1 bulgu (hata) |
Tablo, resmî kaynaklardaki tanımların kısaltılmış açıklamasıdır [2][3]; kesin tanımlar ve nesne türü kapsamı için kaynakçadaki belgelere başvurulmalıdır. Uygulamada bir nesnenin hangi seviyede görüneceği, kullanılan kontrol varyantına ve sürüme göre ayrıca doğrulanmalıdır.
SAP beyaz kitabına göre Level A genişletmeler iki alanda yapılabilir: çekirdek sistemin dışında ayrı bir platformda (side-by-side) veya yayımlanmış yerel API’lerle çekirdek sistemin içinde (on-stack) [2]. Hangisinin uygun olduğu, genişletmenin çekirdek veriye ne kadar yakın çalışması gerektiğine ve kurumun işletim modeline bağlıdır.
Gerçek ürün ekranı
Ekranı okumak için yatay kaydırın ya da görseli seçip tam boyutta açın.
Ekranda görülen Standart bir sınıfın özellikler görünümündeki “API State” sekmesi: sistem içi kullanım sözleşmesinde (“Contract C1”) yayın durumu “Released”, bulut geliştirmede kullanım “Yes”.
Açıkladığı karar Genişletme seviyesi seçilirken dayanılan standart nesnenin bir sürüm sözleşmesi olup olmadığı bu sekmeden kontrol edilir ve karar kaydına yazılır.
Veri durumu Görselde iş verisi yok; bir SAP standart sınıfı ve kaynak kodu yorumu görünür. Proje etiketi ile son değişiklik alanları kaynak görselde SAP tarafından gizlenmiştir.
Ürün: ABAP Development Tools Kaynak: SAP-samples/abap-cheat-sheets © 2022 SAP SE or an SAP affiliate company and abap-cheat-sheets contributors Lisans: Apache License 2.0, değiştirilmeden kullanılmıştır
Adım 4: Bağımlılıklar yükseltmede neyi etkiler?
Bir genişletmenin yükseltme riski, dokunduğu nesnelerin kararlılığına bağlıdır. Yayımlanmış arayüzler teknik bir kararlılık sözleşmesiyle sunulur; SAP iç nesneleri için ise uzun vadeli kararlılık garantisi vermez [2]. Bu yüzden her genişletme için hangi standart nesnelere dayandığı ve bu nesnelerin hangi seviyede sınıflandığı listelenir.
Bağımlılık listesi, yükseltme testinin nereye odaklanacağını da belirler. Level C nesnelere dayanan genişletmelerde, yeni sürümde uyumsuz bir değişiklik olup olmadığı değişiklik günlüğü üzerinden kontrol edilir [2] ve bu kontrol yükseltme planına bir adım olarak yazılır.
Genişletmenin başka özel nesnelere bağımlılığı da listeye girer. Bir özel nesnede yapılan değişiklik, ona dayanan diğer genişletmeleri etkileyebilir; bu zincir görünmezse yükseltme testi yalnız standart nesnelere odaklanır ve asıl kırılma noktasını kaçırabilir.
Adım 5: Genişletmenin yaşam döngüsü nasıl planlanır?
Her genişletme bir gün değişecek veya kaldırılacaktır. Bu nedenle genişletme oluşturulurken sahibi, test yöntemi, belgelendiği yer ve hangi koşulda gözden geçirileceği, genişletme devreye alınmadan önce belirlenir. Standart yetenek zamanla ihtiyacı karşılar hâle gelirse genişletmenin emekliye ayrılması da bir seçenek olarak değerlendirilir.
Yaşam döngüsü kaydında bulunması gerekenler:
- iş sahibi ve teknik sahip
- genişletmeyi koruyan otomatik testlerin kapsamı
- gözden geçirme tetikleyicileri: yükseltme, süreç değişikliği, yeni standart yetenek
- kaldırma koşulu ve kaldırmanın etkileyeceği süreçler
- belgenin bulunduğu yer ve son güncellenme tarihi
Adım 6: Yönetişim nasıl kurulur?
Yönetişim, kararların tek tek kişilerin bilgisine bağlı kalmamasını sağlar. Hangi seviyedeki genişletmenin kimin onayıyla yapılabileceği, istisnaların nasıl kaydedileceği ve kuralların geliştirme sürecinde nasıl denetleneceği önceden yazılır. Kural yazılı değilse her talepte aynı tartışma yeniden yapılır ve kararlar, talebi en çok zorlayanın ısrarına göre şekillenebilir.
SAP, SAP Business Technology Platform (SAP BTP) üzerindeki ABAP ortamı için yayımladığı yönetişim önerisinde merkezi bir ATC kontrol sistemini, öncelik 1 ve 2 bulgular için geliştirme sisteminde engelleme modunu ve eski kod için muafiyet veya başlangıç çizgisi (baseline) kullanımını anlatır [4]. Bu öneri o ortam için yazılmıştır; benzer bir yönetişimin başka bir ortamda nasıl kurulacağı ürün ve sürüm kapsamına göre ayrıca değerlendirilir.
Castintech’in yaklaşımında üç kural öne çıkar: yeni geliştirmede kuralların baştan uygulanması, eski kodun ayrı bir başlangıç çizgisiyle izlenmesi ve her istisnanın gerekçesiyle birlikte kaydedilmesi. Böylece eski kodun yükü yeni geliştirmeyi engellemez; yeni geliştirme de eski kodun sorunlarını büyütmez.
Karar kaydı nasıl görünür?
Aşağıdaki şablon kurgusal bir örnekle doldurulmuştur; gerçek bir projeden alınmamıştır.
| Alan | Örnek içerik |
|---|---|
| Talep | Belirli bir belge türüne ek bir alan ve bu alana bağlı bir doğrulama kuralı eklenmesi |
| İş ihtiyacı | Kayıt sırasında eksik girilen bilginin sonraki adımlarda düzeltme işi yaratması |
| Standart yetenek kontrolü | Standart yapılandırma seçenekleri incelendi; kanıt türü: belgelenmiş deneme |
| Gerekçe | İhtiyaç süreç kalitesiyle ilgili, farklılaştırıcı bir süreç değil; önce süreç değişikliği değerlendirilir |
| Seçilen yol ve seviye | Yayımlanmış bir genişletme noktası kullanılabiliyorsa Level A; kullanılamıyorsa seçenekler ve etkileri ayrıca kaydedilir |
| Bağımlılıklar | Kullanılan standart nesneler ve seviyeleri; bağlı özel nesneler |
| Yaşam döngüsü | İş ve teknik sahip, test kapsamı, gözden geçirme tetikleyicisi, kaldırma koşulu |
| Onay | Onaylayan rol ve tarih |
| Varsayımlar | Doğrulanmamış varsayımlar ve doğrulama adımları |
Sık yapılan yanlış varsayımlar
- “Clean Core, özel kodun tamamen kaldırılması demektir.” Değildir. Amaç, genişletmelerin bilinçli seçilmesi ve kararlı yollarla yapılmasıdır; farklılaştırıcı bir süreç için genişletme doğru karar olabilir.
- “ATC bulgusu yoksa genişletme yükseltmeye hazırdır.” Bulgu olmaması, seçilen kontrol varyantının kapsamıyla sınırlıdır. İş mantığı, test kapsamı ve performans ayrıca değerlendirilir.
- “Seviye modeli her SAP ürününde aynı şekilde geçerlidir.” Model SAP Cloud ERP Private bağlamında tanımlanmıştır; başka bir ortamda kullanılacaksa kapsamı doğrulanmalıdır.
- “Level D genişletmeler hemen yeniden yazılmalıdır.” Önce kullanım ve gereklilik doğrulanır. Kullanılmayan bir genişletme için ilk seçenek emekliye ayırmaktır.
- “Bir kez onaylanan genişletme kalıcıdır.” Standart yetenek, süreç ve sürüm değiştikçe genişletmenin gerekçesi de yeniden değerlendirilir.
Kontrol listesi
- İş ihtiyacı, önerilen çözümden ayrı olarak yazıldı
- Standart yetenek kontrolü yapıldı ve kanıt türü kaydedildi
- Genişletmenin iş gerekçesi ve yaşam boyu yükü yazıldı
- Kullanılabilecek en yüksek seviye belirlendi; daha düşük seviye seçildiyse gerekçesi ve etkisi kaydedildi
- Seviye modelinin ortam için geçerliliği ürün ve sürüm kapsamına göre doğrulandı
- Standart ve özel nesnelere bağımlılıklar listelendi
- Yükseltme testinin odak noktaları belirlendi
- İş sahibi ve teknik sahip adlandırıldı
- Gözden geçirme tetikleyicileri ve kaldırma koşulu yazıldı
- Onay rolü ve istisna kaydı tamamlandı
Sınır notları
Bu rehber genel teknik açıklamadır. A–D seviye modeli ve ATC eşlemesi SAP belgelerine dayanır ve SAP Cloud ERP Private bağlamındadır. Diğer bölümler Castintech’in değerlendirme çerçevesidir ve SAP’nin görüşü olarak okunmamalıdır. Belirli bir süre, maliyet veya yükseltme sonucu iddia etmiyoruz. Ürüne bağlı bilgiler son doğrulama tarihinden sonra değişmiş olabilir.
Sık sorulan sorular
Level B veya Level C bir genişletme hatalı mıdır?
Hayır. SAP de belirli gereksinimler için daha düşük seviyelerin kullanılabileceğini, ancak yükseltme kararlılığı ve clean core uyumu üzerindeki etkisinin kabul edilmesi gerektiğini belirtir [2]. Önemli olan, seçimin gerekçesinin ve etkisinin kayıtlı olmasıdır.
Mevcut genişletmeler de bu çerçeveyle değerlendirilmeli mi?
Evet, özellikle bir yükseltme veya dönüşüm öncesinde. Ancak sıra farklıdır: önce kullanım ve sahiplik doğrulanır, kullanılmayan genişletmeler için ilk seçenek emekliye ayırmadır. Yöntem, özel kod envanteri rehberinde anlatılmıştır.
Seviye bilgisi nereden elde edilir?
Side-by-side genişletme her zaman daha mı iyidir?
Çekirdek sistemin dışında çalışan genişletmeler çekirdekten ayrışmayı kolaylaştırabilir; ancak ağ, yetki, izleme ve işletim yükü getirir. Seçim, genişletmenin çekirdek veriye ne kadar yakın çalışması gerektiğine ve kurumun işletim modeline bağlıdır.
Genişletme kararını kim vermeli?
Gereklilik kararını süreç sahibi, yol ve seviye kararını teknik mimari sorumlusu verir. Daha düşük bir seviyeyi gerektiren istisnalar önceden tanımlanmış bir rol tarafından onaylanır; aynı kişinin hem talep eden hem onaylayan olması önlenir.
İlgili sayfalar ve rehberler
- Özel kod envanteri ve teknik borç yaklaşımı: mevcut genişletmelerin envanterdeki yeri
- Özel kod envanterinin değerlendirilmesi: mevcut genişletmeleri önceliklendirme yöntemi
- Entegrasyon yaklaşımı: arayüz seçiminin yükseltme etkisi
- Dönüşüm öncesi teknik belirsizlikler
- Tüm teknik rehberler
Kaynakça
Metindeki köşeli parantez içindeki numaralar aşağıdaki kaynaklara işaret eder.
- 1
ERP clean core strategy — sap.com.
https://www.sap.com/products/erp/rise/methodology/clean-core.html
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 2
Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP beyaz kitabı, bölüm 3.3 (s. 19–22) ve dipnot 8 (s. 51).
https://www.sap.com/docs/download/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.pdf
Kaynak tarihi: belgede açık yayın tarihi yok; s. 52’de “(08/26)” ve “© 2026” ibaresi var Son doğrulama: 23.09.2026
- 3
Extensibility — help.sap.com, SAP Cloud ALM uygulama yardımı.
https://help.sap.com/docs/cloud-alm/applicationhelp/extensibility
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 4
Keep Clean Core Governance with ABAP Test Cockpit — help.sap.com, SAP BTP geliştirici rehberi.
https://help.sap.com/docs/btp/btp-developers-guide/keep-clean-core-governance-with-abap-test-cockpit
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 5
SAP Cloud ERP Private — sap.com ürün sayfası.
https://www.sap.com/products/erp/cloud-erp-private.html
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 6
SAP Business Technology Platform — sap.com ürün sayfası.
https://www.sap.com/products/technology-platform.html
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
Son doğrulama: 23 Eylül 2026
SAP and ABAP are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.
Bu içerik Castintech tarafından bağımsız olarak hazırlanmıştır.
Bağımsızlık notu
- Castintech, SAP SE ile ortaklık, yetkilendirme, onay veya sponsorluk ilişkisi iddia etmez.
- SAP ve bu sayfada geçen SAP ürün adları, SAP SE’nin veya iştiraklerinin ticari markalarıdır.
- Castintech’in sunduğu çalışma, bağımsız teknik danışmanlık ve destek kapsamındadır.