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 cara menilai penalaran arsitektural saat hiring.
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
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Yang perlu dicari saat hiring
Wawancara arsitektur memberi nilai pada kefasihan, dan kefasihan itu murah. Kandidat bisa menjelaskan pola dengan percaya diri tanpa pernah hidup dengan konsekuensi memilih salah satunya, sehingga bukti yang berguna hampir selalu bersifat retrospektif: apa yang mereka putuskan, berapa biayanya, dan apa yang mereka pelajari ketika kenyataan tidak sesuai diagram.
Bukti tentang konsekuensi
Tanyakan sebuah arsitektur yang mereka rancang dan masih berjalan bertahun-tahun kemudian, serta apa yang ternyata keliru di dalamnya. Architect yang pindah sebelum keputusannya matang tidak pernah menerima umpan balik yang membuat keputusan berikutnya lebih baik.
- Pernah bertahan bersama sebuah sistem cukup lama untuk melihat desainnya menua
- Bisa menyebut satu batas yang mereka tempatkan keliru dan gejala yang ditimbulkannya
- Membedakan desain yang gagal dari desain yang berhasil lalu dilampaui kebutuhan
Trade-off yang dinyatakan dua arah
Ajukan sebuah keputusan desain dan tanyakan berapa biayanya. Siapa pun bisa menganjurkan; pertanyaannya adalah apakah mereka mau menyebut properti apa yang dilepas dan kondisi apa yang membuat pilihan favorit mereka menjadi pilihan yang salah.
- Menyebut sendiri kelemahan dari rekomendasinya sendiri
- Mengidentifikasi kondisi yang akan mengubah jawabannya
- Memperlakukan beban operasional sebagai biaya utama, bukan detail implementasi
Kedekatan dengan sistem yang berjalan
Kegagalan menara gading itu nyata dan sebagian besar bisa dicegah di wawancara. Tanyakan apa yang mereka pelajari dari insiden production terakhir di area mereka, dan apakah arsitektur yang mereka rancang sesuai dengan yang mereka temukan ketika benar-benar menengoknya.
- Baru-baru ini membaca telemetri production dan bisa menyebut apa yang mengejutkan mereka
- Tahu berapa biaya mengoperasikan desainnya, bukan hanya membangunnya
- Pernah merevisi sebuah standar karena tim tidak mungkin mengikutinya secara wajar
Realisme migrasi
Arsitektur tujuan adalah separuh yang mudah. Tanyakan bagaimana mereka akan memindahkan sebuah organisasi ke sana sambil ia terus merilis, dan dengarkan apakah setiap langkah antaranya meninggalkan sistem yang tetap berjalan.
- Merencanakan hidup berdampingan alih-alih satu peristiwa cutover
- Merancang pembalikan untuk setiap tahap, bukan hanya tujuannya
- Memperhitungkan periode ketika dua model harus dipelihara bersamaan
Bagaimana keputusan menjadi mengikat
Arsitektur yang hanya hidup di dokumen tidak mengubah apa pun. Tanyakan bagaimana salah satu keputusan mereka benar-benar sampai ke kode â lewat review, tooling, default, pemeriksaan konformitas atau persuasi â dan bagaimana mereka mendeteksi penyimpangan darinya.
- Lebih memilih pemeriksaan otomatis dan default yang masuk akal daripada aturan tertulis
- Bisa menceritakan saat menemukan tim sudah menyimpang, dan apa yang mereka lakukan
- Menulis keputusan lengkap dengan alternatif yang ditolak dan kondisi kedaluwarsanya
Mengkuantifikasi yang non-fungsional
Tanyakan bagaimana mereka menetapkan target ketersediaan atau latensi pada sebuah sistem nyata. Jawaban yang membedakan menelusurinya kembali ke konsekuensi bisnis, bukan ke angka konvensional yang kedengarannya cukup serius.
- Menurunkan target dari konsekuensi, bukan dari konvensi
- Tahu berapa biaya peningkatan ketersediaan satu tingkat berikutnya
- Pernah menurunkan sebuah target, bukan hanya menaikkannya
Menahan diri
Arsitektur yang berlebihan setidaknya sama merusaknya dengan arsitektur yang kurang, dan jauh lebih sulit diurai. Tanyakan tentang saat mereka memilih opsi yang lebih sederhana, dan tentang kapabilitas yang sengaja tidak mereka siapkan.
- Bisa menceritakan menolak memperkenalkan teknologi yang mereka sukai
- Membedakan keputusan yang mudah dibalik dan tidak butuh seremoni dari yang butuh
- Merancang untuk tahap berikutnya yang masuk akal, bukan untuk keadaan akhir yang dibayangkan
Pertanyaan wawancara yang layak diajukan
Ditawarkan untuk dipakai dalam proses penilaian Anda sendiri. Masing-masing menyasar penalaran yang sulit dilatih, dan catatannya menjelaskan apa yang cenderung terungkap dari sebuah jawaban, bukan jawaban yang benar.
Ceritakan sebuah arsitektur yang Anda rancang dan masih berjalan di production. Apa yang menjadi sulit karenanya, yang tidak Anda antisipasi?
What a strong answer shows
Apakah mereka pernah menerima umpan balik dari keputusannya sendiri. Kekhususan penyesalan itulah sinyalnya â renungan umum tentang kompleksitas biasanya berarti mereka sudah pergi sebelum tagihannya datang.
Bagaimana Anda menentukan sebuah keputusan harus diambil sekarang atau aman untuk ditunda?
What a strong answer shows
Penguasaan atas reversibilitas, yang merupakan naluri arsitektural utama. Cari penundaan yang dipakai sebagai teknik yang disengaja untuk membeli informasi, bukan sebagai ketiadaan pendapat.
Ambil satu sistem yang Anda kenal baik. Di mana Anda akan menarik batasnya secara berbeda, dan bukti apa yang menunjuk ke sana?
What a strong answer shows
Apakah dekomposisi dinalar dari bagaimana domainnya berubah atau dari diagram yang pernah mereka lihat. Jawaban kuat mengutip pola perubahan, keterikatan yang teramati dalam praktik dan bentuk struktur timnya.
Anda mewarisi arsitektur tujuan yang tidak Anda setujui dan sudah sebagian dibangun. Apa yang Anda lakukan?
What a strong answer shows
Pertimbangan atas pekerjaan yang sudah terlanjur dan atas realitas organisasi. Yang mengkhawatirkan ada di kedua ujung â menerima arah yang benar-benar tidak aman, atau memulai ulang hanya karena itu bukan yang akan mereka pilih.
Bagaimana Anda menetapkan target ketersediaan untuk sistem yang pernah Anda tangani, dan berapa biaya peningkatan terakhirnya?
What a strong answer shows
Apakah kebutuhan non-fungsional diturunkan atau sekadar dihafal. Pertanyaan tentang biaya memisahkan orang yang pernah merancang untuk sebuah target dari orang yang pernah mengutipnya.
Ceritakan sebuah standar yang Anda tetapkan dan tidak diikuti tim. Apa kesimpulan Anda?
What a strong answer shows
Reaksi terhadap diabaikan, yang dialami setiap architect. Cari rasa ingin tahu tentang mengapa kepatuhannya sulit, bukan uraian tentang kurangnya disiplin di pihak lain.
Apa yang perlu Anda lihat sebelum merekomendasikan kami beralih dari teknologi yang saat ini kami andalkan?
What a strong answer shows
Apakah perubahan diusulkan atas dasar bukti atau atas dasar preferensi. Jawaban kuat menetapkan ambang di awal dan memperhitungkan biaya transisinya sendiri.
Dokumen arsitektur Anda yang mana yang menurut Anda benar-benar dibaca orang, dan dari mana Anda tahu?
What a strong answer shows
Kejujuran tentang jarak antara yang diproduksi dan yang dikonsumsi. Architect yang pernah menghadapi kenyataan ini cenderung menggeser usahanya ke keputusan, default dan percakapan alih-alih ke volume dokumentasi.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 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.
- Approach
- 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.
- What this adds to the team
- Organisasi memperoleh kapasitas berpengalaman untuk pekerjaan struktural sambil tetap memegang otoritas arsitektural, kepemilikan produk dan keputusan akhir atas setiap hal yang mengikat sistemnya.
Related disciplines
Frequently asked questions
- 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.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.