10.1 Kenapa Satu Solusi Tidak Pernah Cukup

Bayangkan Anda sedang duduk di ruang meeting bersama tim produk. Seorang stakeholder dari divisi penjualan datang dengan permintaan yang terdengar sederhana: “Kami butuh sistem rekomendasi produk untuk customer kami. Bisakah dibuat?”

Di permukaan, ini terdengar seperti satu permintaan dengan satu jawaban. Tapi begitu Anda mulai menggali, Anda akan menemukan bahwa “sistem rekomendasi” bisa berarti banyak hal. Apakah rekomendasinya berdasarkan riwayat pembelian customer itu sendiri? Atau berdasarkan apa yang dibeli customer lain yang mirip? Apakah rekomendasinya muncul di halaman utama aplikasi, atau dikirim lewat email? Apakah sistem harus belajar dari data real-time, atau cukup diperbarui setiap malam?

Setiap pertanyaan ini membuka cabang solusi yang berbeda. Dan cabang-cabang itu bukan sekadar variasi teknis—masing-masing membawa konsekuensi yang berbeda terhadap biaya, waktu pengembangan, kualitas hasil, dan beban operasional tim.

Inilah mengapa seorang solution architect tidak pernah langsung menjawab “pakai ini” ketika mendengar sebuah kebutuhan. Tugas pertama Anda bukan memilih solusi, tetapi menyusun opsi-opsi yang mungkin. Seorang arsitek yang baik tahu bahwa masalah bisnis yang sama bisa diselesaikan dengan beberapa cara teknis yang berbeda, dan setiap cara memiliki trade-off yang perlu dipahami sebelum keputusan diambil.

Ambil contoh sederhana: kebutuhan untuk menyimpan file yang diunggah pengguna. Anda punya setidaknya tiga opsi. Pertama, simpan di server sendiri dengan sistem file biasa. Kedua, gunakan object storage seperti S3 atau layanan cloud sejenis. Ketiga, outsourcing penuh ke layanan file management pihak ketiga. Masing-masing opsi ini punya konsekuensi yang berbeda terhadap biaya infrastruktur, kecepatan akses, keamanan data, dan kemampuan tim untuk memeliharanya.

Berikut tabel perbandingan ketiga opsi tersebut berdasarkan beberapa dimensi penting.

Opsi Biaya Skalabilitas Perawatan Kecepatan Akses
Server Sendiri Rendah (hardware) Rendah Tinggi Tinggi
Object Storage (S3) Sedang (pay-per-use) Tinggi Rendah Sedang
Pihak Ketiga Tinggi (langganan) Tinggi Sangat Rendah Bervariasi

Berikut diagram pohon keputusan yang menggambarkan bagaimana satu permintaan "sistem rekomendasi" bercabang menjadi beberapa opsi dengan konsekuensi berbeda.

flowchart TD A[Sistem Rekomendasi] --> B[Sumber Data] A --> C[Saluran] A --> D[Frekuensi Update] B --> B1[Riwayat Sendiri] B --> B2[Customer Mirip] B1 --> B1a[Biaya rendah, akurasi sedang] B2 --> B2a[Biaya tinggi, akurasi tinggi] C --> C1[Halaman Utama] C --> C2[Email] C1 --> C1a[Real-time, engagement tinggi] C2 --> C2a[Batch, jangkauan luas] D --> D1[Real-time] D --> D2[Batch / Harian] D1 --> D1a[Infrastruktur mahal, respons cepat] D2 --> D2a[Biaya rendah, data tidak segar]

Setiap cabang membawa trade-off yang perlu dipertimbangkan sebelum memutuskan solusi akhir.

Opsi pertama mungkin terlihat paling murah di awal, tapi biaya operasional dan risiko kehilangan data bisa lebih tinggi. Opsi ketiga mungkin paling cepat diimplementasikan, tetapi Anda bergantung pada vendor dan data Anda berada di luar kendali langsung. Tidak ada satu pun yang benar atau salah—yang ada adalah pilihan yang sesuai dengan konteks bisnis dan kapasitas organisasi Anda.

Di era AI, jumlah opsi ini semakin bertambah. Sekarang Anda tidak hanya memilih antara build, buy, atau integrate. Anda juga bisa mempertimbangkan apakah bagian dari solusi bisa memanfaatkan AI—misalnya menggunakan model yang sudah dilatih, atau membangun model khusus dengan data internal Anda. Setiap jalur ini membuka kemungkinan baru, tetapi juga membawa kompleksitas baru yang harus diperhitungkan.

Seorang solution architect menyusun opsi-opsi ini bukan untuk membingungkan tim, tetapi untuk memberi fondasi keputusan yang kokoh. Ketika Anda sudah menyusun tiga hingga lima opsi yang masuk akal, barulah Anda bisa membandingkannya secara adil. Tanpa opsi, Anda hanya punya satu jawaban yang mungkin bukan yang terbaik.

Yang perlu diingat: menyusun opsi bukan berarti Anda harus mengevaluasi semua kemungkinan yang ada di dunia. Cukup opsi-opsi yang realistis untuk konteks organisasi Anda. Jika tim Anda hanya punya pengalaman dengan Java dan PostgreSQL, tidak perlu memasukkan opsi yang menggunakan bahasa pemrograman yang tidak dikuasai siapa pun. Opsi yang baik adalah opsi yang bisa dijalankan, bukan yang sempurna di atas kertas.

Setelah Anda memiliki daftar opsi, tantangan berikutnya adalah membandingkannya. Dan perbandingan ini tidak bisa dilakukan hanya dengan melihat angka biaya di permukaan. Di subbab berikutnya, kita akan membahas kerangka perbandingan yang lebih lengkap—bukan sekadar berapa biaya pembuatan, tetapi juga berapa nilai yang dihasilkan, berapa lama waktu ke pasar, dan bagaimana dampaknya terhadap kemampuan tim di masa depan.