Perubahan kecil pada database dapat berdampak besar pada operasi perusahaan. Kolom yang diganti namanya mungkin masih dibaca aplikasi mobile versi lama. Tipe data baru dapat mengubah hasil laporan keuangan. Sementara itu, proses batch malam hari bisa tetap menulis memakai format sebelumnya, meskipun aplikasi utama sudah diperbarui.
Perubahan skema database enterprise perlu direncanakan sebagai transisi antara data, aplikasi, dan proses bisnis. Keberhasilannya tidak cukup dibuktikan dengan pesan bahwa skrip migrasi selesai. Tim harus memastikan transaksi tetap benar, seluruh konsumen kompatibel, serta jalur pemulihan masih dapat dijalankan.
Panduan ini ditujukan kepada Head of IT, CTO, pemilik aplikasi, DBA, dan manajer operasional yang akan mengubah struktur data pada ERP atau sistem custom yang sudah digunakan. Fokusnya adalah perubahan pada sistem berjalan, bukan pemindahan seluruh data saat implementasi ERP baru.
Apa Itu Perubahan Skema Database Enterprise?
Skema database mengatur bentuk penyimpanan data: tabel, kolom, tipe, relasi, indeks, dan aturan validasi. Perubahannya dapat berupa penambahan atribut, pemisahan sebuah tabel, penggantian kode status, atau pemberlakuan aturan yang sebelumnya belum ada.
Dalam perusahaan, satu struktur sering dipakai oleh banyak konsumen. Selain aplikasi web, terdapat worker, integrasi API, mesin laporan, ekspor spreadsheet, perangkat lapangan, dan sistem vendor. Karena itu, rencana perubahan perlu mencakup siapa yang membaca dan menulis, kapan mereka diperbarui, serta format yang harus tetap didukung selama transisi.
Contoh berikut merupakan ilustrasi perencanaan, bukan laporan proyek Layana.ID: perusahaan distributor ingin mengganti status pesanan bebas berupa teks menjadi daftar status yang terkontrol. Tim perlu memeriksa nilai lama, aturan perpindahan status, dan integrasi pelanggan sebelum menghapus kolom sebelumnya.
Tiga Pertanyaan Sebelum Menyetujui Perubahan
1. Apa Masalah Bisnis yang Akan Diselesaikan?
Jelaskan alasan perubahan dalam bahasa operasional. Apakah laporan sulit direkonsiliasi, kode status berbeda antarcabang, atau struktur lama tidak dapat mewakili proses persetujuan? Bedakan kebutuhan yang wajib dari perbaikan teknis yang dapat menunggu. Penambahan kolom tanpa definisi bisnis hanya memindahkan kebingungan ke tempat baru.
Untuk contoh status pesanan, sepakatilah kapan pesanan dianggap diterima, disetujui, dibatalkan, dan selesai. Finance, sales, dan gudang perlu memahami konsekuensi setiap status. Definisi ini menjadi dasar pemetaan data, skenario uji, serta penanganan pengecualian.
2. Siapa yang Masih Bergantung pada Struktur Lama?
Buat daftar konsumen beserta pemiliknya. Catat aplikasi yang aktif, jadwal worker, laporan periodik, query langsung, integrasi vendor, dan versi mobile yang masih didukung. Gunakan data lineage enterprise untuk membantu menelusuri dampak perubahan hingga laporan dan pengguna akhir.
Jangan menganggap tidak ada trafik berarti konsumen sudah berhenti. Laporan bulanan atau proses tutup buku mungkin baru berjalan setelah rilis. Periode pengamatan perlu mencakup siklus bisnis yang relevan, lalu pemilik proses mengonfirmasi apakah dependensi tersebut benar-benar sudah dipindahkan.
3. Bagaimana Tim Membuktikan dan Memulihkan Hasilnya?
Tentukan bukti penerimaan sebelum menulis skrip: jumlah record yang diperiksa, aturan pemetaan, batas kesalahan yang disetujui, serta transaksi kritis yang harus tetap berfungsi. Tentukan juga siapa yang berhak menghentikan transisi dan siapa yang menilai dampak bisnis jika pemulihan diperlukan.
Gunakan Transisi Bertahap: Expand, Migrate, Contract
Prisma Data Guide menjelaskan pola expand and contract sebagai perubahan struktur dan aplikasi secara bertahap: struktur baru diperkenalkan bersama struktur lama, data serta konsumen dialihkan, lalu struktur lama dihentikan. Pola ini membantu merencanakan kompatibilitas, tetapi bukan jaminan tanpa downtime untuk setiap database atau beban kerja.
Berikut rekomendasi kontrol operasional untuk menerapkan prinsip tersebut. Urutan detail harus disesuaikan dengan mesin database, versi, transaksi, dan karakter sistem perusahaan.
Expand: Tambahkan Jalur Baru Tanpa Memutus Jalur Lama
Rencanakan perubahan aditif terlebih dahulu. Dalam ilustrasi status pesanan, tim dapat menambahkan atribut status baru sambil mempertahankan atribut lama. Jangan langsung mewajibkan nilai baru jika aplikasi yang masih aktif belum dapat mengisinya.
Periksa dampak operasi DDL terhadap lock, penggunaan disk, dan durasi eksekusi pada versi database yang digunakan. Label “online” pada suatu fitur tidak menggantikan pengujian pada ukuran data serta pola akses yang representatif. Tetapkan jendela kerja dan kriteria penghentian bersama tim operasional.
Migrate: Isi Data Historis dan Kendalikan Penulisan Baru
Backfill adalah pengisian struktur baru dari data yang sudah ada. Pisahkan proses ini dari deploy aplikasi agar kemajuan, kegagalan, dan rekonsiliasinya dapat dipantau. Pada contoh status, setiap nilai lama harus memiliki pemetaan yang disepakati; nilai yang tidak dikenali masuk daftar pengecualian, bukan otomatis dipaksa menjadi “selesai”.
Jika kedua struktur menerima penulisan selama transisi, tentukan sumber kebenaran dan mekanisme sinkronisasi. Jelaskan apa yang terjadi ketika pembaruan salah satu sisi gagal. Jangan menganggap dua operasi tulis akan selalu berhasil bersama, terutama jika melintasi sistem atau transaksi yang berbeda.
Contract: Hentikan Struktur Lama Setelah Bukti Lengkap
Penghapusan struktur lama merupakan keputusan tersendiri. Minta bukti bahwa konsumen yang relevan sudah dipindahkan, data baru telah diterima pemilik bisnis, dan kebutuhan rollback sudah dinilai. Jangan menggabungkan penambahan kolom, backfill, pergantian pembacaan, serta penghapusan kolom dalam satu rilis hanya demi memperpendek jadwal.
Simpan rekaman keputusan: objek yang dihentikan, owner, bukti kompatibilitas, serta tanggal persetujuan. Dokumentasi singkat yang dapat ditelusuri lebih berguna daripada asumsi bahwa seluruh tim sudah mengetahui perubahan.
Checklist Backfill yang Dapat Dilanjutkan
Backfill sebaiknya dapat berhenti dan dilanjutkan tanpa mengubah record yang sudah benar secara keliru. Untuk menilai desainnya, gunakan pertanyaan berikut:
- Apakah ada identitas record dan checkpoint yang stabil?
- Apakah proses ulang menghasilkan nilai yang sama untuk input yang sama?
- Bagaimana pembaruan pengguna yang terjadi saat backfill berjalan dilindungi?
- Apakah kegagalan per record dicatat dengan alasan dan jalur penanganan?
- Apakah ukuran batch dapat dibatasi berdasarkan hasil pengamatan beban?
- Apakah pembatalan menghentikan pekerjaan dengan state yang dapat dipulihkan?
Dalam ilustrasi pesanan, jangan menimpa status baru yang sudah diubah oleh pengguna dengan hasil pemetaan dari snapshot lama. Tim perlu memilih mekanisme konsistensi yang sesuai, misalnya pemeriksaan versi atau waktu perubahan, lalu menguji konflik tersebut secara langsung. Pilihan mekanismenya harus mengikuti karakter transaksi, bukan disalin tanpa evaluasi.
Rekonsiliasi tidak cukup dengan membandingkan jumlah baris. Periksa distribusi status, record tanpa pemetaan, total nilai transaksi yang relevan, dan contoh pengecualian. Panduan rekonsiliasi integrasi ERP membantu merumuskan cara menindaklanjuti selisih tanpa menganggap setiap proses ulang aman.
Uji Kombinasi Versi, Bukan Hanya Aplikasi Terbaru
Buat matriks pengujian berdasarkan kombinasi yang mungkin hidup bersamaan selama rollout. Minimal, periksa aplikasi lama dengan struktur yang sudah diperluas, aplikasi transisi dengan kedua format data, serta aplikasi baru dengan struktur baru. Tambahkan worker dan konsumen vendor yang benar-benar ada dalam inventaris.
Gunakan transaksi bisnis nyata sebagai skenario, dengan data uji yang telah disanitasi atau data sintetis yang representatif. Untuk distributor, skenario dapat meliputi pembuatan pesanan, persetujuan, pembatalan, ekspor laporan, dan pembacaan status oleh portal pelanggan. Periksa hasil yang terlihat pengguna serta data yang tersimpan.
Tambahkan satu uji yang berusaha menggagalkan asumsi utama: worker lama tetap berjalan, sebuah nilai historis tidak terpetakan, atau backfill terputus di tengah batch. Tujuannya memastikan sistem mendeteksi kondisi itu dan menyediakan keputusan yang jelas, bukan hanya membuktikan jalur normal.
Rollback Aplikasi Berbeda dengan Pemulihan Data
Mengembalikan versi aplikasi tidak otomatis mengembalikan data ke kondisi sebelumnya. Setelah aplikasi baru menerima informasi yang tidak dapat diwakili struktur lama, rollback kode dapat membuat sebagian informasi tidak terbaca atau kehilangan makna. Tim perlu menentukan batas waktu dan kondisi ketika rollback masih layak.
Microsoft Learn, dalam dokumentasi Applying Migrations untuk EF Core, menganjurkan pemeriksaan dan pengujian migrasi sebelum digunakan pada database produksi. Dokumentasi itu juga mengingatkan risiko kehilangan data ketika membalikkan migrasi. Rencana pemulihan harus dinilai berdasarkan perubahan yang sebenarnya, bukan keberadaan perintah rollback saja.
Untuk keputusan internal, bedakan tiga pilihan: mengembalikan aplikasi sambil mempertahankan struktur aditif, memperbaiki ke depan dengan migrasi berikutnya, atau memulihkan data dari mekanisme backup yang telah diuji. Pemulihan backup perlu memperhitungkan transaksi sejak titik pemulihan serta dampaknya pada sistem terhubung. Jangan menjalankan pilihan tersebut tanpa owner dan persetujuan operasional yang jelas.
Gate Rilis dan Indikator yang Perlu Dipantau
Sebelum perubahan, ukur baseline agar kondisi sesudah rilis dapat dibandingkan. Pilih indikator yang berkaitan langsung dengan operasi: kegagalan transaksi, durasi query kritis, antrean pekerjaan, konflik lock, selisih rekonsiliasi, dan record yang belum dipindahkan. Ambang keputusan harus disepakati berdasarkan baseline dan kebutuhan bisnis; artikel ini tidak menetapkan angka universal.
Gunakan observability aplikasi enterprise untuk menghubungkan gejala dengan versi aplikasi, tahap migrasi, dan alur transaksi. Kemajuan “90% record selesai” tetap belum cukup jika sisa record mencakup transaksi bernilai besar atau proses tutup buku.
- Gate desain: definisi data, daftar konsumen, dan strategi kompatibilitas disetujui.
- Gate rehearsal: migrasi, backfill, konflik, dan pemulihan diuji pada lingkungan representatif.
- Gate perpindahan: data baru lolos rekonsiliasi serta transaksi kritis diterima pemilik bisnis.
- Gate penghentian: penggunaan struktur lama telah diperiksa sepanjang siklus yang relevan.
FAQ Perubahan Skema Database Enterprise
Apakah setiap perubahan membutuhkan expand and contract?
Tidak selalu. Pertimbangkan dampak, ukuran data, konsumen, kemampuan database, dan kebutuhan ketersediaan. Perubahan sederhana pada sistem dengan jendela maintenance yang disetujui dapat memakai prosedur lebih ringkas, selama kompatibilitas, validasi, dan pemulihan tetap dibuktikan.
Apakah pola ini menjamin zero downtime?
Tidak. Hasilnya bergantung pada operasi database, lock, kapasitas, versi aplikasi, dan koordinasi konsumen. Nyatakan target ketersediaan berdasarkan pengujian dan kondisi aktual, bukan nama pola arsitektur.
Kapan kolom lama boleh dihapus?
Setelah konsumen yang relevan berhenti menggunakannya, rekonsiliasi diterima, siklus bisnis penting tercakup, serta konsekuensi pemulihan disetujui. Durasi tunggu ditentukan oleh bukti penggunaan dan risiko perusahaan.
Siapkan Brief Sebelum Mengubah Database Produksi
Mulailah dari satu perubahan yang jelas. Siapkan tujuan bisnis, struktur yang terdampak, konsumen pembaca dan penulis, ukuran data, jendela operasional, serta skenario kegagalan yang ingin dihindari. Brief ini membantu tim menilai apakah rencana rilis cukup terkontrol atau perlu dipecah menjadi beberapa tahap.
Diskusikan rencana perubahan skema dan integrasi sistem bersama Layana.ID. Bawa daftar aplikasi yang terhubung, contoh aturan data, serta batas operasional agar pembahasan dimulai dari kebutuhan dan risiko yang konkret.
Referensi Teknis
Prisma Data Guide — Using the expand and contract pattern for schema changes; Microsoft Learn — Applying Migrations, EF Core. Prinsip sumber digunakan untuk konteks teknis; checklist, ilustrasi distributor, dan gate operasional di atas merupakan rekomendasi perencanaan yang perlu disesuaikan dengan sistem perusahaan.