8.2 Current State dan Target Architecture

Setelah kita punya daftar inisiatif, kita perlu tahu posisi kita saat ini dan ke mana kita harus pergi. Ini bukan soal membuat diagram yang indah. Ini soal kejujuran organisasi terhadap dirinya sendiri.

Kepala teknologi dari perusahaan logistik tadi, setelah semangatnya mereda, mulai bertanya: “Kami ingin jadi perusahaan yang didorong data. Tapi jujur, saya tidak tahu seberapa jauh kami dari target itu. Data kami ada di mana-mana. Ada yang di Excel, ada yang di aplikasi lama, ada yang cuma di kepala orang.”

Situasi ini sangat umum. Banyak organisasi punya arahan strategis yang bagus, tetapi tidak punya gambaran utuh tentang kondisi mereka saat ini. Mereka tidak bisa menjawab pertanyaan sederhana: dari mana kita mulai?

Di sinilah konsep current state dan target architecture masuk. Current state adalah gambaran kondisi arsitektur yang ada sekarang. Bukan kondisi ideal, bukan kondisi yang diharapkan, tetapi kondisi nyata. Target architecture adalah kondisi yang ingin dicapai dalam jangka waktu tertentu. Keduanya adalah dua titik yang harus dipetakan sebelum kita bisa merencanakan perjalanan.

Cara menggambarkan current state tidak perlu rumit. Mulai dari hal-hal yang paling terlihat: aplikasi apa saja yang berjalan, bagaimana data mengalir, sistem mana yang terhubung, dan mana yang tidak. Jangan tergoda membuat diagram raksasa yang mencakup semuanya. Cukup petakan area yang relevan dengan arah strategis. Jika targetnya adalah pengambilan keputusan berbasis data, maka current state cukup menggambarkan sumber data, kualitasnya, dan bagaimana data itu diakses saat ini.

Yang lebih penting dari detail teknis adalah kejujuran. Banyak organisasi cenderung mempercantik current state mereka. Aplikasi lama yang sebenarnya sudah tidak terawat dicatat sebagai “legacy system yang stabil.” Proses manual yang lambat disebut “proses yang sudah mature.” Ini tidak membantu. Current state harus mencerminkan kenyataan, bukan harapan.

Berikut diagram sederhana yang membandingkan current state dan target architecture, serta peran gap analysis di antaranya.

flowchart TD subgraph CurrentState["Current State"] A1["Aplikasi yang berjalan"] A2["Aliran data"] A3["Sistem terhubung / tidak terhubung"] A4["Kualitas data"] end subgraph TargetArchitecture["Target Architecture"] B1["Platform analitik"] B2["Data real-time"] B3["Laporan otomatis"] end CurrentState -->|Gap Analysis| TargetArchitecture

Target architecture, di sisi lain, adalah gambaran ideal yang realistis. Bukan utopia. Target architecture harus bisa dicapai dalam horizon waktu yang ditentukan, biasanya dua sampai tiga tahun. Ia menjawab pertanyaan: seperti apa arsitektur kita jika semua inisiatif strategis berhasil dijalankan? Di sinilah kita bisa mulai membayangkan bagaimana data akan mengalir, aplikasi mana yang akan dipertahankan, mana yang akan diganti, dan capability baru apa yang harus dibangun.

Yang menarik di era AI, target architecture bisa lebih ambisius dari sebelumnya. Dulu, membangun sistem rekomendasi untuk logistik butuh tim data science besar dan biaya tinggi. Sekarang, dengan AI assistant dan asisten alur kerja, capability itu bisa dibangun dengan tim yang lebih kecil dan biaya yang lebih rendah. Target architecture yang dulu terasa mustahil, sekarang bisa menjadi masuk akal.

Perusahaan logistik tadi akhirnya memutuskan untuk memetakan current state mereka dalam waktu dua minggu. Mereka tidak membuat diagram enterprise architecture yang sempurna. Mereka cukup mendokumentasikan aplikasi apa yang mereka miliki, data apa yang tersimpan di mana, dan proses mana yang masih manual. Hasilnya mengejutkan: ternyata 40% data operasional mereka tidak pernah tersentuh analisis karena tersimpan di sistem yang tidak terintegrasi.

Target architecture mereka kemudian dirumuskan sederhana: semua data operasional harus bisa diakses dalam satu platform dalam waktu enam bulan, dengan AI assistant yang bisa menjawab pertanyaan operasional secara real-time. Bukan target yang muluk, tetapi cukup untuk mengubah cara mereka bekerja.

Setelah current state dan target architecture tergambar, pertanyaan berikutnya muncul secara alami: apa yang hilang? Apa yang lemah? Apa yang harus diperbaiki? Bagian berikutnya bergerak ke persoalan tersebut, gap analysis.

Roadmap as Bridge
Roadmap as Bridge