Hampir di semua perusahaan IT atau startup membutuhkan seorang pakar yang menentukan desain high-level, bahasa pemrograman yang digunakan, tools, serta platform. Pakar tersebut bernama software architect.

Software architect adalah orang yang akan mengoptimasi proses development dan pada akhirnya berperan penting dalam setiap strategi bisnis. Siapa yang bisa jadi software architect? Kemampuan atau skill set apa yang harus dimiliki software architect? Apa fungsi dan peran software architect di perusahaan IT atau start up? Artikel ini akan mengupas tuntas pekerjaan seorang software architect.

Apa itu Software Architect?

Sebelum membahas lebih detail, mari kita simak definisi ini terlebih dahulu. Seorang software architect adalah pakar software yang membuat pilihan desain high-level dan menentukan standar teknis, termasuk standar coding yang digunakan, tools, dan platform. Tingkat selanjutnya dari kepakaran software architecture disebut sebagai chief architect. (Sumber: Wikipedia: Software Architect)

Software architecture adalah basis dari suatu sistem, yang diwakili oleh komponen-komponennya, relasi antara satu dengan yang lain serta dengan environment-nya, juga prinsip-prinsip yang menentukan desain dan evolusi sistem. (Sumber: Handbook of Software Architecture)

Seperti sebagian besar posisi high-level, tidak ada kriteria jelas yang menandakan fungsi ini. Namun, ada karakteristik, kualitas, cakupan tanggung jawab yang berkontribusi pada karir software architect.Mari kita perhatikan karakteristik software architect berikut ini:

Komunikatif 

Karakteristik ini mutlak harus dimiliki oleh seorang software architect. Ini karena sehari-hari mereka berdialog dengan klien dalam bahasa bisnis, manajer dari semua level, pakar analisa bisnis, dan developer. Software architect berbicara dengan bahasa yang ringkas, jelas, dan persuasif. Alasan lain mengapa karakteristik ini penting adalah karena software architect berpartisipasi dalam semua proses decision making, seringkali kompromi harus dilakukan agar menguntungkan semua pihak yang terlibat.

Pengetahuan teknis yang luas dan dalam 

Ini jelas karena seseorang tidak dapat menjadi seorang software architect tanpa latar belakang IT yang kuat. Selain itu seorang software architect harus memiliki pemahaman yang baik tidak hanya dalam bidang teknologi, tetapi juga hal lain seperti bisnis. Seorang software architect juga harus mampu menyusun dokumentasi, report, dan diagram.

Tanggung jawab besar 

Keputusan seorang software architect biasanya yang paling “mahal”, dalam arti resiko yang ada dibalik keputusan itu. Jika seorang developer melakukan kesalahan, dia hanya merugikan jam kerja beberapa hari saja. Sedangkan jika software architect melakukan kesalahan, apalagi dalam proyek yang kompleks, kerugian dapat dialami hingga hitungan tahun.

Resistensi terhadap stres 

Pekerjaan ini dipenuhi dengan tuntutan yang berubah dengan cepat, stakeholders yang memiliki latar belakang berbeda, dan kultur bisnis yang beragam. Saat terjadi masalah, seorang software architect dituntut untuk memberi respon yang cepat. Oleh karena itu, area ini memiliki tingkat stres yang tinggi. Bekerja selalu lebih menyenangkan ketika itu membawa kesenangan. Jadi jika Anda memilih posisi ini hanya untuk uang, maka pikirkan lagi.

Keterampilan manajemen 

Ini termasuk keterampilan organisasi dan leadership. Kemampuan yang baik untuk memimpin tim yang berisi spesialis dengan latar belakang yang berbeda sangat penting.

Kemampuan analitik

Salah satu tugas yang paling penting adalah kemampuan untuk merepresentasikan masalah yang abstrak dalam bentuk objek dari sebuah sistem, yang dapat dievaluasi, dirancang dan dikembangkan.

Tanggung jawab utama seorang software architect

Tanggung jawab yang paling utama adalah dukungan teknis proyek dari awal, melalui rilis produk, hingga pengembangan software tambahan. Tanggung jawab lainnya adalah:

• mengidentifikasi business requirements dari stakeholder proyek;
• merancang keseluruhan sistem berdasarkan requirements yang diterima;
• memilih arsitektur sistem dan masing-masing komponen dari sistem ini di high-level;
• memilih teknologi untuk implementasi setiap komponen dan koneksi antar komponen;
• tinjauan arsitektur;
• code-review;
• menulis dokumentasi proyek dan support;
• menciptakan standar development terpadu di perusahaan; dan
• mengontrol arsitektur selama iterasi berikutnya dari sistem setelah rilis.

Membuat arsitektur yang tepat untuk memecahkan masalah yang dihadapi hanyalah sebagian kecil dari tanggung jawab software architect. Mereka juga harus:

• kontrol atas arsitektur sistem;
• kontrol atas waktu dan tenggat waktu;
• kontrol atas sinkronisasi software dengan arsitektur sistem;
• melakukan kontrol kualitas kinerja;
• berikan masukan yang diperlukan untuk pemilihan tools dan environment;
• berinteraksi dengan manajemen dan stakeholders;
• menyelesaikan perselisihan;
• menyelesaikan masalah teknis;
• memahami dan merencanakan jalur evolusi;
• merencanakan teknologi baru jika diperlukan; dan
• mengelola identifikasi risiko dan strategi mitigasi risiko yang terkait dengan arsitektur.

Maka, untuk menjadi seorang software architect, Anda harus terbuka untuk selalu melakukan pembelajaran dan peningkatan. Memahami beberapa stack teknologi adalah suatu keharusan: server language, iOS, Android, dan banyak lagi.

Anda harus rajin membaca banyak literatur profesional dan menemukan beberapa mentor untuk tempat bertanya. Ikuti workshop atau kursus. Untuk menjadi seorang software architect bukan hal yang mudah dan dibutuhkan setidaknya beberapa tahun.

Tipe-tipe software architect

Spesialisasi adalah hal yang lumrah di setiap bidang profesional. Misalnya, dalam dunia kedokteran kita mengenal spesialis bedah, kardiologi, oftalmologi dan lain-lain. Dalam bidang manajemen, misalnya, ada manajer sumber daya, manajer PR, bahkan manajer kebersihan.Spesialisasi diperlukan ketika jumlah pengetahuan di lapangan melebihi batas rasional. Dan karena software architect adalah jenis pengetahuan yang luas, penting untuk melakukan spesialisasi untuk produktivitas yang lebih baik. Berikut jenis-jenis divisi dalam software architect:

System Architect

Tingkat arsitektur terendah. Fokus pada satu aplikasi tunggal. Low level design namun sangat detail. Komunikasi biasanya hanya dalam satu tim development. Cakupan tanggung jawab system architect biasanya sebagai berikut:

• Membawahi satu sistem dan membangun koneksi di dalamnya.
• Berfokus pada komponen teknis development.
• Membantu project manager untuk membuat keputusan manajemen.
• Memiliki pengetahuan yang mendalam tentang teknologi.

Solution Architect

Tingkat menengah arsitektur. Fokus pada satu atau lebih aplikasi untuk kebutuhan bisnis (solusi bisnis). Low level design hingga high level. Komunikasi antara beberapa tim development. Cakupan tanggung jawab solution architect biasanya sebagai berikut:

• Berpartisipasi dalam diskusi bisnis.
• Menciptakan koneksi antara beberapa sistem.
• Menyediakan komunikasi antara beberapa tim.
• Desain koneksi antar sistem.
• Bertindak sebagai perantara antara kebutuhan bisnis dan teknologi.

Enterprise Architect

Tingkat arsitektur tertinggi. Fokus pada berbagai solusi. High level, desain abstrak, yang perlu dirinci oleh solution architect atau application architect. Komunikasi di seluruh organisasi. Cakupan tanggung jawab enterprise architect biasanya sebagai berikut:

• Bertanggung jawab atas semua development dalam perusahaan
• Bekerja dengan high level abstraction dari sistem yang dibuat.
• Menyediakan komunikasi teknis di seluruh perusahaan.
• Tidak berurusan dengan coding.
• Fokus pada komponen bisnis.
• Memiliki wawasan teknis yang luas.

Terkadang arsitek juga dilihat sebagai "perekat" untuk masalah komunikasi antara stakeholders. Sebagai contoh:

• Horizontal: Menjembatani komunikasi antara bisnis dan developer atau tim development yang berbeda.
• Vertikal: Menjembatani komunikasi antara developer dan manajer.
• Teknologi: Mengintegrasikan teknologi atau aplikasi yang berbeda satu sama lain.

Skill yang Harus Dimiliki oleh Software Architect

Untuk mendukung aktivitas kompleks software architect, dibutuhkan keterampilan khusus. Berikut ini 10 keterampilan ini yang harus dimiliki setiap software architect: Design, Decide, Simplify, Code, Document, Communicate, Estimate, Balance, Consult, Market. Mari kita bahas satu per satu.

Design

Apa yang membuat desain yang bagus? Ini mungkin pertanyaan yang paling penting. Mari kita buat perbedaan antara teori dan praktek.

Teori

Ketahui dasar pola desain: Pola adalah salah satu tool paling penting yang perlu dimiliki arsitek untuk mengembangkan sistem yang maintainable. Dengan pola Anda dapat menggunakan kembali desain untuk memecahkan masalah umum dengan solusi yang terbukti.Buku “Design Patterns: Elements of Reusable Object-Oriented Software” yang ditulis oleh Gang of Four (GoF) harus dibaca oleh semua orang yang berkecimpung di dunia software development. Meskipun itu diterbitkan lebih dari 20 tahun yang lalu mereka masih menjadi dasar software arsitektur modern. Misalnya pola Model-View-Controller (MVC) dijelaskan dalam buku ini yang diterapkan di banyak area atau merupakan dasar untuk pola yang lebih baru, misalnya MVVM.

Gali lebih dalam pola dan anti-pola: Jika Anda sudah mengetahui semua pola dasar GOF, maka perluas pengetahuan Anda dengan lebih banyak pola desain software. Atau gali lebih dalam bidang minat Anda. Baca buku “Enterprise Integration Patterns” yang ditulis oleh Gregor Hohpe. Buku ini berlaku di berbagai bidang setiap kali dua aplikasi perlu bertukar data, apakah itu pertukaran file sekolah tua dari beberapa sistem warisan atau arsitektur modern Microservice.

Ketahui quality measures: Mendefinisikan arsitektur bukanlah tujuan akhir. Ini memiliki alasan mengapa pedoman dan standar code didefinisikan, diterapkan dan dikendalikan. Anda melakukan ini karena persyaratan kualitas dan non-fungsional. Anda ingin memiliki sistem yang maintainable, reliable, adaptable, secure, testable, scalable, usable, dll. Cara untuk mencapai semua atribut kualitas tersebut adalah dengan menerapkan architecture work yang baik. Anda dapat mulai mempelajari lebih lanjut tentang quality measures di wikipedia.

Teori itu penting. Praktik mungkin lebih penting jika Anda tidak ingin menjadi arsitek menara gading.

Praktik

Coba dan pahami teknologi stacks yang berbeda: hal ini adalah kegiatan yang paling penting jika Anda ingin menjadi arsitek yang lebih baik. Coba teknologi stacks (baru) dan pelajari kelebihan dan kekurangannya. Teknologi yang berbeda hadir dengan aspek dan pola desain yang berbeda. Anda kemungkinan besar tidak belajar apapun dari hanya membalik-balik slide power point tanpa mencobanya sendiri dan merasakan keuntungan atau kelebihannya sendiri.

Seorang arsitek seharusnya tidak hanya memiliki pengetahuan luas tetapi juga mendalam di beberapa bidang. Tidak harus menguasai semua teknologi stacks tetapi memiliki pemahaman yang kuat tentang yang paling penting di bidang Anda.

Analisis dan pahami pola yang diterapkan: Lihat tren framework saat ini, misalnya, Angular. Anda dapat mempelajari banyak pola dalam praktik, misalnya, Observables. Cobalah untuk memahami bagaimana hal tersebut diterapkan dalam kerangka kerja dan mengapa hal itu dilakukan. Dan jika Anda benar-benar berdedikasi, lihat lebih dalam code dan pahami cara implementasinya.

Selalu penasaran dan ikuti User Groups: Di Indonesia, misalnya, ada Java User Group (JUG), dimana berbagai topik didiskusikan, mulai dari low level coding hingga topik arsitektur yang lebih tinggi. Bergabung dengan komunitas dapat memperkuat pemikiran dan memperluas jaringan pribadi Anda.

Decide

Seorang arsitek harus mampu mengambil keputusan dan memandu proyek atau seluruh organisasi ke arah yang benar.

Ketahui apa yang lebih penting: Jangan buang waktu dengan keputusan atau kegiatan yang tidak penting. Pelajari hal-hal yang penting saja.

Prioritaskan: Selalu pertimbangkan untuk memprioritaskan setiap keputusan yang akan diambil. Ada berbagai cara untuk melakukannya. Coba lihat model Weighted Shortest Job First (WSJF) yang banyak digunakan dalam agile software development. Terutama time criticality dan risk reduction sangat penting untuk memperkirakan prioritas keputusan arsitektur.

Ketahui kompetensi Anda: Jangan putuskan hal-hal diluar kompetensi Anda. Ini sangat penting karena dapat merusak posisi Anda sebagai arsitek secara signifikan jika gegabah. Untuk menghindari hal ini, klarifikasi dengan teman-teman Anda tentang tanggung jawab yang Anda miliki dan apa yang merupakan bagian dari pekerjaan Anda. Lebih lanjut, selalu cross-check keputusan penting dengan rekan kerja.

Evaluasi beberapa opsi: Selalu pikirkan lebih dari satu opsi jika menyangkut keputusan. Dengan memiliki beberapa, semua opsi dapat dibandingkan berdasarkan fakta, bukan insting, misalnya, biaya lisensi atau jatuh tempo. Hal ini juga memudahkan Anda untuk menyakinkan argumen pada stakeholders saat meeting.

Simplify

Ingat prinsip problem solving Occam Razor yang menekankan pada penyederhanaan. Jika Anda memiliki terlalu banyak asumsi untuk memecahkan masalah, Anda mungkin salah atau mengarah pada solusi rumit yang tidak perlu. Asumsi harus dikurangi (disederhanakan) untuk mencapai solusi yang paling baik.

Putar balik solusinya: Untuk mendapatkan solusi sederhana, putar balik solusi dan lihat dari angle yang berbeda. Cobalah untuk membuat solusi dengan memikirkan dari top-down kemudian down-top. Jika Anda memiliki data flow atau proses data, maka pertama-tama pikirkan dari kiri ke kanan kemudian coba lagi dari kanan ke kiri. Ajukan pertanyaan seperti: "Apa yang terjadi pada solusi ideal ini?" Atau: "Apa yang akan perusahaan/X lakukan?" (Di mana X mungkin bukan pesaing Anda, tetapi salah satu perusahaan GAFA). Kedua pertanyaan tersebut memaksa Anda untuk mengurangi asumsi seperti yang disarankan oleh Occam's Razor.

Ambil langkah mundur: Setelah diskusi yang intens dan panjang, hasilnya kerap kali sebuah coretan yang sangat kompleks dan berlembar-lembar. Anda seharusnya tidak pernah melihat ini sebagai hasil akhir. Ambil langkah mundur: Renungkan gambaran besarnya lagi (di tingkat abstrak). Apakah itu masih masuk akal? Kemudian lakukan lagi pada level abstrak lagi dan refactor. Terkadang membantu untuk menghentikan diskusi dan melanjutkan di keesokan harinya. Setidaknya otak perlu membutuhkan waktu untuk memproses dan menghasilkan solusi yang lebih baik, lebih elegan dan lebih sederhana.

Divide and Conquer: Sederhanakan masalah dengan membaginya menjadi bagian-bagian yang lebih kecil. Lalu selesaikan secara terpisah. Setelah itu validasi jika bagian-bagian itu cocok satu sama lain. Ambil langkah mundur untuk melihat gambaran keseluruhan.

Refactoring: Coba solusi yang lebih kompleks jika tidak menemukan ide yang lebih baik. Jika solusinya ternyata membuat masalah baru, Anda dapat memikirkannya kembali nanti dan menerapkan apa yang telah Anda pelajari. Refactoring bukanlah ide buruk. \

Namun sebelum melakukannya, perlu diingat untuk memiliki: (a) automated test yang cukup untuk dapat memastikan ketepatan fungsionalitas sistem, dan (b) buy-in dari stakeholder Anda. Untuk mempelajari lebih lanjut tentang refactoring, Anda dapat membaca “Refactoring. Improving the Design of Existing Code” oleh Martin Fowler.

Code

Bahkan jika Anda adalah enterprise architect, titik level arsitektur yang paling abstrak, Anda harus tahu apa yang developer kerjakan setiap hari. Dan jika Anda tidak tahu bagaimana melakukannya, Anda mungkin akan menghadapi dua masalah utama: (a) Developer tidak akan menghargai pertimbangan Anda, dan (b) Anda tidak memahami tantangan dan kebutuhan developer.

Miliki proyek sampingan: Tujuannya adalah mencoba teknologi dan tools baru untuk mengetahui kondisi sekarang dan perkiraan untuk masa mendatang. Pengalaman adalah kombinasi dari pengamatan, emosi, dan hipotesis (“Experience and Knowledge Management in Software Engineering” oleh Kurt Schneider). 

Membaca tutorial atau panduan pro dan kontra adalah hal bagus. Namun itu hanyalah pengetahuan textbook, hanya dengan mencobanya langsung Anda mengalami emosi dan mampu membangun hipotesis. Semakin banyak jam terbang Anda, semakin baik hipotesis yang muncul. Hal ini juga akan membantu Anda mengambil keputusan yang lebih baik dalam task sehari-hari.

Temukan hal yang tepat untuk dicoba: Anda tidak mungkin bisa mencoba semuanya. Anda membutuhkan pendekatan yang lebih terstruktur. Satu sumber yang dapat dipelajari adalah Technology Radar dari ThoughtWorks. Mereka mengkategorikan teknologi, tools, platform, bahasa, dan kerangka kerja ke dalam empat kategori: Adopt, Trial, Assess dan Hold. 

Adopt berarti ‘keyakinan untuk siap digunakan dalam kebutuhan enterprise.’ Trial berarti ‘perusahaan harus mencobanya dalam satu proyek yang dapat mengatasi risiko.’ Assess berarti ‘lakukan penilaian sejauh apa impact yang dihasilkan bagi perusahaan.’ Hold berarti ‘lakukan dengan hati-hati.’ Dengan kategorisasi ini, lebih mudah untuk mendapatkan gambaran tentang hal-hal baru dan kesiapan mereka untuk mengevaluasi tren mana yang sebaiknya didalami.

Document

Dokumentasi arsitektur bisa jadi penting atau tidak penting. Dokumen yang penting contohnya architectural decisions atau code guidelines. Initial documentation diperlukan sebelum coding dimulai dan perlu penyempurnaan terus-menerus. Dokumentasi lain dapat dibuat secara otomatis karena code juga dapat dijadikan dokumentasi, misalnya Diagram kelas UML.

Clean Code: Code adalah dokumentasi terbaik jika dilakukan dengan benar. Seorang arsitek yang baik harus mampu membedakan antara code yang baik dan buruk. Sumber yang sangat bagus untuk mempelajari lebih lanjut tentang kode yang baik dan buruk adalah buku “Clean Code” oleh Robert C. Martin.

Hasilkan dokumentasi jika mungkin: Sistem berubah dengan cepat dan sulit untuk memperbarui dokumentasi. Apakah itu tentang API atau lanskap sistem dalam bentuk CMDB: Informasi dasar sering berubah terlalu cepat untuk menjaga dokumentasi yang ter-up-to-date.

Sebisa mungkin, sesedikit mungkin: Dokumentasi yang ekstensif sulit untuk dibaca dan dimengerti. Informasi tambahan harus disimpan dalam apendiks. Khususnya untuk decision papers, lebih penting untuk menceritakan narasi yang meyakinkan daripada hanya melempar banyak argumen.

Pelajari lebih lanjut tentang kerangka kerja arsitektur: Poin ini dapat diterapkan ke semua poin teknis lainnya. Framework seperti TOGAF dan Zachmann menyediakan tools yang terasa berat untuk dokumentasi, meskipun keunggulan mereka tidak terbatas hanya pada dokumentasi. Mendapat sertifikasi dalam frameworks semacam itu mengajarkan Anda untuk menangani arsitektur secara lebih sistematis.

Communication

Jika Anda brilian dalam desain tetapi tidak dapat mengkomunikasikan ide-ide Anda, kecil kemungkinan Anda menciptakan dampak atau bahkan cenderung untuk gagal.

Pelajari cara mengomunikasikan ide Anda: Saat presentasi di media manual, Anda harus paham cara menyusun pikiran dan menyajikannya secara visual ke peserta meeting. Buku “UZMO - Thinking With Your Pen” adalah sumber yang bagus untuk meningkatkan keterampilan di bidang ini. Sebagai arsitek, Anda biasanya tidak hanya berpartisipasi dalam rapat, namun juga mendorong keefektivan rapat dan memoderasinya.

Bersikap transparan: Anda perlu membuat alasan yang transparan di balik setiap keputusan. Terutama, jika ada orang tidak terlibat dalam proses pengambilan keputusan, akan sulit untuk memahami, menaati keputusan serta alasan di baliknya.

Estimate dan Evaluate

Ketahui prinsip-prinsip dasar project management: Jangan lupa bahwa ini bukan hanya tentang implementasi, ada lebih banyak kegiatan yang perlu dipertimbangkan, seperti requirements engineering, testing dan fixing bugs. 

Jika Anda ditempatkan dalam proyek yang agile, pelajari cara estimasi dan planning yang benar: Buku "Agile Estimating and Planning" oleh Mike Cohn memberi gambaran yang jelas dalam bidang ini.

Evaluasi "unknown" arsitektur: Sebagai arsitek, Anda juga harus dapat mengevaluasi kesesuaian arsitektur untuk konteks saat ini atau di masa mendatang. Dan ini bukan hanya tentang arsitektur, tetapi juga tentang bagaimana sistem dikelola karena terkait erat dengan kualitas.

Balance

Ada harga, ada kualitas: Anda perlu menyeimbangkan architectural requirements dan functional requirements. Over engineering harus dihindari.

Manajemen konflik: Software architect kerap menjadi jembatan antara beberapa kelompok dengan latar belakang yang berbeda. Latar belakang yang berbeda dapat memicu konflik. Pelajari teori komunikasi dari buku "Four-Ears Model" dari Schulze von Thun untuk menguasai manajemen konflik.

Consult dan Coach

Memiliki visi: Tetapkan visi jangka menengah hingga panjang yang ingin Anda capai, terlepas dari pendekatan apapun yang digunakan. Karena Anda tidak dapat mencapai semuanya sekaligus, maturity model adalah pendekatan yang tepat untuk digunakan. 

Model ini memberi struktur yang jelas, mudah dicerna dan memberi status progress setiap saat. Untuk berbagai aspek, gunakan model yang berbeda, misalnya development practices atau continuous delivery. Setiap tingkat dalam maturity model memiliki requirements yang mengikuti kriteria SMART untuk memudahkan measurement.

Bangun komunitas praktik (CoP): Bertukar pengalaman dan pengetahuan di antara kelompok dengan kepentingan bersama membantu mendistribusikan ide dan standardisasi. Misalnya, Anda dapat mengumpulkan dan membuka forum diskusi bagi semua developer dan arsitek JavaScript di satu ruangan. Lihat juga artikel Communities of Practice dari SAFe Framework yang menjelaskan konsep CoP dalam setting Agile.

Melakukan sesi open-door: Salah satu sumber kesalahpahaman adalah kurangnya komunikasi. Blokir slot waktu, misalnya 30 menit setiap minggu, untuk saling bertukar topik terkini dengan rekan-rekan Anda. Cobalah untuk memecahkan masalah minor saat itu juga. Jadwalkan pertemuan selanjutnya untuk topik yang lebih kompleks.

Market 

Anda memiliki gagasan yang brilian dan berhasil mengkomunikasikannya namun tidak ada yang mau mengikuti? Anda mungkin kurang dalam skill marketing.

Buat prototipe: Tunjukkan prototipe ide Anda. Ada banyak alat untuk membuat prototipe. Dalam konteks perusahaan yang menyukai SAP, cek build.me di mana Anda dapat membuat aplikasi UI5 yang bagus dan dapat diklik dengan cepat dan mudah.

Tapi tolong, jangan melakukan pemasaran yang berlebih: Dalam jangka panjang, konten adalah raja. Jika kata-kata Anda tidak terwujud, ini akan merusak reputasi Anda dalam jangka panjang.

Repeat It, Believe It: Penelitian menunjukkan bahwa paparan berulang terhadap opini membuat orang percaya bahwa pendapat itu lebih umum, bahkan jika sumber pendapat itu hanya satu orang.” (Sumber: The Financial Brand) 

Jika Anda mempublikasikan ide dengan cukup sering, itu dapat membantu meyakinkan orang dengan lebih mudah. Namun tetap waspada, strategi semacam ini harus digunakan dengan bijaksana karena dapat menjadi bumerang sebagai trik pemasaran yang buruk. 

Tertarik menjadi Software Architect?

Jika Anda tertarik menjadi seorang software architect setelah membaca artikel ini, atau tiba-tiba terpikir untuk mencoba mengembangkan karir di jalur ini, pastikan Anda benar-benar menginginkannya. 

Pertama-tama, orang cenderung takut pada hal baru. Posisi baru, jenis stres baru, yang bertentangan dengan status quo yang terlanjur nyaman. Tentu saja, pilihannya tidak selalu tergantung pada seberapa banyak Anda bersedia mengubah sesuatu dalam hidup. Pada saat yang sama, hal itu juga dapat bergantung pada keluarga, komitmen keuangan Anda, orang tua dan faktor lainnya.

Kedua, area keterampilan ini membutuhkan waktu beberapa tahun. Proses menjadi software architect tidak terjadi dalam semalam. Namun, jika pun Anda tidak memiliki rencana pasti, lebih baik mulai mengambil langkah kecil yang menggerakkan Anda ke depan, daripada tetap di tempat yang sama.

Berdiri di tempat yang sama di dunia IT adalah sinonim untuk stagnasi dan belenggu pribadi dalam kehidupan.Simak T-shaped skill dibawah ini sebagai gambaran bagaimana seorang spesialis dapat berkembang secara vertikal maupun horizontal.

Pertumbuhan seorang arsitek terkait erat dengan jumlah platform di mana dia memiliki keahlian teoritis dan terutama praktis, dan juga, dengan jumlah bidang subjek yang dikuasai. Tujuan pengembangan karir arsitek adalah di titik "m-shaped" - yaitu multiplatform & multi domain.

Maka, jika Anda tertarik menjadi seorang software architect atau ingin mengembangkan diri ke area lain dari dunia IT, segera lakukan persiapan matang dan segera bergabung ke tim SoftwareSeni.