Insinyur DevOps menulis kebijakan Kubernetes dalam Rego. Newton menulis aturan kepatuhan keuangan senilai $5 juta dalam bahasa yang sama.
Pilihan desain itu membuat saya berhenti sejenak ketika membacanya di dokumentasi resmi Newton di blog.newton.xyz: "Rego adalah bahasa yang sama yang tim TI sudah gunakan untuk kepatuhan dan penegakan kebijakan di dalam perusahaan tradisional."
Alasannya terdokumentasi dan jelas. Pengembang di perusahaan sudah mengenal Rego. Institusi dapat menulis dan mengaudit kebijakan kepatuhan mereka sendiri tanpa perlu mempelajari sintaks baru. Hambatan adopsi yang lebih rendah berarti integrasi yang lebih cepat.
Argumen itu nyata. Kontra-argumennya juga nyata.
Rego dirancang untuk kontrol akses dalam infrastruktur perangkat lunak. "Izinkan layanan ini untuk membaca rahasia ini" dan "blokir transfer ini ke lawan transaksi yang sudah disanksi" ditulis dalam bahasa yang sama, tetapi itu bukan masalah yang sama. Kontrol akses perangkat lunak gagal dengan permintaan yang ditolak. Kegagalan kepatuhan keuangan memindahkan uang ke tempat yang seharusnya tidak dituju, memicu tindakan regulasi, dan mengekspos institusi pada tanggung jawab hukum. Profil konsekuensinya berbeda jauh dalam skala magnitudo.
SQL awalnya dirancang untuk kueri basis data relasional. Ketika institusi keuangan mulai menggunakannya untuk pemantauan transaksi real-time, mereka menghabiskan bertahun-tahun menemukan edge case yang tidak pernah dirancang untuk ditangani bahasa tersebut pada tingkat risiko itu. Peralatan yang familiar di domain baru tidak otomatis berarti cocok untuk tujuan.
Newton bertaruh bahwa Rego cukup ekspresif untuk mencakup edge case kepatuhan keuangan yang tidak pernah dirancang untuk ditangani. Keakraban pengembang perusahaan adalah sisi positifnya. Kesesuaian domain yang belum teruji adalah bagian yang belum diperiksa siapa pun.
$NEWT #Newt @NewtonProtocol
Pilihan desain itu membuat saya berhenti sejenak ketika membacanya di dokumentasi resmi Newton di blog.newton.xyz: "Rego adalah bahasa yang sama yang tim TI sudah gunakan untuk kepatuhan dan penegakan kebijakan di dalam perusahaan tradisional."
Alasannya terdokumentasi dan jelas. Pengembang di perusahaan sudah mengenal Rego. Institusi dapat menulis dan mengaudit kebijakan kepatuhan mereka sendiri tanpa perlu mempelajari sintaks baru. Hambatan adopsi yang lebih rendah berarti integrasi yang lebih cepat.
Argumen itu nyata. Kontra-argumennya juga nyata.
Rego dirancang untuk kontrol akses dalam infrastruktur perangkat lunak. "Izinkan layanan ini untuk membaca rahasia ini" dan "blokir transfer ini ke lawan transaksi yang sudah disanksi" ditulis dalam bahasa yang sama, tetapi itu bukan masalah yang sama. Kontrol akses perangkat lunak gagal dengan permintaan yang ditolak. Kegagalan kepatuhan keuangan memindahkan uang ke tempat yang seharusnya tidak dituju, memicu tindakan regulasi, dan mengekspos institusi pada tanggung jawab hukum. Profil konsekuensinya berbeda jauh dalam skala magnitudo.
SQL awalnya dirancang untuk kueri basis data relasional. Ketika institusi keuangan mulai menggunakannya untuk pemantauan transaksi real-time, mereka menghabiskan bertahun-tahun menemukan edge case yang tidak pernah dirancang untuk ditangani bahasa tersebut pada tingkat risiko itu. Peralatan yang familiar di domain baru tidak otomatis berarti cocok untuk tujuan.
Newton bertaruh bahwa Rego cukup ekspresif untuk mencakup edge case kepatuhan keuangan yang tidak pernah dirancang untuk ditangani. Keakraban pengembang perusahaan adalah sisi positifnya. Kesesuaian domain yang belum teruji adalah bagian yang belum diperiksa siapa pun.
$NEWT #Newt @NewtonProtocol