Catatan Pembuka

Arsitektur perangkat lunak Anda bukan sesuatu yang “dirancang” tim teknis. Ia “tumbuh” dari struktur organisasi Anda. Hukum yang diajukan tahun 1968 ini terus divalidasi ulang di era AI.
Riset empiris Harvard Business School membuktikan: jarak organisasi lebih kuat memprediksi tingkat cacat perangkat lunak daripada kompleksitas kode. Apa yang Anda kira “utang teknis”, bisa jadi sebenarnya “utang organisasi”.
Kekaisaran microservice Amazon, model squad Spotify, kebuntuan Siri Apple — tiga perusahaan skala triliun dolar dengan nasib berbeda, semuanya menafsirkan hukum yang sama.
Agen AI mulai masuk ke bagan organisasi. Ketika “node” dalam tim tidak lagi seluruhnya manusia, Hukum Conway akan ditulis ulang dengan cara yang tak Anda duga.

Pada 1968, seorang programmer yang namanya nyaris tak dikenal menulis sebuah makalah. Harvard Business Review menolaknya dengan alasan “belum membuktikan tesisnya”. Lima puluh enam tahun kemudian, gagasan inti makalah itu menjadi hukum besi yang diakui seluruh industri perangkat lunak — dan di 2026, saat AI merombak segalanya, hukum ini lebih relevan dari sebelumnya.

1. Dari Makalah yang Ditolak Menjadi “Hukum Gravitasi” Rekayasa Perangkat Lunak

Ditolak Pintu oleh HBR

Pada April 1968, Melvin Conway menerbitkan makalah berjudul sederhana di majalah Datamation: “How Do Committees Invent?”

Klaim inti makalah itu hanya satu kalimat, tapi cukup membuat CTO mana pun terjaga malam:

“Organisasi yang merancang sistem akan menghasilkan desain yang mencerminkan struktur komunikasi organisasinya.”

Dibuat sederhana: bagan organisasi perusahaan Anda adalah cetak biru arsitektur perangkat lunak Anda.

Conway mendokumentasikan sebuah kasus yang sangat jelas dalam makalahnya. Sebuah perusahaan menugaskan delapan orang, dibagi dua tim, untuk membangun dua compiler — tim lima orang dan tim tiga orang. Hasilnya? Tim lima orang menghasilkan compiler lima tahap. Tim tiga orang menghasilkan compiler tiga tahap. Bukan karena alasan teknis, melainkan karena setiap orang perlu “memiliki” unit kerjanya sendiri.

Conway merumuskan hubungan ini dalam bahasa matematika sebagai pemetaan homomorfik (homomorphism) — relasi yang mempertahankan struktur antara organisasi dan desain sistem. Bukan kebetulan. Bukan anomali. Ini hukum yang mendekati keniscayaan matematis.

Yang ironis, Conway awalnya mengirimkan makalah ini ke Harvard Business Review, tapi editor menolaknya dengan alasan “belum membuktikan tesisnya”. Tujuh tahun kemudian, Fred Brooks mengutip gagasan ini dalam karya klasik The Mythical Man-Month, dan secara resmi menamakannya “Hukum Conway” (Conway’s Law).

Sejak saat itu, sebuah observasi yang pernah ditolak jurnal bisnis papan atas berubah menjadi salah satu hukum yang paling banyak dirujuk di rekayasa perangkat lunak.

Kata Putus dari Martin Fowler

Kalau Conway adalah Copernicus yang mengajukan hipotesis, maka dua dekade riset empiris berikutnya adalah teleskopnya.

Pada 2022, ilmuwan utama ThoughtWorks Martin Fowler menulis sebuah penilaian yang banyak disebarkan di industri: “Jika ada satu hukum arsitektur perangkat lunak yang disepakati semua praktisi, itu adalah Hukum Conway. Cukup penting untuk memengaruhi setiap sistem yang pernah saya lihat; cukup kuat sehingga siapa pun yang mencoba melawannya ditakdirkan gagal.”

Bukan deduksi teoretis akademisi dari menara gading. Fowler berulang kali menyaksikan fenomena yang sama dalam praktik konsultasinya di ratusan perusahaan: bagan organisasi selalu menjadi bayangan cetak biru perangkat lunak, terlepas apakah manajemen menyadarinya.

Ada implikasi yang halus tapi krusial di sini, yang sering terlewat. Fowler mengatakan “siapa pun yang mencoba melawan-nya ditakdirkan gagal” — bukan “siapa pun yang mencoba memanfaatkan-nya”. Bedanya di mana? Melawan Hukum Conway berarti mendorong perubahan arsitektur tanpa menyentuh struktur organisasi. Memanfaatkannya berarti menyesuaikan organisasi lebih dulu, dan membiarkan arsitektur “tumbuh alami”.

Perbedaan inilah yang menentukan keberhasilan atau kegagalan proyek transformasi digital. Kita akan mengupas strategi kunci “Inverse Conway Maneuver” di artikel ke-2 saat membahas Team Topologies — pada dasarnya, strategi ini memanfaatkan hukum tersebut, bukan melawannya.

2. Dari Laboratorium ke Medan Perang: Tiga Riset yang Memperkuat Hukum Ini

“Hipotesis Cermin” dari Harvard Business School

Pada 2012, MacCormack dan rekan dari Harvard Business School menerbitkan studius berbobot yang dikenal akademisi sebagai “Hipotesis Cermin” (Mirroring Hypothesis).

Metode risetnya cukup cerdik: mereka mengambil perangkat lunak komersial dan open source yang menjalankan fungsi persis sama, lalu membandingkannya. Perangkat lunak komersial dibangun oleh tim perusahaan yang hierarkis. Perangkat lunak open source dibangun oleh komunitas yang tersebar longgar.

Hasilnya seperti yang diramalkan Hukum Conway: organisasi longgar menghasilkan produk yang jauh lebih modular. Tim perusahaan yang terikat erat, bahkan saat dengan sengaja mengejar desain modular, tetap menghasilkan sistem dengan karakteristik keterikatan yang mencerminkan struktur organisasinya.

Struktur organisasi berperilaku seperti “medan gravitasi” — Anda bisa melawannya sebentar, tapi begitu waktu berlalu, arsitektur sistem akan ditarik kembali ke bentuk yang isomorfik dengan organisasinya.

Apa implikasi sejati riset ini bagi pengambil keputusan? Saat tim teknis Anda berulang kali mengatakan “kita perlu refactor”, yang mungkin perlu di-“refactor” justru bukan kodenya, melainkan organisasinya. Tapi bagaimana membedakan “utang teknis” dari “utang organisasi”? Butuh metode diagnosis sistematis — di artikel ke-12, “Kerangka Keputusan Adopsi Perkakas Pengembangan AI Enterprise”, kita akan menyediakan model evaluasi yang lengkap.

“Eksperimen Windows Vista” dari Microsoft Research

Pada 2008, Nagappan dan rekan di Microsoft Research melakukan studi kuantitatif berskala besar pada proyek Windows Vista. Mereka berusaha menjawab satu pertanyaan kunci: faktor apa paling kuat memprediksi cacat (bug) dalam perangkat lunak?

Kandidat jawabannya: kompleksitas kode, jumlah baris kode, frekuensi perubahan kode, pengalaman pengembang… serta satu variabel yang tampaknya tak berhubungan dengan “teknologi” — jarak organisasi (yaitu jarak dalam bagan organisasi antara tim-tim yang mengembangkan modul terkait).

Kesimpulannya membuat banyak penganut paham teknologi-saja tidak nyaman: jarak organisasi lebih kuat memprediksi tingkat cacat perangkat lunak daripada kompleksitas kode.

Dengan kata lain, modul yang dibangun bersama oleh dua tim yang “berjauhan” di bagan organisasi lebih rentan bug daripada modul yang sangat kompleks tapi dipelihara tim yang bekerja erat. Bug yang Anda kira akibat kode ditulis asal-asalan, bisa jadi sebenarnya akibat struktur organisasi yang dirancang asal-asalan.

Implikasi tingkat perusahaan dari temuan ini jauh lebih dalam dari yang tampak di permukaan. Artinya — strategi QA Anda harus mengikuti struktur organisasi, bukan kompleksitas kode. Modul lintas tim butuh cakupan pengujian dan proses tinjauan yang lebih ketat, meski kodenya sendiri tampak tidak rumit. Di era ketika kode yang dihasilkan AI melonjak (Copilot kini menghasilkan 46% kode yang ditulis pengguna), prinsip ini makin kritis — di artikel ke-8, saat membahas “Paradoks Produktivitas”, kita akan mengupasnya lewat kasus Coinbase.

“Akselerasi” dan “Kekhawatiran Tersembunyi” dari Riset DORA

Tim DevOps Research and Assessment (DORA) di bawah Google, dipimpin Nicole Forsgren, Jez Humble, dan Gene Kim, merilis studi efektivitas pengiriman perangkat lunak berskala terbesar hingga kini.

Temuan intinya selaras dengan Hukum Conway: “Jika kita mewujudkan arsitektur loosely coupled (terkopling longgar) yang terenkapsulasi dengan baik, dan dilengkapi struktur organisasi yang cocok, kita bisa meningkatkan ritme pengiriman dan stabilitas sekaligus mempertahankan pertumbuhan produktivitas linear atau bahkan superlinear saat tim engineering berkembang signifikan.”

Tapi laporan DORA 2022 juga menemukan efek samping yang menarik: arsitektur loosely coupled, meski meningkatkan efisiensi pengiriman, bisa jadi meningkatkan rasa burnout tim. Penyebabnya mungkin: saat tim sangat otonom dan terisolasi satu sama lain, anggota bisa kehilangan rasa makna global, lalu muncul perasaan “saya cuma roda gigi”.

Pengingat penting — penyelarasan arsitektur dan organisasi bukan peluru perak. Ia menyelesaikan masalah efisiensi, tapi bisa menciptakan masalah budaya.

Satu konsekuensi yang patut direnungkan: jika arsitektur loosely coupled plus organisasi loosely coupled sudah membuat developer manusia merasa terisolasi, apa yang terjadi ketika agen AI ditambahkan ke tim? AI tidak akan “merasa terisolasi”, tapi manusia akan makin terisolasi. Dimensi ini jarang dibahas. Namun dalam materi yang kami pelajari, laporan BCG 2025 mengangkat “dilema orkestrasi manajer menengah” — ini juga topik inti artikel ke-11 kami.

3. “Momen Hukum Conway” dari Tiga Perusahaan Skala Triliun Dolar

Amazon: Satu Email CEO yang Mengubah Segalanya

Sekitar 2002, Jeff Bezos mengirim “API Mandate” yang melegenda itu di internal Amazon — semua tim harus berkomunikasi lewat service interface (API). Tidak boleh ada tim yang langsung mengakses penyimpanan data tim lain.

Kalimat terakhir email itu konon berbunyi: “Siapa pun yang tidak mematuhi aturan di atas akan dipecat.”

Banyak orang menganggap arsitektur microservice Amazon sebagai keputusan teknis. Tapi dari sudut pandang Hukum Conway, apa yang dilakukan Bezos sebenarnya adalah keputusan struktur organisasi: ia lebih dulu memaksa memutus “komunikasi jalan pintas” antar tim lewat kendali manajemen, lalu arsitektur perangkat lunak secara alami berevolusi menjadi modul layanan yang saling terisolasi.

Inilah yang nanti diusulkan Bezos sebagai “Two-Pizza Team” — setiap tim berukuran tidak lebih dari jumlah orang yang bisa dikenyangkan dua pizza (biasanya 5–8 orang). Setiap tim punya layanannya sendiri, melakukan deployment secara mandiri, dan berinteraksi dengan dunia luar lewat API.

Kekaisaran microservice Amazon bukan digambar arsitek. Ia “ditumbuhkan” oleh struktur organisasi. Ini studi kasus positif paling klasik Hukum Conway.

Tapi ada satu lapisan yang jarang dibahas artikel lain: kesuksesan pendekatan Amazon tidak hanya karena Bezos memahami Hukum Conway, tapi karena ia sekaligus menyelesaikan masalah “penyelarasan insentif”. Setiap “Two-Pizza Team” punya P&L (laporan laba rugi) sendiri. Mereka otonom secara teknis sekaligus otonom secara komersial. Akibatnya, tim punya dorongan internal untuk menjaga batas layanan tetap jelas — karena batas yang kabur berarti tanggung jawab yang kabur, dan tanggung jawab yang kabur berarti penilaian kinerja yang kabur.

Penyelarasan tiga sisi — struktur organisasi + struktur insentif + arsitektur teknis — itulah gambaran utuh model Amazon. Perusahaan yang hanya meniru struktur organisasi tanpa mempelajari desain insentif, kebanyakan hanya dapat bentuknya, tanpa mendapatkan esensinya.

Spotify: Model Ideal Berbenturan dengan “Entropi” Realitas

Model “Squad” Spotify pernah dipuja Silicon Valley sebagai rujukan desain organisasi: squad otonom 5–8 orang (Squad), beberapa squad membentuk tribe (Tribe), ahli teknis lintas tribe membentuk chapter (Chapter), komunitas berbasis minat membentuk guild (Guild).

Filosofi desain model ini sangat selaras dengan Hukum Conway — lewat struktur tim yang kecil dan otonom, mendorong lahirnya layanan perangkat lunak yang kecil dan otonom.

Tapi Spotify sendiri kemudian mengakui: realitas jauh lebih kompleks dari modelnya. Begitu bisnis tumbuh ke skala tertentu, dependensi lintas squad tak terhindarkan meningkat, dan otonomi murni mulai menimbulkan biaya koordinasi.

Ini mengungkap konsekuensi Hukum Conway yang sering diabaikan: struktur organisasi bukan sesuatu yang cukup didesain sekali untuk selamanya. Sama seperti perangkat lunak, ia cenderung mengalami “entropi meningkat”. Seiring kompleksitas bisnis bertumbuh, batas organisasi perlahan kabur, jalur komunikasi makin panjang, dan arsitektur sistem ikut menurun.

Organisasi teknis yang hebat bukan yang “pernah mendesain arsitektur yang baik”, melainkan yang membangun kapabilitas untuk terus menyesuaikan penyelarasan organisasi-arsitektur. Kapabilitas ini akan kami uraikan di artikel ke-2 tentang Team Topologies — ia menyediakan kerangka yang lebih sistematis dan lebih bisa diterapkan daripada model Spotify.

Apple: Mengapa Siri “Dihajar” ChatGPT

Sepanjang 2024–2025, rencana upgrade Siri AI Apple nyaris menjadi contoh kegagalan klasik bagi Hukum Conway.

Akar masalahnya bukan teknologi. Apple punya talenta riset AI kelas dunia dan dana melimpah. Tapi pengembangan Siri melibatkan dua tim yang memiliki retak struktural di bagan organisasi: tim riset AI (dipimpin John Giannandrea) dan tim pengembangan produk (dipimpin Craig Federighi).

Kedua tim punya prioritas berbeda, ritme berbeda, kriteria keberhasilan berbeda. Tim riset AI mengejar terobosan batas depan kemampuan model. Tim produk mengejar stabilitas pengiriman pengalaman pengguna. Ketika struktur komunikasi antara dua “node” organisasi ini terbelah, sistem yang dihasilkan pasti ikut terbelah.

Apa yang akhirnya didapat pengguna dari Siri? Sebuah “asisten medioker yang fungsinya ditumpuk-tumpuk” — setiap modul tampak oke, tapi begitu diintegrasikan, justru kehilangan pengalaman cerdas yang terpadu. Persis seperti yang diramalkan Hukum Conway: retakan sistem memetakan retakan organisasi.

Kasus Apple layak mendapat perhatian khusus dari pengambil keputusan. Banyak perusahaan sedang mengalami dilema yang persis sama — tim AI dan tim bisnis berada di bawah VP berbeda, proyek implementasi AI berubah jadi “permainan politik antar dua departemen”, bukan “pengiriman kolaboratif satu produk”.

Kalau perusahaan Anda sedang mendorong implementasi AI, lihat kembali bagan organisasi Anda: apakah kapabilitas AI eksis sebagai departemen yang berdiri sendiri, atau tertanam di dalam tim bisnis? Jawaban pertanyaan ini mungkin lebih menentukan keberhasilan proyek daripada pilihan model AI Anda.

4. Era AI: Hukum Conway Sedang Ditulis Ulang

Ketika “Node Organisasi” Tidak Lagi Seluruhnya Manusia

Pada 2026, Hukum Conway menghadapi tantangan terdalam sejak 1968.

Saat Conway merumuskan hukum ini, ada premis implisit: setiap “node” dalam organisasi adalah manusia. Struktur komunikasi adalah komunikasi antarmanusia.

Tapi hari ini, agen AI mulai masuk ke bagan organisasi. Claude Code bisa menyelesaikan tugas pengembangan multi-langkah secara mandiri. Sistem Minions dari Stripe menghasilkan lebih dari 1.000 merged PR per minggu. Cursor membuat 100% engineer di NVIDIA mengubah cara kerja mereka. Laporan Gartner mencatat pada 2025 konsultasi perusahaan soal orkestrasi AI multi-agent melonjak 1.445%.

Ketika sebagian node organisasi bukan lagi manusia, apa yang terjadi pada Hukum Conway?

Pembahasan mendalam pertanyaan ini akan menembus seluruh paruh kedua seri kita — fenomena “One-Person Unicorn” di artikel ke-10, “Hukum Conway Bertemu Agen AI” di artikel ke-11, “Agentic Engineering” di artikel ke-14. Tapi di sini, lebih dulu saya berikan tiga penilaian awal untuk membantu Anda membangun kerangka berpikir:

Pertama, struktur komunikasi akan berubah menjadi struktur kebijakan. Komunikasi antarmanusia bergantung pada budaya, pemahaman tacit, interaksi informal. Tapi antara manusia dan agen AI tidak ada “pemahaman tacit“ — Anda harus mendefinisikan batas interaksi lewat kebijakan, aturan, dan permission eksplisit. Kapabilitas governance akan menggantikan kapabilitas komunikasi sebagai variabel inti desain organisasi.

Kedua, bagan organisasi akan berubah menjadi permission graph. Bagan organisasi tradisional menggambarkan hubungan pelaporan dan pembagian fungsi. “Bagan arsitektur” era AI lebih mirip directed acyclic graph (DAG) yang mendefinisikan kapabilitas dan constraint — agen mana boleh mengakses data apa, menjalankan operasi apa, dan dalam kondisi apa perlu persetujuan manusia.

Ketiga, pengetahuan institusional akan berpindah dari manusia ke kebijakan. Dulu, “pegawai senior pergi dan membawa serta pengetahuan” adalah rasa sakit setiap perusahaan. Ke depan, pengetahuan kunci akan dikodekan ke dalam kebijakan dan konteks agen AI — ini sekaligus peluang (pengetahuan tak lagi hilang) dan risiko (kebijakan yang keliru bisa diperbesar secara sistemik).

Setiap penilaian didukung banyak praktik industri dan data. Misalnya poin ketiga soal “perpindahan pengetahuan institusional”: kasus Klarna memberi contoh pro-kontra yang mencengangkan — setelah memecat 40% karyawan, mereka menemukan sistem AI tak bisa menampung pengetahuan tacit yang dibawa pergi karyawan yang dipecat, sehingga terpaksa mempekerjakan ulang orang. Cerita ini akan kami bedah tuntas di artikel ke-9, “Pelajaran Klarna”.

5. Periksa Sendiri: Jenis “Kesalahan Conway” Apa yang Sedang Dibuat Organisasi Anda?

Kalau Anda membaca sampai sini dan masih merasa “saya sudah paham semua ini”, saya ingin minta Anda mengerjakan satu latihan.

Di bawah adalah lima pola umum “misalignment organisasi-arsitektur” yang kami rangkum dari Hukum Conway dan riset turunannya. Cocokkan dengan perusahaan Anda sendiri, lihat berapa banyak yang terdeteksi:

❶ Microservice kulit luarnya saja: Kode sudah dipisah, tapi 50 orang masih berdebat dalam satu grup.
❷ Ilusi mid-platform: Mid-platform jadi bottleneck komunikasi semua lini bisnis.
❸ Pulau AI: Model yang dihasilkan tim AI tak bisa ditanam ke bisnis, karena organisasi “tidak sejalan”.
❹ Degradasi kolaborasi remote: Isolasi fisik menyebabkan fragmentasi sistem yang tak perlu.
❺ Pencernaan akuisisi yang tidak tuntas: Inkompabilitas budaya organisasi menyebabkan kegagalan integrasi teknis.

Langkah Berikutnya

Ini artikel pertama dari 15 artikel seri “Transformasi Rekayasa Perangkat Lunak di Era AI”. Kami memulai dari Hukum Conway dan membangun satu pemahaman dasar: struktur organisasi menentukan arsitektur sistem. Ini bukan metafora, melainkan hubungan kausal yang sudah diverifikasi secara empiris.

Tapi mengetahui hukum ini hanya titik awal. Pertanyaan sebenarnya: bisakah kita sebaliknya memanfaatkannya? Merancang struktur organisasi secara sengaja untuk membimbing arsitektur sistem yang ideal — inilah gagasan inti “Inverse Conway Maneuver”.

Artikel berikutnya, “Team Topologies — Metodologi Desain Organisasi Era Pasca-Agile”, akan mengupas bagaimana Matthew Skelton dan Manuel Pais mengembangkan gagasan ini menjadi metodologi lengkap yang bisa diterapkan: empat tipe tim dasar, tiga mode interaksi, serta konsep “beban kognitif” yang sangat diremehkan. Praktik dari Netflix, Adidas, dan Accenture akan menunjukkan: dalam kondisi apa Inverse Conway Maneuver efektif, dan dalam kondisi apa ia gagal.

Catatan seri: Seri ini terus memantau evolusi terbaru perkakas pemrograman AI, arsitektur organisasi, dan paradigma rekayasa perangkat lunak — misalnya bagaimana Hukum Conway berubah di era agen AI pada 2026, tingkat kematangan ekosistem perkakas terbaru, dan sebagainya. Ikuti seri ini untuk wawasan yang terus diperbarui.

Tentang Seri Ini

“Transformasi Rekayasa Perangkat Lunak di Era AI” adalah seri riset mendalam untuk pengambil keputusan teknis perusahaan, total 15 artikel. Berbasis riset sistematis terhadap 200+ makalah akademik dan laporan industri, kami menyediakan rujukan keputusan dengan anotasi tingkat bukti. Nantikan lebih banyak konten.

Rujukan

Conway, M. (1968). How Do Committees Invent? Datamation, 14(4), 28–31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.