Menulis Dokumen Architecture North Star
Menulis Dokumen Architecture North Star
Sebagai pedoman teknis untuk penghubung bisnis, sistem dan team terlibat ketika membangun sistem yang kompleks.
Untuk orang-orang astronomi pasti sudah familiar dengan sebutan North Star (Bintang Utara). Saya sering dengar, bahwa orang pada zaman dahulu menggunakan rasi bintang sebagai penunjuk arah. Dan tidak jarang juga saya dengar, bahwa para pelaut dahulu kala, juga sering menggunakan bintang sebagai penunjuk arah. Salah satu bintang yang terkenal adalah Bintang Utara, atau disebut juga bintang Polaris.
Polaris posisinya tidak berubah, dan selalu menunjukkan posisi utara. Sehingga banyak orang pun menggunakan bintang Polaris sebagai pedoman ketika bernavigasi.
Dari sini, dapat kita ketahui beberapa kata kunci, yakni “pedoman”, “penunjuk arah”, dan “tidak berubah”. Dan karena inilah, banyak orang menyebut North Star, sama seperti tujuan ideal yang akan dicapai, baik personal ataupun organisasi.
Term ini jugalah yang kini banyak di adopsi oleh orang orang bisnis, seperti, North Star metric, yang menjelaskan parameter yang digunakan untuk memprediksi kesuksesan dari bisnis. Bisa di asumsikan, bisnis akan gemilang, jika perusahaan tersebut dapat mencapai “North Star metric”.
Agar lebih paham dengan konsep north star, buat kamu yang penggemar anime / manga One Piece, maka saya dapat analogikan menjadi lebih sederhana.
Dalam cerita manga/anime One Piece, disebutkan tokoh utama, Luffy, Kapten Bajak Laut Topi Jerami, memiliki mimpi untuk menjadi Raja Bajak laut dengan menemukan One Piece, harta karun yang tak ternilai yang telah ditemukan oleh Raja Bajak laut sebelumnya.
Dalam perjalanannya, dia pun mengalami banyak situasi naik dan turun yang membuat dia menjadi lebih kuat dan penuh petualangan, dan seiring waktu dia juga me-rekrut nakama nya (atau crew bajak lautnya) untuk menemani perjalanannya menemukan harta karun One Piece.
Nah, semua crew ini, juga memiliki mimpi masing-masing. Sebut saja, Zoro si wakil kapten, bermimpi menjadi pendekar pedang nomor satu di dunia. Nami, si navigator, ingin menggambar peta dunia. Sanji bermimpi ingin menemukan All Blue. Dan anggota beberapa anggota lainnya, juga memiliki mimpi yang berbeda-beda.
Jika dikaitkan pada satu titik, semua ini akan tercapai saat mereka menemukan One Piece. Karena One Piece tersebut berada di pulau terakhir yang ada di dunia One Piece. Jika disederhanakan, dalam One Piece universe,
Zoro akan bisa mengakui dirinya jadi pendekar terbaik, jika dia telah melewati semua tantangan dan sampai di pulau terakhir. Perlu diketahui untuk mencapai hal tersebut sangatlah banyak rintangan, perkelahian, dan perang dimana-mana.
Nami akan dapat menggambar seluruh peta dunia One Piece universe, jika mereka telah menemukan pulau terakhir.
Sanji juga akan menemukan All Blue, yang hanya ada di pulau terakhir.
Begitu juga anggota lainnya, seperti Franky, yang ingin membuat kapal terbaik yang mampu melewati segala jenis laut dan badai, ya tentu saja ini hanya bisa divalidasi jika mereka telah mencapai pulau terakhir.
Dari cerita One Piece diatas, dapat kita petakan pada struktur perusahaan. Harta karun One Piece yang ada pada pulau terakhir, merupakan tujuan akhir dari Bajak Laut Topi Jerami pada cerita diatas, dalam konteks perusahaan ini merupakan visi perusahaan. Visi perusahaan bisa apa saja, seperti eccomerce terbaik di dunia, atau one stop solutions for payments, atau ekspansi ke berbagai negara, dan sebagainya. Ini merupakan contoh dari North Star. Visi perusahaan atau impian yang hendak dicapai si perusahaan.
Lalu, semua crew dalam Topi Jerami (anggota bajak laut Luffy) pada cerita One Piece diatas, bisa di analogikan seperti tim/divisi dalam setiap perusahaan. Contoh, Nami ingin memetakan seluruh dunia, mungkin dalam organisasi, ini adalah divisi sales dan marketing, yang ingin acquire user sebanyak-banyaknya, bahkan seluruh user di dunia. Zoro ingin jadi pedekar terbaik, ini mungkin tim engineering, yang ingin memiliki world-class engineering culture terbaik dan menjadi pioner di dunia teknologi. Franky ingin membuat kapal terbaik, bisa di analogikan seperti Infra team yang mampu support dan scale bisnis support zero down time, dan fast response dalam segala medan.
Sehingga, berlandas pada visi (north-star), semua tim yang ada pada perusahaan akan bekerja independen namun saling mendukung guna mencapai visi (north-star) dari perusahaan tersebut.
Architecture North Star
Dari cerita diatas, kita sudah tahu apa itu North Star secara garis besar ketika dipetakan dalam struktur organisasi. Lalu saya akan membawa kita lebih detail lagi, yaitu North Star dalam sistem architecture. Konsepnya sama, bedanya pengaplikasian-nya lebih ke teknis, dan fokus pada sistem architecture.
Saat perusahaan telah menetapkan North Star metric yang akan dicapai, maka semua tim/divisi akan saling bekerja sama untuk mencapai tujuan tersebut. Contoh, Perusahaan akan fokus pada ekspansi ke negara lain.
Mungkin dari operation, dan business tidaklah terlalu banyak major changes. Namun jika kita berbicara dengan sistem, sistem yang sudah berjalan bertahun-tahun, sistem yang sudah kompleks, tidaklah mudah untuk support kebijakan tersebut. Terlalu banyak resiko yang harus dipertimbangkan, seperti refactor, versioning, data migration. Belum lagi depencies antar service/tim yang biasanya berimbas ke banyak tim engineering lain.
Karena faktor kompleksitas inilah, maka semua perubahan perlu dilakukan dengan hati-hati. Dibutuhkan satu dokumen algiment yang mencakup ideal design yang support terhadap kebijakan perusahaan yang baru. Dan tentu saja harus menjelaskan siapa saja tim-tim yang terkena impactnya. Terlebih jika tim yang kena impact adalah tim core yang terintegrasi oleh banyak tim produk, seperti Auth, Ledger (core banking), dan lain sebagainya. Dan dokumen ini lah kita sebut dengan Architecture North Star document.
Untuk menyimpulkan, tujuan dari Architecture North Star tidak lain diantaranya adalah memastikan semua orang memiliki:
Shared Understanding —setiap tim yang terlibat akan memiliki pemahaman yang sama dan visi yang sama
Coherent Architecture —sistem architecture yang jelas dan bukan arsitektur hacky-hacky atau tambal sulam yang menimbulkan banyak tech debt.
Less Coordination — membantu tim membuat keputusan cepat yang tajam tanpa koordinasi dari architect.
Visibility — membuat semua orang paham dan memiliki common language baik dari product / business dan juga engineering
Autonomy — semua team akan bergerak sendiri, dan mengontrol pace masing-masing selama mereka memiliki tujuan yang sama.
Jadi, Architecture North Star, akan menjadi fondasi untuk semua tim engineering/product yang terlibat untuk mencapai suatu goal, baik business goal, ataupun engineering goal. Dan dokumen tersebut haruslah fixed, mudah digunakan, mudah diakses, dan tidak ambigu, serta memiliki cukup informasi yang membantu semua team membuat keputusan sendiri.
My Experience in Writing Architecture North Star
Beberapa bulan terakhir, saya mendapat mandat untuk menjadi architect dari 4 tim core yang ada di perusahaan saya bekerja saat ini. Dan karena ini tim core, maka banyak tim-tim lain yang beketergantungan dengan ke 4 tim ini. Ke 4 tim tersebut adalah, Auth team — dimana setiap product, user pasti membutuhkan fitur Auth, dan menjadi pintu utama untuk semua akses, seperti API Key, User login, Server key, dsb.
Lalu 3 tim lagi adalah, Ledger team, Billing team, dan Reporting team. Karena perusahaan saya bekerja adalah perusahaan SaaS Payment Gateway, maka setiap produk haruslah terintegrasi dengan Ledger (core-banking) untuk pencatatan transaksi pembayaran, lalu karena produk utama kami adalah SaaS, maka semua produk juga harus terintegrasi ke Billing system dan Reporting, yang membuat semua produk dapat (allow) me-monetize produk mereka dengan pricing yang mereka inginkan.
Nah ke 4 tim inti ini, merupakan menjadi tanggung jawab saya untuk memastikan setiap development baik fitur, refactor, atau apapun yang berhubungan development tidak mengganggu tim lain secara drastis.
Normalnya, semua tim produk memiliki roadmap dan planning yang berbeda-beda. Memiliki prioritas berbeda, dan memiliki pace berbeda. Sehingga, saat kita develop suatu fitur di tim core, maka belum tentu semua tim yang ter-impact akan dapat langsung follow dengan cepat.
Lalu jika ada kebijakan organisasi yang sangat berhubungan dengan tim core, maka akan banyak tim lain yang kena impact. Sehingga saya pun harus menuliskan dokumen yang akan menjelaskan garis besar bagaimana ke 4 tim ini di masa depan, serta langkah-langkah yang harus dilakukan untuk mencapai titik tersebut.
Dokumen ini yang kami sebut “Architecture North Star document” akan menjadi panduan untuk semua tim terlibat membuat prioritas masing-masing. Dan membuat setiap tim lebih autonomous, termasuk di tim inti. Sehingga semua tim align pada satu visi design yang akan dicapai. Meskipun banyak prioritas dari issue lain seperti kebutuhan infra (DB upgrade, maintainance, etc), atau bahkan PM request fitur baru, maka tim engineer akan tetap align, techspec document dan development akan tetap berlandas pada ideal design yang sudah terpapar pada Architecture North Star document.
Menulis dokumen Architecture North Star
Untuk menulis dokumen Architecture North Star, buat saya tidaklah mudah, karena membutuhkan banyak koordinasi dan aligment agar mencapai kesepakatan terhadap semua stakeholders.
List Pain and Dreams
Namun langkah yang saya lakukan adalah tentu saja dimulai dari north-star metric yang akan dicapai perusahaan. Sebut saja, mencapai 100Billion transactions. Atau acquire 100 juta user baru. Atau ekspansi ke 5 negara baru.
Untuk support kebijakan ini, banyak tim harus memikirkan kondisi mereka saat ini. Apa saja yang menjadi blocker dimereka? Lalu apa ideal state yang harus dimiliki.
Sebut saja, untuk tim saya, yakni tim core. Maka untuk support ekpansi ke negara baru, maka banyak perubahan yang harus dilakukan pada sistem sistem core. Contoh, yang sebelumnya sistem kami hanya spesifik dengan negara Indonesia, maka kami harus refactor sistem agar bisa jadi agnostic terhadap semua negara. Atau setidaknya configurable, karena mungkin setiap negara memiliki regulasi yang berbeda-beda.
Nah untuk mengetahui apa saja yang perlu direfactor, tentu saja yang saya lakukan adalah melakukan interview dengan semua stakeholders yang terlibat. Apa saja pains yang ada sekarang jika kita hendak ekspansi ke negara baru? Lalu bagaimana dreams yang diharapkan?
Hasil dari interview ini akan disimpan dalam dokumen pain and dreams. Dokumen ini akan dianalisis tentu saja dengan pertimbangan current system yang sudah berjalan.
Analyze and Write Architecture North Star Document
Setelah Pain and Dreams kita dapatkan, maka tahap selanjutnya adalah memetakan system yang ada sekarang, sejauh apa perubahan yang perlu dilakukan untuk meng-cover keseluruhan pain and dreams. Disinilah role seorang Architect dibutuhkan untuk melihat secara high-level view. Architect harus menjadi jembatan dan melihat dari semua sisi, dari sisi stakeholders dan sisi tim yang terlibat, bahkan dari sisi user atau customer.
Core team tentu saja memiliki ideal solutions, namun terkadang ideal solution tidak align dengan stakeholders lainnya, eg, Sales, Product teams, Finance, dsb. Sehingga perlu aligment yang dipimpin oleh si Architect.
Praktis yang saya lakukan ditahap ini adalah dengan mengikuti Domain Driven Design (DDD). Dimana saya akan melakukan beberapa praktis DDD seperti Event Storming, atau Domain Story Telling yang dimana tujuannya adalah memperjelas domain boundaries, dan memperjelas ideal flow berdasarkan domain knowledge para domain experts (eg, PM, Engineer, Sales, Finance dsb) guna menyelesaikan masalah yang ada pada Pain and Dreams yang sudah di dokumentasikan.
Dalam praktiknya, ketika membuat dokumen architecture north-star untuk mendapatkan gambarannya dan aligned dengan semua stakehodler, para domain expert, bisa mecapai 3-6 bulan agar dapat selesai. Semakin banyak tim terlibat, maka makin lama dokumen akan dapat di finalisasi.
Finalized and Distribute Architecture North Star
Saat architecture north star sudah selesai, maka dokumen tersebut sudah dapat digunakan sebagai bahan acuan atau pedoman untuk development atau perbaikan semua sistem atau produk yang terlibat.
Untuk owner (pada diagram, core team) dari dokumen architecture north star, mereka dapat menggunakan dokumen tersebut untuk sebagai acuan ketika pengembangan fitur baru, atau bahkan refactor sistem yang sekarang untuk mencapai ideal state sesuai yang sudah dipaparkan pada dokumen architecture north star.
Sama halnya dengan tim product atau tim yang kena impact dari north-star dokumen dari tim core, maka mereka dapat menggunakan architecture north star tim core juga sebagai acuan untuk pengembangan fitur baru, atau untuk sebagai acuan di architecture north star mereka secara tim juga.
Sehingga, meskipun setiap produk memiliki prioritas berbeda, tetapi dengan semua tetap aligned pada satu visi yang ada pada architecture north-star, perubahan pun tidak terlalu mengejutkan, melainkan lebih terstruktur.
Dan yang paling penting adalah, semua proses ini haruslah diulang-ulang / direvisi kembali sesuai kebutuhan. Karena seiring dengan waktu berjalan, business goal mungkin berubah, sehingga ketika itu terjadi, kita harus tetap memastikan architecture kita tetap align dengan tujuan perusahaan yang baru.
Kesimpulan
North Star dalam artinya, terdapat beberapa kata kunci, yakni “pedoman”, “penunjuk arah”, dan “tidak berubah”. Sehingga dari makna ini, banyak orang menyebut North Star, sama seperti tujuan ideal yang akan dicapai, baik personal ataupun organisasi.
North Star Metric, menjelaskan parameter yang digunakan untuk memprediksi kesuksesan dari bisnis. Bisa juga diartikan sebagai dreams yang ingin dicapai dari sebuah perusahaan, eg, 100 Billion transactions monthly.
Architecture North Star, merupakan ideal system architecture yang harus dicapai oleh tim yang terlibat. Architecture North Star ditulis dalam satu dokumen yang dapat dijadikan sebagai pedoman dan referensi oleh semua tim engineering yang terlibat. Dokumen ini akan digunakan ketika melakukan development atau refactor pada sistem yang telah berjalan.
Untuk menulis dokumen Architecture North Star, dimulai dari menerjemahkan visi perusahaan, dan perubahan yang harus dilakukan untuk mendukung visi tersebut. Secara garis besar, berikut flow bagaimana proses dokumen arhctecture norht star.
List Pain and Dream yang dialami stakeholders, e.g., Customer, anggota tim, management, tim lain, sales, account manager, partners, dsb.
Define solusi ideal yang dapat menyelesasikan semua itu dengan berlandas pada fokus bisnis, dan keadaan system yang sudah ada
Analisis sistem, proses apa saja yang terdampak untuk menuju kondisi ideal tersebut.
Gunakan dokumen Architecture North star sebagai pedoman ketika develop fitur baru, atau refactor sistem yang sudah berjalan.
Ulang proses ini setiap ada variable yang tidak terduga, perubahan business goal, atau lain sebagainya yang menjadi blocker semua tim untuk mencapai Architecture North Star.
References