🇬🇧 Read this article in English
TL;DR: Platform low-code menawarkan keunggulan nyata dalam hal kecepatan dan biaya untuk studi kasus yang tepat, tetapi tanpa tata kelola dan disiplin arsitektur yang baik, platform ini diam-diam menumpuk technical debt yang pada akhirnya akan merepotkan orang lain. Para eksekutif membutuhkan kerangka kerja untuk memutuskan di mana low-code cocok diterapkan — dan di mana platform ini sama sekali tidak boleh digunakan.
Setiap CIO yang saya ajak bicara saat ini menghadapi tekanan yang sama: melakukan lebih banyak dengan sumber daya yang lebih sedikit, melakukannya lebih cepat, dan membuatnya cukup tangguh untuk bertahan dari apa pun bentuk disrupsi berikutnya. Tekanan tersebut menciptakan lahan subur bagi platform low-code — alat yang menjanjikan pemangkasan waktu pengembangan dari hitungan bulan menjadi minggu, mendemokratisasi pembuatan aplikasi, dan mengurangi ketergantungan pada talenta developer yang langka. Tawarannya sangat menarik. Namun kenyataannya, seperti biasa, jauh lebih kompleks.
Saya sudah pernah melihat pola ini sebelumnya. Sebuah kategori teknologi baru muncul, pemasaran vendor melampaui kesiapan perusahaan, dan organisasi mengadopsinya tanpa struktur tata kelola untuk mengelola apa yang telah mereka bangun. Hasilnya bukanlah inovasi. Melainkan kekacauan yang butuh bertahun-tahun untuk diurai. Ini bukan berarti low-code adalah pilihan yang salah. Ini berarti kita harus jujur tentang apa itu low-code, apa yang bukan, dan di mana batas antara peluang nyata dan bom waktu technical debt.
Mengapa Platform Low-Code Semakin Diminati Perusahaan Saat Ini
Waktu kemunculannya bukanlah sebuah kebetulan. Ada beberapa kekuatan yang menyatu dan membuat platform low-code menjadi sangat menarik saat ini.
Pertama, kelangkaan talenta developer adalah hal yang nyata dan semakin memburuk. Biro Statistik Tenaga Kerja AS memproyeksikan permintaan developer perangkat lunak tumbuh sebesar 22% hingga tahun 2030, jauh di atas rata-rata. Sementara itu, organisasi memperketat anggaran seiring naiknya inflasi dan bergesernya era modal murah. Anda tidak bisa sekadar merekrut orang untuk menyelesaikan tumpukan pekerjaan ketika standar gaji pasar untuk developer tingkat menengah telah melonjak 15-20% dalam dua tahun terakhir.
Kedua, pandemi memaksa generasi proses bisnis untuk beralih ke ranah online dalam hitungan minggu, bukan tahun. Banyak dari solusi yang dibangun tergesa-gesa tersebut — alur kerja berbasis spreadsheet, rantai email manual yang disambung paksa ke sistem legacy — kini mulai kewalahan menangani beban operasional normal. Unit bisnis menginginkan alat yang lebih baik. Divisi IT tidak bisa mengirimkannya cukup cepat melalui pengembangan tradisional. Low-code mengisi celah tersebut, setidaknya di atas kertas.
Ketiga, platform itu sendiri telah jauh lebih matang. Gartner memperkirakan bahwa pada tahun 2025, 70% aplikasi baru yang dikembangkan oleh perusahaan akan menggunakan teknologi low-code atau no-code, naik dari kurang dari 25% pada tahun 2020. Microsoft Power Platform, OutSystems, Mendix, ServiceNow App Engine — ini bukan lagi sekadar alat mainan. Mereka menangani alur kerja nyata, terhubung ke sumber data nyata, dan beroperasi pada skala enterprise.
Jadi pertanyaannya bukanlah apakah low-code memiliki tempat dalam arsitektur enterprise. Tentu saja ada. Pertanyaannya adalah di mana, di bawah kondisi apa, dan dengan batasan pengaman (guardrails) seperti apa.
Biaya Tersembunyi yang Tidak Dibicarakan Siapa Pun
Inilah yang tidak akan ditunjukkan oleh demo vendor kepada Anda: total biaya kepemilikan (TCO) untuk aplikasi low-code jauh melampaui biaya lisensi dan proses pembuatan awal. Saya telah melihat tiga pola yang terus berulang di berbagai organisasi yang mengadopsi low-code tanpa perencanaan yang matang.
Shadow IT dalam Skala Besar
Tujuan utama dari low-code adalah memungkinkan non-developer untuk membangun aplikasi. Itu juga yang menjadi risikonya. Ketika seorang analis pemasaran membuat Power App untuk melacak kampanye, dan manajer keuangan membuat aplikasi lain untuk persetujuan anggaran, lalu pimpinan operasional membuat aplikasi ketiga untuk menjadwalkan gudang — Anda kini memiliki tiga aplikasi tanpa tata kelola yang menyentuh data perusahaan tanpa pengawasan arsitektur sama sekali.
Saya pernah bekerja dengan sebuah perusahaan manufaktur skala menengah yang menemukan, selama audit platform, ada lebih dari 200 alur Power Automate yang berjalan di seluruh organisasi. Kurang dari 30 yang memiliki dokumentasi. Tidak ada yang tahu siapa pemilik dari sekitar seperempat aplikasi tersebut. Beberapa di antaranya memindahkan data keuangan antar sistem dengan cara yang, secara halus, akan membuat auditor mereka gelisah.
Ini bukan masalah Power Platform. Ini adalah masalah tata kelola. Namun, low-code membuatnya jauh lebih mudah untuk menciptakan aplikasi tanpa tata kelola dengan sangat cepat.
Vendor Lock-In yang Mengintai Anda
Sebagian besar platform low-code menggunakan bahasa pemodelan, struktur data, dan lingkungan penerapan (deployment) yang eksklusif (proprietary). Ketika Anda membangun lima puluh aplikasi di OutSystems, Anda tidak membangun lima puluh aset portabel. Anda membangun lima puluh aplikasi yang hanya bisa berjalan di OutSystems.
Hal ini mungkin tidak terlalu bermasalah untuk alur persetujuan sederhana. Namun ini menjadi sangat krusial ketika proses bisnis yang kritis menjadi bergantung pada platform yang model penetapan harga, peta jalan fitur, atau kelangsungan pasarnya tidak dapat Anda kendalikan. Saya pernah melihat organisasi menghadapi kenaikan biaya lisensi 40-60% saat perpanjangan karena vendor tahu biaya migrasinya akan jauh lebih tinggi.
Ilusi Pemeliharaan (Maintenance)
Aplikasi low-code memang cepat dibangun. Namun bukan berarti bebas pemeliharaan. Setiap aplikasi membutuhkan pembaruan saat API yang mendasarinya berubah, saat aturan bisnis berkembang, saat patch keamanan diperlukan, atau saat platform itu sendiri merilis pembaruan yang mengubah sistem. Citizen developer yang membangun aplikasi itu dalam satu sore mungkin sudah pindah ke peran lain, keluar dari perusahaan, atau sekadar lupa bagaimana cara kerjanya.
Pengembangan tradisional setidaknya menghasilkan kode yang bisa dibaca, di-debug, dan dimodifikasi oleh developer lain. Aplikasi low-code yang dibangun melalui antarmuka visual bisa menjadi sangat tidak transparan ketika ada yang rusak dan pembuat aslinya tidak ada di tempat.
Kerangka Kerja untuk Mengevaluasi Di Mana Low-Code Cocok Diterapkan
Tidak setiap keputusan aplikasi membutuhkan tingkat ketelitian yang sama. Saya menggunakan kerangka kerja dua sumbu yang sederhana saat menasihati klien tentang apakah low-code sesuai untuk kasus penggunaan tertentu:
Sumbu 1: Kekritisan Bisnis (Business Criticality) — Seberapa besar dampaknya jika aplikasi ini gagal, menghasilkan data yang salah, atau tidak dapat diakses? Beri skor dari rendah (alat bantu internal) hingga tinggi (berdampak pada pendapatan, regulasi, atau berhadapan langsung dengan pelanggan).
Sumbu 2: Kompleksitas dan Kedalaman Integrasi — Berapa banyak sistem yang disentuh aplikasi ini? Seberapa kompleks logika bisnisnya? Apakah ini membutuhkan integrasi kustom, menangani data sensitif, atau perlu diskalakan secara tak terduga?
Ini memberi Anda empat kuadran:
| Kompleksitas Rendah | Kompleksitas Tinggi | |
|---|---|---|
| Kekritisan Rendah | Ideal untuk low-code. Biarkan citizen developer yang menjalankannya. | Low-code memungkinkan, tetapi butuh pengawasan arsitektur dari IT. |
| Kekritisan Tinggi | Low-code dapat diterima dengan tata kelola, pengujian, dan kepemilikan IT. | Pengembangan tradisional atau platform enterprise. Jangan bangun ini menggunakan low-code. |
Titik ideal untuk platform low-code adalah kuadran kiri atas: alat departemen, dasbor internal, alur persetujuan sederhana, formulir pengumpulan data, dan otomatisasi tugas. Ini adalah kasus penggunaan yang benar-benar bagus. Mereka membebaskan kapasitas IT untuk pekerjaan bernilai lebih tinggi, dan memberikan kecepatan yang diinginkan oleh tim bisnis.
Zona bahayanya ada di kuadran kanan bawah. Ketika seseorang mengusulkan untuk membangun proses yang kompleks dan kritis bagi bisnis di platform low-code karena alasan lebih cepat dan lebih murah, Anda perlu bertanya: lebih cepat dan lebih murah dibandingkan dengan apa? Dibandingkan dengan biaya untuk membangunnya kembali dengan benar dalam dua tahun ke depan ketika aplikasi tersebut tidak bisa diskalakan, tidak bisa diaudit, dan tidak bisa dipelihara?
Tata Kelola: Syarat Mutlak yang Tidak Bisa Ditawar
Jika Anda hanya mengambil satu pelajaran dari artikel ini, biarlah ini: low-code tanpa tata kelola bukanlah inovasi. Itu adalah penderitaan yang tertunda.
Tata kelola yang efektif untuk low-code bukan berarti birokrasi yang mematikan keunggulan kecepatan. Ini berarti serangkaian standar yang ringan namun ditegakkan secara tegas. Berdasarkan apa yang saya lihat berhasil di lapangan, berikut adalah elemen-elemen esensialnya:
- Registri aplikasi: Setiap aplikasi low-code harus didaftarkan secara terpusat. Siapa yang membangunnya, apa fungsinya, data apa yang disentuhnya, siapa pemiliknya. Tanpa pengecualian.
- Penegakan klasifikasi data: Alat low-code tidak boleh memiliki akses tak terbatas ke data sensitif. Tetapkan sumber data mana yang boleh dihubungkan oleh citizen developer, dan mana yang membutuhkan keterlibatan IT.
- Kontrol lingkungan (Environment): Lingkungan produksi, staging, dan pengembangan harus dipisahkan. Seorang citizen developer tidak boleh menguji perubahan langsung pada data produksi.
- Ambang batas peninjauan: Aplikasi di bawah ambang batas kompleksitas tertentu bisa bersifat layanan mandiri (self-service). Di atas ambang batas tersebut, tinjauan arsitektur IT wajib dilakukan sebelum peluncuran (deployment).
- Kepemilikan siklus hidup: Setiap aplikasi membutuhkan pemilik teridentifikasi yang bertanggung jawab atas pemeliharaan. Jika pemiliknya keluar, kepemilikan berpindah secara eksplisit — bukan dibiarkan begitu saja tanpa pemilik.
Microsoft, patut diapresiasi, telah membangun beberapa kontrol ini ke dalam toolkit Center of Excellence untuk Power Platform. Platform lain menawarkan tingkat pengawasan administratif yang bervariasi. Namun, alat-alat tersebut hanya berfungsi jika ada yang mengonfigurasi dan menegakkannya. Dan pihak tersebut haruslah pimpinan IT.
Apa yang Saya Sampaikan kepada Klien Saat Ini
Saran saya kepada para eksekutif yang mengevaluasi platform low-code saat ini bermuara pada lima poin:
- Adopsi secara terencana, bukan reaktif. Low-code harus menjadi keputusan arsitektur yang sadar, bukan sesuatu yang terjadi karena sebuah unit bisnis mendaftar uji coba gratis dan mulai membangun aplikasi.
- Mulai dari kerangka tata kelola, bukan pemilihan platform. Putuskan bagaimana Anda akan mengelola aplikasi low-code sebelum Anda memutuskan platform mana yang akan dibeli. Model tata kelola inilah yang harus mengarahkan evaluasi vendor, bukan sebaliknya.
- Sesuaikan alat dengan masalahnya. Gunakan kerangka kerja kekritisan-kompleksitas. Disiplinlah dalam menempatkan low-code di kuadran yang semestinya.
- Anggarkan untuk total biaya kepemilikan (TCO). Masukkan lisensi, pelatihan, biaya tata kelola, pemeliharaan berkelanjutan, hingga biaya migrasi atau penghentian (retirement) pada akhirnya ke dalam model biaya Anda. Pembuatan awal adalah bagian termurah dari seluruh siklus hidup aplikasi.
- Perlakukan citizen developer sebagai mitra, bukan ancaman. Pengguna bisnis yang membangun aplikasi low-code sebenarnya sedang berusaha memecahkan masalah nyata. Salurkan energi tersebut secara produktif dengan pelatihan, standar, dan dukungan — bukan dengan pembatasan yang justru mendorong mereka kembali menggunakan spreadsheet.
Pertanyaan yang Sering Diajukan (FAQ)
Apakah platform low-code cukup aman untuk penggunaan skala enterprise?
Platform itu sendiri umumnya memenuhi standar keamanan enterprise — sebagian besar vendor besar mengantongi sertifikasi SOC 2, ISO 27001, dan sejenisnya. Risiko keamanan biasanya tidak terletak pada platformnya. Melainkan pada bagaimana aplikasi dibangun di atasnya. Seorang citizen developer yang menghubungkan Power App secara langsung ke database produksi tanpa kontrol akses yang tepat telah menciptakan kerentanan keamanan yang tidak bisa diperbaiki oleh sertifikasi platform mana pun. Keamanan bergantung pada tata kelola, kebijakan akses data, dan kontrol lingkungan, bukan hanya pada infrastruktur vendor.
Haruskah IT memegang penuh pengembangan low-code, atau haruskah unit bisnis memiliki otonomi?
Kedua ekstrem ini tidak bekerja dengan baik. Kepemilikan penuh oleh IT menghilangkan keunggulan kecepatan yang membuat low-code bernilai. Otonomi bisnis secara penuh menciptakan pertumbuhan aplikasi yang tidak terkendali. Model yang saya rekomendasikan adalah pendekatan terfederasi (federated approach): unit bisnis memiliki kendali pengembangan untuk aplikasi di bawah ambang batas kompleksitas dan kekritisan yang ditentukan, sementara IT menyediakan platform, batasan pengaman, dan pengawasan arsitektur untuk apa pun yang berada di atas ambang batas tersebut. Anggap saja seperti aturan mendirikan bangunan — Anda tidak butuh arsitek hanya untuk memasang rak, tetapi Anda butuh arsitek untuk menambah lantai pada gedung.
Bagaimana platform low-code memengaruhi arsitektur IT jangka panjang?
Ini adalah pertanyaan yang jarang sekali diajukan. Setiap aplikasi low-code adalah keputusan arsitektur, terlepas dari apakah ia diperlakukan demikian atau tidak. Ia menciptakan aliran data, titik integrasi, dan ketergantungan. Seiring berjalannya waktu, portofolio besar aplikasi low-code tanpa tata kelola dapat memecah arsitektur data Anda, menciptakan proses yang tumpang tindih, dan membuatnya jauh lebih sulit untuk memigrasikan atau mengonsolidasikan sistem. Dampak ini bisa dikelola jika Anda mempertahankan visibilitas terhadap apa yang telah dibangun dan menegakkan standar integrasi. Tanpa visibilitas tersebut, Anda sedang menumpuk utang arsitektur (architectural debt) bersamaan dengan technical debt.
Apakah low-code hanya sekadar tren, atau akan bertahan lama?
Low-code akan bertahan, tetapi tidak dalam bentuk yang dibesar-besarkan oleh siklus hype. Low-code tidak akan menggantikan pengembangan perangkat lunak tradisional untuk sistem yang kompleks dan krusial bagi misi perusahaan (mission-critical). Apa yang akan dilakukannya — dan sudah dilakukannya — adalah mengubah secara permanen bagaimana organisasi menangani antrean panjang aplikasi kecil dan otomatisasi yang tidak pernah memiliki kapasitas untuk dibangun oleh tim IT. Kelangkaan developer bersifat struktural, bukan siklikal. Permintaan untuk aplikasi bisnis terus tumbuh lebih cepat daripada pasokan developer. Low-code adalah respons rasional terhadap hitung-hitungan tersebut, dan hitung-hitungan itu tidak akan berubah.
Kesimpulan (The Bottom Line)
Platform low-code bukanlah revolusi yang diklaim oleh vendor mereka, bukan pula bencana yang ditakuti oleh para kritikusnya. Mereka adalah alat — alat yang sangat kuat — yang dapat menghasilkan dampak baik atau buruk, bergantung sepenuhnya pada bagaimana mereka dikelola dan di mana mereka diterapkan.
Organisasi yang akan berhasil dalam hal ini adalah mereka yang memperlakukan low-code sebagai kapabilitas strategis dengan batasan yang jelas, bukan sebagai eksperimen yang tidak terkendali. Mereka akan berinvestasi pada tata kelola sebelum berinvestasi pada lisensi. Mereka akan jujur tentang masalah mana yang benar-benar bisa diselesaikan oleh low-code dan mana yang hanya disamarkannya. Dan mereka akan menahan godaan untuk membiarkan kecepatan pengiriman (delivery) menggantikan kualitas pengambilan keputusan.
Technical debt tidak pernah mengumumkan kedatangannya. Ia menumpuk secara diam-diam dalam alur kerja tanpa tata kelola, aplikasi yang tidak terdokumentasi, dan jalan pintas arsitektur yang tampak masuk akal pada saat itu. Para eksekutif yang memahami hal ini — yang membangun batasan pengaman sekarang daripada harus membersihkan kekacauan di kemudian hari — adalah mereka yang organisasinya akan tetap berjalan lancar ketika gelombang teknologi berikutnya datang dan berjanji untuk mengubah segalanya.
