Menyeimbangkan prioritas yang bersaing

Keberhasilan transformasi digital ditentukan oleh kemampuan pemangku kepentingan bisnis dan teknologi untuk menyeimbangkan prioritas yang bersaing.

Seperti transformasi digital lainnya, adopsi cloud memaparkan prioritas bersaing sepanjang siklus hidup adopsi. Dan seperti halnya bentuk transformasi lainnya, kemampuan untuk menyeimbangkan prioritas tersebut memiliki efek signifikan pada realisasi nilai bisnis. Menyeimbangkan prioritas bersaing ini membutuhkan percakapan yang terbuka dan terkadang sulit di antara pemangku kepentingan, dan kadang-kadang dengan kontributor individu.

Artikel ini menguraikan beberapa prioritas bersaing yang umum dibahas selama implementasi setiap metodologi. Ini dapat membantu Anda mempersiapkan diskusi tersebut saat Anda mengembangkan strategi adopsi cloud Anda.

Bagian berikut selaras dengan alur dalam diagram siklus hidup adopsi cloud sebelumnya. Namun, penting untuk mengenali bahwa adopsi cloud adalah proses berulang, bukan yang berurutan, dan bahwa prioritas pesaing ini mungkin muncul kembali di berbagai titik selama perjalanan adopsi cloud Anda.

Tema umum pendekatan Cloud Adoption Framework

Solusi monolitik dan perencanaan lanjutan dibangun berdasarkan serangkaian asumsi yang mungkin terbukti tidak akurat dari waktu ke waktu. Mengadopsi cloud sering kali merupakan pengalaman baru bagi bisnis dan tim teknisnya. Seperti kebanyakan pengalaman baru, ada beberapa kemungkinan bahwa asumsi awal akan terbukti salah.

Mengikuti prinsip-prinsip tangkas yang terbukti dari keputusan teknis yang tertunda adalah pendekatan yang disukai untuk sebagian besar panduan dalam kerangka kerja ini. Pendekatan tersebut mengikuti pola yang konsisten: menetapkan status akhir umum, bergerak cepat ke implementasi awal, menguji dan memvalidasi asumsi, dan merefaktor lebih awal untuk mengatasi asumsi yang rusak. Jenis mindset berkembang ini memaksimalkan pembelajaran dan meminimalkan risiko terhadap nilai bisnis, tetapi membutuhkan kenyamanan dengan ambiguitas.

Ambiguitas terkadang bisa lebih menakutkan, atau lebih berbahaya, daripada asumsi palsu. Meskipun kerangka kerja ini memprioritaskan pembelajaran dan mengatasi ambiguitas selama implementasi, banyak situasi mengharuskan tim untuk memprioritaskan pendekatan berbasis analisis atau berbasis asumsi. Bagian berikut menyediakan setidaknya satu "contoh cakupan yang diperluas" untuk menggambarkan ketika perulangan kedua yang lebih dalam mungkin berharga.

Keseimbangan selama fase strategi

Tujuan inti metodologi Strategi adalah untuk mengembangkan keselarasan antar pemangku kepentingan. Setelah ditentukan, posisi strategis yang selaras mendorong perilaku di setiap metodologi untuk memastikan bahwa keputusan teknis selaras dengan hasil bisnis yang diinginkan. Menumbuhkan keselarasan di antara pemangku kepentingan menciptakan serangkaian prioritas umum yang bersaing: kedalaman justifikasi versus waktu untuk dampak bisnis.

Prioritas bersaing:

• Kedalaman pembenaran: Pemangku kepentingan sering menginginkan analisis keuangan yang mendalam dan pembenaran bisnis penuh sebelum mereka nyaman dengan menyelaraskan ke arah strategis. Sayangnya, tingkat analisis tersebut mungkin memerlukan periode waktu yang lama untuk memungkinkan pengumpulan dan analisis data.

• Dampak waktu ke bisnis: Sebaliknya, pemangku kepentingan sering dimintai pertanggungjawaban untuk memberikan hasil bisnis dalam jangka waktu yang ditentukan. Analisis dan penilaian yang memakan waktu dapat membahmari hasil tersebut sebelum pekerjaan teknis dimulai.

Cakupan minimum: Menemukan saldo yang benar memerlukan diskusi pemangku kepentingan di awal proses. Metodologi Strategi merekomendasikan untuk membatasi ruang lingkup penyelarasan selama upaya awal ini. Dalam pendekatan yang direkomendasikan, pemangku kepentingan fokus pada penyelarasan di sekitar serangkaian motivasi inti, hasil yang terukur, dan pembenaran bisnis tingkat tinggi. Pemangku kepentingan kemudian harus dengan cepat berkomitmen pada beberapa proyek awal atau pilot untuk mendorong peluang pembelajaran yang diperlukan.

Contoh cakupan yang diperluas: Jika analisis bisnis awal menunjukkan risiko tinggi yang berdampak negatif pada bisnis, pemangku kepentingan mungkin perlu melambat dan lebih berhati-hati mengevaluasi analisis yang lebih dalam selama pembenaran bisnis.

Keseimbangan selama fase perencanaan

Seperti selama fase strategi, ada kebutuhan selama fase perencanaan untuk menyeimbangkan kedalaman perencanaan awal versus keputusan teknis yang tertunda.

Prioritas bersaing:

• Kedalaman perencanaan awal untuk implementasi teknis di cloud sering didasarkan pada banyak asumsi. Terutama ketika ada kesenjangan keterampilan di tim, lingkungan menderita kesenjangan penemuan, atau beban kerja tidak memiliki status akhir arsitektur yang ditentukan dengan jelas. Semua asumsi ini umum dalam rencana adopsi cloud yang terperinci. Eksperimen, pilot, dan analisis kualitatif diperlukan untuk memverifikasi atau meningkatkan asumsi ini.

• Keputusan teknis yang tertunda didasarkan pada asumsi bahwa nantinya keputusan teknis dibuat, semakin akurat. Mengikuti prinsip perencanaan produk yang tangkas membantu menunda keputusan teknis, memungkinkannya terjadi pada waktu yang tepat, berdasarkan informasi yang memadai. Namun, pendekatan ini menghasilkan lebih banyak ambiguitas dalam rencana awal.

Cakupan minimum: Kami menyarankan pendekatan pengembangan produk yang tangkas untuk mendorong tindakan prompt dalam rencana yang dapat dikelola. Metodologi Rencana merekomendasikan langkah-langkah berikut untuk mencapai saldo ini:

1. Inventarisasi estat digital penuh dengan menggunakan alat penemuan otomatis, tetapi gunakan rasionalisasi inkremental untuk merencanakan sejauh 1 hingga 3 bulan kerja berikutnya.
2. Pastikan keselarasan organisasi yang tepat untuk bergerak cepat.
3. Buat rencana kesiapan keterampilan untuk tim yang ditugaskan. Gunakan template strategi dan rencana untuk menerapkan backlog awal dengan cepat.

Contoh cakupan yang diperluas: Pengiriman rencana adopsi cloud terkadang mungkin sebagai respons terhadap peristiwa bisnis yang sensitif terhadap waktu atau berdampak tinggi. Ketika keberhasilan membutuhkan pergerakan sejumlah besar aset selama periode waktu tetap, langkah-langkah sebelumnya sering diikuti oleh upaya perencanaan yang lebih dalam. Kunci keberhasilan dalam skenario ini adalah merencanakan cukup untuk memulai, dan kemudian merencanakan keterlibatan penuh. Pendekatan ini mengurangi kemungkinan perencanaan akan memblokir hasil bisnis.

Keseimbangan selama fase kesiapan

Ketika tim mempersiapkan langkah-langkah pertama mereka ke dalam adopsi cloud, sering kali ada prioritas bersaing antara waktu adopsi dan operasi jangka panjang. Tim mungkin berjuang dengan keseimbangan antara sangat cocok untuk memberikan tugas di tangan dan dikelola dengan baik. Perjuangan ini diperlukan dalam lingkungan TI tradisional, di mana tindakan mengembangkan platform membutuhkan aset fisik dan siklus akuisisi. Namun, ketika seluruh platform IT didefinisikan dalam kode, taktik pengembangan tradisional, seperti pemfaktoran ulang, mengurangi kebutuhan untuk dikelola dengan baik dari awal.

Prioritas bersaing:

• Operasi jangka panjang: Organisasi sering diblokir oleh keinginan untuk memiliki lingkungan cloud yang memenuhi paritas fitur dengan manajemen operasi, tata kelola, dan sistem keamanan saat ini. Dalam satu studi, lebih dari 90 persen organisasi membutuhkan dukungan untuk melewati pola pikir itu. Pemblokir ini dapat membuat penundaan berbulan-bulan, melambat, atau mencegah dampak bisnis.

• Waktu adopsi: Alat berbasis cloud seperti Azure Policy, pendekatan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) seperti infrastruktur sebagai kode (IaC), dan grup manajemen dapat menyederhanakan proses pemfaktoran ulang di seluruh platform IT. Selain itu, zona pendaratan yang telah ditentukan sebelumnya memberikan rekomendasi untuk mempercepat penyebaran terhadap lingkungan yang sudah memenuhi banyak persyaratan paritas fitur. Alat-alat ini memberikan peluang untuk mempercepat waktu ke pasar dengan efek minimal pada operasi jangka panjang.

Cakupan minimum: Metodologi Ready menguraikan jalur langsung dari adopsi cepat ke operasi jangka panjang. Pendekatan ini dimulai dengan pengenalan dasar untuk alat yang dapat Anda gunakan untuk merefaktor lingkungan Anda. Alat-alat ini memperhitungkan kebutuhan Anda dan memandu Anda ke pilihan zona pendaratan yang telah ditentukan sebelumnya, masing-masing dikirimkan dengan model IaC. Anda kemudian dapat merefaktor kode selama adopsi cloud untuk meningkatkan operasi, keamanan, dan manajemen.

Contoh cakupan yang diperluas: Untuk tim yang rencana adopsinya meminta tujuan jangka menengah (dalam 24 bulan) untuk menghosting lebih dari 1.000 aset (aplikasi, infrastruktur, atau aset data) di cloud, kami merekomendasikan tampilan zona pendaratan yang lebih kuat. Dalam situasi ini, Anda harus mempertimbangkan metodologi Tata Kelola dan Kelola selama percakapan zona pendaratan awal Anda. Namun, pertimbangan yang lebih dalam ini sering kali menambah minggu atau bulan ke rencana adopsi cloud. Untuk meminimalkan efek pada hasil bisnis, tim adopsi harus menguji beban kerja aktual di cloud sementara, pada saat yang sama, menciptakan zona pendaratan yang lebih matang dan solusi arsitektur pusat.

Saldo selama fase migrasi

Selama migrasi, tim adopsi biasanya mengasumsikan bahwa beban kerja akan dihosting ulang di cloud dalam konfigurasi mereka saat ini. Asumsi ini bersaing dengan rencana maju untuk merancang ulang setiap beban kerja untuk lebih memanfaatkan kemampuan cloud. Kedua tampilan tidak saling eksklusif dan dapat gratis saat Anda mengelolanya dengan menggunakan proses umum.

Prioritas bersaing:

• Rehost: Organisasi sering menyamakan migrasi dengan pendekatan lift-and-shift yang mereplikasi semua aset ke cloud dalam konfigurasi mereka saat ini. Pendekatan ini menghasilkan sedikit penyimpangan dalam portofolio IT. Ini juga merupakan cara tercepat untuk menghentikan aset di pusat data yang ada.

• Merancang ulang: Memodernisasi arsitektur setiap beban kerja memaksimalkan nilai adopsi cloud di seluruh biaya, performa, dan operasi. Namun, pendekatan ini lebih lambat dan sering memerlukan akses ke kode sumber setiap aplikasi.

Cakupan minimum: Selama perencanaan tahap awal, gunakan opsi rehost untuk perencanaan, dengan pemahaman yang jelas bahwa pilihan ini didasarkan pada asumsi bisnis awal dan bukan keputusan teknis. Dalam metodologi Migrasi, tim adopsi cloud kemudian menantang asumsi ini untuk setiap beban kerja yang dimigrasikan. Metodologi ini mengikuti pendekatan penilaian/migrasi/promosikan untuk setiap beban kerja atau grup beban kerja untuk membuat pabrik migrasi. Selama fase penilaian, tim adopsi mengevaluasi kecocokan teknis dan arsitektur setiap beban kerja. Upaya penilaian itu jarang menghasilkan pendekatan lift-and-shift murni karena banyak komponen dalam arsitektur cenderung dipilih untuk refactoring dan modernisasi.

Contoh cakupan yang diperluas: Untuk beban kerja misi penting atau sensitivitas tinggi, seperti aplikasi layanan mikro mainframe atau multitier, penilaian beban kerja yang lebih menyeluruh mungkin diperlukan selama fase penilaian. Dalam situasi rearchitecture ini, Anda harus menggunakan Azure Well-Architected Review dan Azure Well-Architected Framework untuk menyempurnakan persyaratan beban kerja selama penilaian.

Keseimbangan selama fase inovasi

Inovasi yang berhadapan dengan pelanggan sejati sering menciptakan prioritas yang bertentangan antara kebutuhan untuk memberikan set fitur yang direncanakan dan menerapkan proses pengembangan empati pelanggan.

Prioritas bersaing:

• Fokus fitur: Rencana awal untuk inovasi dibangun di atas real estat digital dan kemampuan cloud yang ada untuk menghadirkan serangkaian fitur yang memenuhi kebutuhan pelanggan. Sangat mudah untuk memungkinkan rencana untuk mendorong implementasi teknis, yang mengarah ke upaya pengembangan yang berfokus pada fitur. Pendekatan ini sering menyebabkan kepuasan pemangku kepentingan sementara tetapi mengurangi kemungkinan mendorong inovasi yang memengaruhi perilaku pelanggan.

• Empati pelanggan: Rencana awal merupakan bagian penting dari sisi pengembangan bisnis dan harus disertakan dalam pelaporan rutin. Namun, belajar, mengukur, dan membangun dengan empati pelanggan sebagai tujuan adalah ukuran keberhasilan yang lebih akurat dalam upaya inovasi. Berfokus pada pelanggan atas fitur lebih cenderung menghasilkan kepuasan pelanggan jangka pendek dan jangka panjang dan dampak bisnis.

Cakupan minimum: Metodologi Inovasi menggambarkan cara mengintegrasikan strategi dan rencana melalui konensi nilai bisnis. Panduan ini kemudian memperkenalkan alat cloud-native yang dapat mempercepat setiap disiplin inovasi dan praktik terbaik untuk implementasi. Terakhir, bagian peningkatan proses menunjukkan pendekatan untuk membangun empati pelanggan sambil menghormati rencana dan strategi di seluruh perjalanan adopsi cloud. Pendekatan ini berfokus pada memberikan inovasi dengan penggunaan teknologi sesedikitan mungkin.

Contoh cakupan yang diperluas: Inovasi terkadang tergantung pada beban kerja misi kritis atau sensitivitas tinggi. Ketika pelanggan adalah pengguna internal, upaya pengembangan mungkin sangat penting dan sensitivitas tinggi selama iterasi paling awal. Dalam skenario ini, tim adopsi harus menggunakan Azure Well-Architected Review dan Azure Well-Architected Framework untuk mengevaluasi desain arsitektur tingkat lanjut di awal proses.

Keseimbangan selama fase pemerintahan

Praktik tata kelola cloud adalah keseimbangan antara dua prioritas yang bersaing: kecepatan dan kelincahan versus lingkungan yang diatur dengan baik. Tim tata kelola cloud berfokus pada evaluasi dan meminimalkan risiko terhadap bisnis melalui kontrol yang seragam dan meminimalkan perubahan. Tim adopsi berfokus pada mendorong hasil bisnis, yang memerlukan risiko baru dan secara inheren menciptakan perubahan.

Prioritas bersaing:

• Dikelola dengan baik: Setiap kontrol yang dirancang untuk meminimalkan risiko memblokir beberapa aspek perubahan atau membatasi opsi desain. Kontrol sangat penting untuk lingkungan yang diatur dengan baik. Namun, ketika kontrol dirancang dan disebarkan dalam isolasi, kontrol dapat merusak risiko yang dimaksudkan untuk mencegahnya.
• Kecepatan dan ketangkasan: Kecepatan dan ketangkasan adalah persyaratan bisnis mendasar dalam ekonomi digital. Keduanya membutuhkan kemampuan untuk mendorong perubahan dengan penghambat minimal untuk inovasi atau adopsi. Tetapi ketika perubahan didorong tanpa tata kelola, itu menghasilkan risiko baru yang dapat membahayakan bisnis dengan cara yang tidak terduga.

Cakupan minimum: Metodologi Pemerintah merekomendasikan bahwa baik tata kelola maupun adopsi tidak boleh terjadi secara terpisah. Metodologi ini dimulai dengan pemahaman tentang disiplin tata kelola dan percakapan tentang risiko bisnis, kebijakan, dan proses. Sebagai peserta aktif di seluruh adopsi cloud, tim tata kelola dapat menerapkan serangkaian perlindungan minimum untuk mengatasi risiko nyata dalam rencana adopsi cloud. Seiring waktu, tim tata kelola dapat merefaktor dan memperluas perlindungan tersebut untuk memenuhi risiko baru. Pendekatan ini memaksimalkan pembelajaran dan inovasi sekaligus meminimalkan risiko.

Contoh cakupan yang diperluas: Ketika risiko bisnis tinggi, terutama di awal adopsi, tim tata kelola cloud mungkin perlu mempercepat perluasan implementasi tata kelola. Anda dapat menggunakan panduan dan latihan yang sama untuk menambahkan tingkat tata kelola yang lebih tinggi ini, tetapi Anda mungkin perlu melaju lebih cepat. Dalam beberapa skenario, status tata kelola tingkat lanjut bahkan mungkin diperlukan saat Anda mengembangkan zona pendaratan pertama.

Keseimbangan selama fase manajemen

Model bisnis TI untuk manajemen operasi terus berkembang selama dekade terakhir. Ketika pemeliharaan perangkat keras bergerak lebih jauh dari proposisi nilai inti IT, tampilan tentang manajemen operasi telah bergeser. Karena IT meningkatkan fokus pada memberikan nilai bisnis, tim manajemen operasi ditentang oleh kebutuhan untuk menyeimbangkan no-ops dan low-ops versus investasi luas.

Prioritas bersaing:

• Investasi luas: Berinvestasi secara merata dalam penghindaran pemadaman, pemulihan cepat, dan pemantauan di seluruh lingkungan adalah pendekatan tradisional untuk manajemen operasi. Pendekatan ini bisa mahal dan terkadang menduplikasi produk pendukung yang disediakan oleh vendor cloud.

• Tanpa operasi dan operasi rendah: Gunakan alat operasi cloud-native untuk meminimalkan tugas berulang dan berulang yang sebelumnya dikirimkan oleh karyawan Anda. Mengurangi dependensi operasional ini membebaskan karyawan untuk mendorong nilai dengan cara lain. Namun, dalam isolasi, pendekatan ini dapat menyebabkan dukungan operasi subpar.

Cakupan minimum: Metodologi Kelola merekomendasikan untuk menetapkan dasar cloud-native, tanpa operasi. Mengakui bahwa garis besar tanpa operasi tidak akan memenuhi semua kebutuhan bisnis, bekerja dengan bisnis untuk menentukan komitmen dan menyelaraskan investasi dengan lebih baik. Perluas baseline untuk memenuhi kebutuhan umum untuk semua beban kerja. Kemudian aktifkan tim platform atau tim beban kerja tertentu untuk mempertahankan solusi yang terkelola dengan baik dalam lingkungan yang terkelola dengan baik.

Contoh cakupan yang diperluas: Di sebagian besar lingkungan, nilai bisnis dari persentase kecil beban kerja membenarkan investasi mendalam dalam operasi dari IT. Untuk beban kerja tersebut, tim TI mungkin ingin menggunakan Azure Well-Architected Review dan Azure Well-Architected Framework untuk memandu operasi yang lebih dalam.

Keseimbangan selama fase organisasi

Prioritas bersaing yang dijelaskan dalam artikel ini mencerminkan drive IT untuk memberikan tuntutan bisnis untuk kecepatan dan kelincahan. Pergeseran yang sama muncul dalam perubahan pada bagan organisasi atau struktur tim virtual untuk memberikan dukungan yang lebih baik untuk hasil bisnis. Ketika pemimpin TI merefleksikan struktur tim, dua prioritas yang bersaing biasanya ditangani: kontrol terpusat versus kontrol yang didelegasikan.

Prioritas bersaing:

• Kontrol terpusat: Model operasi ini berfokus pada sentralisasi semua kontrol yang diperlukan untuk memberlakukan kebijakan yang kaku. Dalam model ini, TI berfungsi sebagai penghambat inovasi, kecepatan, dan ketangkasan. Namun, TI dapat memastikan tingkat stabilitas, kepatuhan, dan keamanan yang lebih tinggi.

• Kontrol yang didelegasikan: Dalam model operasi terdistribusi ini, diasumsikan bahwa setiap tim DevOps atau tim aplikasi bisnis akan memberikan serangkaian kontrol mereka sendiri, berdasarkan solusi yang diperlukan untuk memberikan tujuan bisnis. Dalam model ini, IT memberikan panduan untuk membantu tim menghindari risiko tetapi meminimalkan jumlah batasan teknis yang diberlakukan jika memungkinkan.

Cakupan minimum: Sebagian besar organisasi melalui serangkaian evolusi alami dari waktu ke waktu. Metodologi Organize menguraikan rangkaian evolusi yang paling umum. Kami menyarankan agar tim mencoba bergerak menuju struktur pusat keunggulan cloud (CCoE) untuk memberikan pendekatan kontrol yang didelegasikan.

Contoh cakupan yang diperluas: Banyak situasi memicu kebutuhan akan kontrol terpusat. Persyaratan kepatuhan pihak ketiga dan paparan keamanan sementara adalah dua contoh pemicu untuk kontrol terpusat. Dalam situasi ini, biasanya ada kebutuhan untuk menetapkan kebijakan pembatasan dan kontrol tetap yang kaku. Namun, untuk memungkinkan inovasi dan adopsi berlanjut, kami mendorong tim IT pusat untuk memberikan kontrol tersebut berdasarkan kekritisan dan sensitivitas setiap beban kerja. Menyediakan lingkungan dengan kontrol yang lebih sedikit tetapi pengurangan cakupan atau profil risiko memungkinkan fleksibilitas bahkan ketika kontrol diperlukan.

Langkah berikutnya

Pelajari cara menyeimbangkan migrasi, inovasi, dan eksperimen untuk memaksimalkan nilai upaya migrasi cloud Anda.

Menyeimbangkan portofolio