Dari Strategi ke Eksekusi Solusi
Bagian ini membahas: Arah Teknologi dan Enterprise Architecture; Dari Rencana Teknologi ke Architecture Roadmap; Solution Context, Scope, dan Boundary; Opsi Solusi, Integrasi, Data, Security, dan Operability; Solution Architecture yang Bisa Dieksekusi; Berpikir seperti Senior Engineer.
6 bab · 49 artikel
Bab 7: Arah Teknologi dan Enterprise Architecture
membuka level strategis tanpa membuatnya terasa berat. Arsitek tidak mulai dari framework, cloud provider, database, atau AI tool. Arsitek mulai dari arah organisasi: apa yang ingin dicapai, capability apa yang harus dibangun, pilihan apa yang harus dibuat, dan sistem seperti apa yang dibutuhkan untuk mendukungnya.
Kenapa Arsitek Harus Mulai dari Arah, Bukan dari Teknologi
Seorang kepala teknologi di sebuah perusahaan ritel pernah bercerita tentang kebingungan timnya. Mereka mendapat mandat untuk membangun sist
Visi dan Misi sebagai Filter, Bukan Pajangan
Di perusahaan yang sama, setelah kebingungan memilih database dan microservices, kepala teknologi itu memutuskan untuk berhenti sejenak. Ia
Dari Visi ke Rencana Strategis Teknologi
Setelah visi dan misi menjadi filter, langkah berikutnya adalah menerjemahkannya ke dalam rencana strategis teknologi yang bisa dijalankan.
Portfolio, Program, Project, Product, Platform, dan Capability
Rencana strategis teknologi tidak bisa berdiri sendiri; ia perlu dipahami dalam konteks portfolio inisiatif organisasi. Kepala teknologi di
Membaca Organisasi: Business Model, Operating Model, dan Value Stream
Setelah memahami kategorisasi inisiatif, arsitek perlu membaca organisasi lebih dalam: model bisnis, model operasi, dan value stream. Ini bu
Capability Map: Peta Kebutuhan Teknologi Organisasi
Kepala teknologi di perusahaan ritel itu sudah punya pemahaman tentang business model, operating model, dan value stream. Ia tahu bahwa nila
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
AI sebagai Asisten Strategis, Bukan Pengambil Keputusan
Enterprise architecture memberikan konteks, tetapi keputusan tetap dibuat oleh manusia. Kepala teknologi di perusahaan ritel itu kini memili
Bab 8: Dari Rencana Teknologi ke Architecture Roadmap
menjelaskan cara mengubah arah strategis menjadi roadmap arsitektur yang bisa dieksekusi. Roadmap arsitektur bukan daftar proyek teknis. Ia adalah urutan perubahan yang membuat organisasi makin mampu mencapai target capability.
Arah Strategis Belum Cukup
Beberapa bulan lalu, saya duduk bersama kepala teknologi sebuah perusahaan logistik menengah. Ia baru saja selesai mengikuti retreat tahunan
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
Gap Analysis: Apa yang Hilang dan Lemah
Setelah dua titik ini jelas, kita perlu mencari celah antara keduanya. Kepala teknologi perusahaan logistik itu sudah punya target architect
Bukan Sekadar Daftar Proyek
Kepala teknologi perusahaan logistik itu sekarang punya daftar panjang hasil gap analysis. Data tidak terintegrasi. Tiga sistem warisan tida
Dimensi Roadmap: Aplikasi, Data, Integrasi, Infrastruktur, Keamanan, dan Platform
Kepala teknologi perusahaan logistik itu mulai menyusun roadmap. Ia membuat daftar inisiatif berdasarkan gap analysis: mengganti tiga sistem
Prioritas: Value, Mitigasi, Dependensi, dan Readiness
Enam dimensi sudah membuat roadmap terlihat lebih utuh, tetapi belum menjawab pertanyaan paling sulit: mana yang harus dimulai dulu. Kepala
Architecture Decision Record sebagai Pengikat Alasan
Kepala teknologi perusahaan logistik itu akhirnya memutuskan prioritas pertama: membangun data warehouse. Alasannya masuk akal. Tanpa data w
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
Bab 9: Solution Context, Scope, dan Boundary
menurunkan arah besar ke satu inisiatif nyata. Solution architect tidak langsung memilih framework atau menggambar diagram. Ia perlu memahami kenapa inisiatif ini ada, siapa yang terdampak, capability apa yang ingin diperbaiki, sistem apa yang tersentuh, dan boundary apa yang perlu dijaga.
Dari Peta Besar ke Satu Titik Mulai
Bayangkan Anda baru saja keluar dari rapat portfolio review. Di layar proyektor masih terlihat peta besar berisi puluhan inisiatif yang ters
Masalah, Outcome, dan Ukuran Keberhasilan
Setelah inisiatif dipilih, langkah selanjutnya adalah merumuskan masalah yang ingin dipecahkan dan outcome yang diharapkan.
Siapa Saja yang Terdampak
Dengan outcome yang jelas, kita perlu tahu siapa saja yang terlibat dan terdampak oleh solusi ini. Ini bukan pertanyaan sepele. Saya pernah
Keadaan Sekarang: Proses, Sistem, dan Titik Sakit
Setelah mengenali stakeholder, kita perlu memahami keadaan saat ini sebelum merancang perubahan. Ini langkah yang sering dilewati. Banyak ti
Keadaan yang Dituju: Perubahan yang Ingin Terjadi
Dari keadaan sekarang, kita bisa membayangkan keadaan yang diinginkan setelah solusi berjalan. Ini bukan sekadar daftar fitur atau tampilan
Batas Solusi: In-Scope, Out-of-Scope, dan Asumsi
Setelah tahu arah perubahan, kita perlu menetapkan batas-batas solusi agar tidak melebar. Ini langkah yang sering dianggap remeh. Banyak tim
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
Solusi Bertahap: Sementara, Transisi, dan Target
Setelah boundary antar sistem dan tim sudah jelas, pertanyaan berikutnya adalah: bagaimana kita sampai ke target state? Apakah kita bisa lan
Bab 10: Opsi Solusi, Integrasi, Data, Security, dan Operability
memperlihatkan isi inti solution architecture. Solution architect menyusun beberapa opsi, membandingkan konsekuensinya, lalu merancang solusi yang bisa bekerja dalam lingkungan nyata: terhubung dengan sistem lain, mengelola data dengan benar, aman, bisa dipantau, dan bisa dipulihkan saat bermasalah.
Kenapa Satu Solusi Tidak Pernah Cukup
Bayangkan Anda sedang duduk di ruang meeting bersama tim produk. Seorang stakeholder dari divisi penjualan datang dengan permintaan yang ter
Membandingkan Opsi: Bukan Sekadar Biaya
Setelah kita punya beberapa opsi, kita perlu cara untuk membandingkannya secara objektif. Masalahnya, banyak tim langsung jatuh ke satu dime
Integrasi: Hidup di Antara Sistem Lain
Setelah opsi dipilih, solusi harus bisa hidup di lingkungan nyata yang penuh sistem lain. Ini adalah momen yang sering diremehkan oleh tim y
Data: Milik Siapa, Bagaimana Bentuknya, dan Ke Mana Alirnya
Integrasi membawa konsekuensi pada data: siapa pemiliknya, bagaimana bentuknya, dan bagaimana alurnya. Ini adalah pertanyaan yang sering dia
Security: Bukan Tambahan, Tapi Bagian dari Rancangan
Data yang mengalir perlu diamankan, dan itu membawa kita ke security view. Saya pernah melihat sebuah tim membangun sistem rekomendasi yang
Operability: Agar Solusi Tidak Jadi Beban Tim Ops
Setelah aman, solusi harus bisa dioperasikan: dipantau, dipulihkan, dan didukung.
Deployment: Lingkungan, Konfigurasi, dan Strategi Lepas Landas
Semua aspek itu perlu dituangkan ke deployment view agar solusi benar-benar bisa dieksekusi. Saya pernah melihat tim yang sudah menyusun sol
Bab 11: Solution Architecture yang Bisa Dieksekusi
menjelaskan cara mengemas rancangan solusi agar bisa dipakai banyak pihak. Solution architecture bukan dokumen panjang untuk arsip. Ia harus membantu engineer membangun, bisnis memahami konsekuensi, operation menyiapkan support, security melakukan review, dan manajemen mengambil keputusan.
Dokumen yang Dipakai, Bukan Disimpan
Bayangkan Anda baru saja menyelesaikan rapat dengan tim produk. Sebuah ide aplikasi baru sudah disetujui. Semua orang antusias. Tim produk s
Isi Minimum yang Harus Ada
Setelah memahami tujuan dokumen, kita perlu tahu isi minimal yang harus ada di dalamnya. Bayangkan Anda adalah solution architect yang baru
Diagram yang Cukup untuk Dipahami
Dari semua bagian solution architecture, diagram adalah yang paling cepat menyampaikan gambaran solusi. Sebuah diagram yang baik bisa membua
Menulis Trade-off untuk Semua Pihak
Bayangkan Anda sudah menyelesaikan diagram context dan component. Tim engineer mulai mengangguk paham. Tapi tiba-tiba kepala produk bertanya
Menjaga Dokumen Tetap Hidup Selama Delivery
Setelah dokumen selesai ditulis, tantangan berikutnya adalah menjaganya tetap relevan selama delivery berlangsung. Ini adalah titik di mana
Memecah Solusi Menjadi Bagian yang Bisa Dikerjakan
Dokumen yang hidup akan menjadi dasar untuk memecah solusi menjadi bagian-bagian yang bisa dikerjakan secara bertahap.
Menyusun Urutan Pengerjaan yang Realistis
Setelah solusi dipecah menjadi work package dan release slice, pertanyaan berikutnya selalu sama: "Kita mulai dari mana?" Jawabannya tidak s
Rencana Pengiriman yang Lengkap
Bayangkan Anda sudah menyusun urutan pengerjaan yang realistis. Tim engineering sudah tahu work package mana yang dikerjakan pertama, mana y
AI Membantu, Manusia Memutuskan
Semua perencanaan ini bisa dibantu AI, tetapi ada bagian yang tetap membutuhkan keputusan dan tanggung jawab manusia. Bayangkan Anda baru se
Bab 12: Berpikir seperti Senior Engineer
mengajak pembaca turun dari dokumen solusi ke kenyataan engineering. Senior engineer adalah jembatan antara desain dan implementasi. Ia membaca codebase, memecah pekerjaan, menjaga kualitas, memilih bukti testing, dan belajar dari production feedback.
Dari Dokumen ke Codebase
Bayangkan Anda baru saja bergabung dengan tim yang sudah berjalan setahun. Di tangan Anda ada dokumen solution architecture setebal tiga pul
Membaca Alur, Bukan Sekadar File
Setelah memahami peta codebase, langkah berikutnya adalah mencari alur utama yang benar-benar terjadi di dalamnya. Banyak engineer junior me
Petunjuk dari Production: Log, Metrik, dan Insiden
Alur utama saja belum cukup; senior engineer juga membaca log, metrik, dan riwayat insiden untuk menemukan petunjuk desain yang tidak tertul
Memotong Pekerjaan Menjadi Irisan Vertikal
Anda sudah membaca codebase. Anda sudah menelusuri alur utama. Anda sudah belajar dari log dan insiden production. Sekarang Anda tahu persis
Urutan Kerja yang Cerdas, Bukan Sekadar Prioritas
Setelah Anda memotong pekerjaan menjadi irisan vertikal, godaan terbesar adalah mengerjakan semuanya berdasarkan urutan yang paling menarik
Kualitas Kode yang Terjaga, Bukan Sekadar Rapi
Saat kode mulai ditulis, senior engineer tidak hanya mengejar fitur selesai, ia juga menjaga kualitas kode secara aktif. Banyak engineer jun
Review sebagai Memahami Konsekuensi, Bukan Mencari Salah
Kualitas kode juga dijaga melalui review, tetapi senior engineer melihat review dengan cara yang berbeda. Banyak tim menjalankan code review
Testing sebagai Bukti, Bukan Sekadar Kewajiban
Setelah kode direview, senior engineer memastikan perubahan itu benar-benar bekerja melalui testing yang tepat. Banyak tim menulis test kare
Belajar dari Production: Lingkaran Umpan Balik yang Nyata
Setelah rilis, senior engineer tidak berhenti; ia membaca feedback dari production untuk terus belajar dan memperbaiki. Banyak engineer meng