14.4 Architect: Bentuk Sistem dan Arah Keputusan

Bayangkan Anda bekerja di sebuah perusahaan yang sudah memiliki sepuluh aplikasi. Masing-masing dibuat oleh tim berbeda, di waktu berbeda, dengan teknologi berbeda. Suatu hari, perusahaan ingin semua pelanggan bisa login dengan satu akun. Tim Anda ditugaskan membuat fitur single sign-on.

Berikut contoh konfigurasi YAML untuk gateway autentikasi terpusat yang mengarahkan semua permintaan login dan validasi token ke satu layanan SSO.

# gateway-sso.yaml
routes:
  - path: /auth/login
    method: POST
    target: sso-service.internal:8080/login
    auth: false

  - path: /auth/validate
    method: GET
    target: sso-service.internal:8080/validate
    auth: false

  - path: /auth/logout
    method: POST
    target: sso-service.internal:8080/logout
    auth: true

  - path: /api/*
    method: ANY
    target: backend-service:3000
    auth: true
    authProvider: sso-service.internal:8080/validate

Dua jalur arsitektur berikut memperlihatkan bagaimana pilihan bentuk sistem menentukan arah modifikasi yang harus dilakukan tiap tim.

flowchart TD A[Keputusan Arsitektur: SSO] --> B{Database Terpusat?} B -->|Ya| C[Satu database untuk semua aplikasi] B -->|Tidak| D[Setiap aplikasi punya database sendiri] C --> E[Aplikasi lama: migrasi database ke pusat] C --> F[Aplikasi baru: langsung pakai database pusat] C --> G[Aplikasi manual: pindahkan data ke database pusat] D --> H[Aplikasi lama: buat API autentikasi] D --> I[Aplikasi baru: sudah punya API, sesuaikan format token] D --> J[Aplikasi manual: tambah endpoint validasi] E --> K[Semua aplikasi pakai satu sumber identitas] H --> L[Semua aplikasi komunikasi lewat API dengan standar token]

Tim A mengerjakan aplikasi lama yang pakai database sendiri. Tim B mengerjakan aplikasi baru yang sudah pakai API. Tim C masih pakai file konfigurasi manual. Anda sebagai engineer di salah satu tim mulai mengerjakan bagian Anda. Kode berfungsi. Tes berjalan. Tapi setelah integrasi, ternyata aplikasi lain tidak siap menerima token dari sistem login baru. Ada yang pakai format berbeda. Ada yang tidak punya endpoint untuk validasi. Ada yang menyimpan password dengan cara yang tidak kompatibel.

Inilah yang membedakan engineer dengan architect. Engineer memastikan bagian yang dikerjakan berfungsi dengan baik dan andal. Architect memikirkan bagaimana semua bagian itu akan bekerja bersama, tidak hanya hari ini, tetapi juga saat sistem berkembang satu atau dua tahun ke depan.

Arsitek tidak mulai dari kode. Arsitek mulai dari pertanyaan: bentuk seperti apa yang kita inginkan untuk sistem ini? Apakah semua aplikasi akan terhubung langsung ke satu database? Atau setiap aplikasi punya database sendiri dan berkomunikasi lewat API? Apakah kita ingin semua autentikasi melalui satu layanan terpusat, atau setiap aplikasi boleh punya cara login sendiri selama mengikuti standar tertentu?

Pertanyaan-pertanyaan ini menentukan arah keputusan. Begitu arsitek memutuskan bahwa semua autentikasi harus melalui satu layanan, maka semua tim harus mengikuti. Aplikasi lama harus dimodifikasi. Aplikasi baru harus dibangun dengan aturan itu. Vendor eksternal harus mendukung format token yang sama. Keputusan arsitektural seperti ini tidak bisa diubah setiap minggu karena dampaknya ke seluruh sistem.

Lebih dari itu, arsitek memikirkan capability. Bukan hanya fitur apa yang bisa dilakukan sistem hari ini, tetapi kemampuan apa yang perlu dimiliki sistem di masa depan. Mungkin hari ini cukup dengan login menggunakan email dan password. Tapi tahun depan perusahaan ingin mendukung login dengan Google dan Apple. Arsitek sudah memikirkan dari awal bagaimana arsitektur token dan penyimpanan identitas bisa diperluas tanpa harus menulis ulang seluruh sistem.

Yang paling penting, arsitek memikirkan konsekuensi jangka panjang. Setiap pilihan arsitektur punya harga yang harus dibayar. Memilih satu database raksasa untuk semua aplikasi membuat integrasi mudah, tetapi jika database itu bermasalah, semua aplikasi berhenti. Memilih microservices membuat setiap tim bisa bergerak cepat, tetapi tim harus punya kemampuan mengelola banyak layanan dan komunikasi antar layanan yang kompleks. Arsitek tidak memilih yang paling canggih, tetapi yang paling sesuai dengan kemampuan tim, kebutuhan bisnis, dan risiko yang bisa diterima.

Dalam praktiknya, arsitek sering terlihat seperti orang yang banyak melarang. “Jangan pakai database itu.” “Jangan buat API seperti ini.” “Jangan tambah fitur sebelum selesai urusan keamanan.” Tapi larangan itu bukan karena arsitek suka mempersulit. Larangan itu muncul karena arsitek sudah melihat konsekuensi dari pilihan yang tampak sepele hari ini, tetapi akan menjadi masalah besar enam bulan lagi.

Jika engineer adalah orang yang memastikan sistem berjalan dengan benar, arsitek adalah orang yang memastikan sistem tumbuh ke arah yang benar. Engineer membangun jalan yang kokoh. Arsitek menentukan jalan mana yang boleh dibangun, mana yang tidak, dan bagaimana semua jalan terhubung menjadi satu jaringan yang bisa dipakai bertahun-tahun.

Di era AI, peran arsitek menjadi semakin krusial. AI bisa menulis kode dengan cepat, bahkan bisa menulis kode untuk seluruh modul. Tapi AI tidak bisa memutuskan apakah keputusan arsitektural yang diambil hari ini akan membawa masalah di masa depan. AI tidak bisa melihat konsekuensi jangka panjang dari memilih satu framework dibanding framework lain. AI tidak bisa menilai apakah tim punya kapasitas untuk merawat arsitektur yang dipilih. Itu tetap menjadi tanggung jawab manusia yang berpikir sebagai arsitek.

Dari programmer ke engineer, lalu ke architect. Setiap level bukan sekadar tambahan tanggung jawab, tetapi perubahan cara memandang sistem. Programmer melihat kode. Engineer melihat sistem. Architect melihat bentuk, arah, dan konsekuensi. Dan di era AI, kemampuan melihat jauh ke depan inilah yang membuat seorang arsitek tidak bisa digantikan oleh mesin.