Mengapa Membiarkan Setiap Tim Membangun Pipeline Sendiri Justru Merugikan

Bayangkan ini: organisasi Anda memiliki lima tim yang searah aliran (stream-aligned teams). Setiap tim membangun pipeline CI/CD mereka sendiri dari awal. Satu tim memilih Jenkins, yang lain menggunakan GitLab CI, tim ketiga bersumpah setia pada GitHub Actions. Setiap tim memiliki cara sendiri dalam mengelola lingkungan staging, deploy ke produksi, dan menyimpan rahasia seperti kunci API atau kata sandi database.

Pada awalnya, ini terlihat seperti kebebasan. Tim bergerak cepat. Mereka memilih apa yang cocok untuk mereka. Tidak ada yang terhambat menunggu tim pusat.

Namun setelah beberapa bulan, pola-pola ini mulai terasa menyakitkan. Sebuah kerentanan keamanan ditemukan di salah satu pipeline. Tim keamanan sekarang harus mendatangi setiap tim satu per satu karena tidak ada cara standar untuk menerapkan perbaikan. Seorang pengembang pindah ke tim lain dan harus mempelajari pipeline yang benar-benar baru dari awal. Tim operasi mencoba memantau kesehatan aplikasi di seluruh organisasi, tetapi setiap tim mengirimkan log dalam format yang berbeda.

Ini bukan kebebasan. Ini adalah fragmentasi yang menyamar sebagai otonomi.

Masalah Membangun Segalanya dari Awal

Ketika setiap tim membangun pipeline mereka sendiri secara independen, organisasi membayar pajak tersembunyi. Pajak ini muncul dalam beberapa cara:

• Perbaikan keamanan memakan waktu lebih lama. Tidak ada satu tempat pun untuk memperbarui dependensi bersama atau memperbaiki kerentanan umum.
• Transfer pengetahuan melambat. Pindah antar tim berarti mempelajari ulang alur kerja deploy, bukan hanya domain bisnis.
• Visibilitas operasional terganggu. Pemantauan, pencatatan log, dan peringatan menjadi tidak konsisten antar tim.
• Audit dan kepatuhan menjadi menyakitkan. Setiap tim mendokumentasikan prosesnya sendiri, dan tidak ada pandangan terpadu tentang bagaimana perubahan bergerak ke produksi.

Akar masalahnya bukan karena tim tidak kompeten. Akar masalahnya adalah setiap tim memecahkan masalah infrastruktur yang sama berulang kali. Mereka menghabiskan energi pada plumbing (urusan teknis infrastruktur) alih-alih pada produk.

Apa yang Sebenarnya Dilakukan oleh Platform Team

Platform team ada untuk memutus siklus ini. Tugas utamanya adalah membangun dan memelihara kemampuan bersama (shared capabilities) yang dapat digunakan oleh semua tim yang searah aliran. Kemampuan-kemampuan ini membentuk apa yang sering disebut sebagai platform internal.

Platform ini dapat mencakup:

• Pipeline CI/CD yang terstandarisasi
• Templat untuk lingkungan pengembangan dan staging
• Perangkat deployment
• Pemantauan dan pencatatan log terpusat
• Sistem manajemen rahasia bersama

Namun inilah perbedaan kritisnya: platform team tidak mengerjakan pekerjaan tim yang searah aliran. Mereka tidak men-deploy aplikasi. Mereka tidak memutuskan kapan rilis terjadi. Mereka tidak menulis fitur bisnis.

Platform team membangun fondasi. Tim yang searah aliran membangun di atasnya.

Jebakan Hambatan (Bottleneck Trap)

Ada kesalahan umum yang dilakukan organisasi ketika pertama kali membentuk platform team. Mereka memperlakukan platform team sebagai tim yang men-deploy segalanya. Jika tim yang searah aliran perlu merilis versi baru, mereka membuka tiket dan menunggu platform team melakukannya.

Ini mengubah platform team menjadi hambatan. Sekarang tim yang searah aliran mengantre, menunggu platform team memiliki waktu luang. Tujuan utama memiliki platform team adalah untuk mempercepat delivery, bukan memperlambatnya.

Model yang benar adalah self-service. Platform team menyediakan kemampuan yang dapat digunakan sendiri oleh tim yang searah aliran. Platform team mendefinisikan antarmuka, API, templat. Tim yang searah aliran menjalankan pipeline, membuat keputusan, dan memiliki hasilnya.

Jika ada yang rusak di pipeline, tim yang searah aliran melaporkannya ke platform team. Mereka tidak memperbaiki infrastruktur sendiri. Namun mereka juga tidak menunggu izin untuk deploy.

Bagaimana Platform Team Berkembang

Platform team tidak bisa statis. Kebutuhan tim yang searah aliran berubah seiring waktu.

Di awal, pipeline sederhana yang membangun, menguji, dan men-deploy mungkin sudah cukup. Namun seiring pertumbuhan organisasi, tim mulai membutuhkan lebih banyak. Satu tim membutuhkan pengujian integrasi dengan database nyata. Tim lain membutuhkan lingkungan staging yang mirip dengan produksi. Tim ketiga membutuhkan canary deployment untuk meluncurkan perubahan secara bertahap.

Platform team harus mendengarkan kebutuhan ini dan mengembangkan platform yang sesuai. Ini bukan pembangunan satu kali. Ini adalah hubungan berkelanjutan antara platform team dan tim-tim yang dilayaninya.

Platform team juga tidak bekerja sendiri. Mereka sering berkolaborasi dengan enabling team untuk meningkatkan kemampuan tertentu. Mereka mungkin bekerja dengan complicated-subsystem team ketika bagian dari platform membutuhkan keahlian mendalam, seperti replikasi database atau keamanan jaringan.

Apa yang Berubah Ketika Anda Melakukannya dengan Benar

Ketika platform team bekerja dengan baik, tim yang searah aliran dapat fokus pada aliran nilai (value stream) mereka. Mereka tidak perlu khawatir tentang cara mengatur server untuk pipeline. Mereka tidak perlu memikirkan cara mengamankan akses ke produksi. Mereka tidak perlu mencari cara untuk mengumpulkan log dari setiap aplikasi.

Semua itu ditangani oleh platform. Tim yang searah aliran menulis kode, menjalankan pipeline, dan mengirimkan fitur. Platform menangani sisanya.

Ini bukan tentang mengambil otonomi. Ini tentang menghilangkan duplikasi yang tidak perlu. Tim masih memiliki keputusan deploy mereka. Mereka masih memutuskan kapan akan merilis. Mereka hanya tidak perlu menemukan kembali infrastruktur setiap saat.

Daftar Periksa Singkat untuk Memulai Platform Team

Jika Anda mempertimbangkan untuk membentuk platform team, berikut beberapa hal yang perlu diperiksa sejak awal:

• Mulailah dari titik sakit terbesar. Jangan mencoba membangun platform yang lengkap pada hari pertama. Pilih satu kemampuan yang diperjuangkan oleh setiap tim, seperti manajemen rahasia atau templat deployment, dan selesaikan itu terlebih dahulu.
• Rancang untuk self-service. Jika platform team Anda menjadi gerbang yang harus ditunggu semua orang, Anda telah menciptakan hambatan baru. Setiap kemampuan harus dapat digunakan oleh tim yang searah aliran tanpa membuka tiket.
• Ukur adopsi, bukan fitur. Platform dengan banyak fitur yang tidak digunakan siapa pun adalah kewajiban. Lacak berapa banyak tim yang benar-benar menggunakan platform, dan dengarkan mengapa yang lain tidak mengadopsinya.
• Rencanakan evolusi. Platform perlu berubah seiring pertumbuhan tim. Bangun umpan balik sehingga platform team mendengar apa yang berhasil dan apa yang hilang.

Kesimpulan

Platform team bukan tentang memusatkan kendali. Ini tentang memusatkan pekerjaan infrastruktur yang membosankan dan berulang sehingga tim yang searah aliran dapat fokus pada hal yang penting: memberikan nilai kepada pengguna. Jika dilakukan dengan benar, platform team membuat setiap tim lain lebih cepat, lebih aman, dan lebih konsisten. Jika dilakukan dengan salah, ia menjadi antrean lain yang harus ditunggu.

Perbedaannya adalah apakah Anda membangun fondasi atau gerbang. Bangunlah fondasi.