Motivasi awal motivasi - Dasar-dasar Arsitektur SaaS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Motivasi awal motivasi

Untuk memahami SaaS, mari kita mulai dengan gagasan yang cukup sederhana tentang apa yang ingin kita capai saat membuat bisnis SaaS. Tempat terbaik untuk memulai adalah dengan melihat bagaimana perangkat lunak tradisional (non-SaaS) telah dibuat, dikelola, dan dioperasikan.

Diagram berikut memberikan pandangan konseptual tentang bagaimana beberapa vendor telah mengemas dan menyampaikan solusi mereka.

Diagram yang menggambarkan model klasik untuk pengemasan dan memberikan solusi perangkat lunak.

Model klasik untuk pengemasan dan memberikan solusi perangkat lunak

Dalam diagram ini, kami telah menjelaskan kumpulan lingkungan pelanggan. Pelanggan ini mewakili berbagai perusahaan atau entitas yang telah membeli perangkat lunak vendor. Masing-masing pelanggan ini pada dasarnya berjalan di lingkungan mandiri di mana mereka telah menginstal produk penyedia perangkat lunak.

Dalam mode ini, instalasi setiap pelanggan diperlakukan sebagai lingkungan mandiri yang didedikasikan untuk pelanggan itu. Ini berarti bahwa pelanggan melihat diri mereka sebagai pemilik lingkungan ini, berpotensi meminta penyesuaian satu kali atau konfigurasi unik yang mendukung kebutuhan mereka.

Salah satu efek samping yang umum dari pola pikir ini adalah bahwa pelanggan akan mengontrol versi produk yang mereka jalankan. Ini dilakukan karena berbagai alasan. Pelanggan mungkin khawatir tentang fitur baru, atau khawatir tentang gangguan yang terkait dengan mengadopsi versi baru.

Anda dapat membayangkan bagaimana dinamika ini dapat memengaruhi jejak operasional penyedia perangkat lunak. Semakin Anda mengizinkan pelanggan untuk memiliki lingkungan satu kali, semakin menantang untuk mengelola, memperbarui, dan mendukung berbagai konfigurasi setiap pelanggan.

Kebutuhan akan lingkungan satu kali ini seringkali mengharuskan organisasi untuk membuat tim khusus yang menyediakan pengalaman manajemen dan operasi terpisah untuk setiap pelanggan. Sementara beberapa sumber daya ini mungkin dibagi di seluruh pelanggan, model ini umumnya memperkenalkan biaya tambahan untuk setiap pelanggan baru yang onboarded.

Memiliki setiap pelanggan menjalankan solusi mereka di lingkungan mereka sendiri (di cloud atau di tempat) juga berdampak biaya. Meskipun Anda dapat mencoba menskalakan lingkungan ini, penskalaan akan terbatas pada aktivitas satu pelanggan. Pada dasarnya, pengoptimalan biaya Anda terbatas pada apa yang dapat Anda capai dalam lingkup lingkungan pelanggan individu. Ini juga berarti bahwa Anda mungkin memerlukan strategi penskalaan terpisah untuk mengakomodasi variasi aktivitas antar pelanggan.

Awalnya, beberapa bisnis perangkat lunak akan melihat model ini sebagai konstruksi yang kuat. Mereka menggunakan kemampuan untuk menyediakan kustomisasi satu kali sebagai alat penjualan, memungkinkan pelanggan baru untuk memaksakan persyaratan yang unik untuk lingkungan mereka. Sementara jumlah pelanggan dan pertumbuhan bisnis tetap sederhana, model ini tampaknya sangat berkelanjutan.

Namun, ketika perusahaan mulai memiliki kesuksesan yang lebih luas, kendala model ini mulai menciptakan tantangan nyata. Bayangkan, misalnya, skenario di mana bisnis Anda mencapai lonjakan pertumbuhan yang signifikan yang membuat Anda menambahkan banyak pelanggan baru dengan cepat. Pertumbuhan ini akan mulai menambah overhead operasional, kompleksitas manajemen, biaya, dan sejumlah masalah lainnya.

Pada akhirnya, overhead kolektif dan dampak dari model ini dapat mulai secara fundamental merusak keberhasilan bisnis perangkat lunak. Titik nyeri pertama mungkin efisiensi operasional. Kepegawaian tambahan dan biaya yang terkait dengan membawa pelanggan mulai mengikis margin bisnis.

Namun, masalah operasional hanyalah bagian dari tantangan. Masalah sebenarnya adalah bahwa model ini, sesuai skala, secara langsung mulai memengaruhi kemampuan bisnis untuk merilis fitur-fitur baru dan mengimbangi pasar. Ketika setiap pelanggan memiliki lingkungan mereka sendiri, penyedia harus menyeimbangkan sejumlah pembaruan, migrasi, dan persyaratan pelanggan saat mereka mencoba untuk memperkenalkan kemampuan baru ke dalam sistem mereka.

Ini biasanya mengarah ke siklus rilis yang lebih lama dan lebih kompleks, yang cenderung mengurangi jumlah rilis yang dibuat setiap tahun. Lebih penting lagi, kompleksitas ini memiliki tim yang mencurahkan lebih banyak waktu untuk menganalisis setiap fitur baru jauh sebelum dirilis ke pelanggan. Tim mulai lebih fokus pada memvalidasi fitur baru dan lebih sedikit pada kecepatan pengiriman. Overhead merilis fitur baru menjadi sangat signifikan sehingga tim menjadi lebih fokus pada mekanisme pengujian, dan lebih sedikit pada fungsionalitas baru yang mendorong inovasi penawaran mereka.

Dalam mode yang lebih lambat dan lebih berhati-hati ini, tim cenderung memiliki waktu siklus yang panjang yang menempatkan kesenjangan yang lebih besar dan lebih besar antara awal ide dan ketika mendarat di tangan pelanggan. Secara keseluruhan, ini dapat menghambat kemampuan Anda untuk bereaksi terhadap dinamika pasar dan tekanan kompetitif.