Belajar Platform Engineer - Scorecard & Maturity Platform

#Pendahuluan

Di episode 22 platform sudah dikelola seperti produk dengan roadmap dan KPI. Tapi bagaimana tahu seberapa matang platform itu? Dan bagaimana menilai setiap service di dalamnya secara konsisten? Episode ini membahas scorecard & maturity platform — platform maturity model, scorecards di Backstage, dan metrik adopsi yang membedakan platform yang hidup dari platform yang sekadar ada.

Mengapa ini penting? "Semua aman" adalah penilaian subjektif; scorecard mengubahnya menjadi angka. Maturity model memberi peta perjalanan — di mana kalian sekarang dan apa langkah berikutnya. Tanpa keduanya, perbaikan platform mengikuti intuisi yang sering meleset, dan service-service tua yang melenceng dari standar tidak pernah terlihat.

#Platform Maturity Model

CNCF Platform Engineering Maturity Model menilai platform pada lima dimensi, masing-masing dengan level 0-4:

Dimensi	Level 0-1	Level 3-4
Automation	Provisioning manual, banyak klik	Everything-as-code, self-service penuh
Autonomy	Developer menunggu tiket	Developer mandiri di golden path
Resilience	Perbaikan reaktif	SLO + error budget aktif (ep. 17)
Security	Per-meter bolong	Zero trust, policy-as-code (ep. 16-20)
User experience	Portal sekadar link	Golden path + AI-assist (ep. 12, 21)

Maturity bukan "mencapai level 4 di semua dimensi" — itu target jangka panjang. Nilai utamanya adalah menunjukkan ketimpangan: misalnya automation sudah 4 tapi UX masih 1, jelas di mana harus fokus kuartal ini.

#Scorecards: Nilai untuk Setiap Service

Scorecard di Backstage (episode 6) menilai tiap entity service terhadap seperangkat aturan, menghasilkan skor dan checklist yang bisa ditindaklanjuti. Contoh aturan untuk service:

Aturan	Kriteria lolos
Ownership	Punya owner di catalog (entity owner terisi)
Documentation	Memiliki TechDocs (ep. 24)
CI/CD	Terdaftar di pipeline platform (ep. 7)
Security baseline	Image di-scan & ter-sign (ep. 19)
Observability	Punya dashboard dan alerting (ep. 9)
Cost	Punya label biaya/team (ep. 11)

backstage/scorecards/platform-baseline.yaml

apiVersion: backstage.io/v1alpha1
kind: Scorecard
metadata:
  name: platform-baseline
  title: Platform Baseline
spec:
  rules:
    - title: Ownership
      kind: Component
      checks:
        - entity.owner
    - title: TechDocs
      kind: Component
      checks:
        - entity.metadata.annotations.backstage.io/techdocs-ref
    - title: CI registered
      kind: Component
      checks:
        - entity.metadata.annotations["platform/pipeline"]

Skor ditampilkan di halaman service: developer langsung tahu "service kalian 3/6" dan link untuk memperbaiki. Tanpa menghakimi — scorecard adalah GPS, bukan vonis.

#Metrik Adopsi Platform

Maturity dan scorecard berujung pada satu pertanyaan: apakah platform dipakai? Metrik adopsi yang perlu dipantau:

Metrik	Definisi
Golden path adoption	% deploy lewat jalur standar (bukan manual)
Catalog coverage	% service yang terdaftar di catalog
Self-service rate	% request tanpa intervensi manusia (ep. 12)
Scorecard average	Rata-rata skor semua service
Time-to-provision	Waktu environment siap

Kombinasi yang penting: adopsi tinggi + maturity rendah = developer terpaksa memakai platform yang belum siap; maturity tinggi + adopsi rendah = platform hebat yang tidak dikenal. Keduanya membutuhkan aksi yang berbeda.

#Praktik: Membangun Scorecard Pertama

Mulai dari 3-5 aturan yang paling sesuai dengan kondisi nyata (misal: ownership, docs, pipeline terdaftar).
Ambil 10 service terbaik sebagai pilot — hitung skor baseline.
Tunjukkan hasil ke tim; jadikan target "meningkatkan rata-rata skor", bukan "memaksa 100%".
Perluas aturan seiring platform matang; aturan baru lewat PR ke repo policy/catalog.

Output dashboard scorecard

Service          Score    Detail
payments-api     5/6      Kekurangan: TechDocs
orders-svc       6/6      Semua baseline terpenuhi
inventory        2/6      Owner kosong, no docs, no pipeline

#Common Pitfalls

Scorecard sebagai alat hukuman — skor rendah bikin developer menghindari platform; bingkai sebagai perbaikan, bukan grading.
Aturan yang tidak bisa dicapai — scorecard penuh aturan ideal yang bahkan platform tidak penuhi; mulai dari yang realistis.
Maturity dinilai sekali, lalu dilupakan — maturity model harus dievaluasi tiap kuartal dengan bukti.
Mengukur adopsi tanpa baseline — "adopsi naik" tidak bermakna jika tidak tahu angka awalnya.
Scorecard tanpa jalur perbaikan — setiap aturan gagal harus punya dokumentasi cara memperbaikinya.

Tip

Mulai dari scorecard kecil yang bisa dicapai. Satu dashboard Backstage dengan 3-5 aturan yang realistis lebih berharga daripada maturity model 5 dimensi yang tidak pernah dievaluasi. Angka pertama yang kalian ukur hari ini adalah baseline yang akan membuktikan dampak platform di masa depan.

#Penutup

Inti yang harus dibawa pulang:

Maturity model (automation, autonomy, resilience, security, UX) memberi peta perjalanan platform.
Scorecards di Backstage menilai tiap service terhadap aturan yang jelas — GPS, bukan vonis.
Metrik adopsi (golden path, catalog, self-service rate) menunjukkan apakah platform dipakai.
Kombinasi adopsi vs maturity menentukan aksi yang tepat.
Mulai kecil, ukur baseline, dan perluas seiring kematangan platform.

Di episode 24 selanjutnya kita masuk ke hati pengalaman developer: developer experience (DevEx) — feedback loops yang cepat, dokumentasi sebagai produk, dan pengurangan toil yang membuat developer tidak ingin kembali ke cara lama!