Tahun pertama memakai platform low-code terasa seperti kemenangan: puluhan aplikasi lahir dalam hitungan minggu, backlog tim IT menyusut, dan unit bisnis akhirnya bisa membangun sendiri. Tahun kedua, tagihannya datang. Ratusan aplikasi kini tersebar tanpa ada yang tahu pasti mana yang masih dipakai, siapa pemiliknya, mana yang menyimpan data pelanggan, dan mana yang akan rusak saat sistem sumber di-upgrade. Fenomena ini punya nama: application sprawl. Artikel ini bukan ajakan mengerem low-code, melainkan peta untuk menjinakkannya lewat disiplin tata kelola siklus hidup aplikasi yang dikenal sebagai ALM.
Ringkas: Application sprawl adalah kondisi ketika organisasi memiliki terlalu banyak aplikasi tak terkelola, tanpa pemilik, versi, atau rencana pensiun yang jelas. Platform low-code mempercepatnya karena aplikasi mudah dibuat siapa saja. Obatnya adalah ALM (Application Lifecycle Management): disiplin mengelola setiap aplikasi dari pembuatan hingga dekomisioning agar portofolio tetap terkendali dan upgrade-safe.
Kita akan mulai dari apa yang membuat portofolio aplikasi tumbuh liar, lalu masuk ke lima fase siklus hidup, praktik yang menahannya, dan satu peringatan yang jarang disuarakan: tata kelola yang terlalu ketat justru mematikan alasan low-code dipilih.
Apa Itu Application Sprawl, dan Mengapa Low-Code Mempercepatnya?
Application sprawl terjadi ketika jumlah aplikasi tumbuh lebih cepat daripada kemampuan organisasi mengelolanya. Low-code mempercepatnya karena membangun aplikasi tak lagi menuntut developer profesional: siapa pun bisa merakit satu dalam sehari. Kecepatan itu berkah sekaligus jebakan, sebab tanpa disiplin lifecycle, setiap aplikasi baru menambah beban yang tak terlihat.
Skala pembuatnya menjelaskan kenapa volume meledak. Menurut Gartner, pada 2025 sekitar 70% aplikasi baru yang dikembangkan organisasi memakai teknologi low-code atau no-code, naik tajam dari kurang dari 25% pada 2020. Gartner juga memperkirakan pada 2026 setidaknya 80% pengguna alat low-code berasal dari luar departemen IT formal, naik dari 60% pada 2021, dan sekitar 41% karyawan kini dapat dikategorikan sebagai business technologist (karyawan non-IT yang membuat kapabilitas teknologi). Ketika pembuat aplikasi berlipat, portofolio pun berlipat.
Masalahnya bukan jumlah, melainkan ketidakterkelolaan. Sejumlah aplikasi sekali pakai memang sehat dan wajar. Yang berbahaya adalah aplikasi yang hidup tanpa jejak. Gejalanya biasanya muncul bersamaan:
- Aplikasi tanpa pemilik. Pembuatnya sudah pindah divisi atau resign, tetapi aplikasinya masih jalan dan dipakai diam-diam.
- Versi yang tak terlacak. Tidak ada yang tahu perubahan terakhir dilakukan kapan, oleh siapa, dan apakah bisa dikembalikan.
- Data sensitif yang menyelinap. Aplikasi “iseng” ternyata menyimpan data pelanggan atau angka keuangan tanpa kontrol akses yang memadai.
- Ketergantungan tersembunyi. Satu aplikasi menarik data dari sistem inti, lalu patah tanpa peringatan saat sistem itu dimutakhirkan.
Analis seperti Forrester mencatat application sprawl cenderung tumbuh lebih cepat daripada tata kelola, integrasi, dan pengawasan siklus hidupnya. Kesenjangan itu menumpuk risiko dan technical debt (utang teknis) seiring adopsi meluas. Padahal pasarnya terus membesar; Forrester memproyeksikan belanja low-code global menembus sekitar USD 50 miliar pada 2028. Semakin besar adopsi, semakin mahal harga dari tidak menatanya.
Apa Itu ALM (Application Lifecycle Management) untuk Low-Code?
ALM adalah disiplin mengelola aplikasi di seluruh siklus hidupnya: ide, bangun, uji, rilis ke produksi, pelihara, lalu pensiun. Pada konteks low-code, ALM menambahkan satu dimensi: mengatur kecepatan rilis yang tinggi dan peran citizen developer agar tetap aman. Tujuannya menjaga setiap aplikasi punya environment yang benar, versi yang terlacak, dan pemilik yang jelas.
Di dunia ERP klasik, konsep ini sudah lama ada lewat perpindahan antar sistem dan klien ABAP. Yang berubah pada low-code berbasis cloud adalah batas environment-nya. Di SAP BTP (Business Technology Platform), batas antar-environment diwujudkan lewat subaccount yang berbeda, bukan sistem fisik terpisah. Pola yang direkomendasikan, sebagaimana diuraikan dalam materi DevOps untuk SAP BTP, memakai tiga subaccount, yaitu Development, Test, dan Production, yang dirangkai dalam lanskap linear tiga simpul (Dev ke Test, lalu Test ke Produksi) dengan pemisahan tugas yang tegas.
ALM bukan alat pengekang citizen developer, justru sebaliknya: ia memberi mereka lingkungan dan rambu yang aman untuk berkarya. Framing yang benar adalah pemberdayaan dengan batas yang jelas, bukan birokrasi yang memperlambat.
Lima Fase Siklus Hidup Aplikasi Low-Code dan Kontrol di Tiap Fase
Siklus hidup aplikasi low-code dapat dipecah menjadi lima fase: rancang, bangun, uji, rilis, lalu pelihara hingga pensiun. Setiap fase punya kontrol kunci yang berbeda, dan di SAP BTP tiap fase memetakan ke environment atau layanan tertentu. Mengabaikan kontrol di satu fase saja sudah cukup untuk melahirkan sprawl di kemudian hari.
| Fase | Apa yang terjadi | Kontrol kunci | Padanan di SAP BTP / Build |
|---|---|---|---|
| 1. Rancang | Ide dan kebutuhan divalidasi; pemilik ditetapkan | Intake dan triase; tetapkan owner dan tingkat risiko | Masuk via SAP Build Lobby; dicatat di katalog |
| 2. Bangun | Aplikasi dirakit di lingkungan pengembangan | Isolasi dari produksi; standar dan template | Subaccount Dev; SAP Build Apps / Build Process Automation |
| 3. Uji | Validasi fungsi dan data sebelum rilis | Gerbang kualitas; data uji non-produksi | Subaccount Test; transport via SAP CTM (Dev ke Test) |
| 4. Rilis | Aplikasi dirilis ke pengguna | Transport terkontrol; audit trail; separation of concerns | Subaccount Prod; released version via SAP CTM (Test ke Prod) |
| 5. Pelihara & pensiun | Perbaikan, pelacakan versi, lalu dekomisioning | Versioning dan rollback; pantau pemakaian; aturan pensiun | Project versioning SAP Build Apps; hapus dari subaccount Prod |
Perpindahan antar-fase itulah yang dijaga SAP Cloud Transport Management (SAP CTM), layanan terpusat di SAP BTP untuk memindahkan aplikasi antar-subaccount secara terkontrol, lengkap dengan audit trail menyeluruh dan pemisahan tugas antara tim pembangun dan operasional, tanpa memerlukan sistem ABAP. Pada fase pelihara, disiplin versioning yang rapi juga menopang prinsip SAP Clean Core: ekstensi low-code yang dikelola dengan benar di SAP BTP tetap upgrade-safe saat inti S/4HANA dimutakhirkan.
Praktik ALM yang Mencegah Kekacauan: dari Environment sampai Katalog Kepemilikan
Praktik ALM yang efektif berdiri di atas enam pilar: pemisahan environment, transport terkontrol, versioning, katalog kepemilikan, aturan pensiun, dan sebuah Center of Excellence yang menaungi semuanya. Keenamnya tidak perlu diterapkan sekaligus, tetapi tanpa salah satunya, celah tata kelola akan cepat dimanfaatkan oleh aplikasi yang tumbuh tanpa pengawasan.
- Pisahkan environment dev, test, dan produksi. Perubahan setengah jadi tidak boleh menyentuh aplikasi yang sedang dipakai. Di SAP BTP, pemisahan ini diwujudkan lewat subaccount berbeda untuk tiap tahap.
- Kontrol transport antar-environment. Jangan pernah memindahkan aplikasi ke produksi secara manual. SAP CTM memindahkan deliverable antar-subaccount dengan jejak audit dan persetujuan yang terekam.
- Terapkan versioning dan jalur rollback. SAP Build Apps memperkenalkan project versioning, yang memungkinkan released version sebuah proyek ditransport antar-subaccount (SAP Community). SAP Build Process Automation punya alur transport kontennya sendiri antar-tenant.
- Bangun katalog aplikasi dengan pemilik yang jelas. Katalog, yaitu daftar terpusat berisi setiap aplikasi, pemiliknya, dan statusnya, adalah praktik tata kelola, bukan satu fitur SAP bernama resmi. Entry point pengelolaan proyek sendiri ada di SAP Build Lobby, dengan hak akses dikontrol lewat role di SAP BTP.
- Tetapkan aturan pensiun. Aplikasi tanpa aktivitas dalam periode tertentu masuk daftar tinjau; sebelum dinonaktifkan, datanya diarsipkan, penggunanya diberi tahu, dan aksesnya dicabut.
- Bentuk Center of Excellence (CoE). CoE adalah tim lintas-fungsi yang menetapkan standar, guardrail, dan template yang bisa dipakai ulang. CoE ini bisa dijalankan internal maupun dengan pendampingan mitra implementasi.
Disiplin yang sama berlaku lintas lapisan, bukan hanya aplikasi. Konten analitik seperti dasbor dan laporan di platform Business Intelligence menghadapi masalah sprawl dan kepemilikan yang serupa: terlalu banyak dasbor tanpa pemilik sama membingungkannya dengan terlalu banyak aplikasi tanpa pemilik. Survei industri menyebut sekitar 48% organisasi sudah memiliki CoE low-code khusus, dan 84% perusahaan besar menjalankan tiga platform low-code atau lebih, satu tanda bahwa tata kelola portofolio sudah menjadi kebutuhan arus utama.
Tata Kelola yang Berlebihan Juga Membunuh Low-Code
Tata kelola yang berlebihan sama berbahayanya dengan tidak ada tata kelola. Jika setiap aplikasi, sekecil apa pun, harus melewati komite dan antrean tiket, kecepatan yang menjadi alasan utama low-code dipilih akan lenyap. Solusinya bukan kontrol seragam, melainkan tiering berbasis risiko: perlakukan aplikasi sesuai dampak dan sensitivitas datanya.
Bagian ini jarang ditulis kompetitor, padahal di sinilah keseimbangan ditentukan. Aplikasi pelacak tugas satu tim tidak layak diperlakukan sama ketatnya dengan aplikasi yang menyentuh data keuangan atau pelanggan. Memaksakan proses berat untuk semuanya akan mendorong karyawan kembali ke spreadsheet bayangan, dan shadow IT justru lebih sulit diawasi daripada aplikasi low-code yang terdaftar.
| Tier aplikasi | Contoh | Tingkat tata kelola |
|---|---|---|
| Rendah risiko | Pelacak tugas tim kecil, tanpa data sensitif | Ringan: self-service, guardrail minimal |
| Menengah / lintas-tim | Workflow persetujuan antar-departemen | Sedang: review desain, environment Test wajib |
| Tinggi / data kritikal | Aplikasi menyentuh data keuangan, pelanggan, atau ERP | Ketat: transport terkontrol, owner wajib, audit |
Dengan model berjenjang seperti ini, kebebasan dan kontrol tidak lagi bertarung. Aplikasi berisiko rendah tetap lahir cepat, sementara yang berisiko tinggi mendapat pengawasan yang memang pantas diterimanya.
FAQ (Pertanyaan yang Sering Diajukan)
Apa itu application sprawl pada low-code?
Application sprawl adalah kondisi ketika organisasi memiliki terlalu banyak aplikasi tak terkelola, tanpa pemilik, versi, atau rencana pensiun yang jelas. Low-code mempercepatnya karena aplikasi mudah dibuat siapa saja. Akibatnya portofolio membengkak, risiko dan technical debt menumpuk, dan tim IT kehilangan jejak mana aplikasi yang masih dipakai serta mana yang menyimpan data sensitif.
Apa itu ALM (Application Lifecycle Management) untuk low-code?
ALM adalah disiplin mengelola aplikasi di seluruh siklus hidupnya: ide, bangun, uji, rilis ke produksi, pelihara, hingga pensiun. Pada low-code, ALM menambahkan pengelolaan kecepatan rilis dan peran citizen developer. Tujuannya menjaga agar setiap aplikasi punya environment yang benar, versi terlacak, pemilik jelas, dan jalur pensiun, sehingga portofolio tetap terkendali.
Mengapa aplikasi low-code butuh environment dev/test/prod yang terpisah?
Memisahkan environment development, test, dan produksi mencegah perubahan setengah jadi merusak aplikasi yang sedang dipakai. Di SAP BTP, pemisahan ini diwujudkan lewat subaccount berbeda, dan perpindahan antar-environment dilakukan terkontrol memakai SAP Cloud Transport Management, lengkap dengan audit trail dan pemisahan tugas antara tim pembangun dan operasional.
Bagaimana cara memensiunkan aplikasi low-code yang tak terpakai?
Mulailah dari katalog aplikasi: identifikasi aplikasi dengan pemakaian nol atau pemilik yang hilang. Tetapkan aturan pensiun, misalnya aplikasi tanpa aktivitas dalam periode tertentu masuk daftar tinjau. Sebelum dinonaktifkan, arsipkan datanya, beri tahu pengguna tersisa, cabut akses, lalu hapus dari subaccount produksi. Pensiun terencana mengurangi permukaan risiko sekaligus membersihkan sprawl.
Siapa yang bertanggung jawab atas aplikasi low-code di perusahaan?
Setiap aplikasi sebaiknya punya pemilik bisnis yang jelas dan tercatat di katalog, yaitu orang atau unit yang bertanggung jawab atas relevansi, data, dan keputusan pensiunnya. IT dan Center of Excellence menetapkan guardrail seperti environment, hak akses, dan standar. Tanpa kepemilikan yang jelas, aplikasi menjadi yatim dan berubah menjadi sumber utama sprawl.
Apa itu Center of Excellence (CoE) low-code?
CoE low-code adalah tim lintas-fungsi yang menjadi pusat tata kelola: menetapkan standar, guardrail, template yang bisa dipakai ulang, dan kurasi platform. Ia menghubungkan IT dengan citizen developer agar kecepatan tetap tinggi tanpa kehilangan kontrol. Survei industri menunjukkan sekitar 48% organisasi sudah memiliki CoE low-code khusus, tanda bahwa tata kelola terstruktur kini menjadi arus utama.
Apakah SAP Build/BTP menyediakan kontrol ALM bawaan?
Ya. SAP BTP memisahkan environment lewat subaccount Dev, Test, dan Prod, sedangkan SAP Cloud Transport Management memindahkan aplikasi antar-environment secara terkontrol dengan audit trail. SAP Build Apps memiliki project versioning yang memungkinkan released version ditransport antar-subaccount, sementara SAP Build Process Automation mendukung transport konten antar-tenant. Disiplin ALM dapat ditegakkan dengan kapabilitas resmi, bukan sekadar prosedur manual.
Kesimpulan
Portofolio low-code yang sehat bukan yang paling sedikit aplikasinya, melainkan yang setiap aplikasinya punya pemilik, versi, environment yang benar, dan jalur pensiun yang jelas. Tagihan tahun kedua yang membuka artikel ini bisa dihindari bukan dengan mengerem inovasi, melainkan dengan menatanya sejak hari pertama. Pendampingan pasca go-live sering menjadi penentu di titik ini. Sebagai SAP Platinum Partner dan Certified AMS Partner (PCoE) yang menjadi bagian dari Metrodata Group sejak 1998, Soltius mengelola siklus hidup aplikasi SAP Build di atas SAP BTP lewat Application Management Services (AMS), berperan sebagai mitra yang mendampingi dan merawat, bukan membangun, platformnya.
Untuk menilai kesiapan tata kelola aplikasi low-code di perusahaan Anda, jelajahi solusi dan layanan terkait di soltius.co.id.
