Perusahaan pada umumnya menjalankan beberapa ratus hingga beberapa ribu aplikasi, dan jumlahnya hampir selalu lebih tinggi daripada yang diyakini oleh pimpinan. Shadow IT, langganan SaaS departemen yang dibayar dengan kartu pengeluaran, serta sistem yang bertahan melewati suatu migrasi karena tidak ada yang yakin bahwa sistem itu sudah mati, semuanya menggelembungkan jumlah yang sebenarnya. Temuan pertama yang tidak nyaman dari hampir setiap tinjauan portofolio bukanlah bahwa aplikasinya sudah tua, melainkan bahwa tidak ada seorang pun yang mampu menghasilkan daftar aplikasi yang tepercaya, apalagi menyebutkan apa yang dikerjakan masing-masing aplikasi bagi bisnis.

Hal ini kini lebih penting daripada satu dekade lalu karena satu alasan spesifik: biaya marginal untuk memperoleh aplikasi baru telah anjlok. Ketika menambah kapabilitas berarti sebuah proyek modal, sebuah server, dan negosiasi lisensi, himpunan aset tumbuh perlahan dan penuh pertimbangan. Ketika hal itu cukup berarti seorang kepala departemen mendaftar ke sebuah layanan cloud dalam satu sore, pertumbuhannya menjadi terus-menerus dan tidak terkoordinasi. Himpunan aset berkembang lebih cepat daripada kemampuan fungsi pusat mana pun untuk memetakannya, dan tumpang tindih fungsional menjadi keadaan default alih-alih pengecualian. Dua tim menyelesaikan masalah yang sama dengan dua perangkat berbeda dan keduanya tidak mengetahui keberadaan satu sama lain.

Biayanya bukan hanya pengeluaran lisensi, meskipun pengeluaran ganda itu nyata dan sering kali material. Biaya yang lebih dalam adalah keterkaitan dan kerapuhan. Setiap aplikasi yang menyentuh data pelanggan adalah satu tempat lagi di mana data itu bisa menyimpang dari kesesuaian, satu integrasi lagi yang harus dipelihara, satu sistem lagi yang harus dipertimbangkan sebelum perubahan apa pun aman dilakukan. Himpunan aset yang tumbuh secara tak sengaja cenderung saling terhubung secara padat dan tak terlihat, sehingga upaya untuk mengubah apa pun berskala sebesar keseluruhannya, bukan sebesar perubahannya. Application architecture ada untuk membuat himpunan aset itu terbaca dan kemudian membentuknya kembali secara sengaja.

Prinsip pengorganisasian application architecture adalah bahwa aplikasi bukanlah objek utama. Kapabilitas bisnislah objek utamanya. Suatu kapabilitas adalah pernyataan stabil mengenai sesuatu yang harus mampu dilakukan organisasi, yang diungkapkan secara independen dari cara pelaksanaannya: mengelola hubungan pelanggan, menetapkan harga sebuah polis, menyelesaikan pembayaran, merencanakan produksi. Kapabilitas berubah perlahan karena menggambarkan bisnis itu sendiri. Aplikasi berubah terus-menerus karena merupakan implementasi. Menautkan arsitektur pada kapabilitas memberi Anda sistem koordinat yang bertahan lebih lama daripada sistem tertentu mana pun.

Terhadap sistem koordinat itu Anda membangun dua pandangan yang membuat suatu himpunan aset terbaca. Yang pertama adalah pemetaan kapabilitas ke aplikasi: untuk setiap kapabilitas, aplikasi mana yang mendukungnya, dan sejauh apa. Hal ini seketika memunculkan redundansi, di mana beberapa aplikasi mengaku memberikan kapabilitas yang sama, serta kesenjangan, di mana sebuah kapabilitas yang menjadi tumpuan bisnis ternyata hanya didukung oleh spreadsheet dan kebiasaan. Pandangan kedua adalah dekomposisi fungsional: memecah sebuah aplikasi menjadi balok-balok penyusun fungsional yang benar-benar disediakannya, sehingga sebuah sistem yang dijual sebagai satu paket tunggal dipahami sebagai delapan atau sepuluh layanan berbeda yang diberikannya, yang sebagian di antaranya tumpang tindih dengan layanan dari produk yang sama sekali berbeda.

Kedua pandangan ini mengubah perdebatan subjektif menjadi bukti. Ketika sebuah unit bisnis bersikeras perlu mempertahankan sebuah sistem, pertanyaannya menjadi presisi: kapabilitas mana yang didukungnya yang tidak didukung oleh yang lain, dan jika jawabannya tidak ada, maka percakapan bergeser dari sentimen ke pengurutan. Sebuah perangkat yang banyak digunakan untuk merangkai keputusan yang dihasilkan adalah disposition model, yang sering diungkapkan sebagai tolerate, invest, migrate dan eliminate. Setiap aplikasi diletakkan terhadap nilai bisnisnya sekaligus kesesuaian teknisnya, dan kuadran tempatnya jatuh menentukan niatnya: mengembangkannya, mempertahankannya, menggantinya, atau memensiunkannya. Nilai dari model ini bukan pada labelnya, melainkan pada disiplin memaksa setiap aplikasi untuk memiliki masa depan yang dinyatakan alih-alih masa depan yang default.

Dua kekuatan tengah membentuk ulang cara lanskap disusun. Yang pertama adalah pergeseran yang menentukan dari paket-paket terintegrasi berukuran besar menuju himpunan aset yang composable, yang dibangun dari potongan-potongan yang lebih kecil dan dapat diganti secara independen. Kosakatanya pun bergerak seiring: packaged business capabilities, composable ERP, dan gaya arsitektur yang lebih mengutamakan komponen yang dapat saling dipertukarkan ketimbang satu vendor yang menguasai seluruh domain. Niatnya sehat: mengurangi radius ledakan dari satu sistem mana pun dan mempertahankan pilihan untuk mengganti sebuah komponen tanpa mengganti segala sesuatu di sekitarnya. Composability adalah lindung nilai terhadap penggantian paket berisiko tinggi selama bertahun-tahun yang telah dialami sebagian besar organisasi setidaknya sekali dan tidak ingin mereka ulangi.

Kekuatan kedua adalah konsumerisasi pengadaan, yang telah mengubah sebaran SaaS menjadi masalah portofolio yang menentukan pada dekade ini. Himpunan aset kini tumbuh di tepi-tepinya, melalui banyak langganan kecil ketimbang sedikit penerapan besar, dan sebagian besarnya tak terlihat oleh arsitektur pusat hingga sebuah perpanjangan atau tinjauan keamanan menyingkapnya. Hasilnya adalah himpunan aset yang sekaligus lebih modular dan lebih terfragmentasi: lebih mudah ditambahi, lebih sulit dilihat secara utuh.

Composability juga memindahkan kompleksitas alih-alih menghilangkannya. Sebuah himpunan aset yang terdiri dari banyak komponen kecil yang saling dipertukarkan hanya sebaik integrasi dan arsitektur data yang mengikatnya, dan sebuah lanskap bisa saja mengurai sebuah monolit menjadi sistem terdistribusi yang lebih sulit dipahami daripada monolit itu sendiri. Karena itu, disiplin saat ini lebih tidak berkutat pada memilih modular di atas terintegrasi sebagai doktrin, dan lebih berkutat pada memutuskan, kapabilitas demi kapabilitas, di mana organisasi benar-benar memperoleh manfaat dari kemampuan penggantian yang independen dan di mana sebuah paket yang berbatas jelas adalah jawaban yang lebih jujur. Pandangan yang semakin matang memperlakukan composability sebagai sebuah perangkat yang berbiaya, bukan sebagai tujuan akhir.

Sebuah lanskap yang melayani kapabilitas dengan baik cenderung mematuhi sekumpulan kecil prinsip, dan prinsip-prinsip itu layak dinyatakan secara gamblang karena itulah yang membedakan himpunan aset yang dirancang dari yang bertumpuk. Yang pertama adalah kepemilikan fungsional tunggal: setiap kapabilitas seharusnya memiliki satu aplikasi yang otoritatif, dan setiap domain data yang signifikan satu sistem pencatat (system of record). Ini bukan berarti satu aplikasi per kapabilitas di mana-mana, yang tidak dapat dicapai maupun selalu diinginkan, tetapi ini berarti bahwa di mana pun terdapat duplikasi, itu merupakan pilihan yang disengaja dan terdokumentasi alih-alih kecelakaan yang tak disadari siapa pun.

Prinsip kedua adalah keterkaitan longgar dengan kohesi fungsional tinggi. Aplikasi seharusnya ditata sedemikian rupa sehingga hal-hal yang berubah bersama berdiam bersama, dan hal-hal yang berubah secara independen dipisahkan oleh antarmuka yang stabil dan eksplisit. Ukuran sebuah himpunan aset yang sehat bukanlah seberapa sedikit sistem yang dimilikinya, melainkan seberapa independen sistem-sistem itu dapat berubah. Sebuah himpunan aset di mana perubahan pada satu sistem memaksa perubahan terkoordinasi pada lima sistem lain memiliki keterkaitan tinggi, terlepas dari betapa modernnya komponen individualnya, dan keterkaitan, bukan usia, biasanya adalah sumber sesungguhnya dari kesan bahwa lanskap itu mustahil digerakkan.

Prinsip ketiga adalah bahwa integrasi merupakan arsitektur, bukan sekadar sambungan pipa. Cara aplikasi berbicara satu sama lain, melalui event, melalui layanan bersama, melalui lapisan data yang di-master, atau melalui antarmuka point-to-point yang rapuh yang dibangun satu per satu di tengah krisis, menentukan keterkaitan keseluruhannya. Sebuah lanskap yang dirangkai point-to-point menjadi sebuah jaring yang kompleksitasnya tumbuh sebesar kuadrat ukurannya. Prinsip keempat adalah bahwa setiap aplikasi harus memiliki tahap siklus hidup yang dinyatakan dan seorang pemilik yang disebut namanya. Sistem tanpa pemilik tidak dapat ditata kelola, dan sistem tanpa masa depan yang dinyatakan adalah sistem yang bertahan selamanya secara default. Pemensiunan, khususnya, adalah aktivitas rancangan: dekomisioning direncanakan sejak momen sebuah pengganti dipilih, dengan migrasi data, pelepasan keterkaitan antarmuka, dan pengarsipan diperlakukan sebagai pekerjaan kelas satu alih-alih pemikiran yang belakangan yang tak pernah benar-benar mendapatkan pendanaan.

Rasionalisasi sebagai latihan spreadsheet. Kegagalan yang paling umum adalah memperlakukan rasionalisasi sebagai penyapuan pemangkasan biaya sekali jalan: seorang konsultan menghasilkan sebuah daftar, sebuah target ditetapkan, beberapa duplikat yang jelas dipangkas, dan himpunan aset kembali bertumpuk pada hari proyek berakhir. Rasionalisasi adalah kapabilitas yang terus-menerus, bukan sebuah peristiwa. Tanpa seorang pemilik dan sebuah proses tetap, jumlahnya kembali seperti semula dalam beberapa tahun dan latihan itu harus dibayar ulang.

Pemensiunan yang tak pernah tuntas. Organisasi pandai membeli pengganti dan payah mematikan apa yang mereka gantikan. Sistem baru mengudara, sistem lama semestinya menyusul, dan bertahun-tahun kemudian sistem lama itu masih berjalan karena satu laporan, satu arsip kepatuhan, atau satu antarmuka yang membandel tak pernah dimigrasi. Himpunan aset berakhir memikul baik yang lama maupun yang baru, yang lebih buruk daripada salah satunya saja. Kegagalannya hampir selalu bahwa dekomisioning tak pernah didanai atau direncanakan sebagai pekerjaan yang nyata.

Build-versus-buy yang diputuskan oleh disposisi ketimbang kesesuaian. Beberapa organisasi membangun secara refleks karena rekayasa menginginkannya, yang lain membeli secara refleks karena pengadaan lebih mudah, dan keduanya memperlakukan sebuah keputusan arsitektur yang sesungguhnya sebagai default budaya. Kerangka yang benar bersifat sempit: bangun hanya di mana kapabilitas itu merupakan sumber diferensiasi yang sejati, dan beli di mana kapabilitas itu merupakan komoditas yang diselesaikan pasar dengan baik. Membangun kapabilitas komoditas adalah cara organisasi memperoleh sistem buatan khusus yang harus mereka pelihara selamanya tanpa keunggulan kompetitif apa pun.

Ketergantungan pada satu paket disalahartikan sebagai integrasi. Satu vendor yang mencakup banyak kapabilitas sering dijual sebagai himpunan aset yang terintegrasi, dan kadang memang benar-benar demikian. Namun integrasi yang dicapai dengan satu produk menguasai segalanya bukanlah arsitektur, melainkan ketergantungan, dan hal itu menghilangkan pilihan untuk mengganti bagian mana pun tanpa sebuah program. Mode kegagalannya adalah menemukan, pada saat perpanjangan, bahwa himpunan aset tidak memiliki daya tawar dan tidak memiliki jalan keluar. Tumpang tindih yang ditoleransi sebagai otonomi. Terakhir, tumpang tindih fungsional kerap dibela sebagai kemandirian unit bisnis. Kadang hal itu sah. Sering kali itu hanyalah duplikasi yang tak terkelola yang mengenakan bahasa pemberdayaan, dan itu bertahan karena tidak ada yang membuat biayanya terlihat.

Nashua memulai dengan membuat himpunan aset terbaca, karena tidak ada satu pun yang di hilir dapat dipertanggungjawabkan tanpa itu. Itu berarti membangun inventaris aplikasi yang tepercaya yang mencerminkan kenyataan alih-alih terakhir kali seseorang memperbarui sebuah spreadsheet, termasuk sistem shadow dan departemen yang terlewatkan oleh register formal. Setiap aplikasi kemudian dipetakan ke kapabilitas bisnis yang didukungnya dan diurai menjadi layanan fungsional yang benar-benar disediakannya, sehingga tumpang tindih dan redundansi berhenti menjadi anekdot dan menjadi bukti yang dapat Anda tunjuk.

Dari garis dasar itu, pekerjaan beralih ke disposisi. Nashua meletakkan setiap aplikasi terhadap nilai bisnisnya sekaligus kesesuaian teknis dan fungsionalnya, dan menetapkan niat yang dinyatakan: mempertahankan, berinvestasi, mengganti, atau memensiunkan. Ini dilakukan bersama bisnis, bukan terhadap bisnis, karena sebuah disposisi yang tidak diterima oleh fungsi pemiliknya adalah sebuah slide, bukan sebuah keputusan. Di mana niatnya adalah merasionalisasi, Nashua mengurutkan pekerjaan berdasarkan keterkaitan dan risiko alih-alih berdasarkan kemudahan, menangani duplikasi dan kekusutan point-to-point yang membuat himpunan aset mahal untuk diubah, serta memperlakukan dekomisioning sistem yang digantikan sebagai pekerjaan yang didanai dan direncanakan dengan migrasi data dan pelepasan keterkaitan antarmuka dilingkupi sejak awal.

Keputusan build-versus-buy dirangkai terhadap diferensiasi ketimbang preferensi. Nashua membantu membedakan segelintir kapabilitas di mana build buatan khusus mengganjar biaya pemeliharaan seumur hidupnya dari mayoritas kapabilitas di mana sebuah komponen paket yang berbatas jelas adalah pilihan yang jujur, dan merancang integrasi serta arsitektur data yang menjaga komponen-komponen itu tetap terkait longgar dan dapat diganti secara independen. Sepanjang prosesnya, penekanannya adalah menegakkan application portfolio management sebagai kapabilitas tetap dengan pemilik yang disebut namanya, siklus hidup yang dinyatakan, dan irama tinjauan yang dapat diulang, sehingga himpunan aset berhenti bertumpuk secara tak sengaja dan mulai berubah secara terancang. Hasil kerjanya bukanlah laporan sekali jalan, melainkan portofolio yang tertata kelola yang tetap terbaca setelah keterlibatan berakhir.

Perbedaan yang dibawa Nashua adalah penolakan untuk memperlakukan application architecture baik sebagai latihan biaya murni maupun latihan teknologi murni. Merasionalisasi sebuah himpunan aset mudah dijanjikan dan sulit dipertahankan, karena kekuatan yang membuatnya bertebaran, pengadaan yang mudah, otonomi lokal, dan keengganan mematikan apa pun, tidak berhenti pada hari sebuah target tercapai. Nashua bekerja untuk meninggalkan bukan sekadar potret yang lebih ramping, melainkan sebuah portofolio yang dapat terus ditata kelola oleh organisasi: kapabilitas terpetakan, disposisi dimiliki, keterkaitan dipahami, dan sebuah irama yang menangkap duplikasi tak sengaja berikutnya sebelum ia mengeras. Perpaduan antara ketelitian fungsional dan realisme organisasi itulah yang mengubah lanskap dari sesuatu yang menimpa sebuah organisasi menjadi sesuatu yang dapat diarahkannya.

Ada pula sebuah konsekuensi praktis yang mengubah apa yang boleh diasumsikan oleh pekerjaan ini. Ketika sebuah keterlibatan menuntut sebuah kapabilitas yang belum ada, ia tidak perlu menunggu siklus pengadaan atau peta jalan seorang vendor. enterprise platform dibangun untuk mengakomodasi hampir semua fitur dengan cepat, melalui agentic engineering: apa yang dibutuhkan dideskripsikan dalam bahasa sederhana dan dihasilkan dengan cepat, tetapi selalu di dalam prinsip-prinsip arsitektur yang kokoh dan di bawah jaminan mutu yang ketat, sehingga kecepatan tidak pernah mengorbankan koherensi, keamanan, atau kendali. Efeknya bersifat strategis alih-alih sekadar praktis. Ia menggeser garis make-or-buy, menjaga opsionalitas tetap murah, dan membiarkan arsitektur mengikuti strategi alih-alih strategi tertekuk mengikuti apa pun yang kebetulan tersedia di rak.

Yang secara konsisten membedakan hasilnya adalah bahwa Nashua memegang pandangan bisnis dan teknis bersama dalam satu percakapan. Sebuah disposition model hanya sebaik peta kapabilitas di bawahnya, sebuah peta kapabilitas hanya sebaik kejujuran inventaris di bawahnya, dan tak satu pun darinya bertahan setelah bersentuhan dengan organisasi kecuali fungsi-fungsi pemiliknya menerima keputusan dan tata kelola untuk mempertahankannya. Nashua menggarap keseluruhan rantai alih-alih mata rantai tunggal mana pun, itulah sebabnya himpunan aset yang dibantu dirancangnya cenderung tetap terancang, melayani kapabilitas yang benar-benar menjadi tumpuan bisnis alih-alih bertumpuk diam-diam hingga perhitungan menyakitkan berikutnya.