migrasi SaaS

Banyak penyedia yang mengadopsi SaaS bermigrasi ke SaaS dari model perangkat lunak yang diinstal tradisional (dijelaskan sebelumnya). Untuk penyedia ini, sangat penting untuk memiliki keselarasan yang baik pada prinsip-prinsip inti SaaS.

Di sini, sekali lagi, adalah di mana ada beberapa kebingungan tentang apa artinya bermigrasi ke model SaaS. Beberapa, misalnya, melihat pindah ke cloud saat bermigrasi ke SaaS. Yang lain melihat penambahan otomatisasi ke proses instalasi dan penyediaan mereka sebagai pencapaian migrasi.

Adalah adil untuk mengatakan bahwa setiap organisasi dapat memulai di tempat yang berbeda, memiliki pertimbangan warisan yang berbeda, dan kemungkinan menghadapi pasar yang berbeda dan tekanan kompetitif. Ini berarti bahwa setiap migrasi akan terlihat berbeda.

Namun, sementara setiap jalur berbeda, ada beberapa area di mana ada terputus di sekitar prinsip-prinsip inti yang membentuk strategi migrasi. Memiliki keselarasan yang baik di sekitar konsep dan prinsip dapat berdampak signifikan pada keberhasilan keseluruhan migrasi SaaS Anda.

Berdasarkan konsep yang diuraikan sebelumnya, harus jelas bahwa perpindahan ke SaaS dimulai dengan strategi dan tujuan bisnis. Poin ini bisa hilang dalam pengaturan migrasi di mana ada tekanan untuk sampai ke SaaS secepat mungkin.

Dalam mode ini, organisasi sering melihat migrasi terutama sebagai latihan teknis. Kenyataannya adalah, setiap migrasi SaaS harus dimulai dengan pandangan yang jelas tentang target pelanggan, pengalaman layanan, tujuan operasional, dan sebagainya. Memiliki fokus yang lebih jelas pada apa yang dibutuhkan bisnis SaaS Anda akan memiliki dampak besar pada bentuk, prioritas, dan jalur yang Anda ambil untuk memigrasikan solusi Anda ke SaaS.

Memiliki visi yang jelas ini sejak awal migrasi Anda meletakkan dasar untuk bagaimana Anda memigrasikan teknologi dan bisnis sebagai bagian dari kepindahan Anda ke SaaS. Saat Anda berangkat di jalur ini, fokuslah pada pertanyaan-pertanyaan yang dapat memberi tahu Anda paling banyak tentang ke mana Anda menuju.

Tabel berikut memberikan pandangan tentang sifat kontras pola pikir migrasi teknis dan bisnis.

Tabel 1 - Migrasi pertama teknis vs. bisnis pertama

Pola pikir pertama teknologi	Pola pikir bisnis pertama
Bagaimana kita mengisolasi data penyewa?	Bagaimana SaaS dapat membantu kami mengembangkan bisnis kami?
Bagaimana kita menghubungkan pengguna dengan penyewa?	Segmen mana yang kita targetkan?
Bagaimana kita menghindari kondisi tetangga yang bising?	Berapa ukuran dan profil segmen ini?
Bagaimana kita melakukan pengujian A/B?	Tingkat apa yang perlu kita dukung?
Bagaimana kita menskalakan berdasarkan beban penyewa?	Pengalaman layanan apa yang kami targetkan?
Penyedia penagihan mana yang harus kita gunakan?	Apa strategi penetapan harga dan pengemasan kami?

Di sebelah kiri adalah contoh seperti apa migrasi teknologi. Tim teknik sangat fokus pada mengejar topik multi-penyewa klasik yang tentunya penting bagi arsitektur SaaS mana pun.

Masalahnya adalah bahwa jawaban atas banyak pertanyaan di sebelah kiri sering dipengaruhi secara langsung oleh jawaban atas pertanyaan di sebelah kanan. Tidak mungkin titik ini baru bagi siapa pun yang melihat migrasi. Namun, kenyataannya adalah bahwa banyak organisasi memulai dengan mengejar efisiensi operasional dan biaya sebagai langkah pertama mereka, dengan asumsi bit bisnis akan bekerja sendiri.

Dalam strategi migrasi ini, ada juga kebingungan tentang bagaimana lingkungan warisan Anda mungkin berevolusi agar sesuai dengan model SaaS. Ini juga merupakan area di mana ada banyak pilihan untuk bermigrasi ke SaaS. Namun, ada sistem nilai umum yang umumnya kami anjurkan untuk migrasi apa pun.

Dalam diskusi kami sebelumnya tentang prinsip-prinsip SaaS, kami menguraikan berbagai pola dan terminologi yang digunakan untuk menggambarkan lingkungan SaaS. Salah satu tema umum yang mencakup semua solusi tersebut adalah gagasan memiliki layanan bersama yang mengelilingi aplikasi Anda. Identitas, orientasi, metrik, penagihan—ini semua disebut sebagai elemen umum yang merupakan inti dari lingkungan SaaS mana pun.

Sekarang, saat kita melihat migrasi, Anda akan melihat bahwa layanan bersama yang sama ini memainkan peran kunci dalam cerita migrasi apa pun. Berikut ini adalah diagram berikut ini.

Migrasi ke SaaS

Diagram ini merupakan pengalaman target untuk setiap jalur migrasi. Ini mencakup semua layanan bersama yang sama yang dijelaskan sebelumnya. Di tengah adalah placeholder untuk aplikasi Anda.

Ide utamanya adalah Anda dapat mendaratkan sejumlah model aplikasi di tengah lingkungan ini. Langkah pertama Anda dalam migrasi mungkin memiliki setiap penyewa berjalan di silo sendiri. Atau, Anda mungkin memiliki beberapa arsitektur hibrida di mana elemen dibungkam dan bit fungsionalitas lainnya ditangani melalui kumpulan layanan mikro yang dimodernisasi.

Seberapa banyak Anda awalnya memodernisasi aplikasi Anda akan bervariasi berdasarkan sifat lingkungan warisan Anda, kebutuhan pasar, pertimbangan biaya, dan sebagainya. Yang tidak berubah adalah pengenalan layanan bersama ini.

Setiap migrasi SaaS perlu mendukung layanan bersama dasar ini untuk memberi bisnis Anda kemampuan untuk beroperasi dalam model SaaS. Semua variasi arsitektur aplikasi membutuhkan identitas SaaS, misalnya. Anda memerlukan operasi yang sadar penyewa untuk mengelola dan memantau solusi SaaS Anda.

Menempatkan layanan bersama ini di depan migrasi memungkinkan Anda menyajikan pengalaman SaaS kepada pelanggan Anda—bahkan jika aplikasi yang mendasarinya masih berjalan dalam silo tumpukan penuh untuk setiap penyewa.

Tujuan umum adalah untuk mendapatkan aplikasi Anda berjalan dalam model SaaS. Kemudian, Anda dapat mengalihkan perhatian Anda ke modernisasi lebih lanjut dan penyempurnaan aplikasi Anda. Pendekatan ini juga memungkinkan Anda untuk memindahkan bagian lain dari bisnis Anda (pemasaran, penjualan, dukungan, dan sebagainya) dengan kecepatan yang lebih cepat. Lebih penting lagi, ini memungkinkan Anda untuk mulai terlibat dan mengumpulkan umpan balik pelanggan yang dapat digunakan untuk membentuk modernisasi lingkungan Anda yang sedang berlangsung.

Penting untuk dicatat bahwa layanan bersama yang Anda tempatkan mungkin tidak menyertakan setiap fitur atau mekanisme yang pada akhirnya Anda perlukan. Tujuan utamanya adalah menciptakan mekanisme bersama yang diperlukan pada awal migrasi Anda. Ini memungkinkan Anda untuk fokus pada elemen-elemen sistem yang penting untuk evolusi arsitektur aplikasi Anda dan evolusi operasional Anda.