Menjalani peran Software Architect ternyata tidak mudah. Tim, manajer, bahkan perusahaan berharap banyak dari seorang Software Architect, yang salah satunya adalah dapat memahami keseluruhan sistem, baik dari bird-view maupun dari sisi implementasi detail pada level koding.

Melakukan peralihan konteks dari high-level view ke tingkat detail terbukti sangat melelahkan. Semakin kompleks sistem yang ada pada perusahaan, maka semakin sukar untuk memahami keseluruhan secara detail. Jujur saja saya pun tidak yakin ada orang yang mampu memahami keseluruhan sistem dari high-level view sampai tingkat detail (koding) tanpa membaca dokumentasi. Jika pun ada, maka saya akan meragukan apakah ia manusia, atau alien?

Dongeng: Kisah Pilu Software Architect

Ini adalah kisah seorang Arsitek yang bekerja di sebuah perusahaan di Indonesia. Screenshot di atas menggambarkan salah satu kegiatan hariannya. Ada beberapa pola yang bersifat detail seperti RFC xxxx, Standup, dan lainnya. Selain itu, ia juga menghadiri beberapa rapat bersifat high-level view, seperti Decoupling xxxx, Risk xxx, Event Storming xxx, Domain Storytelling xxx, Centralizing xxx, dan lainnya.

Misalnya, ketika menghadiri rapat bertema Decoupling xxx, si arsitek harus memikirkan batasan domain antara dua atau tiga tim yang terlibat dalam proyek tersebut. Atau, ketika menghadiri rapat dengan pihak upper management, misal: Centralizing xxx, ia harus memikirkan rencana dan arah jangka panjang dari sistem yang diwakilkan, mempertanggung jawabkan north-star architecture yang akan dimiliki tim tersebut. Kemudian setelah selesai semua rapat high-level view, ia juga harus menghadiri rapat RFC sync bersama salah satu engineer.

Berikut cuplikan percakapan rapat mereka.

Iman Tumorang: Hi? Yes what can I help you?
John Snow: I can’t pull the Go private library, how to do it?
Iman Tumorang: Oh you can read this, and please make sure you have connected to our VPN
…

John Snow: Which repo should I implement this, and which queue runner? Which cron? etc..

Bisakah Anda membayangkan saat Anda sudah letih dengan banyaknya meeting dengan tema yang high-level view, kemudian secara drastis menerima pertanyaan yang bersifat sangat detail? Bagaimana cara Anda bisa dengan cepat melakukan peralihan konteks dan mengarahkan engineer terkait ke repositori dan kodingan yang tepat?

Contoh yang lain adalah, bayangkan ketika timmu kedatangan engineer baru, dan dia ingin memahami keseluruhan sistem yang timmu miliki dari end-to-end? Bagaimana cara kamu menjelaskannya dengan mudah?

Introducing C4 Model

Seorang gamer yang pernah bermain CounterStrike, atau PointBlank(PB) pasti familiar dengan C4. Tenang teman, C4 yang saya maksud disini bukanlah hal yang berbahaya seperti C4 pada game tersebut. C4 disini memang bisa meledak, tetapi meledak dari yang high-level menjadi kecil dan detail.

TLDR; C4 Model dari website ini https://c4model.com/

1. A set of hierarchical abstractions (software systems, containers, components, and code).

2. A set of hierarchical diagrams (system context, containers, components, and code).

3. Notation independent.

Untuk menyimpulkan, C4 Model adalah sekumpulan diagram yang menjelaskan keseluruhan sistem secara hierarki dari hulu ke hilir. Disebut dengan C4 karena terdapat 4C dalam C4 Model, yaitu Context, Container, Components dan Code. Jadi ke-4 C ini saling berketerkaitan dan berurutan. Dan jika disederhanakan dalam diagram mungkin seperti berikut.

Dengan 4 level ini, akan sangat membantu setiap orang untuk dapat memahami sistem secara keseluruhan baik dari high-level sampai ke level detail. Tujuan dari C4 Model ini paling penting adalah discovery dan traceability. Kita dapat dengan mudah memahami sistem dari end-to-end bahkan sampai level kodingan.

Level 1: Context

Context merupakan pintu masuk untuk melihat seluruh sistem yang dimiliki. Jika terdapat banyak entitas perusahaan, maka setiap entitas dapat disebut sebagai sebuah sistem. Sebagai contoh, Eccomerce, Payment, dll.

Pada level ini, cukup dengan memahami secara high-level view. Fokus yang harus dibicarakan adalah tentang bisnis atau stakeholder lainnya yang masih berada pada level high-level view.

Scope yang harus dipahami adalah Users, 3rd Parties (Partner), Blackbox System, Alur Bisnis, User Journey, dll.

Audience yang hadir ketika membahas level ini adalah semua stakeholders bisnis (Sales/Partner/Account Manager), Product (PM, UI/UX, QA), Architect, dan Developer. Jika salah satu audience tersebut hadir, maka kita cukup membahas dilevel Context saja, tidak perlu lebih mendetail.

Level 2: Container

Saat kita melakukan zoom-in lebih detail dalam sebuah sistem dari Context (C-Level 1), kita akan menemukan Container. Container ini dapat dianalogikan seperti tim-tim yang ada di suatu organisasi, ataupun lebih tepatnya adalah aplikasi yang dimiliki oleh perusahaan tersebut yang merupakan masih bagian dari Context (C-teratas).

Container dapat berupa Microservice, Aplikasi (Web/Mobile/Desktop), Dashboard, dan lainnya.

Scope yang harus dipahami adalah semua scope dari C-sebelumnya (Context) ditambah dengan container/aplikasi yang merupakan bagian dari C-sebelumnya (Context).

Audience yang wajib hadir ketika membahas level ini adalah semua stakeholder Product (PM, UI/UX, QA), Architect, dan Developer. Di level ini para Business stakeholder sudah menjadi opsional dan tidak perlu tahu secara detail akan level ini.

Level 3: Component

Saat kita telah berpindah ke container/aplikasi yang lebih spesifik, kita akan memperluas cakupan pemahaman kita terhadap aplikasi dengan melihat komponen-komponen didalamnya. Tergantung dari container tersebut, misalnya microservice, maka akan terdapat beberapa komponen seperti Cron, API server, Queue consumer, gRPC handler, dll.

Sementara jika container sebelumnya adalah aplikasi web maka kemungkinan komponen yang terdapat bisa berupa SPA, Frontend Gateway, dan lain-lain. Pada level ini kita akan melihat semua komponen yang terdapat pada container yang telah kita zoom-in dan menjelaskan arsitektur aplikasi secara internal.

Scope yang harus dipahami adalah semua scope dari container sebelumnya ditambah dengan komponen-komponen yang terdapat pada setiap container/aplikasi, seperti Cron, gRPC, SPA, Queue Consumer, dan lainnya.

Audience yang wajib hadir saat membahas level ini adalah semua stakeholder Arsitektur dan Developer. Business dan Product stakeholder sudah menjadi opsional dan tidak perlu tahu secara detail akan level ini.

Level 4: Code

Setelah salah satu komponen dipilih, dengan melakukan zoom-in lagi, kita dapat menemukan kodingan dari komponen tersebut. Artifaknya dapat berupa tautan ke repository Git (Github/Bitbucket, dll), atau dokumentasi langsung ke UML/ERD/Class diagram, atau apapun yang menjelaskan tentang bentuk asli dari komponen tersebut.

Scope yang harus dipahami adalah bentuk wujud nyata dari sistem yang dibangun, misalnya kodingan, UML/ERD/Class diagram, dll.

Audience yang wajib hadir saat membahas level ini adalah semua stakeholder Arsitektur dan Developer.

Workshop: Sistem Informasi Absensi Karyawan

Mungkin untuk dapat mengenal lebih dekat dengan C4 Model, saya akan buat mini-workshop pemetaan sistem ke dalam C4 Model — dengan menggunakan IcePanel.io sebagai platform diagramnya.

The story:

Perusahaan Tumorang Happy Employee Inc adalah penyedia HRIS terdepan di dunia. Salah satu produk andalan mereka adalah fitur absensi karyawan, yang telah dipakai oleh jutaan perusahaan di seluruh dunia, termasuk Gugel, MateMeta, Macrohard, dan bahkan Mamazon juga menjadi salah satu klien mereka.

Mereka memiliki banyak Software Architect yang menangani sistem mereka secara keseluruhan, salah satunya adalah Jack. Jack sangat kompeten dan terlibat dalam banyak proyek, sehingga dia pun mulai merasa kewalahan dengan context switching yang kadang-kadang tidak bisa dihindari.

Untuk meningkatkan discoverability, traceability, serta mempermudah learning curve para engineer dalam memahami keseluruhan sistem, Jack pun memetakan keseluruhan sistem Tumorang Happy Employee menggunakan C4 Model.

Berikut pemetaan keseluruhan sistem yang dilakukan oleh Jack dalam bentu C4 Model.

Level 1: Context

Pada level 1 — Context, hanya terdapat 3 kotak umum, yaitu Employees, sistem Tumorang Happy Employee, dan 3rd Party (Email Platform). Di level ini, semua aktivitas inti yang dilakukan oleh user dapat dilistkan dalam bentuk panah. Namun, untuk mempermudah, maka hanya dibuat satu garis panah saja. Dengan asumsi bahwa semua aktivitas dari sisi client sudah tertutupi dengan satu arah panah.

Kemudian, Sistem absensi juga ternyata memiliki integrasi ke 3rd Parties, sehingga ditarik garis panah ke 3rd Party (Email platform). Terlepas dari semua aktivitas yang ada, dapat di asumsikan semua aktifitas ke 3rd Party hanya dalam satu garis panah.

Level 2: Container

Nah, saat si “Sistem Absensi” kita zoom-in, (tombol zoom), maka kita akan dapat melihat keseluruhan container/application yang ada di dalam Sistem Absensi.

Dapat dilihat, semua container yang ada pada sistem absensi. Disini sudah dapat kelihatan bentuk wujud dari struktur organisasi dari perusahaan tersebut. Seperti Mobile dan User dashboard terknoneksi langsung ke Auth Platform. Lalu terdapat juga koneksi ke 3rd Party melalui Notification platform.

Level 3: Component

Lalu kemudian, kita bisa zoom lagi setiap Container. Contoh kita zoom-in lagi si Notification platform.

Disini kita akan menemukan beberapa komponen yang ada di Notification Platform, seperti HTTP Server, gRPC server, dan Queue consumers.

Level 4: Code

Yang terakhir adalah codingan, untuk level ini, kita hanya tinggal membuat link referensi ke Github repository. Jika menggunakan platform IcePanel, maka akan terlihat seperti ini.

Disini kita sudah memetakan keseluruhan sistem dengan C4 model dengan bantuan IcePanel tentunya. Berikut detail diagramnya di Icepanel untuk lebih detail

Kesimpulan

Jika dibuat dalam diagram secara keseluruhan, maka berikutlah penjabaran C4 model.

*klik gambar untuk lebih detail

Jika kita kembali ke dongeng #1 di atas, C4 Model dapat membantu si Architect untuk melakukan zoom-in dan zoom-out secara praktis. Pada pagi hari ia melakukan meeting dengan tim A tentang high-level view dan aligment (C-Level 2). Siang harinya, ia bertemu dengan engineer X untuk membahas implementasi RFC (C-Level 3 & 4). Sang Architect dapat dengan mudah memahami konteks dengan cepat hanya dengan memanfaatkan C4 Model yang dimilikinya.

Namun, untuk sampai ke tahap itu akan memerlukan waktu yang lama karena membutuhkan dedikasi semua Architect untuk memetakan keseluruhan sistem mereka ke dalam C4 Model. Apabila C4 Model sudah solid, maka siapa pun pasti akan sangat terbantu untuk memahami sistem secara keseluruhan.

Untuk toolsnya sendiri, saya tidak ada rekomendasi. Namun untuk blogpost ini, saya menggunakan IcePanel. Selain IcePanel, kamu juga dapat menggunakan tools diagram lainnya, seperti, Structurizr, C4-PlantUML, atau yang lebih hard-core dapat menggunakan Draw.io, Excalidraw, dsb.

Demikian tulisan ini saya simpulkan, semoga berguna bagi yang membutuhkan.

Reference

• Link untuk Excalidraw untuk dapat melihat diagram saya diatas.

• Link untuk IcePanel untuk Miniworkshop diatas

• https://c4model.com/