Langkah 1. Mengevaluasi aplikasi Anda - AWS Bimbingan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Langkah 1. Mengevaluasi aplikasi Anda

Tujuan dari fase ini adalah untuk:

  • Pahami lanskap aplikasi Anda secara menyeluruh dan persiapkan aplikasi Anda untuk platform data modern, sehingga Anda dapat mempercepat waktu untuk menghargai tanpa memengaruhi bisnis Anda, dan kemudian memodernisasi, mengoptimalkan, dan menskalakan.

  • Profil lanskap aplikasi Anda untuk mengidentifikasi manfaat, risiko, dan biaya yang terkait dengan perubahan.

  • Menyediakan serangkaian layanan end-to-end: mulai dari strategi dan perencanaan; melalui penyebaran, migrasi, dan modernisasi aplikasi; hingga dukungan berkelanjutan.

  • Buat kebijakan, rekomendasi, dan kontrol yang menyediakan praktik dan alat yang dapat digunakan kembali untuk memberikan nilai bisnis yang berkelanjutan.

Pada tahap evaluasi, pemilik aplikasi dan arsitek menggunakan buku pedoman diagnostik modernisasi untuk memvalidasi tujuan dan prioritas modernisasi mereka.

Menggunakan playbook diagnostik modernisasi

Buku pedoman diagnostik modernisasi menyediakan proses untuk menentukan nilai pindah dari keadaan saat ini ke keadaan future untuk perusahaan. Ini termasuk perubahan teknologi yang melibatkan modernisasi.

Anda menggunakan playbook diagnostik untuk menentukan prioritas aplikasi atau rangkaian aplikasi Anda untuk modernisasi cloud, dan untuk mengidentifikasi komponen yang perlu ditangani selama modernisasi.

Dimensi diagnostik

Buku pedoman diagnostik modernisasi membantu Anda memahami dimensi status saat ini dan target (pasca-migrasi) aplikasi atau sekelompok aplikasi berikut:

  • Pengelompokan aplikasi - Apakah ada alasan untuk mengelompokkan aplikasi (misalnya, berdasarkan teknologi atau model operasi) untuk modernisasi?

  • Pengurutan - Apakah ada urutan aplikasi yang harus dimodernisasi, berdasarkan dependensi?

  • Teknologi - Apa saja kategori teknologi (misalnya, middleware, database, messaging)?

  • Dependensi - Apakah aplikasi memiliki dependensi kunci pada sistem lain atau middleware?

  • Lingkungan - Berapa banyak lingkungan pengembangan, pengujian, dan produksi yang digunakan?

  • Penyimpanan - Apa persyaratan penyimpanan (misalnya, jumlah salinan data uji)?

  • Model operasi - Dapatkah semua komponen aplikasi mengadopsi integrasi dan alur (CI/CD).

    • Jika demikian, tanggung jawab infrastruktur apa yang harus didistribusikan ke tim aplikasi dan kepada siapa?

    • Jika tidak, tanggung jawab infrastruktur apa (misalnya, menambal) harus tetap dengan tim operasi?

  • Model pengiriman:

    • Berdasarkan aplikasi atau kelompok aplikasi, haruskah Anda melakukan replatform, refactor, menulis ulang, atau mengganti?

    • Bagian modernisasi mana yang harus menggunakan layanan cloud-native?

  • Set keterampilan - Keahlian apa yang diperlukan? Misalnya:

    • Latar belakang aplikasi cloud untuk membangun aplikasi dengan arsitektur modular dengan menggunakan teknologi kontainer dan tanpa server dari bawah ke atas.

    • DevOpskeahlian untuk mengembangkan solusi di bidang proses CI/CD, infrastruktur sebagai kode, dan otomatisasi atau observabilitas aplikasi dengan menggunakan open-source dan alat dan layanan. AWS

  • Pendekatan modernisasi - Mempertimbangkan keadaan aplikasi saat ini, pilihan teknologi cloud, utang teknis saat ini, CI/CD, pemantauan, keterampilan, dan model operasi, apa pekerjaan migrasi teknis yang perlu dilakukan?

  • Waktu modernisasi - Apa pertimbangan waktu portofolio bisnis atau pertimbangan pekerjaan terencana lainnya yang dapat mempengaruhi waktu modernisasi?

  • Unit dan total biaya infrastruktur - Berapa biaya tahunan untuk mempertahankan beban kerja Anda di tempat vs.AWS, berdasarkan analisis ekonomi?

Mengevaluasi aplikasi terhadap dimensi ini membantu Anda tetap berlabuh dalam bisnis, teknologi, dan ekonomi saat Anda mendorong modernisasi Anda ke cloud.

Blok bangunan

Ketika Anda memodernisasi aplikasi, Anda dapat mengklasifikasikan pengamatan Anda menjadi tiga blok bangunan: kelincahan bisnis, kelincahan organisasi, dan efektivitas teknik.

  • Kelincahan bisnis - Praktik yang menyangkut efektivitas dalam bisnis untuk menerjemahkan kebutuhan bisnis menjadi persyaratan. Seberapa responsif organisasi pengiriman terhadap permintaan bisnis, dan seberapa besar kontrol yang dimiliki bisnis dalam melepaskan fungsionalitas ke lingkungan produksi.

  • Kelincahan organisasi - Praktik yang menentukan proses pengiriman. Contohnya termasuk metodologi dan DevOps upacara yang tangkas serta penugasan peran dan kejelasan, dan kolaborasi, komunikasi, dan pemberdayaan secara keseluruhan di seluruh organisasi.

  • Efektivitas teknik - Praktik pengembangan yang terkait dengan jaminan kualitas, pengujian, CI/CD, manajemen konfigurasi, desain aplikasi, dan manajemen kode sumber.

Mengidentifikasi metrik

Untuk mengetahui apakah Anda memberikan apa yang penting kepada pelanggan Anda, Anda harus menerapkan langkah-langkah yang mendorong peningkatan dan mempercepat pengiriman. Tujuan, pertanyaan, metrik (GQM) menyediakan kerangka kerja yang efektif untuk memastikan bahwa tindakan Anda memenuhi kriteria ini. Gunakan kerangka kerja ini untuk bekerja kembali dari tujuan Anda dengan mengikuti langkah-langkah berikut:

  1. Identifikasi tujuan atau hasil yang Anda lakukan.

  2. Turunkan pertanyaan yang harus dijawab untuk menentukan apakah tujuan sedang terpenuhi.

  3. Putuskan apa yang harus atau dapat diukur untuk menjawab pertanyaan secara memadai. Ada dua kategori tindakan:

    • Metrik produk, yang memastikan bahwa Anda memberikan apa yang penting kepada pelanggan Anda.

    • Metrik operasional, yang memastikan bahwa Anda meningkatkan siklus hidup pengiriman perangkat lunak Anda.

Metrik produk

Metrik produk berfokus pada hasil bisnis dan harus ditetapkan ketika laba atas investasi (ROI) untuk lingkup pekerjaan baru ditentukan. Teknik yang berguna untuk membangun metrik produk adalah menanyakan apa yang akan berubah dalam bisnis ketika ruang lingkup pekerjaan baru diimplementasikan. Sangat membantu untuk meresmikan pemikiran ini ke dalam bentuk tes yang berfokus pada apa yang akan benar ketika fitur modernisasi disampaikan.

Misalnya, jika Anda yakin bahwa migrasi transaksi keluar dari sistem lama akan membuka peluang baru untuk klien onboard, apa peningkatannya? Berapa banyak kapasitas yang harus dibuat untuk onboard klien berikutnya? Bagaimana tes akan dibangun untuk memvalidasi hasil itu? Untuk skenario ini, metrik produk Anda dapat mencakup hal-hal berikut ini:

  • Mengidentifikasi uji nilai bisnis atau hipotesis (misalnya, membebaskan x persen dari kapasitas transaksi akan onboard y persen dari bisnis baru).

  • Tetapkan garis dasar (misalnya, kapasitas transaksi x saat ini mendukung pelanggan y).

  • Validasi hasilnya (misalnya, Anda telah meningkatkan kapasitas sebesar x persen, jadi dapatkah Anda sekarang onboard y persen bisnis baru?)

Metrik operasional

Untuk menentukan apakah Anda meningkatkan siklus hidup pengiriman perangkat lunak dan mempercepat modernisasi Anda, Anda harus mengetahui waktu tunggu dan waktu implementasi Anda untuk mengirimkan perangkat lunak. Artinya, seberapa cepat Anda dapat mengubah kebutuhan bisnis menjadi fungsionalitas dalam produksi?

Metrik operasional yang berguna meliputi:

  • Lead time - Berapa banyak waktu yang dibutuhkan untuk lingkup pekerjaan untuk beralih dari permintaan ke produksi?

  • Waktu siklus - Berapa lama waktu yang dibutuhkan untuk menerapkan lingkup pekerjaan, dari awal hingga akhir?

  • Frekuensi penyebaran - Seberapa sering Anda menerapkan perubahan pada produksi?

  • Waktu untuk memulihkan layanan - Berapa lama waktu yang dibutuhkan untuk pulih dari kegagalan (diukur sebagai waktu rata-rata untuk memperbaiki atau MTTR)?

  • Ubah tingkat kegagalan - Berapa waktu rata-rata antara kegagalan (MTBF)?