8.8 Roadmap sebagai Jembatan Enterprise dan Solution Architecture
Kepala teknologi perusahaan logistik itu sekarang punya ADR untuk setiap keputusan arsitekturnya. Ia bisa menjelaskan mengapa data warehouse menjadi prioritas pertama, mengapa sistem warisan tertentu ditunda penggantiannya, dan mengapa dashboard real-time harus menunggu integrasi selesai. Tapi ketika ia mulai membahas roadmap ini dengan tim solution architect, muncul pertanyaan baru: “Ini kan rencana enterprise. Tapi saya sedang merancang solusi untuk modul pengiriman. Apa hubungannya dengan roadmap ini?”
Pertanyaan itu wajar. Di banyak organisasi, enterprise architecture dan solution architecture hidup di dua dunia yang berbeda. Enterprise architect berbicara tentang target capability, peta aplikasi, dan standar data. Solution architect berbicara tentang desain API, pemilihan teknologi, dan detail implementasi. Keduanya jarang bertemu. Akibatnya, solusi yang dibangun bisa berjalan sendiri-sendiri, dan ketika sudah jadi, enterprise architect baru sadar bahwa solusi itu tidak sesuai dengan arah strategis.
Roadmap arsitektur menjembatani kedua dunia ini. Ia bukan milik enterprise architect saja, dan bukan juga milik solution architect saja. Ia adalah dokumen yang membuat enterprise architecture bisa dimengerti oleh tim solusi, dan membuat solution architecture tetap selaras dengan arah organisasi.
Cara kerjanya sederhana. Enterprise architecture menyediakan target capability: misalnya, pada kuartal ketiga tahun depan, organisasi harus mampu menghasilkan laporan operasional real-time. Roadmap arsitektur kemudian menjabarkan apa yang harus terjadi agar capability itu terwujud: data warehouse harus siap, integrasi dengan sistem warisan harus berfungsi, dan dashboard harus sudah diuji. Setiap solution architect yang bekerja pada modul tertentu bisa melihat roadmap ini dan tahu bahwa solusinya bukan proyek mandiri, melainkan bagian dari urutan perubahan yang lebih besar.
Diagram berikut menunjukkan aliran penjabaran dari enterprise architecture ke solution architecture melalui roadmap.
Target Capability"] R1["Roadmap: Inisiatif A
Data Warehouse Siap"] R2["Roadmap: Inisiatif B
Integrasi Sistem Warisan"] R3["Roadmap: Inisiatif C
Dashboard Real-time"] SA1["Solution Architecture
Desain API Modul Pengiriman"] SA2["Solution Architecture
Detail Implementasi Dashboard"] EA --> R1 EA --> R2 EA --> R3 R1 --> SA1 R2 --> SA1 R3 --> SA2
Dengan kata lain, roadmap arsitektur adalah penerjemah. Ia menerjemahkan “kita ingin jadi perusahaan yang didorong data” menjadi “pada bulan April, tim integrasi akan menyelesaikan koneksi ke sistem A; pada bulan Mei, data warehouse akan menerima data dari sistem B; pada bulan Juni, dashboard pengiriman akan mulai diuji”. Setiap solution architect bisa melihat posisinya dalam urutan itu dan menyesuaikan desainnya.
Yang sering luput adalah bahwa roadmap juga menjadi alat negosiasi. Ketika seorang solution architect mengusulkan solusi yang membutuhkan infrastruktur baru, ia bisa melihat roadmap dan tahu apakah infrastruktur itu sudah direncanakan atau belum. Jika belum, ia harus menyesuaikan desainnya atau mengajukan perubahan roadmap. Tanpa roadmap, setiap solusi berjalan sendiri dan organisasi kehilangan kendali atas arah teknologinya.
Di perusahaan logistik itu, kepala teknologi mulai menggunakan roadmap sebagai acuan dalam setiap rapat desain solusi. Setiap kali tim solution architect mengusulkan sesuatu, ia bertanya: “Apakah ini selaras dengan roadmap? Apakah ini mempercepat atau memperlambat capability yang kita targetkan?” Pertanyaan itu sederhana, tapi efeknya besar. Tim solusi mulai berpikir dalam konteks organisasi, bukan hanya dalam batas modul yang mereka kerjakan.
Roadmap arsitektur, dengan ADR sebagai pengikat alasannya, menjadi jembatan yang kokoh antara strategi dan eksekusi. Ia membuat enterprise architecture tidak berhenti sebagai dokumen di lemari, dan membuat solution architecture tidak tersesat dalam detail teknis. Keduanya bergerak ke arah yang sama, dengan urutan yang jelas, dan dengan alasan yang terdokumentasi.
Setelah roadmap ini berfungsi sebagai jembatan, kepala teknologi itu mulai berpikir lebih jauh: bagaimana memastikan bahwa setiap solusi yang dibangun benar-benar memberikan value yang dijanjikan? Pertanyaan itu membawanya ke bab berikutnya, tentang bagaimana mengukur keberhasilan arsitektur.