7.7 Enterprise Architecture: Menjaga Arah Lintas Domain
Kepala teknologi di perusahaan ritel itu kini memiliki capability map. Ia bisa melihat bahwa untuk ekspansi ke kota kecil, organisasi perlu kemampuan di bidang manajemen inventaris, pemrosesan pesanan, pengiriman, pembayaran, dan layanan pelanggan. Setiap capability punya prioritas dan kesenjangan yang jelas. Tapi ketika tim mulai mengerjakan, masalah baru muncul.
Tim aplikasi ingin membangun sistem kasir baru dengan teknologi terbaru. Tim data ingin memastikan semua transaksi masuk ke data warehouse yang sama. Tim infrastruktur sudah mulai menyiapkan server di cloud. Tim security datang dengan daftar persyaratan yang panjang. Dan tim delivery bertanya: “Kita pakai metode apa? Sprint berapa minggu?”
Masing-masing tim bergerak dengan logikanya sendiri. Semua masuk akal dari sudut pandang masing-masing. Tapi ketika digabungkan, keputusan di satu domain mulai berbenturan dengan domain lain. Tim aplikasi memilih framework yang tidak kompatibel dengan standar integrasi yang sudah ada. Tim data memutuskan skema database yang menyulitkan tim security dalam menerapkan enkripsi. Tim infrastruktur menyiapkan lingkungan yang tidak mendukung cara kerja tim delivery.
Berikut diagram yang menggambarkan relasi dan potensi benturan antar domain arsitektur, serta peran enterprise architecture sebagai pengoordinasi.
Inilah saatnya enterprise architecture masuk.
Enterprise architecture bukanlah framework kaku yang harus diikuti seperti manual pesawat. Ia adalah cara berpikir untuk menjaga agar keputusan di satu domain tidak merusak keputusan di domain lain. Bayangkan Anda sedang membangun sebuah bangunan. Arsitek gedung tidak mendesain setiap ruangan secara detail, tapi ia memastikan bahwa desain struktur, instalasi listrik, pipa air, dan ventilasi tidak saling bertabrakan. Begitu juga enterprise architecture: ia menjaga keselarasan antar domain arsitektur.
Domain-domain itu biasanya mencakup aplikasi, data, integrasi, infrastruktur, security, dan delivery. Masing-masing punya logika dan prioritas sendiri. Tim aplikasi ingin cepat merilis fitur baru. Tim data ingin data bersih dan konsisten. Tim infrastruktur ingin sistem stabil dan mudah di-scale. Tim security ingin tidak ada celah keamanan. Tim delivery ingin proses pengembangan efisien dan terukur. Semua keinginan ini sah, tapi tanpa koordinasi, hasilnya adalah kekacauan.
Enterprise architecture menjawab pertanyaan-pertanyaan lintas domain. Ketika tim aplikasi memilih framework, enterprise architecture bertanya: “Apakah framework ini mendukung pola integrasi yang sudah kita tetapkan? Apakah data yang dihasilkan bisa dikonsumsi oleh sistem lain? Apakah infrastruktur yang ada bisa menjalankannya? Apakah ini aman? Apakah tim delivery punya kapasitas untuk mengelolanya?”
Pertanyaan-pertanyaan ini tidak dimaksudkan untuk menghambat. Sebaliknya, pertanyaan ini menjaga agar setiap keputusan teknis tidak menjadi utang yang harus dibayar mahal di kemudian hari. Satu keputusan yang salah di domain aplikasi bisa membuat tim data bekerja dua kali lipat. Satu pilihan infrastruktur yang tidak tepat bisa membuat tim security kerepotan selama bertahun-tahun.
Di perusahaan ritel itu, kepala teknologi mulai membangun fungsi enterprise architecture. Bukan dengan membentuk tim besar yang membuat dokumen tebal. Ia memulainya dengan satu prinsip sederhana: setiap keputusan teknis yang berdampak lintas domain harus melalui diskusi singkat yang melibatkan perwakilan dari setiap domain. Diskusi itu tidak perlu lama. Cukup tiga puluh menit untuk memastikan tidak ada benturan yang tidak terlihat.
Hasilnya, tim tidak lagi bekerja dalam silo. Tim aplikasi tetap bisa bergerak cepat, tapi dengan kesadaran bahwa keputusan mereka mempengaruhi domain lain. Tim security tidak lagi datang di akhir proyek dengan daftar larangan. Mereka duduk bersama sejak awal. Tim data tidak lagi menemukan kejutan saat data dari sistem baru tidak cocok dengan skema yang sudah ada.
Enterprise architecture, pada intinya, adalah disiplin untuk menjaga arah. Ia tidak menentukan teknologi mana yang harus dipakai, tapi ia memastikan bahwa pilihan teknologi di setiap domain selaras dengan arah organisasi. Tanpa enterprise architecture, capability map hanyalah peta tanpa navigator. Setiap tim berlayar sendiri-sendiri, dan tidak ada yang memastikan mereka semua menuju ke arah yang sama.
Setelah enterprise architecture berfungsi, organisasi siap untuk langkah berikutnya: memanfaatkan AI sebagai asisten strategis yang membantu arsitek merangkum konteks, menyajikan opsi, dan mempercepat analisis lintas domain.
