Bandingkan tanggung jawab sebelum produk

Bandingkan hasil yang sama

Pilihan alat prototipe tidak harus menentukan model operasi produksi. Orang dapat bereksplorasi dengan alat yang sesuai untuk pekerjaannya. Organisasi tetap memerlukan cara yang didukung untuk mengamankan, melakukan deployment, memelihara, dan mengoperasikan hasil yang berguna.

Asisten pemrograman, platform internal, dan software factory dapat menyelesaikan bagian masalah yang berbeda. Membandingkan harga langganan tanpa menentukan cakupan dapat menghasilkan keputusan menyesatkan.

Mulai dari hasil yang diperlukan: mengirimkan dan mengoperasikan layanan internal sesuai persyaratan data, keamanan, dan keandalan perusahaan. Lalu identifikasi pekerjaan yang diperlukan sepanjang siklus hidup. Sertakan pekerjaan setelah demonstrasi pertama berhasil.

Untuk layanan kontrak fiktif, organisasi memerlukan persyaratan yang disetujui, akses karyawan, data privat, rilis terverifikasi, respons insiden, dan pembaruan berkelanjutan. Alat yang menghasilkan endpoint menangani sebagian dari daftar ini.

Jelaskan tiga model operasi yang masuk akal

Dengan asisten pemrograman, pengembang menggunakan AI dalam sistem engineering yang sudah ada. Organisasi menyediakan proses pendukung, integrasi, kemampuan platform, dan pengumpulan bukti. Model ini dapat sesuai bagi organisasi dengan layanan bersama yang matang.

Dengan sistem pengiriman yang dirakit secara internal, organisasi mengintegrasikan agen, konteks, pemeriksaan, deployment, dan umpan balik operasi. Organisasi mendapatkan kendali atas desain sekaligus bertanggung jawab atas produk integrasi, dukungan, dan upgrade-nya.

Dengan software factory yang dibeli, pemasok menyediakan alur kerja terhubung dengan cakupan lebih luas. Verifikasi cakupan yang sebenarnya dan integrasi yang didukung. Organisasi tetap memerlukan keputusan produk dan pembagian tanggung jawab yang eksplisit.

Ini model perbandingan, bukan kategori produk universal. Pemasok atau platform internal tertentu dapat menggabungkan kemampuan dengan cara berbeda.

Verifikasi jalur dari prototipe menuju layanan yang beroperasi

Gunakan skenario konkret yang sama untuk setiap opsi. Untuk prototipe perbankan, mulai dengan transaksi sintetis tanpa izin ke sistem aktif. Minta tim atau pemasok mendemonstrasikan kemampuan berikut sebelum memperluas akses:

1. Nilai prototipe dan identifikasi kode yang perlu diubah atau diganti.
2. Lakukan deployment ke infrastruktur yang diperlukan, termasuk akun cloud sendiri jika diwajibkan kebijakan.
3. Verifikasi izin aplikasi, penanganan secret, serta aliran data pengembangan dan runtime.
4. Hasilkan bukti terhadap persyaratan yang berlaku dan catat keputusan rilis.
5. Pantau layanan, perbaiki kerentanan, uji pemulihan, dan tanggapi insiden.

Memindahkan kode ke akun Anda merupakan satu bagian dari pekerjaan ini. Verifikasi siapa yang dapat mengelola lingkungan dan lokasi layanan eksternal menerima data. Sesuaikan kontrol dengan kewajiban Anda; lokasi deployment saja tidak membuktikan kepatuhan.

Untuk batas yang dinyatakan oleh salah satu pemasok, bandingkan penjelasan tanggung jawab bersama Taiga dengan peta Anda. Materi ini milik penerbit. Verifikasi perjanjian dan konfigurasi yang berlaku sebelum mengaktifkan Taiga.

Pisahkan pelaksanaan, pemeriksaan, dan keputusan

Untuk setiap aktivitas, catat siapa yang melaksanakan, memverifikasi hasil, dan menerima dampaknya. Satu pihak dapat memegang beberapa peran, tetapi peran yang kosong merupakan kekurangan.

Layanan cloud juga membagi tanggung jawab antara penyedia dan pelanggan. Pembagian tepatnya bergantung pada layanan. Gunakan hal ini sebagai alasan untuk meminta peta yang tepat, bukan untuk berasumsi bahwa setiap produk terkelola memiliki batas yang sama. Tanggung jawab bersama AWS.

Cari kekurangan dan pekerjaan yang berulang

Misalkan pemasok menghasilkan pipeline sementara tim platform sudah memelihara jalur deployment yang disetujui. Putuskan apakah pemasok perlu menggunakan jalur tersebut. Dua pipeline yang dipelihara secara terpisah dapat menimbulkan kontrol yang bertentangan dan biaya yang tidak perlu.

Sebaliknya, pemasok mungkin berasumsi bahwa pelanggan memiliki tim insiden, sementara pelanggan menganggap operasi sudah termasuk. Selesaikan kekurangan ini sebelum pengguna bergantung pada layanan.

Panduan platform CNCF memungkinkan organisasi menggabungkan kemampuan internal dan terkelola. Pertanyaan yang relevan adalah apakah pengalaman yang dihasilkan memenuhi kebutuhan pengguna dengan tanggung jawab yang jelas. Panduan CNCF.

Gunakan peta dalam keputusan komersial

Lampirkan peta tanggung jawab pada catatan evaluasi dan perjelas dalam perjanjian yang berlaku. Hitung biaya pekerjaan yang tetap ditangani organisasi Anda. Sertakan biaya pemeliharaan koneksi antarkomponen.

Pemasok dengan cakupan lebih luas dapat bernilai ketika mengurangi pekerjaan integrasi dan mempertahankan bukti sepanjang siklus hidup. Pendekatan internal dapat bernilai ketika persyaratan unik membenarkan tanggung jawab berkelanjutan. Putuskan berdasarkan hasil yang diperlukan dan cakupan yang terverifikasi.