9.7 Boundary: Antara Aplikasi, Data, dan Tim
Dengan scope yang jelas, kita perlu memastikan boundary antar sistem, data, dan tim juga jelas. Saya pernah melihat proyek yang sudah punya scope bagus, tetapi tetap kacau karena dua tim mengira mereka yang bertanggung jawab pada modul yang sama. Akibatnya, kode ditulis dua kali, integrasi tidak cocok, dan data disimpan di dua tempat dengan format berbeda. Masalahnya bukan pada scope, tetapi pada boundary yang tidak pernah didefinisikan.
Boundary adalah garis pemisah yang tegas antara satu bagian solusi dengan bagian lainnya. Garis ini bisa berada di antara aplikasi, service, modul, data, integrasi, platform, dan proses manual. Setiap boundary harus disertai ownership yang jelas: siapa yang membangun, siapa yang mengelola, siapa yang menyediakan antarmuka, dan siapa yang menjadi konsumen.
Bayangkan Anda sedang merancang sistem pengajuan kredit. Ada modul pengajuan, modul scoring, modul dokumen, dan modul persetujuan. Tanpa boundary yang jelas, tim pengajuan bisa saja membuat logika scoring sendiri karena merasa tim scoring lambat. Atau tim dokumen menyimpan data pengajuan ulang karena tidak tahu bahwa data itu sudah ada di modul pengajuan. Setiap tim merasa punya alasan, tetapi hasilnya adalah duplikasi, inkonsistensi, dan utang teknis yang menumpuk.
Berikut diagram yang memperjelas boundary antar modul, antarmuka, dan kepemilikan data/tim pada sistem pengajuan kredit.
Boundary yang baik dimulai dari antarmuka. Antarmuka adalah kontrak antara dua bagian solusi. Misalnya, modul pengajuan menyediakan API untuk membuat pengajuan baru. Modul scoring memanggil API itu untuk mengambil data yang diperlukan. Selama antarmuka jelas, masing-masing modul bisa dikembangkan secara independen. Tim pengajuan tidak perlu tahu bagaimana scoring bekerja. Tim scoring tidak perlu tahu bagaimana data disimpan di modul pengajuan.
Berikut contoh kontrak API sederhana untuk modul pengajuan yang menjadi boundary bagi konsumen seperti modul scoring.
openapi: 3.0.0
info:
title: Modul Pengajuan Kredit
version: 1.0.0
paths:
/pengajuan:
post:
summary: Membuat pengajuan baru
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
nasabah_id:
type: string
jumlah:
type: number
required:
- nasabah_id
- jumlah
responses:
'201':
description: Pengajuan berhasil dibuat
Data juga punya boundary. Siapa pemilik data pelanggan? Siapa yang boleh menulis? Siapa yang hanya boleh membaca? Siapa yang menyediakan data master? Saya pernah melihat dua sistem menyimpan data pelanggan dengan field yang sama, tetapi isinya berbeda karena tidak ada satu sumber kebenaran. Boundary data yang jelas mencegah hal ini. Setiap data punya satu sistem sumber, dan sistem lain hanya menjadi konsumen.
Platform dan proses manual juga perlu boundary. Apakah tim aplikasi boleh menyediakan server sendiri, atau harus menggunakan platform yang sudah disediakan tim infrastruktur? Apakah ada proses manual yang menjadi jalur cadangan jika sistem otomatis gagal? Siapa yang menjalankan proses manual itu? Boundary ini sering diabaikan karena dianggap sepele, padahal dampaknya besar saat terjadi insiden.
Yang paling penting, boundary harus disepakati oleh semua tim yang terlibat. Bukan hanya ditulis di dokumen arsitektur, tetapi dibahas bersama, direview, dan dikonfirmasi. Setiap tim harus tahu: ini bagian saya, ini bukan bagian saya, ini antarmuka yang harus saya penuhi, dan ini data yang menjadi tanggung jawab saya.
Dengan boundary yang jelas, tim bisa bergerak lebih cepat. Mereka tidak perlu menunggu tim lain untuk setiap keputusan kecil. Mereka bisa bekerja paralel karena kontrak antarmuka sudah disepakati. Mereka tidak perlu khawatir tumpang tindih karena garis pemisah sudah ditarik.
Setelah boundary jelas, kita bisa mulai membayangkan bagaimana solusi akan dibangun secara bertahap. Tidak semua bagian harus selesai bersamaan. Beberapa bagian bisa menjadi solusi sementara, beberapa menjadi transisi, dan beberapa menjadi target akhir. Itu menjadi arah pembahasan berikutnya.
