Daftar-periksa untuk menghindari penguncian vendor?

Apakah ada seperangkat aturan yang disetujui industri untuk menghindari vendor lock-in?

Maksud saya, sesuatu yang bisa ditunjukkan kepada seorang manajer, atau pembuat keputusan lain, yang mudah dimengerti dan mudah diverifikasi.

Apakah ada seperangkat aturan yang diterima secara universal, daftar periksa atau serangkaian kondisi yang membantu mendeteksi dan mencegah vendor terkunci dengan cara yang objektif dan terukur?
Adakah di antara Anda yang memperingatkan manajer tentang risiko vendor terkunci selama tahap awal proyek?

management decisions risk

— Tulains Córdova
sumber

kunci vendor belum tentu merupakan "hal buruk"

— Ryathal

Ini adalah pertanyaan bagus yang mengejutkan, yang relevan dengan sekelompok besar pengembang. Seringkali Anda tidak tahu Anda memiliki masalah ini sampai terlambat.

— joshin4colours

Bukankah pertanyaan ini memerlukan klarifikasi lebih lanjut mengenai bidang tertentu yang ingin Anda hindari lockin vendor. Kalau tidak, jawaban yang dapat diberikan oleh siapa pun adalah akal sehat (mis. Tambahkan tidak ada nilai).

— Dunk

@Ryathal Oct: Bagaimana mengunci (pembatasan opsi, pilihan masa depan) tidak buruk?

— Giorgio

@Giorgio karena kontrak dukungan lebih penting di dunia bisnis daripada kemampuan untuk berubah, begitu sistem bekerja bagian fakta A dapat ditukar dengan bagian X tidak relevan karena tidak ada yang akan melakukan itu sampai ada senjata yang dipegang di kepalanya.

— Ryathal

Jawaban:

Dalam pekerjaan saya sebagai konsultan, saya sering memperingatkan klien tentang risiko vendor terkunci. Ini dari pengalaman pahit dipanggil untuk membalikkan proyek yang gagal: jika Anda tidak memikirkan hal ini pada awalnya, maka mungkin akan dikenakan biaya dalam jangka panjang.

Tidak ada "daftar periksa standar" tetapi di sini ada daftar periksa bagus untuk hal-hal utama yang saya cari:

Open API : apakah API yang akan kita gunakan (yaitu membangun ketergantungan) terbuka dalam arti dapat diimplementasikan secara bebas oleh vendor yang bersaing?
Kepatuhan standar - apakah produk sesuai dengan standar industri yang relevan?
Adanya alternatif yang kompatibel - Apakah sebenarnya ada produk lain yang kompatibel (baik komersial atau open source) yang bisa kita ganti dengan perubahan minimal?
Open source - apakah kode open source vendor (yaitu di bawah lisensi OSI yang disetujui )?
Kemandirian platform - apakah teknologi tumpukan portable di berbagai platform?
Fleksibilitas kontrak - dapatkah kita mengakhiri atau memperkecil kontrak lebih awal tanpa penalti yang berarti?
Penyediaan layanan independen - apakah ada opsi yang dapat dipercaya untuk membeli layanan dari vendor yang berbeda (yaitu bukan hanya vendor asli)
Kemampuan dan keterampilan - jika kita ingin berpisah dengan vendor asli, apakah kita memiliki kemampuan dan keterampilan yang diperlukan untuk terus bekerja secara efektif baik in-house atau dengan vendor lain?
Catatan perilaku yang baik - apakah vendor memiliki rekam jejak yang baik yang menunjukkan bahwa Anda dapat memercayai mereka untuk tidak mengeksploitasi penguncian apa pun yang mungkin mereka peroleh?
Stabilitas persyaratan - apakah persyaratan kita didefinisikan dengan baik dan cenderung tetap sama? (jika demikian, Anda dapat mengontrak untuk persyaratan ini di muka dan penguncian vendor tidak penting ...)

Jika jawabannya adalah ya untuk sebagian besar atau semua pertanyaan ini, Anda dapat memastikan menghindari vendor lock-in. Jika tidak, Anda harus berhati-hati.

— mikera
sumber

Ini adalah beberapa pedoman yang saya gunakan ketika mengevaluasi kunci:

Apakah vendor menggunakan format standar industri?

Jika Anda berakhir dengan berton-ton file dan kode yang harus berbicara bahasa asing, maka beralih sangat sulit. Jika Anda memiliki format standar seperti XML dan JSON tidak demikian. Misalnya ASP. Net menggunakan aspx, yang merupakan markup yang bukan html, juga bukan XML yang valid. Ini membuatnya sangat sulit untuk mengonversi file-file tersebut atau menguraikannya.

Apakah vendor menyediakan poin yang cukup untuk diintegrasikan dengan sistem mereka?

Bisakah Anda membebaskan data Anda dari sistem, dan mengintegrasikannya dengan sistem Anda sendiri melalui beberapa bentuk interoperasi, seperti layanan web? Jika Anda ingin mengintegrasikannya dengan sistem Anda, apakah Anda perlu menambahkan lebih banyak produk vendor dengan harga premium?

Seberapa sulit untuk mengubah solusi untuk yang lain?

Pemeriksaan kewarasan yang konstan diperlukan untuk melihat betapa sulitnya untuk menjauh dari vendor. Jika barang vendor meliputi seluruh infrastruktur Anda, Anda harus lelah.

— Tjaart
sumber

Aspek non-teknis lainnya adalah: apa catatan rekam jejak vendor sehubungan dengan menanggapi permintaan terkait-penguncian. Beberapa vendor lebih baik daripada yang lain.

— Joachim Sauer

Singkatnya, saya akan mencari ulasan dan umpan balik tentang vendor dan produk.

Secara teknis, penguncian vendor terjadi ketika proyek memiliki kopling ketat dengan vendor (produk pihak ketiga).

Bagaimana cara menghindarinya? Dengan memiliki alternatif dan meneliti satu pertanyaan tentang setiap alternatif - Seberapa sulit untuk mengubah solusi untuk yang lain?

Selain detail teknis produk yang dipromosikan vendor, sangat penting untuk mengetahui jalur kesuksesan / kegagalan yang dimiliki pelanggan lain dengan vendor ini. Mungkin terlihat sulit (Goggling, membaca ulasan, mengidentifikasi seberapa asli review, dll.) Untuk dicapai. Namun, ada sistem peringkat yang kredibel di AS yang disebut BBB (Better business Bureau) .

Catatan perusahaan yang berbasis di AS di Biro independen ini sangat berguna dan 95% mencerminkan kenyataan. Jadi, saya akan sangat menyarankan untuk memeriksa dengan mereka juga.

— EL Yusubov
sumber

Saya ragu untuk memilih ini karena ini bukan "salah", tetapi jawaban Anda tidak benar-benar menjawab pertanyaan itu. Penguncian vendor tidak ada hubungannya dengan BBB.

Klarifikasi bagian yang hilang dari detail teknis.

— EL Yusubov

Suntingan yang bagus - lebih langsung menjawab pertanyaan sekarang