Pada 27 Agustus 2026, sebuah perintah eksekutif AS mengganti nama Danau Ontario menjadi Danau Amerika di basis data nama geografis federal. Tiga hari kemudian Google Maps menerapkan perubahan itu, dan Apple Maps menyusul pada 2 September. Kanada menolak nama tersebut, padahal perbatasan kedua negara melintasi danau itu sendiri.

Akibatnya, satu entitas geografis kini memiliki tiga label tergantung dari mana Anda melihatnya: orang di AS melihat Danau Amerika, orang di Kanada melihat Danau Ontario, dan semua orang lainnya melihat keduanya. Ini bukan kasus pertama; Teluk Meksiko diganti namanya menjadi Teluk Amerika tahun lalu dengan logika yang sama.

Mudah saja membaca ini sebagai berita politik lalu melupakannya. Yang sebenarnya terjadi adalah sebuah ujian rekayasa: setiap sistem di dunia yang menyimpan nama danau ini sebagai teks tetap kini menampilkan informasi yang salah kepada sebagian penggunanya. Pertanyaan yang penting bagi kita: apakah sistem Anda dibangun untuk menyerap perubahan semacam itu?

Kesalahan mendasar: menyimpan label, bukan identitas

Sebagian besar sistem menyimpan apa yang dilihat mata. Kolom teks bernama kota berisi Riyadh, kolom negara berisi nama negara, tarif pajak adalah angka yang ditulis di dalam kode. Cara ini bekerja dengan efisien sampai fakta itu sendiri berubah, lalu Anda mendapati bahwa data historis Anda tidak bisa lagi ditafsirkan.

Aturan rekayasanya sederhana: simpan pengenal yang stabil dan buat labelnya saat ditampilkan. Danau itu adalah entitas dengan pengenal yang tidak berubah, dan memiliki beberapa nama tergantung bahasa, konteks, dan sumber resmi. Simpan pengenalnya, maka penggantian nama menjadi pembaruan pada satu tabel referensi. Simpan namanya, maka itu menjadi proyek migrasi data yang utuh.

Apa yang benar-benar berubah dalam kehidupan sebuah perusahaan Saudi?

Danau itu contoh yang jauh. Daftar berikut tidak:

  • Tarif pajak. PPN Saudi naik dari 5% menjadi 15% pada 2020, dan perusahaan yang menuliskan angka itu di dalam kodenya melewati minggu yang berat. Lebih buruk daripada perubahannya sendiri: faktur lama harus tetap memakai tarif lamanya.
  • Persyaratan faktur elektronik. Gelombang integrasi dengan Otoritas Zakat, Pajak, dan Bea Cukai (ZATCA) datang secara bertahap, dan setiap gelombang bisa membawa perubahan pada spesifikasi teknis.
  • Nama negara. Türkiye menjadi nama resmi di PBB pada 2022, Makedonia menjadi Makedonia Utara, Swaziland menjadi Eswatini. Setiap daftar negara yang diketik manual ke dalam sistem Anda sudah ketinggalan zaman.
  • Alamat nasional dan format data. Format kode pos, nomor identitas nasional, IBAN, dan nomor badan usaha diperbarui, dan setiap validasi yang ditulis sebagai ekspresi reguler yang kaku akan rusak pada perluasan pertama.
  • Pajak di pasar lain. Jika Anda berjualan di luar Arab Saudi, perubahan datang dari negara-negara yang beritanya tidak Anda ikuti — seperti yang terjadi bulan ini ketika toko aplikasi menambahkan pajak baru di tiga negara sekaligus.

Lima prinsip untuk infrastruktur yang mampu menyerap perubahan

  • Pengenal, bukan label. Kaitkan setiap entitas dengan pengenal yang stabil dan simpan nama-namanya di tabel terpisah yang menerima lebih dari satu nama per entitas, menurut bahasa dan menurut sumber.
  • Tanggal berlaku pada setiap nilai yang bisa berubah. Tarif pajak bukan satu angka, melainkan rangkaian nilai yang masing-masing memiliki tanggal mulai dan tanggal berakhir. Hal ini saja sudah menyelesaikan masalah pencetakan ulang faktur lama dengan tarif yang benar, dan mencegah bencana akuntansi pada audit pertama.
  • Data referensi sebagai konfigurasi, bukan kode. Daftar negara, mata uang, pajak, dan wilayah berada di tabel atau file konfigurasi yang diperbarui oleh administrator yang berwenang — bukan di konstanta di dalam kode yang memerlukan rilis baru dan tim pengembang.
  • Lapisan tampilan yang terpisah dari penyimpanan. Apa yang disimpan adalah satu hal; apa yang ditampilkan adalah hal lain. Begitu sebuah sistem memisahkan keduanya, menampilkan nama yang berbeda kepada pengguna yang berbeda menjadi sekadar pengaturan, bukan pembangunan ulang — persis seperti yang dilakukan Google pada danau itu.
  • Satu sumber kebenaran. Jika tarif pajak tertulis di basis data, di templat faktur, dan di laporan penjualan, Anda memiliki tiga salinan yang pasti suatu saat tidak akan cocok. Pilih satu tempat dan buat bagian lainnya membaca dari sana.

Pemeriksaan praktis atas sistem Anda minggu ini

Ini tidak memerlukan proyek. Duduklah bersama developer Anda dan ajukan lima pertanyaan:

  • Jika tarif pajak berubah besok, berapa banyak file yang harus kita ubah? Dan apakah faktur lama tetap benar?
  • Di mana daftar negara dan mata uang kita — di dalam tabel, atau ditulis di dalam kode?
  • Apakah kita menyimpan nama kota sebagai teks, atau sebagai pengenal yang terhubung ke sebuah referensi?
  • Apa yang terjadi jika otoritas menambahkan satu digit pada nomor identitas nasional atau mengubah format kode pos?
  • Berapa banyak tempat di sistem yang mengetahui nilai pajak? Jika lebih dari satu, itulah masalah Anda berikutnya.

Jawaban-jawaban itu akan memperlihatkan titik-titik rapuh Anda dalam setengah jam, dan sebagian besar bisa diperbaiki dalam beberapa hari jika ditangani sebelum dibutuhkan, bukan sesudahnya.

Pandangan Origami

Kami melihat di sini pelajaran yang selalu kami ulangi kepada klien: sistem yang baik bukanlah sistem yang berjalan hari ini, melainkan sistem yang mampu menyerap dunia yang terus berubah tanpa harus ditulis ulang. Perbedaan keduanya bukan terletak pada kepintaran programmer, melainkan pada keputusan desain sederhana yang diambil di minggu pertama: pengenal alih-alih teks, tanggal berlaku alih-alih angka tetap, tabel referensi alih-alih daftar di dalam kode.

Keputusan-keputusan itu memakan waktu beberapa jam di awal dan menghemat berminggu-minggu kemudian. Kami pernah melihat perusahaan berhenti menerbitkan faktur selama berhari-hari karena perubahan regulasi yang sebenarnya bisa diserap dengan memperbarui satu baris di sebuah tabel, dan penyebabnya selalu sama: sebuah nilai ditulis di tempat yang tidak pernah dirancang untuk berubah.

Kesimpulan

Sebuah danau diganti namanya di satu negara dan nama itu ditolak di negara lain, sehingga kini danau itu memiliki tiga label sekaligus. Ini bukan pengecualian; ini adalah gambaran kecil dari apa yang terus-menerus terjadi pada data referensi. Pajak, nama, format, dan regulasi berubah karena keputusan pihak luar yang tidak Anda kendalikan. Yang Anda kendalikan adalah kesiapan sistem Anda, dan itu ditentukan saat desain, bukan saat perubahan terjadi.

Sumber

  • Blog resmi Google — pernyataan tentang penerapan perubahan nama di Google Maps dan cara penampilannya kepada pengguna di AS, Kanada, dan seluruh dunia, 30 Agustus 2026.
  • Liputan Reuters, TIME, dan BBC tentang perintah eksekutif pada 27 Agustus 2026, perubahan di Apple Maps pada 2 September, dan sikap Kanada.
  • Otoritas Zakat, Pajak, dan Bea Cukai (ZATCA), zatca.gov.sa — rujukan resmi untuk tarif PPN dan tahapan faktur elektronik.
  • Perserikatan Bangsa-Bangsa — penetapan Türkiye sebagai nama resmi pada 2022, sebagai contoh terdokumentasi perubahan nama negara.