Meninjau keputusan rasionalisasi

Selama tahap strategi dan perencanaan awal, kami sarankan Anda menerapkan pendekatan rasionalisasi tahapan ke properti digital. Tetapi pendekatan ini menyematkan beberapa asumsi ke dalam keputusan yang dihasilkan. Kami menyarankan tim strategi cloud dan tim adopsi cloud untuk mengulas keputusan tersebut mengingat dokumentasi beban kerja yang diperluas. Ulasan ini juga merupakan saat yang tepat untuk melibatkan pemangku kepentingan bisnis dan sponsor eksekutif dalam keputusan status di masa depan.

Penting

Validasi lebih lanjut dari keputusan rasionalisasi akan terjadi selama fase penilaian migrasi. Validasi ini berfokus pada ulasan bisnis tentang rasionalisasi untuk meratakan sumber daya dengan tepat.

Untuk memvalidasi keputusan rasionalisasi, gunakan pertanyaan berikut untuk memfasilitasi percakapan dengan bisnis. Pertanyaan dikelompokkan oleh kemungkinan rasionalisasi keselarasan.

Indikator inovasi

Jika ulasan gabungan dari pertanyaan-pertanyaan berikut menangguhkan jawaban afirmatif, beban kerja mungkin menjadi kandidat yang lebih baik untuk inovasi. Beban kerja seperti itu tidak akan dimigrasikan melalui model lift dan shift atau modernisasi. Sebaliknya, logika bisnis atau struktur data akan dibuat ulang sebagai aplikasi baru atau didesain ulang. Pendekatan ini bisa lebih padat karya dan memakan waktu. Namun untuk beban kerja yang mewakili pengembalian bisnis yang signifikan, investasi dibenarkan.

  • Apakah aplikasi dalam beban kerja ini membuat diferensiasi pasar?
  • Apakah ada investasi yang diusulkan atau disetujui yang bertujuan untuk meningkatkan pengalaman terkait dengan aplikasi dalam beban kerja ini?
  • Apakah data dalam beban kerja ini membuat penawaran produk atau layanan baru tersedia?
  • Apakah ada investasi yang diusulkan atau disetujui yang bertujuan untuk mengambil keuntungan dari data terkait dengan beban kerja ini?
  • Apakah efek diferensiasi pasar atau penawaran baru dapat diukur? Jika demikian, apakah pengembalian itu membenarkan peningkatan biaya inovasi selama adopsi cloud?

Dua pertanyaan berikut dapat membantu Anda memasukkan skenario teknis tingkat tinggi dalam ulasan rasionalisasi. Menjawab "ya" untuk dapat mengidentifikasi cara memperhitungkan atau mengurangi biaya terkait dengan inovasi.

  • Akankah struktur data atau logika bisnis berubah selama adopsi cloud?
  • Apakah alur penyebaran yang ada digunakan untuk menyebarkan beban kerja ini ke produksi?

Jika jawaban untuk kedua pertanyaan adalah "ya," tim harus mempertimbangkan untuk memasukkan beban kerja ini sebagai kandidat inovasi. Minimal, tim harus menandai beban kerja ini untuk ulasan arsitektur untuk mengidentifikasi peluang modernisasi.

Indikator migrasi

Migrasi adalah cara yang lebih cepat dan lebih murah untuk mengadopsi cloud. Namun hal itu tidak memanfaatkan peluang untuk berinovasi. Sebelum Anda berinvestasi dalam inovasi, jawab pertanyaan-pertanyaan berikut. Mereka dapat membantu Anda menentukan apakah model migrasi lebih berlaku untuk beban kerja.

  • Apakah kode sumber data yang mendukung aplikasi ini stabil? Apakah Anda berharap kode tersebut tetap stabil dan tidak berubah selama jangka waktu siklus rilis ini?
  • Apakah beban kerja ini mendukung proses bisnis produksi saat ini? Akankan beban kerja ini melakukannya selama siklus rilis ini?
  • Apakah prioritas bahwa upaya adopsi cloud ini meningkatkan stabilitas dan kinerja beban kerja ini?
  • Apakah pengurangan biaya terkait dengan beban kerja adalah tujuan selama upaya ini?
  • Apakah mengurangi kompleksitas operasional untuk beban kerja adalah tujuan selama upaya ini?
  • Apakah inovasi dibatasi oleh arsitektur saat ini atau proses operasi TI?

Jika jawaban atas pertanyaan-pertanyaan ini adalah "ya," Anda harus mempertimbangkan model migrasi untuk beban kerja ini. Rekomendasi ini benar bahkan jika beban kerja adalah kandidat untuk inovasi.

Tantangan dalam kompleksitas operasional, biaya, performa, atau stabilitas dapat menghambat pengembalian bisnis. Anda dapat menggunakan cloud untuk segera menghasilkan perbaikan terkait dengan tantangan tersebut. Jika berlaku, kami sarankan Anda menggunakan pendekatan migrasi untuk menstabilkan beban kerja terlebih dahulu. Kemudian memperluas peluang inovasi di lingkungan cloud yang stabil dan tangkas. Pendekatan ini memberikan pengembalian jangka pendek dan mengurangi biaya yang diperlukan untuk mendorong perubahan jangka panjang.

Penting

Model migrasi termasuk modernisasi bertahap. Menggunakan arsitektur platform as a service (PaaS) adalah aspek umum dari aktivitas migrasi. Begitu juga perubahan konfigurasi kecil yang menggunakan layanan platform tersebut. Batas untuk migrasi didefinisikan sebagai perubahan material pada logika bisnis atau struktur bisnis pendukung. Perubahan tersebut dianggap sebagai upaya inovasi.

Memperbarui paket proyek

Kemampuan yang dibutuhkan untuk upaya migrasi berbeda dari kemampuan yang dibutuhkan untuk upaya inovasi. Selama penerapan rencana adopsi cloud, disarankan untuk menetapkan upaya migrasi dan inovasi ke tim yang berbeda. Setiap tim memiliki perulangan, perilisan, dan perencanaan iramanya sendiri. Menetapkan tim terpisah memberikan fleksibilitas proses untuk mempertahankan satu rencana adopsi cloud sambil memperhitungkan upaya inovasi dan migrasi.

Saat Anda mengelola rencana adopsi cloud di Azure DevOps, manajemen tersebut tercermin dengan mengubah item pekerjaan induk (atau epik) dari migrasi cloud ke inovasi cloud. Perubahan halus ini membantu memastikan semua peserta dalam rencana adopsi cloud dapat dengan cepat melacak upaya yang diperlukan dan perubahan pada upaya remediasi. Pelacakan ini juga membantu meratakan tugas yang tepat ke tim adopsi cloud yang relevan.

Untuk rencana adopsi besar dan kompleks dengan beberapa proyek yang berbeda, pertimbangkan untuk memperbarui jalur perulangan. Mengubah jalur area membuat beban kerja hanya terlihat oleh tim yang ditetapkan ke jalur area tersebut. Perubahan ini dapat mempermudah kerja tim adopsi cloud dengan mengurangi jumlah tugas yang terlihat. Namun hal ini menambah kompleksitas untuk proses manajemen projek.

Langkah berikutnya

Buat rencana perulangan dan rilis untuk mulai merencanakan pekerjaan.

Buat rencana perulangan dan rilis untuk mulai merencanakan pekerjaan.