Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Langkah 1. Evaluasi 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 menilai tanpa memengaruhi bisnis Anda, dan kemudian memodernisasi, mengoptimalkan, dan menskalakan.
+ Buat profil lanskap aplikasi Anda untuk mengidentifikasi manfaat, risiko, dan biaya yang terkait dengan perubahan.
+ Menyediakan end-to-end serangkaian layanan: mulai dari strategi dan perencanaan; melalui penyebaran, migrasi, dan modernisasi aplikasi; hingga dukungan berkelanjutan.
+ Bangun 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 buku pedoman diagnostik modernisasi
Buku pedoman diagnostik modernisasi menyediakan proses untuk menentukan nilai perpindahan dari keadaan saat ini ke keadaan future untuk perusahaan. Ini termasuk perubahan teknologi yang melibatkan modernisasi.
Anda menggunakan buku pedoman 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 berikut dari keadaan saat ini dan target (pasca-migrasi) aplikasi atau sekelompok aplikasi:
+ Pengelompokan aplikasi — Apakah ada alasan untuk mengelompokkan aplikasi (misalnya, berdasarkan teknologi atau model operasi) untuk modernisasi?
+ Sequencing — Apakah ada urutan di mana aplikasi 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 pipeline integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD)?
+ Jika demikian, tanggung jawab infrastruktur apa yang harus didistribusikan ke tim aplikasi dan kepada siapa?
+ Jika tidak, tanggung jawab infrastruktur apa (misalnya, penambalan) yang harus tetap ada pada tim operasi?
+ Model pengiriman:
+ Berdasarkan aplikasi atau kelompok aplikasi, haruskah Anda memplatform ulang, memfaktorkan ulang, menulis ulang, atau mengganti?
+ Bagian modernisasi mana yang harus menggunakan layanan cloud-native?
+ Skill set — Keahlian apa yang dibutuhkan? Contoh:
+ Latar belakang aplikasi cloud untuk membangun aplikasi dengan arsitektur modular dengan menggunakan teknologi kontainer dan tanpa server dari bawah ke atas.
+ DevOps keahlian untuk mengembangkan solusi di bidang CI/CD proses, infrastruktur sebagai kode, dan otomatisasi atau observabilitas aplikasi dengan menggunakan sumber terbuka dan AWS alat dan layanan.
+ 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 kerja terencana lainnya yang dapat memengaruhi waktu modernisasi?
+ Unit dan total biaya infrastruktur — Berapa biaya tahunan untuk mempertahankan beban kerja Anda di tempat vs. pada 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
Saat 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 ke dalam 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 mendefinisikan proses pengiriman. Contohnya termasuk metodologi dan DevOps upacara 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 bagi pelanggan Anda, Anda harus menerapkan langkah-langkah yang mendorong peningkatan dan mempercepat pengiriman. Sasaran, pertanyaan, metrik (GQM) menyediakan kerangka kerja yang efektif untuk memastikan bahwa ukuran 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.
1. Turunkan pertanyaan yang harus dijawab untuk menentukan apakah tujuan tercapai.
1. Putuskan apa yang harus atau dapat diukur untuk menjawab pertanyaan secara memadai. Ada dua kategori ukuran:
+ Metrik produk, yang memastikan bahwa Anda memberikan apa yang penting bagi 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 ruang lingkup pekerjaan baru ditentukan. Teknik yang berguna untuk menetapkan metrik produk adalah dengan menanyakan apa yang akan berubah dalam bisnis ketika ruang lingkup pekerjaan baru itu diterapkan. Sangat membantu untuk memformalkan pemikiran ini ke dalam bentuk tes yang berfokus pada apa yang benar ketika fitur modernisasi disampaikan.
Misalnya, jika Anda yakin bahwa migrasi transaksi dari sistem lama akan membuka peluang baru bagi klien onboard, apa peningkatannya? Berapa banyak kapasitas yang harus dibuat untuk bergabung dengan klien berikutnya? Bagaimana tes dibangun untuk memvalidasi hasil itu? Untuk skenario ini, metrik produk Anda mungkin termasuk yang berikut:
+ Identifikasi uji nilai bisnis atau hipotesis (misalnya, membebaskan *x* persen dari kapasitas transaksi akan masuk *y* persen dari bisnis baru).
+ Tetapkan baseline (misalnya, kapasitas transaksi *x* saat ini mendukung pelanggan *y)*.
+ Validasi hasilnya (misalnya, Anda telah meningkatkan kapasitas sebesar *x* persen, jadi dapatkah Anda sekarang bergabung dengan *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 lama waktu yang dibutuhkan untuk lingkup pekerjaan untuk beralih dari permintaan ke produksi?
+ Waktu siklus — Berapa lama waktu yang dibutuhkan untuk mengimplementasikan ruang 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)?
+ Perubahan tingkat kegagalan — Berapa waktu rata-rata antara kegagalan (MTBF)?