Saya pernah bekerja dengan orang-orang cerdas, di organisasi dengan niat baik dan praktik modern. Namun saya terus melihat hal-hal yang sama salah. Di tempat yang sama. Itu membuat saya berpikir.
Para pengembang merasa keamanan itu membatasi. Tim keamanan merasa pengembang ceroboh. Operasi menginginkan stabilitas sementara manajemen menginginkan kecepatan dan inovasi.
Diagnosis yang biasa adalah: masalah komunikasi. Tim perlu berkolaborasi lebih banyak. Bertemu lebih sering. Lebih memahami satu sama lain. Maka: lebih banyak rapat, lebih banyak sesi penyelarasan, lebih banyak retrospektif bersama.
Saya telah mendengar saran itu berkali-kali. Dan saya telah melihat betapa sedikitnya yang berhasil diselesaikan secara struktural. Karena setahun kemudian, organisasi yang sama masih memiliki ketegangan yang sama — hanya sekarang dengan kalender yang lebih penuh.
Konsultasi lebih banyak tidak menyelesaikan apa pun ketika orang beroperasi dari logika yang secara fundamental berbeda. Mereka tidak saling berbicara karena tidak saling mengenal — tetapi karena mereka cukup memahami satu sama lain dan tetap tidak setuju tentang apa yang penting.
Saya mungkin melihat ini secara berbeda karena latar belakang saya. Selain pekerjaan saya di IT, saya belajar administrasi publik. Selama studi itu saya membaca Jane Jacobs dan bukunya Systems of Survival. Jacobs menggambarkan bagaimana masyarakat berfungsi dari dua sistem moral yang secara fundamental berbeda. Beberapa sistem berorientasi pada perlindungan, stabilitas, dan kontrol. Yang lain berorientasi pada perdagangan, inovasi, dan pergerakan. Keduanya diperlukan, tetapi mereka memandang risiko, tanggung jawab, dan perubahan secara fundamental berbeda.
Bertahun-tahun kemudian saya mulai melihat pola yang sama — pertama di organisasi IT, kemudian juga di lingkungan industri.
Keamanan siber, operasi, dan manajemen IT sebagian besar berfungsi dari logika protektif. Menjaga kelangsungan. Bertanggung jawab atas gangguan, insiden, dan ketersediaan. Dari perspektif itu, kehati-hatian adalah rasional. Kontrol adalah rasional. Standardisasi adalah rasional.
Tim pengembangan dan departemen inovasi sering berfungsi dari logika yang berlawanan. Memungkinkan perubahan. Dihargai karena kecepatan, fungsionalitas baru, dan pertumbuhan. Dari perspektif itu, tata kelola terasa seperti penundaan. Kontrol tambahan terasa seperti gesekan.
Dan tiba-tiba banyak perilaku mulai masuk akal bagi saya.
Pengembang yang frustrasi dengan prosedur perubahan tidak harus belum dewasa. Insinyur keamanan yang menuntut kontrol tambahan juga tidak secara otomatis birokratis. Tim-tim ini bertabrakan bukan karena orang sulit, tetapi karena mereka melayani logika moral yang berbeda.
Di lingkungan industri ketegangan itu menjadi lebih tajam
Seorang pengembang IT yang ingin men-deploy sesuatu bisa, paling buruk, melakukan rollback. Seorang operator proses di lantai produksi bekerja dengan instalasi fisik, sistem keselamatan, dan proses yang tidak bisa begitu saja di-restart. Pembaruan firmware pada PLC bukan tugas sprint — itu adalah perubahan dengan konsekuensi fisik yang berpotensi, di mana orang-orang di dekat instalasi memiliki kepentingan bahwa Anda berhati-hati.
Saya pernah bekerja di lingkungan semacam itu. Dan yang selalu mencolok bagi saya: ketegangan jarang terletak pada teknologi itu sendiri. Teknologi dapat diselesaikan. Ketegangan terletak pada jahitan — antarmuka antara sistem, antara tim, antara tanggung jawab.
Tetapi saya melihat dinamika yang sama di luar lingkungan teknis juga. Ketika saya terlibat dalam reformasi pendidikan berskala besar — model pedagogis baru, penilaian programatik, organisasi berbeda — saya mengenali pola yang persis sama. Guru yang menjaga kualitas dan kesinambungan pendidikan. Inovator yang menginginkan kecepatan karena dunia berubah dan pendidikan harus mengikuti. Dua kelompok dengan niat baik, tetapi dengan definisi keberhasilan yang secara fundamental berbeda. Dan ketegangan di sana juga bukan pada orangnya, melainkan pada jahitannya — tempat-tempat di mana jadwal, sistem penilaian, dan metode kerja tidak terhubung karena dirancang dari logika yang berbeda.
Itulah momen saya menyadari pola ini tidak spesifik sektor. Ini ada di setiap organisasi yang harus secara bersamaan melindungi sesuatu dan mengubah sesuatu.
Wawasan itu juga mengubah pandangan saya tentang arsitektur.
Banyak organisasi masih melihat arsitektur sebagai disiplin teknis: merancang sistem, menetapkan standar, memodelkan infrastruktur. Tetapi pertanyaan-pertanyaan tersulit jarang bersifat murni teknis.
Bagaimana Anda memberi pengembangan kecepatan yang cukup tanpa sepenuhnya melepaskan kendali? Bagaimana Anda mencegah keamanan menjadi rem inovasi? Bagaimana Anda melindungi stabilitas tanpa membuat setiap eksperimen menjadi tidak mungkin?
Ini pada akhirnya bukan pertanyaan murni teknis. Ini adalah pertanyaan tata kelola. Dan justru kombinasi itu — teknis dan tata kelola — yang saya anggap paling berharga dalam pekerjaan saya.
Mungkin itulah juga mengapa banyak transformasi DevOps dan DevSecOps terbukti lebih sulit dari yang diharapkan. Organisasi mencoba mendekatkan dua logika yang berbeda, tetapi memperlakukan ketegangan seolah-olah dapat sepenuhnya diselesaikan. Saya pikir itu adalah kesalahpahaman.
Organisasi yang sehat sebenarnya membutuhkan kedua sistem. Tanpa logika protektif, muncul kekacauan dan kerapuhan. Tanpa logika inovatif, muncul stagnasi dan hilangnya kemampuan adaptasi.
Tapi lalu bagaimana?
Jika konsultasi lebih banyak bukan solusinya, dan ketegangan melekat pada cara organisasi bekerja — apa yang Anda lakukan dengannya?
Jawaban saya adalah: perlakukan sebagai pertanyaan arsitektur, bukan pertanyaan proses.
Sebagian besar organisasi mencoba mengelola ketegangan dengan tata kelola yang lebih baik. Prosedur yang lebih jelas, dewan perubahan yang lebih cepat, lebih banyak disiplin di meja. Itu membantu secara marjinal. Masalah fundamental tetap ada: kontrol duduk sebagai gerbang setelah proses pengembangan, sehingga secara struktural terasa seperti rem.
Yang membantu adalah tiga prinsip yang terus saya lihat berhasil dalam praktik.
Rancang batasnya, bukan perilakunya. Berhentilah mencoba mengontrol apa yang terjadi di dalam tim atau sistem. Sebagai gantinya, kendalikan antarmuka — tempat-tempat di mana sistem dan tim saling bersentuhan. Di dalam batas itu: kebebasan. Melewati batas itu: tata kelola. Di lingkungan industri ini sudah menjadi praktik bertahun-tahun — zona dan conduit, ISA-95, model Purdue. Dunia IT dapat belajar lebih banyak dari itu daripada yang sering disadarinya.
Jadikan jalur aman juga jalur cepat. Jika opsi aman membutuhkan lebih banyak usaha daripada yang tidak aman, orang akan secara struktural memilih yang tidak aman. Bukan karena ketidakmauan, tetapi karena tekanan waktu. Solusinya bukan penegakan yang lebih ketat — melainkan menurunkan ambang batas untuk pilihan yang tepat. Infrastruktur yang telah disetujui sebelumnya, pemeriksaan otomatis, solusi standar yang dapat langsung diambil pengembang. Kebebasan tetap ada, tetapi gesekan ada di sisi yang tepat.
Bedakan berdasarkan risiko. Tidak setiap perubahan setara. Penyesuaian UI secara fundamental berbeda dari perubahan logika autentikasi atau pembaruan pada PLC yang mengontrol proses fisik. Organisasi yang memiliki satu proses perubahan untuk segalanya menciptakan frustrasi sendiri. Mereka yang menganggap serius risiko membuat perbedaan — dan memberi perubahan berisiko rendah ruang untuk bergerak cepat.
Prinsip menyeluruh di balik semua ini: Anda tidak menyelesaikan ketegangan antara perlindungan dan inovasi dengan mendekatkan orang. Anda menyelesaikannya dengan merancang arsitektur sehingga kecepatan dan keamanan tidak lagi saling berlawanan.
Itulah pada akhirnya yang dilakukan seorang arsitek. Bukan memilih antara dua logika — tetapi membangun lingkungan di mana keduanya dapat ada.