Bagaimana Tool Sprawl Muncul dan Apa yang Sebenarnya Mengendalikannya

Anda bergabung dengan tim baru. Mereka menggunakan CI server A. Tim di seberang lorong menggunakan CI server B. Satu tim menyimpan artefak di registry mereka sendiri. Tim lain menggunakan registry yang sama sekali berbeda. Semua orang punya alasan yang bagus: tumpukan teknologi mereka berbeda, mereka punya kebutuhan kepatuhan tertentu, atau mereka lebih suka alur kerja dari satu alat dibandingkan alat lainnya.

Pada awalnya, ini tampak baik-baik saja. Setiap tim mengirimkan kode. Setiap tim punya otonomi. Tidak ada yang menghalangi siapa pun.

Kemudian pekerjaan integrasi dimulai.

Tim A perlu menarik artefak dari registry Tim B. Formatnya tidak kompatibel. Tim C perlu mengakses rahasia yang dikelola oleh Tim D, tetapi alat manajemen rahasia tidak saling terhubung. Setiap kali tim baru terbentuk, seseorang harus mencari pola integrasi dari awal. Dokumentasi tersebar di wiki, utas Slack, dan file README. Ketika orang berpindah tim, pengetahuan tentang bagaimana hal-hal terhubung ikut lenyap bersama mereka. Mengaudit pipeline menjadi mimpi buruk karena tidak ada standar yang konsisten.

Inilah yang disebut tool sprawl. Dan ini bukan tentang jumlah alat.

Tool Sprawl Adalah Masalah Keputusan, Bukan Masalah Teknis

Tool sprawl terjadi ketika setiap tim memilih alat berdasarkan kebutuhan lokal tanpa mempertimbangkan bagaimana alat-alat tersebut akan bekerja sama dalam sistem yang lebih besar. Keputusan itu masuk akal bagi tim. Namun, hal itu menciptakan gesekan bagi organisasi.

Reaksi umum adalah dengan memusatkan semuanya. Pilih satu CI server. Satu artifact registry. Satu secret manager. Paksa setiap tim untuk menggunakannya. Ini menyelesaikan masalah integrasi tetapi menciptakan masalah baru: tim kehilangan kemampuan untuk memilih alat yang sesuai dengan pekerjaan mereka yang sebenarnya. Mereka mulai mencari cara untuk bekerja di sekitar alat yang diwajibkan. Shadow IT tumbuh. Orang-orang menemukan cara untuk melewati sistem.

Pendekatan yang lebih baik bukanlah menghilangkan pilihan. Ini tentang menyediakan referensi bersama yang membatasi pilihan tanpa menghilangkan fleksibilitas. Referensi itu disebut operating model.

Apa Sebenarnya Operating Model Itu

Operating model adalah serangkaian keputusan yang mendefinisikan standar, pola integrasi, dan batasan untuk pemilihan alat. Ini bukan buku aturan yang kaku. Ini adalah kesepakatan bersama tentang bagaimana alat terhubung dan persyaratan minimum apa yang harus mereka penuhi.

Tiga hal membentuk operating model yang praktis:

Standar. Ini mencakup dasar-dasar: format apa yang digunakan artefak, bagaimana rahasia diteruskan antar alat, protokol apa yang digunakan untuk komunikasi antar sistem. Standar tidak menentukan alat mana yang akan digunakan. Standar menentukan bagaimana alat harus berperilaku saat berinteraksi dengan alat lain.

Pola integrasi. Ini menggambarkan aliran data dan pemicu. Pola tipikal mungkin terlihat seperti: commit masuk ke repositori, CI server membaca konfigurasi dari repositori yang sama, build menghasilkan artefak dalam format yang ditentukan, artefak masuk ke registry yang ditunjuk, dan alat deployment menarik dari registry tersebut. Polanya sama terlepas dari CI server atau alat deployment mana yang digunakan.

Batas untuk pemilihan alat. Ini menentukan kategori alat mana yang diizinkan, atau setidaknya kriteria minimum apa yang harus dipenuhi alat baru sebelum dapat digunakan. Sebuah batasan mungkin mengatakan: alat CI apa pun harus mendukung pembacaan konfigurasi dari repositori, harus menghasilkan artefak dalam format yang disepakati, dan harus terintegrasi dengan penyimpanan rahasia bersama. Jika suatu alat memenuhi kriteria tersebut, tim dapat memilihnya.

Operating model tidak harus sempurna dari hari pertama. Ia harus ada dan dipelihara. Ketika alat baru yang benar-benar lebih baik muncul, modelnya dapat diperbarui. Tujuannya bukan untuk membekukan toolchain. Tujuannya adalah memastikan setiap alat dapat berkomunikasi dengan alat lainnya tanpa pekerjaan integrasi khusus setiap saat.

Portal Developer sebagai Mekanisme Pengiriman

Operating model di atas kertas hanyalah dokumentasi. Ia menjadi berguna ketika tertanam dalam cara kerja pengembang yang sebenarnya. Salah satu cara praktis untuk melakukan ini adalah melalui developer portal.

Developer portal bukan sekadar katalog alat. Portal yang baik terhubung ke golden path: rute standar dan teruji untuk membawa perubahan dari kode ke produksi. Ketika seorang pengembang ingin membuat pipeline baru, portal menunjukkan langkah-langkah yang harus diikuti, alat apa yang tersedia di setiap langkah, dan seperti apa konfigurasi standarnya. Pengembang tidak perlu mencari tahu integrasi dari awal. Portal menyediakan pola yang siap pakai.

Portal juga membuat operating model terlihat. Tim dapat melihat alat apa yang digunakan orang lain. Mereka dapat melihat integrasi mana yang didukung. Mereka dapat melihat standar yang harus mereka ikuti. Visibilitas ini mengurangi kemungkinan tim secara diam-diam mengadopsi alat yang tidak sesuai dengan model.

Cara Memulai Tanpa Over-Engineering

Anda tidak memerlukan dokumen operating model yang lengkap sebelum memulai. Anda memerlukan kesepakatan kerja kecil yang dapat Anda perluas seiring waktu.

Mulailah dari titik integrasi yang paling menyakitkan. Mungkin itu format artefak. Mungkin itu manajemen rahasia. Pilih satu area di mana tim sudah kesulitan untuk terhubung. Setujui standar untuk satu hal itu. Dokumentasikan. Buatlah terlihat. Kemudian lanjutkan ke titik sakit berikutnya.

Ketika sebuah tim ingin membawa alat baru, ajukan tiga pertanyaan:

• Apakah alat tersebut memenuhi standar yang ada?
• Dapatkah ia mengikuti pola integrasi yang disepakati?
• Apa yang akan rusak jika kita menambahkannya?

Jika jawabannya tidak jelas, itu adalah sinyal bahwa operating model perlu diperbarui atau alat tersebut tidak cocok. Bagaimanapun, percakapan menjadi tentang model, bukan tentang alat.

Daftar Periksa Cepat untuk Mencegah Tool Sprawl

• Identifikasi tiga titik sakit integrasi teratas di toolchain Anda saat ini
• Setujui satu standar untuk setiap titik sakit (format, protokol, atau antarmuka)
• Dokumentasikan standar di tempat yang dapat diakses oleh setiap tim
• Tentukan kriteria minimum untuk alat baru di setiap kategori
• Tinjau model setiap tiga bulan dan perbarui ketika alat atau kebutuhan berubah

Intisari Konkret

Tool sprawl tidak diselesaikan dengan melarang pilihan atau dengan membeli platform yang menjanjikan untuk menyatukan semuanya. Ini diselesaikan dengan membuat ekspektasi integrasi menjadi eksplisit. Sebuah operating model memberikan kebebasan kepada tim dalam batasan yang menjaga sistem tetap berfungsi secara keseluruhan. Mulailah dengan satu standar, buatlah terlihat, dan biarkan model tumbuh dari titik gesekan yang nyata. Tujuannya bukan alat yang lebih sedikit. Tujuannya adalah alat yang benar-benar bekerja sama.