Software architect
Software architect bertanggung jawab atas struktur: bagaimana sebuah sistem terbagi menjadi bagian-bagian, bagaimana bagian-bagian itu berkomunikasi, properti apa yang harus dijaga oleh keseluruhannya, dan bagaimana ia berubah bentuk selama bertahun-tahun tanpa dibangun ulang. Keputusannya relatif sedikit dan relatif mahal untuk dibalik. Panduan ini menjelaskan cakupan disiplinnya, bedanya dengan engineering senior, dan di mana keputusannya terasa bertahun-tahun kemudian.
Apa yang dikerjakan seorang software architect?
Software architect menentukan bagaimana sekumpulan sistem distrukturkan dan bagaimana struktur itu berkembang. Pekerjaannya mencakup memecah sebuah domain menjadi service atau modul, mendefinisikan batas dan contract di antaranya, menetapkan kebutuhan non-fungsional seperti ketersediaan, latensi, throughput dan target pemulihan, memilih teknologi terhadap kebutuhan tersebut, merencanakan migrasi dari yang ada menuju yang dituju, serta mencatat penalaran di balik setiap pilihan agar dapat dipahami dan dipertanyakan di kemudian hari. Architect umumnya bekerja lintas beberapa tim dengan horizon beberapa tahun, dan biasanya lebih sedikit hands-on dibanding engineer yang mengimplementasikan keputusannya.
Yang memisahkan arsitektur dari engineering senior yang baik adalah biaya jika keliru. Sebagian besar keputusan engineering bisa dibalik dalam satu sprint. Keputusan arsitektural mengikat organisasi: sebuah batas yang ditarik di tempat yang salah baru ditemukan delapan belas bulan kemudian, ketika tiga tim sudah membangun di sekitarnya dan koreksinya menuntut pembongkaran setiap integrasi yang melewatinya. Asimetri itulah yang membuat architect mencurahkan usaha yang tidak proporsional pada pertanyaan keputusan mana yang searah dan mana yang aman untuk ditunda.
Disiplin ini adalah penerapan batasan. Arsitektur yang mengizinkan segalanya tidak memutuskan apa pun, dan tim kemudian menemukan ulang pertanyaan yang sama secara terpisah lalu menjawabnya dengan berbeda. Arsitektur yang berguna mempersempit ruang â inilah batas-batasnya, beginilah service saling berbicara, inilah yang harus dipenuhi sebuah komponen baru sebelum ia tayang â sambil menyisakan ruang yang cukup di dalam batasan itu sehingga tim tetap punya otonomi nyata atas pekerjaan mereka sendiri.
Pola kegagalan yang berulang sudah terkenal dan layak disebut. Architect yang berhenti bersentuhan dengan production, yang diagramnya menggambarkan sistem yang diniatkan alih-alih sistem yang berjalan, dan yang standarnya datang sebagai pengumuman alih-alih usulan, akan diabaikan dengan sopan. Keluaran yang penting bukanlah sebuah dokumen; ia adalah keputusan yang benar-benar dijadikan acuan tim saat membangun, dan itu biasanya menuntut sang architect hadir ketika masalahnya sedang dirasakan.
Kapan organisasi membutuhkan kapabilitas ini
Arsitektur selalu terjadi â pertanyaannya adalah apakah ada yang mengerjakannya dengan sengaja. Berikut kondisi ketika versi implisitnya berhenti memadai.
Beberapa tim saling membangun berlawanan arah
Setiap tim mengoptimalkan delivery-nya sendiri dan sambungan di antara mereka memburuk: data terduplikasi tanpa pemilik, integrasi dibangun dua kali dengan cara yang tidak kompatibel, perubahan di satu service merusak dua service lain tanpa peringatan. Tidak ada satu tim pun yang bisa memperbaikinya karena masalahnya berada di antara mereka.
Sebuah monolith sedang dipecah, atau sebuah pemecahan sedang dikembalikan
Kedua arah menuntut keterampilan langka yang sama â mengetahui di mana sambungan yang sebenarnya berada. Memecah pada garis yang salah menghasilkan sistem terdistribusi dengan seluruh keterikatan sebuah monolith tanpa satu pun kemudahannya, dan hasil itu jauh lebih sering terjadi daripada sebaliknya.
Kebutuhan non-fungsional berubah menjadi kewajiban kontraktual
Pelanggan enterprise, regulator atau komitmen ketersediaan mengubah latensi, waktu pemulihan, residensi data atau kemampuan audit menjadi kewajiban. Memasang properti semacam itu ke dalam sistem yang dirancang tanpanya sering lebih sulit daripada pembangunan awalnya.
Pemilihan teknologi besar sudah di depan mata
Sebuah datastore, tulang punggung messaging, penyedia identitas atau komitmen cloud akan dijalani bertahun-tahun. Keputusan seperti ini biasanya diambil di bawah tekanan waktu oleh siapa pun yang paling lantang, dan konsekuensinya tiba lama setelah orang yang memutuskannya pindah.
Sebuah migrasi harus berjalan bersamaan dengan delivery
Mengganti sistem inti sambil terus merilis menuntut strategi hidup berdampingan: apa yang diarahkan ke mana selama transisi, bagaimana state direkonsiliasi, seperti apa rollback-nya di setiap tahap. Migrasi jauh lebih sering gagal pada pengurutannya daripada pada teknologinya.
Tidak ada yang bisa menjelaskan mengapa sistemnya seperti sekarang
Orang yang mengambil keputusan awal sudah pergi dan penalarannya ikut pergi, sehingga bentuk sekarang diperlakukan entah sebagai sesuatu yang sakral atau sebagai sesuatu yang sembarang. Kedua pembacaan itu keliru dan keduanya menuntun ke kesalahan yang mahal.
Kapabilitas inti
Dekomposisi sistem
Menemukan batas yang mencerminkan bagaimana bisnis benar-benar berubah, sehingga perubahan yang lazim mendarat di dalam satu komponen alih-alih menyebar ke empat. Batas yang ditarik mengikuti lapisan teknis alih-alih urusan domain adalah sumber lazim dari sistem yang setiap fiturnya menuntut rilis terkoordinasi.
Integrasi dan contract
Menentukan bagaimana komponen berkomunikasi â sinkron atau asinkron, skema bersama atau penerjemahan di tepi â dan mendefinisikan contract yang cukup stabil untuk diandalkan. Versioning, deprekasi dan kompatibilitas mundur adalah bagian dari desain, bukan renungan setelah consumer pertama rusak.
Kebutuhan non-fungsional
Mengubah harapan yang kabur menjadi target yang dinyatakan untuk ketersediaan, latensi, throughput, daya tahan, pemulihan, residensi dan kemampuan audit, lalu merancang untuk memenuhinya. Kebutuhan yang belum dikuantifikasi siapa pun tidak bisa dipenuhi secara sengaja, hanya secara kebetulan.
Pemilihan teknologi
Menilai kandidat terhadap kebutuhan yang benar-benar akan menggigit, termasuk beban operasional, ketersediaan orang yang menguasainya, lisensi, biaya keluar dan kecocokan organisasional. Pertanyaan yang relevan jarang mana yang terbaik secara abstrak, melainkan mana yang cocok dengan batasan yang ada dan dengan orang-orang yang akan menjalankannya.
Analisis trade-off
Menyatakan secara eksplisit apa yang dikorbankan setiap pilihan sekaligus apa yang diberikannya, dan tegas tentang kualitas mana yang sedang dilepas. Arsitektur yang disajikan seolah tanpa kelemahan entah belum dianalisis atau sedang dijual alih-alih dijelaskan.
Strategi migrasi
Merencanakan rute dari keadaan sekarang ke keadaan yang dituju dalam tahapan yang masing-masing meninggalkan sistem tetap berjalan, dengan hidup berdampingan, rekonsiliasi dan pembalikan yang dirancang sejak awal. Bagian sulitnya hampir tidak pernah desain tujuannya; ia adalah urutannya.
Architecture decision record
Menuliskan apa yang diputuskan, alternatif apa yang ditolak, apa yang diasumsikan dan apa yang akan membenarkan peninjauan ulang. Nilainya muncul bertahun-tahun kemudian, ketika seseorang harus memutuskan apakah sebuah batasan masih berlaku atau diam-diam sudah kedaluwarsa.
Analisis kegagalan dan ancaman
Bernalar tentang apa yang terjadi ketika sebuah dependency melambat alih-alih mati, di mana retry justru melipatgandakan beban, bagaimana kegagalan parsial tampak bagi pengguna, dan bagaimana batas kepercayaan serta aliran data membuka sistem terhadap serangan.
Pemodelan biaya
Memahami berapa biaya menjalankan sebuah desain pada volume yang diperkirakan maupun yang tidak diperkirakan. Arsitektur yang secara teknis benar dan secara ekonomi tidak berkelanjutan itu lazim, dan penemuannya biasanya datang bersama tagihan.
Memengaruhi tanpa memerintah
Membuat tim membangun sesuai sebuah keputusan yang tidak dipaksakan kepada mereka. Inilah kapabilitas yang menentukan apakah seluruh daftar di atas menghasilkan sesuatu, dan inilah yang paling sering absen pada kandidat dengan kredensial teknis yang kuat.
Bagaimana disiplin ini dipraktikkan
Arsitektur tidak didefinisikan oleh daftar produk, sehingga bagian ini menguraikan metode alih-alih tooling. Praktik, notasi dan artefak di bawah ini adalah yang lazim dipakai di industri â gambaran umum tentang disiplinnya, dan bukan pernyataan tentang cara kerja siapa pun secara khusus. Menyebut namanya mudah; bukti yang layak dicari adalah apakah pertimbangan yang terkandung di dalamnya memang ada.
Pemodelan dan notasi
- C4 model
- Context dan container diagram
- Sequence diagram
- Domain model dan bounded context
- Data flow diagram
Praktik pengambilan keputusan
- Architecture decision record
- Proses RFC
- Forum architecture review
- Technology radar
- Analisis trade-off terstruktur
Analisis atribut kualitas
- Budget latensi dan error
- Target ketersediaan dan pemulihan
- Pemodelan kapasitas
- Threat modelling
- Analisis mode kegagalan
Evolusi dan migrasi
- Migrasi strangler fig
- Anti-corruption layer
- Kebijakan versioning dan deprekasi contract
- Cutover bertahap dan dual running
- Perencanaan backfill dan rekonsiliasi
Tata kelola tanpa menjadi penjaga gerbang
- Fitness function
- Pemeriksaan konformitas otomatis
- Aturan dependency dan batas antar modul
- Default platform paved road
- Catatan deviasi dan pengecualian
Pengumpulan bukti
- Proof of concept
- Load dan soak testing
- Latihan fault injection
- Peninjauan telemetri production
- Analisis biaya operasional
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah organisasi menjalankan sistem inti yang dikembangkan beberapa tim secara bersamaan. Integrasinya dibangun sendiri-sendiri, kepemilikan atas data bersama tidak jelas, dan sebuah komitmen kepada pelanggan memunculkan kewajiban pemulihan serta residensi yang tidak pernah diniatkan dipenuhi oleh desain saat ini. Arah struktural dibutuhkan sementara delivery tetap berjalan.
- Pendekatan
- Kapasitas senior tambahan bekerja di dalam praktik arsitektur milik klien â forum review klien, standar klien, decision record klien dan arah teknis klien. Otoritas struktural tetap berada di tempatnya sekarang; kapasitas tambahan menyumbangkan analisis, opsi yang terdokumentasi dan tenaga implementasi untuk keputusan yang diambil dan dimiliki klien.
- Yang ditambahkan ke tim
- Organisasi memperoleh kapasitas berpengalaman untuk pekerjaan struktural sambil tetap memegang otoritas arsitektural, kepemilikan produk dan keputusan akhir atas setiap hal yang mengikat sistemnya.
Disiplin terkait
Pertanyaan yang sering diajukan
- Apa bedanya software architect dan tech lead?
- Radius dampak dan horizon. Tech lead bertanggung jawab atas pekerjaan teknis satu tim dalam hitungan minggu dan bulan, tetap dekat dengan kode, dan biasanya bisa mengoreksi keputusan yang buruk dalam satu sprint. Architect bekerja lintas sistem dan lintas tim dengan pandangan beberapa tahun, dan keputusan yang buruk merambat ke segala hal yang dibangun di atasnya sebelum ada yang menyadarinya. Kedua peran ini saling melengkapi: arsitektur menetapkan batasan di antara tim, dan kepemimpinan teknis menghasilkan keputusan yang baik di dalamnya.
- Apakah software architect masih perlu menulis kode?
- Tidak harus dalam jumlah besar, tetapi mereka butuh cukup kontak dengan sistem yang berjalan agar model realitas mereka tetap akurat. Kontak itu bisa datang lewat prototipe, review, keterlibatan dalam insiden atau membaca telemetri, alih-alih lewat pekerjaan fitur rutin. Architect tanpa kontak semacam itu mulai merancang untuk sistem sebagaimana diceritakan kepada mereka, dan itulah mekanisme di balik hampir semua keluhan tentang menara gading.
- Apakah organisasi kecil membutuhkan architect khusus?
- Sering kali tidak sebagai posisi terpisah. Dengan satu produk dan beberapa tim, keputusan arsitektural masih cukup sedikit untuk dipegang engineer berpengalaman bersama seorang pemimpin teknis. Kebutuhannya muncul ketika keputusan mulai melintasi batas tim, ketika beberapa sistem harus saling beroperasi, atau ketika sebuah komitmen membuat properti non-fungsional tidak bisa ditawar. Menunjuk seorang architect sebelum ada struktur lintas bidang yang perlu dimiliki cenderung menghasilkan tata kelola yang mencari-cari masalah.
- Apa sebenarnya yang dihasilkan sebuah architecture decision record?
- Ia mengawetkan penalaran, yang meluruh lebih cepat daripada kode. Sebuah record menyatakan apa yang diputuskan, alternatif mana yang ditolak, apa yang diasumsikan dan apa yang akan membenarkan perubahan arah. Nilainya tiba kemudian, ketika seseorang harus menilai apakah sebuah batasan masih berlaku. Record yang hanya mendokumentasikan hasilnya, tanpa opsi yang ditolak maupun asumsinya, memberikan sangat sedikit dari nilai itu dan menjadi alasan banyak tim menyimpulkan praktik ini birokratis.
- Bagaimana membedakan arsitektur yang baik dari arsitektur yang mahal?
- Dari apakah kompleksitasnya menjawab kebutuhan yang benar-benar ada. Arsitektur yang baik membuat perubahan yang diantisipasi menjadi murah dan menyatakan perubahan mana yang tidak dioptimalkannya. Arsitektur yang mahal membangun fleksibilitas di muka untuk perubahan yang tidak diminta siapa pun, lalu menagihnya pada setiap fitur yang dikirim sesudahnya. Ujinya sederhana: apakah sang architect bisa menyebut tekanan spesifik yang menjadi alasan keberadaan setiap potong strukturnya.
- Bisakah arsitektur dimiliki sebuah kelompok alih-alih satu orang?
- Bisa, dan di banyak organisasi justru lebih baik. Sekelompok engineer senior yang mengambil keputusan struktural bersama, dengan cara yang jelas untuk menutup keputusan dan catatan tentang apa yang diputuskan, menghasilkan keputusan dengan dukungan yang lebih luas daripada satu orang yang mengeluarkan arahan. Yang sulit dilakukan sebuah kelompok adalah menjaga konsistensi selama bertahun-tahun tanpa ada yang bertanggung jawab atas koherensinya, sehingga bentuk yang lazim adalah pengambilan keputusan bersama dengan satu penjaga catatan yang ditunjuk.
- Bagaimana software architect bekerja dengan tim engineering yang sudah ada?
- Sebagai kontributor bagi praktik arsitektur Anda, bukan penggantinya. Dalam pengaturan penambahan kapasitas tim engineering, organisasi Anda tetap memegang otoritas arsitektural, arah teknis, standar engineering, roadmap dan kepemilikan produk; keputusan struktural diambil dan disetujui oleh orang-orang Anda, dan tim Anda yang mengarahkan pekerjaan. Di sisi Talent.ID, pengaturannya hanya mencakup kepegawaian: hubungan kerja itu sendiri, payroll, benefit karyawan, dan administrasi talenta. Tidak ada pengambilan keputusan arsitektural yang ikut berpindah bersamanya.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.