Hierarki portofolio

Untuk memahami bagaimana portofolio beban kerja, aset, dan layanan pendukung semuanya bekerja sama, Anda perlu membuat hierarki portofolio. Artikel ini memberikan definisi yang jelas untuk tingkat hierarki portofolio Anda, bersama dengan panduan bagi tim untuk menyampaikan harapan untuk setiap tingkat. Sepanjang artikel ini, setiap tingkat hierarki juga disebut cakupan.

Beban kerja

Kumpulan teknologi yang memberikan nilai bisnis yang ditentukan disebut beban kerja. Koleksi mungkin mencakup aplikasi, server, atau komputer virtual, data, perangkat, dan aset lain yang dikelompokkan secara serupa. Sebagian besar bisnis bergantung pada beberapa beban kerja untuk memberikan fungsi bisnis yang vital.

Biasanya, pemangku kepentingan bisnis dan pemimpin teknis berbagi akuntabilitas atas dukungan berkelanjutan dari setiap beban kerja. Dalam beberapa fase siklus hidup beban kerja, peran tersebut dinyatakan dengan jelas. Dalam fase operasional yang lebih dari siklus hidup beban kerja, peran tersebut dapat ditransisikan ke tim manajemen operasi berbagi atau tim operasi cloud. Ketika jumlah beban kerja meningkat, peran (dinyatakan atau tersirat) menjadi lebih kompleks dan lebih matriks.

Beban kerja dan aset pendukungnya adalah inti dari portofolio apa pun. Cakupan atau lapisan menentukan bagaimana beban kerja tersebut dilihat dan sejauh mana beban kerja tersebut terpengaruh oleh matriks tim pendukung potensial.

Meskipun ketentuannya dapat bervariasi, semua solusi TI mencakup aset dan beban kerja:

• Aset: Unit terkecil dari fungsi teknis yang mendukung beban kerja atau solusi.
• Beban kerja: Unit terkecil dari dukungan TI untuk bisnis. Beban kerja adalah kumpulan infrastruktur, aplikasi, dan aset data yang mendukung tujuan bisnis umum atau eksekusi proses bisnis umum.

Saat Anda menyebarkan beban kerja pertama, beban kerja dan asetnya mungkin satu-satunya cakupan yang ditentukan. Lapisan lain mungkin secara eksplisit didefinisikan sebagai lebih banyak beban kerja yang disebarkan.

Portofolio TI

Ketika perusahaan mendukung beban kerja melalui pendekatan matriks atau pendekatan terpusat, hierarki yang lebih luas kemungkinan ada untuk mendukung beban kerja tersebut:

• Zona pendaratan: Zona pendaratan menyediakan beban kerja dengan utilitas dasar yang diperlukan, atau pipa bersama, yang diperlukan untuk mendukung satu atau beberapa beban kerja. Zona pendaratan sangat penting di cloud sehingga seluruh metodologi Siap dari Cloud Adoption Framework berfokus pada zona pendaratan. Untuk definisi yang lebih detail, lihat Apa yang dimaksud dengan zona pendaratan?
• Utilitas dasar: Layanan TI bersama ini diperlukan agar beban kerja dapat beroperasi dalam portofolio teknologi dan bisnis.
• Platform Dasar: Konstruksi organisasi ini memusatkan solusi dasar dan membantu memastikan bahwa kontrol tersebut diberlakukan untuk semua zona pendaratan.
• Platform cloud: Bergantung pada strategi keseluruhan untuk mendukung portofolio penuh, pelanggan mungkin memerlukan beberapa platform cloud dengan penyebaran fondasi platform yang berbeda untuk mengatur beberapa wilayah, solusi hibrid, atau bahkan solusi multicloud.
• Portofolio: Melalui lensa teknologi, portofolio adalah kumpulan beban kerja, aset, dan sumber daya pendukung yang menjangkau semua platform cloud. Melalui lensa bisnis, portofolio adalah kumpulan proyek, orang, proses, dan investasi yang mendukung dan mengelola portofolio teknologi untuk mendorong hasil bisnis. Bersama-sama, kedua lensa ini menangkap portofolio.

Akuntabilitas dan panduan hierarki

Tim yang bertanggung jawab mengelola setiap lapisan hierarki portofolio. Diagram berikut menunjukkan pemetaan antara tim yang bertanggung jawab dan panduan untuk mendukung keputusan bisnisnya, keputusan teknis, dan implementasi teknis.

Catatan

Tim yang disebutkan dalam daftar berikut mungkin tim virtual atau individu. Untuk beberapa varian hierarki ini, beberapa tim yang bertanggung jawab dapat diciutkan seperti yang dijelaskan kemudian dalam varian akuntabilitas.

• Portofolio: Tim strategi cloud dan pusat keunggulan cloud (CCoE) menggunakan metodologi Strategi dan Rencana untuk memandu keputusan yang memengaruhi portofolio keseluruhan. Tim strategi cloud bertanggung jawab atas tingkat perusahaan hierarki portofolio cloud. Tim strategi cloud juga harus diberitahu tentang keputusan tentang lingkungan, zona pendaratan, dan beban kerja prioritas tinggi.
• Platform cloud: Tim tata kelola cloud bertanggung jawab atas disiplin ilmu yang memastikan konsistensi di setiap lingkungan selaras dengan metodologi Tata Kelola . Tim tata kelola cloud bertanggung jawab atas tata kelola semua sumber daya di semua lingkungan. Tim tata kelola cloud harus dikonsultasikan tentang perubahan yang mungkin memerlukan pengecualian atau perubahan kebijakan yang mengatur. Tim tata kelola cloud juga harus diberitahu tentang kemajuan dengan beban kerja dan adopsi aset.
• Zona pendaratan dan dasar cloud: Tim platform cloud bertanggung jawab untuk mengembangkan zona pendaratan dan utilitas platform yang mendukung adopsi. Tim automasi cloud bertanggung jawab untuk mengotomatisasi pengembangan, dan dukungan berkelanjutan untuk, zona pendaratan dan utilitas platform tersebut. Kedua tim menggunakan metodologi Siap untuk memandu implementasi. Kedua tim harus diberitahu tentang kemajuan dengan adopsi beban kerja dan setiap perubahan pada perusahaan atau lingkungan.
• Beban kerja: Adopsi terjadi pada tingkat beban kerja. Tim adopsi cloud menggunakan metodologi Migrasi dan Berinovasi untuk membangun proses yang dapat diskalakan untuk mempercepat adopsi. Setelah adopsi selesai, kepemilikan beban kerja kemungkinan ditransfer ke tim operasi cloud yang menggunakan metodologi Kelola untuk memandu manajemen operasi. Kedua tim harus merasa nyaman menggunakan Microsoft Azure Well-Architected Framework dengan baik untuk membuat keputusan arsitektur terperinci yang memengaruhi beban kerja yang mereka dukung. Kedua tim harus diberitahu tentang perubahan zona pendaratan dan lingkungan. Kedua tim mungkin kadang-kadang berkontribusi pada fitur zona pendaratan.
• Aset: Aset biasanya menjadi tanggung jawab tim operasi cloud. Tim tersebut menggunakan garis besar manajemen dalam metodologi Kelola untuk memandu keputusan manajemen operasi. Ini juga harus menggunakan Azure Advisor dan Azure Well-Architected Framework untuk membuat perubahan sumber daya dan arsitektur terperinci yang diperlukan untuk memenuhi persyaratan operasi.

Varian akuntabilitas

• Lingkungan tunggal: Ketika perusahaan hanya membutuhkan satu lingkungan, CCoE biasanya tidak diperlukan.
• Zona pendaratan tunggal: Jika lingkungan hanya memiliki satu zona pendaratan, kemampuan tata kelola dan platform kemungkinan dapat digabungkan menjadi satu tim.
• Beban kerja tunggal: Beberapa bisnis hanya membutuhkan satu beban kerja, atau beberapa beban kerja, dalam satu zona pendaratan dan satu lingkungan. Dalam kasus tersebut, ada sedikit kebutuhan untuk pemisahan tugas antara pemerintahan, platform, dan tim operasi.

Contoh beban kerja dan akuntabilitas umum

Contoh berikut menggambarkan hierarki portofolio.

Beban kerja COTS

Secara tradisional, perusahaan lebih menyukai solusi perangkat lunak commercial-off-the-shelf (COTS) untuk menjalankan proses bisnis. Solusi ini dipasang, dikonfigurasi, dan kemudian dioperasikan. Ada sedikit perubahan pada arsitektur solusi setelah konfigurasi.

Dalam skenario ini, setiap adopsi cloud solusi COTS berakhir dengan transisi ke tim operasi cloud. Tim operasi cloud kemudian menjadi pemilik teknis untuk perangkat lunak itu dan bertanggung jawab untuk mengelola konfigurasi, biaya, siklus patching, dan kebutuhan operasional lainnya.

Beban kerja ini termasuk paket akuntansi, perangkat lunak logistik, atau solusi khusus industri. Dalam terminologi Microsoft, vendor paket ini disebut vendor perangkat lunak independen (ISV). Banyak ISV menawarkan layanan untuk menyebarkan dan memelihara instans paket perangkat lunaknya di langganan Anda. Mereka mungkin juga menawarkan versi paket perangkat lunak yang berjalan di lingkungan cloud yang dihosting sendiri, menyediakan alternatif platform sebagai layanan (PaaS) untuk beban kerja.

Kecuali untuk penawaran PaaS, tim operasi cloud bertanggung jawab untuk memastikan persyaratan kepatuhan operasional dasar untuk beban kerja tersebut. Tim operasi cloud harus bekerja dengan tim tata kelola cloud untuk menyelaraskan biaya, performa, dan pilar arsitektur lainnya.

Dalam pengembangan dengan revisi aktif

Ketika solusi COTS atau penawaran PaaS tidak selaras dengan kebutuhan bisnis, atau tidak ada solusi, perusahaan membangun beban kerja yang dikembangkan kustom. Biasanya, hanya sebagian kecil portofolio TI yang menggunakan pendekatan beban kerja ini. Tetapi beban kerja ini cenderung mendorong persentase kontribusi TI yang tidak proporsional tinggi terhadap hasil bisnis, terutama hasil yang terkait dengan aliran pendapatan baru. Beban kerja ini cenderung memetakan dengan baik ide-ide inovasi baru.

Mengingat berbagai gerakan yang berakar pada metodologi tangkas dan praktik Azure DevOps, beban kerja ini mendukung penyelarasan bisnis/Azure DevOps atas manajemen TI tradisional. Untuk beban kerja ini, mungkin tidak ada handoff ke tim operasi cloud selama beberapa tahun. Dalam kasus tersebut, tim pengembangan berfungsi sebagai pemilik teknis beban kerja.

Karena kendala waktu dan modal yang luas, opsi pengembangan kustom sering kali terbatas pada peluang bernilai tinggi. Contoh khas termasuk inovasi aplikasi, analisis data mendalam, atau fungsi bisnis misi penting.

Putus/perbaikan atau pengembangan matahari terbenam

Setelah beban kerja yang dikembangkan kustom mencapai kematangan puncak, tim pengembangan dapat dipindahkan ke proyek lain. Dalam kasus ini, kepemilikan teknis biasanya bertransisi ke tim operasi cloud. Ketika ada kebutuhan untuk perbaikan kecil, tim operasi akan meminta pengembang untuk menyelesaikan kesalahan.

Dalam beberapa kasus, tim pengembangan pindah ke proyek yang pada akhirnya akan menggantikan beban kerja saat ini. Atau, tim mungkin melanjutkan karena peluang bisnis yang didukung oleh beban kerja sedang dihapus. Dalam skenario matahari terbenam ini, tim operasi cloud berfungsi sebagai pemilik teknis sampai beban kerja tidak lagi diperlukan.

Dalam kedua skenario, tim operasi cloud biasanya berfungsi sebagai pemilik teknis dan pembuat keputusan jangka panjang. Tim itu kemungkinan akan meminta pengembang aplikasi ketika perubahan operasional memerlukan perubahan arsitektur yang signifikan.

Beban kerja kritis-misi

Di setiap perusahaan, beberapa beban kerja terlalu penting bagi bisnis agar mereka gagal. Dengan beban kerja misi penting ini, biasanya ada pemilik operasi dan pengembangan dengan berbagai tingkat tanggung jawab. Tim-tim tersebut harus menyelaraskan perubahan operasional dan perubahan arsitektur untuk meminimalkan gangguan pada solusi produksi.

Skenario ini membutuhkan fokus yang kuat pada pemisahan tugas. Tim operasi umumnya akan meminta pertanggungjawaban untuk perubahan operasional sehari-hari di lingkungan produksi. Ketika perubahan operasional tersebut memerlukan perubahan arsitektur, mereka akan diselesaikan oleh tim pengembangan atau adopsi dalam lingkungan nonproduksi, sebelum tim operasi menerapkan perubahan pada produksi.

Contoh beban kerja misi penting dengan pemisahan tugas yang diperlukan termasuk beban kerja seperti SAP, Oracle, atau solusi perencanaan sumber daya perusahaan (ERP) lainnya, yang menjangkau beberapa unit bisnis di perusahaan.

Penyelarasan portofolio strategi

Sangat penting untuk memahami tujuan strategis dari upaya adopsi cloud dan menyelaraskan portofolio untuk mendukung transformasi itu. Beberapa jenis penjajaran portofolio strategis yang umum membantu membentuk struktur hierarki portofolio. Bagian berikut memberikan contoh penyelarasan portofolio dan efek pada hierarki portofolio.

Inovasi atau portofolio yang dipimpin pengembangan

Beberapa perusahaan, terutama startup yang berkembang pesat, memiliki persentase proyek pengembangan kustom yang lebih tinggi dari rata-rata. Dalam portofolio pengembangan yang berat, lingkungan, zona pendaratan, dan beban kerja sering dikompresi, sehingga mungkin ada lingkungan khusus untuk beban kerja tertentu. Hasilnya adalah rasio 1:1 antara lingkungan, zona pendaratan, dan beban kerja.

Karena lingkungan menjadi host solusi kustom, alur Azure DevOps dan pelaporan tingkat aplikasi dapat menggantikan kebutuhan akan fungsi operasi dan tata kelola. Pelanggan tersebut kemungkinan akan mengurangi fokus pada operasi, tata kelola, atau peran pendukung lainnya. Penekanan yang lebih kuat pada tanggung jawab adopsi cloud dan tim otomatisasi cloud juga khas.

Penjajaran portofolio: Portofolio TI kemungkinan akan fokus pada beban kerja dan pemilik beban kerja untuk mendorong keputusan arsitektur yang kritis. Tim tersebut kemungkinan akan menemukan nilai lebih dalam panduan Azure Well-Architected Framework selama aktivitas adopsi dan operasi.

Definisi batas: Batas-batas logis, bahkan pada tingkat perusahaan, kemungkinan akan fokus pada segmentasi lingkungan produksi dan nonproduksi. Mungkin juga ada segmentasi yang jelas antara produk dalam portofolio perangkat lunak perusahaan. Kadang-kadang, mungkin juga ada segmentasi antara pengembangan dan instans pelanggan yang dihosting.

Portofolio yang dipimpin operasi

Organisasi perusahaan multinasional dengan tim operasi TI yang lebih mapan biasanya memiliki fokus yang lebih kuat pada tata kelola dan operasi daripada pengembangan. Dalam organisasi ini, persentase beban kerja yang lebih tinggi biasanya selaras dengan KATEGORI COTS atau break/fix, dikelola oleh pemilik teknis dalam tim operasi cloud.

Penyelarasan portofolio: Portofolio TI akan selaras dengan beban kerja, tetapi beban kerja tersebut kemudian diselaraskan dengan unit operasi atau unit bisnis. Mungkin juga ada organisasi di sekitar model pendanaan, industri, atau persyaratan segmentasi bisnis lainnya.

Definisi batas: Zona pendaratan kemungkinan akan mengelompokkan aplikasi ke arketipe aplikasi untuk menjaga operasi serupa dalam segmentasi serupa. Lingkungan kemungkinan akan mengacu pada konstruksi fisik seperti pusat data, negara, wilayah penyedia cloud, atau standar organisasi operasional lainnya.

Portofolio yang dipimpin oleh migrasi

Mirip dengan portofolio yang dipimpin operasi, portofolio yang sebagian besar dibangun melalui migrasi akan didasarkan pada dorongan bisnis tertentu yang mengarah pada migrasi aset yang ada. Biasanya, pusat data adalah faktor terbesar dalam dorongan tersebut.

Penyelarasan portofolio: Portofolio TI mungkin selaras dengan beban kerja, tetapi kemungkinan besar aset selaras. Jika transisi ke operasi TI telah terjadi dalam sejarah perusahaan, banyak aset penggunaan aktif mungkin tidak mudah dipetakan ke beban kerja yang didanai. Dalam kasus ini, banyak aset mungkin tidak memiliki beban kerja yang ditentukan atau pemilik beban kerja yang jelas sampai akhir proses migrasi.

Definisi batas: Zona pendaratan kemungkinan akan mengelompokkan aplikasi ke dalam batas-batas yang mencerminkan segmentasi lokal. Meskipun bukan praktik terbaik, lingkungan sering cocok dengan nama pusat data lokal dan zona pendaratan yang mewakili praktik segmentasi jaringan. Ini adalah praktik yang lebih baik untuk mematuhi segmentasi yang lebih erat selaras dengan portofolio yang dipimpin operasi.

Portofolio yang dipimpin tata kelola

Penyelarasan dengan tim tata kelola harus terjadi sedini mungkin. Melalui praktik tata kelola dan alat tata kelola cloud, portofolio, dan batas lingkungan dapat menyeimbangkan kebutuhan inovasi, operasi, dan upaya migrasi dengan sebaik-baiknya.

Penyelarasan portofolio: Portofolio yang dipimpin tata kelola cenderung mencakup titik data yang menangkap detail inovasi dan operasi, seperti beban kerja, pemilik operasi, klasifikasi data, dan kekritisan operasional. Titik data ini menciptakan tampilan portofolio yang menyeluruh.

Definisi batas: Batas-batas dalam portofolio yang dipimpin oleh tata kelola cenderung mendukung operasi daripada inovasi, sambil menggunakan hierarki berbasis grup manajemen yang memetakan kriteria untuk unit bisnis dan lingkungan pengembangan. Pada setiap tingkat hierarki, batas tata kelola cloud dapat memiliki tingkat penegakan kebijakan yang berbeda untuk memungkinkan pengembangan dan fleksibilitas kreatif. Pada saat yang sama, persyaratan kelas produksi dapat diterapkan pada langganan produksi untuk memastikan pemisahan tugas dan operasi yang konsisten.

Langkah berikutnya

Pelajari bagaimana produk Azure mendukung hierarki portofolio.