Meninjau dan membandingkan model operasi cloud umum

Artikel
03/22/2023

Model operasi unik dan spesifik untuk bisnis yang mereka dukung, berdasarkan persyaratan dan kendala mereka saat ini. Tetapi model operasi bukan kepingan salju. Ada beberapa pola umum dalam model operasi pelanggan; artikel ini menguraikan empat pola yang paling umum.

Perbandingan model operasi

Gambar berikut memetakan model operasi umum berdasarkan berbagai kompleksitas, dari yang paling tidak kompleks (terdesentralisasi) hingga yang paling kompleks (operasi global). Tabel berikut membandingkan model operasi yang sama berdasarkan nilai relatif dari beberapa atribut lainnya.

Diagram memperlihatkan tingkat kompleksitas model operasi.

Prioritas atau ruang lingkup

Model operasi cloud terutama didorong oleh dua faktor:

Prioritas atau motivasi strategis
Cakupan portofolio yang akan dikelola

	Operasi terdesentralisasi (ops)	Operasi terpusat (ops)	Operasi perusahaan (ops)	Operasi terdistribusi (ops)
Prioritas atau motivasi strategis	Inovasi	Kontrol	Demokratisasi	Integrasi
Cakupan portofolio	Beban kerja	Zona landasan	Platform cloud	Portofolio penuh
Lingkungan beban kerja	Kompleksitas tinggi	Kompleksitas rendah	Kompleksitas sedang	Kompleksitas sedang atau variabel
Zona landasan	T/A	Kompleksitas tinggi	Kompleksitas sedang hingga rendah	Kompleksitas rendah
Utilitas dasar	T/A	Dukungan N/A atau rendah	Terpusat dan lebih banyak dukungan	Sebagian besar dukungan
Dasar cloud	T/A	T/A	Dasar hibrid, penyedia layanan khusus, atau regional	Didistribusikan dan disinkronkan

Prioritas atau motivasi strategis: Setiap model operasi memberikan motivasi strategis yang khas untuk adopsi cloud. Tetapi beberapa model operasi menyederhanakan motivasi tertentu.
Cakupan portofolio: Cakupan portofolio mengidentifikasi cakupan terbesar yang didukung desain model operasi tertentu. Misalnya, operasi terpusat dirancang untuk beberapa zona pendaratan. Tetapi keputusan model operasi dapat menciptakan risiko operasional bagi organisasi. Risiko operasional mengakibatkan ketika mencoba mengelola portofolio kompleks yang besar. Portofolio ini mungkin memerlukan banyak zona pendaratan atau kompleksitas variabel dalam desain zona pendaratan.

Penting

Mengadopsi cloud sering memicu refleksi pada model operasi saat ini dan dapat menyebabkan pergeseran dari satu model operasi umum ke model operasi lainnya. Tetapi adopsi cloud bukan satu-satunya pemicu. Prioritas bisnis dan ruang lingkup adopsi cloud dapat mengubah cara portofolio perlu didukung. Juga, mungkin ada pergeseran lain dalam model operasi yang paling tepat selaras. Ketika dewan, atau tim eksekutif lainnya, mengembangkan rencana bisnis 5 hingga 10 tahun, rencana tersebut sering mencakup persyaratan (eksplisit atau tersirat) untuk menyesuaikan model operasi. Model operasi adalah referensi yang baik untuk memandu keputusan. Model-model ini mungkin berubah atau perlu disesuaikan untuk memenuhi kebutuhan dan batasan Anda.

Penjajaran akuntabilitas

Banyak tim dan individu bertanggung jawab untuk mendukung fungsi yang berbeda. Tetapi setiap model operasi umum menetapkan akuntabilitas akhir untuk hasil keputusan untuk satu tim atau individu. Pendekatan ini mempengaruhi bagaimana model operasi didanai dan tingkat dukungan apa yang disediakan untuk setiap fungsi.

	Ops terdesentralisasi	Ops terpusat	Ops perusahaan	Operasi terdistribusi
Penyelarasan bisnis	Tim beban kerja	Strategi cloud pusat	CCoE	Variabel - membentuk tim strategi cloud yang luas?
Operasi cloud	Tim beban kerja	TI Pusat	CCoE	Berdasarkan analisis portofolio - lihat penjajaran Bisnis dan komitmen Bisnis
Tata kelola cloud	Tim beban kerja	TI Pusat	CCoE	Tata kelola berlapis
Keamanan cloud	Tim beban kerja	Pusat operasi keamanan (SOC)	CCoE + SOC	Campuran - lihat Menentukan strategi keamanan
Automasi cloud dan DevOps	Tim beban kerja	TI Pusat atau N/A	CCoE	Berdasarkan analisis portofolio - lihat penjajaran Bisnis dan komitmen Bisnis

Mempercepat implementasi model operasi di Azure

Seperti yang dibahas dalam Tentukan model operasi Anda, setiap metodologi Cloud Adoption Framework menyediakan jalur terstruktur untuk mengembangkan model operasi Anda. Metodologi ini dapat membantu Anda mengatasi pemblokir yang berasal dari kesenjangan dalam mengadopsi model operasi cloud.

Tabel berikut menguraikan cara untuk mempercepat implementasi model operasi Anda.

	Ops terdesentralisasi	Ops terpusat	Ops perusahaan	Operasi terdistribusi
Titik awal	Azure Well-Architected Framework (WAF)	Zona pendaratan Azure: opsi mulai dari skala kecil	Zona pendaratan Azure: Skala perusahaan CAF	Penyelarasan bisnis
Perulangan	Fokus pada beban kerja memungkinkan tim melakukan iterasi dalam WAF.	Opsi mulai dari skala kecil membutuhkan lebih banyak perulangan pada setiap metodologi tetapi dapat dilakukan saat upaya adopsi cloud matang.	Seperti yang diilustrasikan oleh implementasi referensi, perulangan masa depan biasanya fokus pada penambahan konfigurasi kecil.	Ulas opsi implementasi zona pendaratan Azure untuk memulai dengan opsi yang paling sesuai dengan garis dasar operasi Anda. Ikuti jalur perulangan yang didefinisikan dalam prinsip desain opsi itu.

Operasi terdesentralisasi

Operasi selalu kompleks. Jika Anda membatasi cakupan operasi Anda ke satu beban kerja atau kumpulan kecil beban kerja, Anda mengontrol kompleksitas. Operasi terdesentralisasi adalah yang paling tidak kompleks dari model operasi umum. Dalam bentuk operasi ini, semua beban kerja beroperasi secara independen oleh tim beban kerja khusus.

Prioritas: Tim Anda mengukur inovasi atas kontrol atau standardisasi terpusat di beberapa beban kerja.
Keuntungan yang berbeda: Maksimalkan kecepatan inovasi dengan menempatkan beban kerja dan tim bisnis dalam kendali penuh atas desain, pembangunan, dan operasi.
Kekurangan yang berbeda: Pengurangan standardisasi lintas beban kerja, skala ekonomi melalui layanan bersama, dan upaya kepatuhan terpusat tata kelola yang konsisten.
Risiko: Pendekatan ini memperkenalkan risiko saat mengelola portofolio beban kerja. Tim beban kerja mungkin memiliki tim khusus yang didedikasikan untuk fungsi TI pusat. Model operasi ini dipandang sebagai opsi berisiko tinggi oleh beberapa organisasi, terutama perusahaan yang diharuskan mengikuti persyaratan kepatuhan pihak ketiga.
Panduan: Operasi terdesentralisasi terbatas pada keputusan tingkat beban kerja. Microsoft Azure Well-Architected Framework mendukung keputusan yang dibuat dalam cakupan tersebut. Proses dan panduan dalam Cloud Adoption Framework dapat menambahkan overhead yang tidak diperlukan oleh operasi terdesentralisasi.

Keuntungan dari operasi terdesentralisasi

Manajemen biaya: Biaya operasi mudah dipetakan ke satu unit bisnis. Operasi khusus beban kerja mendukung pengoptimalan beban kerja yang lebih besar.
Tanggung jawab: Biasanya, bentuk operasi ini sangat bergantung pada automasi untuk meminimalkan overhead. Tanggung jawab cenderung fokus pada Azure DevOps dan alur untuk manajemen rilis. Jenis operasi ini mendukung penyebaran yang lebih cepat dan siklus umpan balik yang lebih pendek selama pengembangan.
Standardisasi: Gunakan kode sumber dan alur penyebaran untuk menstandarkan lingkungan dari rilis ke rilis.
Dukungan operasi: Keputusan yang memengaruhi operasi hanya berkaitan dengan kebutuhan beban kerja itu dan menyederhanakan keputusan operasi. Anggota komunitas Azure DevOps mengatakan bahwa dukungan operasi adalah bentuk operasi yang paling murni karena ruang lingkup operasional yang lebih ketat.
Keahlian: Azure DevOps dan tim pengembangan paling diberdayakan oleh pendekatan ini dan mengalami resistensi paling sedikit untuk mendorong perubahan pasar.
Desain zona pendaratan: Tidak ada keuntungan operasional khusus.
Utilitas dasar: Tidak ada keuntungan operasional khusus.
Pemisahan tugas: Tidak ada keuntungan operasional khusus.

Kekurangan operasi terdesentralisasi

Manajemen biaya: Biaya perusahaan lebih sulit dihitung. Kurangnya tim tata kelola terpusat membuat lebih sulit untuk menerapkan kontrol biaya atau pengoptimalan yang seragam. Pada skala tersebut, model ini bisa mahal, karena setiap beban kerja mungkin memiliki duplikasi dalam aset yang digunakan dan tugas kepegawaian.
Tanggung jawab: Kurangnya dukungan terpusat berarti bahwa tim beban kerja sepenuhnya bertanggung jawab atas tata kelola, keamanan, operasi, dan manajemen perubahan. Kurangnya dukungan bermasalah ketika tugas-tugas tersebut belum diotomatisasi dalam tinjauan kode dan alur rilis.
Standardisasi: Standardisasi di seluruh portofolio beban kerja bervariasi dan tidak konsisten.
Dukungan operasi: Efisiensi skala sering terlewatkan saat membuat praktik terbaik di berbagai beban kerja.
Keahlian: Anggota tim memiliki tanggung jawab yang lebih besar untuk membuat keputusan yang bijaksana dan etis tentang tata kelola, keamanan, operasi, dan manajemen perubahan dalam desain dan konfigurasi aplikasi. Lihat Microsoft Azure Well-Architected Review dan Azure Well-Architected Framework secara sering untuk meningkatkan keahlian yang diperlukan.
Desain zona pendaratan: Zona pendaratan tidak spesifik beban kerja dan tidak dipertimbangkan dalam pendekatan ini.
Utilitas dasar: Beberapa (jika ada) layanan dasar dibagi lintas beban kerja, mengurangi efisiensi skala.
Pemisahan tugas: Persyaratan yang lebih tinggi untuk DevOps dan tim pengembangan meningkatkan penggunaan hak istimewa yang ditinggikan dari tim tersebut. Jika Anda memerlukan pemisahan tugas, Anda mungkin perlu berinvestasi besar-besaran dalam kematangan DevOps untuk beroperasi dengan pendekatan ini.

Operasi terpusat

Lingkungan keadaan yang stabil mungkin tidak memerlukan fokus pada arsitektur atau persyaratan operasional yang berbeda dari beban kerja individu. Operasi pusat cenderung menjadi norma untuk lingkungan teknologi yang terutama terdiri dari beban kerja kondisi yang stabil. Contoh operasi negara stabil termasuk hal-hal seperti aplikasi commercial-off-the-shelf (COTS), atau aplikasi kustom mapan yang memiliki tempo rilis lambat. Jika tingkat perubahan didorong oleh pembaruan dan patch rutin, sentralisasi operasi mungkin merupakan cara yang efektif untuk mengelola portofolio Anda.

Prioritas adalah kontrol pusat atas inovasi, dan mengukur proses operasional yang ada atas pergeseran budaya ke operasi cloud modern.
Keuntungan yang berbeda: Sentralisasi memperkenalkan skala ekonomi, kontrol terbaik dari jenis, dan operasi standar, dan bekerja paling baik dengan lingkungan cloud. Lingkungan ini membutuhkan konfigurasi khusus untuk mengintegrasikan operasi cloud ke dalam operasi dan proses yang ada. Sentralisasi paling menguntungkan dengan portofolio beberapa ratus beban kerja dengan kompleksitas arsitektur sederhana dan persyaratan kepatuhan.
Kekurangan yang berbeda: Penskalaan untuk memenuhi tuntutan portofolio beban kerja yang besar dapat menempatkan tekanan yang signifikan pada tim terpusat yang membuat keputusan operasional untuk beban kerja produksi. Jika aset teknis mengharapkan untuk menskalakan lebih dari 1.000 VM, aplikasi, atau sumber data, Anda mungkin mempertimbangkan model perusahaan jika dalam waktu 18-24 bulan.
Risiko: Pendekatan ini membatasi sentralisasi ke sejumlah kecil langganan (seringkali satu langganan produksi). Risiko signifikan terlibat ketika refaktor nanti dalam perjalanan cloud Anda, dan mungkin mengganggu rencana adopsi Anda. Untuk menghindari pengerjaan ulang, cobalah berfokus pada segmentasi, batas lingkungan, peralatan identitas, dan elemen dasar lainnya.
Panduan: Opsi implementasi zona pendaratan Azure yang diselaraskan dengan kecepatan pengembangan "mulai dari skala kecil dan perluas" menciptakan titik awal yang baik. Anda dapat menggunakan opsi ini untuk mempercepat upaya adopsi. Namun agar berhasil, tetapkan kebijakan yang jelas untuk memandu upaya adopsi dini dalam toleransi risiko yang dapat diterima. Metodologi Mengatur dan Mengelola membantu menciptakan proses untuk mematangkan operasi secara paralel. Mengikuti langkah-langkah ini berfungsi sebagai gerbang panggung yang harus diselesaikan sebelum memungkinkan peningkatan risiko saat operasi matang.

Keuntungan dari operasi terpusat

Manajemen biaya: Memusatkan layanan bersama di banyak beban kerja menciptakan skala ekonomi dan menghilangkan tugas duplikat. Tim pusat dapat dengan cepat menerapkan pengurangan biaya melalui optimalisasi ukuran dan skala di seluruh perusahaan.
Tanggung jawab: Ahli terpusat dan standardisasi dapat menyebabkan stabilitas yang lebih tinggi, performa operasional yang lebih baik, dan pemadaman terkait perubahan minimal. Pendekatan ini mengurangi tekanan keterampilan yang luas pada tim yang berfokus pada beban kerja.
Standardisasi: Secara umum, standardisasi dan biaya operasi terendah dengan model terpusat karena ada lebih sedikit sistem atau tugas duplikat.
Dukungan operasi: Mengurangi kompleksitas dan memusatkan operasi memudahkan tim IT yang lebih kecil untuk mendukung operasi.
Keahlian: Memusatkan tim pendukung memungkinkan para ahli dalam keamanan, risiko, tata kelola, dan operasi mendorong keputusan penting bisnis.
Desain zona pendaratan: TI Pusat mengurangi kompleksitas dengan meminimalkan jumlah zona pendaratan dan langganan. Desain zona pendaratan cenderung meniru desain pusat data sebelumnya, yang mengurangi waktu transisi. Seiring berjalannya adopsi, sumber daya bersama dapat dipindahkan ke langganan atau dasar platform terpisah.
Utilitas dasar: Anda membawa desain pusat data yang ada ke cloud menghasilkan layanan bersama dasar yang meniru alat dan operasi lokal. Ketika operasi lokal adalah model operasi utama Anda, itu mungkin merupakan keuntungan, tetapi waspadalah terhadap beberapa kekurangan. Operasi lokal mengurangi waktu transisi, memanfaatkan ekonomi skala, dan mendukung proses operasional yang konsisten antara beban kerja lokal dan yang dihosting cloud. Pendekatan ini dapat mengurangi kompleksitas dan upaya jangka pendek dan memungkinkan tim yang lebih kecil mendukung operasi cloud dengan kurva pembelajaran yang berkurang.
Pemisahan tugas: Pemisahan tugas jelas dalam operasi pusat. TI pusat mempertahankan kontrol lingkungan produksi dan mengurangi kebutuhan akan izin yang ditingkatkan dari tim lain. Pendekatan ini mengurangi pelanggaran dengan membatasi jumlah akun dengan hak istimewa yang ditinggikan.

Kekurangan operasi terpusat

Manajemen biaya: Tim pusat tidak selalu memahami arsitektur beban kerja untuk menghasilkan pengoptimalan yang berdampak pada tingkat beban kerja. Kurangnya pemahaman ini membatasi jumlah penghematan biaya yang berasal dari operasi beban kerja yang disetel dengan baik. Tidak sepenuhnya memahami arsitektur beban kerja dapat memengaruhi pengoptimalan biaya terpusat, yang memengaruhi performa, skala, dan pilar lain dari beban kerja yang dirancang dengan baik. Sebelum Anda menerapkan perubahan biaya di seluruh perusahaan pada beban kerja profil tinggi, tim TI pusat Anda harus memahami dan menyelesaikan Tinjauan Well-Architected Microsoft Azure.
Tanggung jawab: Memusatkan dukungan dan akses produksi menempatkan beban operasional yang tinggi pada beberapa orang dan tekanan yang lebih besar pada setiap individu. Tekanan yang diberikan pada para individu ini menyebabkan kebutuhan untuk melakukan tinjauan yang lebih dalam terhadap beban kerja yang dikerahkan, yang memvalidasi kepatuhan terhadap tata kelola keamanan terperinci dan persyaratan kepatuhan.
Standardisasi: Pendekatan TI pusat menyulitkan untuk menskalakan standardisasi tanpa penskalaan linier staf TI pusat.
Dukungan operasi: Kekurangan terbesar dari pendekatan ini dikaitkan dengan skala dan pergeseran signifikan yang mengukur inovasi.
Keahlian: Pengembang dan ahli Azure DevOps berisiko kurang dihargai atau terlalu dibatasi dalam jenis lingkungan ini.
Desain zona pendaratan: Desain pusat data didasarkan pada kendala pendekatan sebelumnya, yang tidak selalu relevan dengan cloud. Mengikuti pendekatan ini mengurangi peluang untuk memikirkan kembali segmentasi lingkungan dan memberdayakan peluang untuk inovasi. Kurangnya segmentasi zona pendaratan meningkatkan efek potensial pelanggaran, kompleksitas kepatuhan tata kelola dan kepatuhan, dan dapat membuat pemblokir untuk diadopsi dalam perjalanan cloud. Lihat bagian risiko di atas.
Utilitas dasar: Selama transformasi digital, cloud mungkin menjadi model operasi utama. Alat pusat, yang dibangun untuk operasi lokal, mengurangi peluang untuk memodernisasi operasi dan meningkatkan efisiensi operasional. Memilih untuk tidak memodernisasi operasi di awal proses adopsi juga merupakan pilihan. Modernisasi mungkin dicapai dengan membuat langganan fondasi platform dalam perjalanan adopsi cloud. Upaya itu bisa rumit, mahal, dan memakan waktu tanpa perencanaan lanjutan.
Pemisahan tugas: Operasi pusat umumnya mengikuti salah satu dari dua jalur dan keduanya mungkin menghambat inovasi.
- Opsi 1: Tim di luar TI pusat diberikan akses terbatas ke lingkungan pengembangan yang meniru produksi. Opsi ini menghambat eksperimen.
- Opsi 2: Tim berkembang dan menguji di lingkungan yang tidak didukung. Opsi ini menghambat proses penyebaran dan memperlambat pengujian integrasi pascapenyebaran.

Operasi perusahaan

Operasi perusahaan adalah status target yang disarankan untuk semua operasi cloud. Operasi perusahaan menyeimbangkan kebutuhan akan kontrol dan inovasi dengan menyederhanakan keputusan dan tanggung jawab. Central IT digantikan oleh pusat keunggulan cloud yang lebih fasilitatif atau tim CCoE, yang mendukung tim beban kerja. Tim CCoE, meminta pertanggungjawaban tim beban kerja atas keputusan, sebagai lawan mengendalikan atau membatasi tindakan mereka. Tim beban kerja diberikan lebih banyak kekuatan dan lebih banyak tanggung jawab untuk mendorong inovasi, dalam pagar pembatas yang terdefinisi dengan baik.

Prioritas: Prioritas adalah demokratisasi keputusan teknis. Demokratisasi keputusan teknis menggeser tanggung jawab yang sebelumnya dipegang oleh TI pusat ke tim beban kerja. Untuk memberikan pergeseran prioritas ini, keputusan menjadi kurang tergantung pada proses ulasan yang dikelola manusia. Pendekatan ini mendukung peninjauan, tata kelola, dan penegakan otomatis, menggunakan alat cloud-native.
Keuntungan yang berbeda: Segmentasi lingkungan dan pemisahan tugas memungkinkan keseimbangan antara kontrol dan inovasi. Operasi terpusat mempertahankan beban kerja yang memerlukan peningkatan kepatuhan dan operasi negara yang stabil, atau mewakili risiko keamanan yang lebih besar. Sebaliknya, pendekatan ini mendukung pengurangan kontrol terpusat terhadap beban kerja dan lingkungan yang membutuhkan inovasi yang lebih besar. Portofolio yang lebih besar mungkin berjuang dengan keseimbangan antara kontrol dan inovasi. Fleksibilitas ini membuatnya lebih mudah untuk meningkatkan ribuan beban kerja dengan pengurangan rasa sakit operasional.
Kerugian yang berbeda: Apa yang berhasil secara lokal mungkin tidak berfungsi dengan baik dalam operasi cloud perusahaan. Pendekatan operasi ini membutuhkan perubahan di banyak bidang. Pergeseran budaya dalam kontrol dan tanggung jawab seringkali merupakan tantangan terbesar. Pergeseran operasional yang mengikuti pergeseran budaya membutuhkan waktu dan melakukan upaya untuk menerapkan, matang, dan menstabilkan. Pergeseran arsitektur mungkin diperlukan dalam beban kerja yang stabil, sementara pergeseran peralatan diperlukan untuk memberdayakan dan mendukung pergeseran budaya, operasional, dan arsitektur. Pergeseran ini mungkin memerlukan komitmen untuk penyedia cloud utama. Upaya adopsi yang dilakukan sebelum perubahan ini dapat memerlukan pengerjaan ulang yang signifikan yang melampaui upaya refaktor umum.
Risiko: Pendekatan ini membutuhkan komitmen eksekutif terhadap strategi perubahan. Ini juga membutuhkan komitmen dari tim teknis untuk mengatasi kurva belajar dan memberikan perubahan yang diperlukan. Kerja sama jangka panjang antara bisnis, CCoE dan IT pusat, dan tim beban kerja diperlukan untuk melihat manfaat jangka panjang.
Panduan: Opsi zona pendaratan Azure didefinisikan sebagai skala perusahaan. Opsi ini menyediakan implementasi referensi untuk menunjukkan bagaimana perubahan teknis dikirimkan menggunakan alat cloud-native di Azure. Pendekatan skala perusahaan memandu tim melalui pergeseran operasional dan budaya yang diperlukan untuk mengambil keuntungan penuh dari implementasi tersebut. Pendekatan yang sama mungkin menyesuaikan arsitektur referensi untuk mengonfigurasi lingkungan untuk memenuhi strategi adopsi dan kendala kepatuhan Anda. Saat Anda menerapkan skala perusahaan, metodologi Tata Kelola dan Kelola dapat membantu menentukan proses. Proses ini dapat memperluas kemampuan kepatuhan dan operasi Anda untuk memenuhi kebutuhan operasional Anda.

Keuntungan dari operasi perusahaan

Manajemen biaya: Tim pusat bertindak berdasarkan pengoptimalan lintas portofolio dan meminta pertanggungjawaban tim beban kerja individu untuk pengoptimalan beban kerja yang lebih dalam. Tim yang berfokus pada beban kerja diberdayakan untuk membuat keputusan dan memberikan kejelasan ketika keputusan tersebut memiliki efek biaya negatif. Tim pusat dan beban kerja berbagi akuntabilitas untuk keputusan biaya di tingkat yang tepat.
Tanggung jawab: Tim pusat menggunakan alat cloud-native untuk menentukan, menegakkan, dan mengotomatiskan pagar pembatas. Upaya tim beban kerja dipercepat melalui otomatisasi dan praktik CCoE. Tim beban kerja diberdayakan untuk mendorong inovasi dan membuat keputusan di dalam pagar pembatas tersebut.
Standardisasi: Pagar pembatas terpusat, dan layanan dasar, menciptakan konsistensi di semua lingkungan.
Dukungan operasi: Beban kerja yang memerlukan dukungan operasi terpusat tersegmentasi ke lingkungan dengan kontrol keadaan stabil. Segmentasi dan pemisahan tugas memberdayakan tim beban kerja untuk bertanggung jawab atas dukungan operasional di lingkungan khusus mereka sendiri. Alat cloud native otomatis memastikan garis dasar operasi minimum untuk semua lingkungan dengan dukungan operasional terpusat.
Keahlian: Memusatkan layanan inti seperti keamanan, risiko, tata kelola, dan operasi memastikan keahlian pusat yang tepat. Proses dan pagar pembatas yang jelas mendidik dan memberdayakan tim beban kerja untuk membuat keputusan yang lebih detail. Keputusan ini memperluas efek para ahli terpusat tanpa perlu skala staf linier dengan skala teknologi.
Desain zona pendaratan: Desain zona pendaratan mereplikasi kebutuhan portofolio, menciptakan batas keamanan, tata kelola, dan akuntabilitas yang jelas. Batas-batas ini diperlukan untuk mengoperasikan beban kerja di cloud. Praktik segmentasi tidak mungkin menyerupai batasan yang dibuat oleh desain pusat data sebelumnya. Dalam operasi perusahaan, desain zona pendaratan kurang kompleks, memungkinkan skala yang lebih cepat dan mengurangi hambatan untuk permintaan swalayan.
Utilitas dasar: Utilitas dasar dihosting dalam langganan terpisah yang dikendalikan secara terpusat, yang dikenal sebagai dasar platform. Alat pusat kemudian disalurkan ke setiap zona pendaratan sebagai layanan utilitas. Memisahkan utilitas dasar dari zona pendaratan memaksimalkan konsistensi dan skala ekonomi. Utilitas ini juga menciptakan perbedaan yang jelas antara tanggung jawab yang dikelola secara terpusat dan tanggung jawab tingkat beban kerja.
Pemisahan tugas: Pemisahan tugas yang jelas antara utilitas dasar dan zona pendaratan adalah salah satu keuntungan terbesar dalam pendekatan operasi. Alat dan proses cloud-native mendukung akses dan keseimbangan kontrol yang tepat antara tim terpusat dan tim beban kerja. Pendekatan ini didasarkan pada persyaratan zona pendaratan individu dan beban kerja yang dihosting di segmen zona pendaratan.

Kekurangan operasi perusahaan

Manajemen biaya: Tim pusat lebih bergantung pada tim beban kerja untuk membuat perubahan produksi dalam zona pendaratan. Pergeseran ini menciptakan risiko untuk kelebihan anggaran potensial dan ukuran kanan yang lebih lambat dari pengeluaran aktual. Proses pengendalian biaya, anggaran yang jelas, kontrol otomatis, dan ulasan reguler harus ada lebih awal untuk menghindari kejutan biaya.
Tanggung jawab: Operasi perusahaan membutuhkan persyaratan budaya dan operasional yang lebih besar. Persyaratan-persyaratan ini memastikan kejelasan dalam tanggung jawab dan akuntabilitas antara tim pusat dan beban kerja.
Proses manajemen perubahan tradisional, atau papan penasihat perubahan (taksi), mungkin tidak mempertahankan kecepatan dan keseimbangan yang diperlukan dalam model operasi ini. Proses tersebut tercermin dalam mengotomatiskan proses dan prosedur yang menskalakan adopsi cloud dengan aman.
Kurangnya komitmen untuk mengubah terwujud terlebih dahulu dalam negosiasi dan penyelarasan tanggung jawab. Ketidakmampuan untuk menyejajarkan pada pergeseran tanggung jawab merupakan indikasi bahwa model operasi TI pusat mungkin diperlukan selama upaya adopsi cloud jangka pendek.
Standardisasi: Kurangnya investasi dalam pagar pembatas terpusat, atau otomatisasi, menciptakan risiko terhadap standardisasi, yang lebih sulit diatasi melalui proses ulasan manual. Ketergantungan operasional antara beban kerja di zona pendaratan dan layanan bersama menciptakan risiko yang lebih besar. Risiko-risiko ini meluas dari standardisasi selama siklus peningkatan atau versi utilitas dasar di masa depan. Selama revisi dasar platform, pengujian yang ditingkatkan, atau bahkan otomatis, diperlukan dari semua zona pendaratan yang didukung dan beban kerja yang mereka selenggarakan.
Dukungan operasi: Garis besar operasi yang disediakan melalui otomatisasi dan operasi terpusat mungkin cukup untuk beban kerja yang berdampak rendah atau kritis rendah. Tetapi tim beban kerja, atau bentuk operasi khusus lainnya, mungkin diperlukan untuk beban kerja kritis yang kompleks atau tinggi. Jika demikian, ini dapat menciptakan pergeseran anggaran operasi, mengharuskan unit bisnis untuk memberikan pengeluaran operasi pada bentuk operasi lanjutan tersebut. Jika TI pusat diperlukan untuk menjaga akuntabilitas atas biaya operasi, operasi perusahaan mungkin sulit diterapkan.
Keahlian: Anggota tim IT pusat mungkin diperlukan untuk mengembangkan keahlian dalam mengotomatiskan kontrol pusat yang sebelumnya dikirimkan melalui proses manual. Selain itu, tim-tim ini mungkin mengembangkan kemahiran untuk pendekatan infrastruktur-sebagai-kode untuk mendefinisikan lingkungan, dan memahami percabangan, penggabungan, dan penyebaran alur. Minimal, tim otomatisasi platform mungkin memerlukan keterampilan pengambilan keputusan untuk memahami keputusan yang dibuat oleh pusat keunggulan cloud atau tim operasi pusat. Tim beban kerja mungkin diminta untuk mengembangkan lebih banyak pengetahuan yang berkaitan dengan kontrol dan proses yang mengatur keputusan mereka.
Desain zona pendaratan: Desain zona pendaratan bergantung pada utilitas dasar. Tim beban kerja harus memahami apa yang ada dalam desain dan apa yang dilarang untuk disertakan. Pemahaman ini dapat membantu menghindari duplikasi upaya, kesalahan, atau konflik. Untuk menciptakan fleksibilitas, Anda dapat memperhitungkan proses pengecualian ke desain zona pendaratan Anda.
Utilitas dasar: Memusatkan utilitas dasar membutuhkan waktu. Utilitas-utilitas ini akhirnya mempertimbangkan opsi dan mengembangkan solusi yang mungkin skala untuk memenuhi berbagai rencana adopsi. Penundaan dalam upaya adopsi awal dimungkinkan. Penundaan dapat diimbangi dalam jangka panjang karena percepatan dan penghindaran pemblokir di kemudian hari dalam proses.
Pemisahan tugas: Memastikan pemisahan tugas yang jelas membutuhkan proses manajemen identitas yang matang. Mungkin ada lebih banyak pemeliharaan yang terkait dengan keselarasan pengguna, grup, dan aktivitas onboarding dan off-boarding yang tepat. Anda mungkin perlu mengadopsi proses baru untuk mengakomodasi akses just-in-time melalui hak istimewa yang ditingkatkan.

Operasi terdistribusi

Model operasi yang ada mungkin terlalu tertanam bagi seluruh organisasi untuk beralih ke model operasi baru. Bagi yang lain, operasi global dan berbagai persyaratan kepatuhan dapat mencegah unit bisnis tertentu melakukan perubahan. Dalam hal ini, mungkin memerlukan pendekatan mendistribusikan operasi. Pendekatan ini sejauh ini adalah yang paling kompleks, karena perlu mengintegrasikan satu atau beberapa model operasi yang disebutkan sebelumnya.

Meskipun sangat tidak dianjurkan, pendekatan operasi ini mungkin diperlukan untuk beberapa organisasi. Pendekatan ini terutama berkaitan dengan organisasi yang memiliki koleksi unit bisnis yang berbeda, basis segmen pelanggan yang beragam, atau operasi regional.

Prioritas: Integrasikan beberapa model operasi yang ada.
Keadaan transisi dengan fokus pada memindahkan seluruh organisasi ke salah satu model operasi yang disebutkan sebelumnya.
Pendekatan operasional jangka panjang ketika organisasi terlalu besar atau terlalu kompleks untuk menyejajarkan dengan model operasi tunggal.
Keuntungan berbeda: Integrasikan elemen model operasi umum dari setiap unit bisnis. Pendekatan ini menciptakan kendaraan untuk mengelompokkan unit operasi ke dalam hierarki yang membantu operasi matang mereka menggunakan proses berulang yang konsisten.
Kekurangan yang berbeda: Konsistensi dan standardisasi di beberapa model operasi sulit dipertahankan untuk waktu yang lama. Pendekatan operasional ini membutuhkan kesadaran mendalam tentang portofolio dan bagaimana berbagai segmen portofolio teknologi beroperasi.
Risiko: Kurangnya komitmen terhadap model operasi utama dapat menyebabkan kebingungan di seluruh tim. Gunakan model operasi ini ketika tidak ada cara untuk menyelaraskan dengan satu model operasi.
Panduan: Mulailah dengan tinjauan menyeluruh terhadap portofolio, yang menggunakan pendekatan yang diuraikan dalam artikel penyejajaran bisnis. Cobalah untuk mengelompokkan portofolio dengan model operasi negara (desentralisasi, terpusat, atau perusahaan).
Mengembangkan hierarki kelompok manajemen yang mencerminkan pengelompokan model operasi. Pengaturan ini mencakup pola organisasi lainnya untuk wilayah, unit bisnis, atau kriteria lain yang memetakan kluster beban kerja dari wadah yang paling tidak umum ke yang paling umum.
Evaluasi penyelarasan beban kerja ke model operasi untuk menemukan kluster model operasi yang paling relevan untuk memulai. Ikuti panduan yang dipetakan ke model operasi untuk semua beban kerja di bawah hierarki grup node dan manajemen.
Gunakan metodologi Tata Kelola untuk menemukan kebijakan perusahaan umum, termasuk praktik manajemen operasional yang diperlukan di berbagai titik hierarki. Terapkan kebijakan Azure umum untuk mengotomatiskan kebijakan perusahaan bersama.
Saat Anda menguji kebijakan Azure dengan berbagai penyebaran, cobalah untuk memindahkannya lebih tinggi dalam hierarki grup manajemen. Kebijakan dapat diterapkan pada banyak beban kerja, yang mungkin menemukan kesamaan dan kebutuhan operasi yang berbeda.
Seiring waktu, pendekatan ini dapat membantu Anda menentukan model yang menskalakan berbagai model operasi. Pendekatan ini juga dapat menyatukan tim melalui serangkaian kebijakan dan prosedur umum.

Kelebihan dan kekurangan dari pendekatan ini sengaja kosong. Setelah Anda menyelesaikan penyelarasan bisnis portofolio Anda, lihat bagian model operasi utama di atas untuk kejelasan tentang kelebihan dan kekurangan.

Langkah berikutnya

Pelajari terminologi yang terkait dengan model operasi. Terminologi ini membantu Anda memahami bagaimana model operasi sesuai dengan tema perencanaan perusahaan yang lebih besar.

Terminologi model operasi

Pelajari bagaimana zona pendaratan menyediakan blok bangunan dasar dari lingkungan adopsi cloud apa pun.

Apa itu zona arahan?