Enterprise Software Modernization: Kapan Perusahaan Perlu Memodernisasi Sistem yang Sudah Ada?

Banyak perusahaan menghadapi dilema ketika sistem yang sudah digunakan selama bertahun-tahun mulai terasa tidak lagi sesuai dengan kebutuhan bisnis. Sistem tersebut mungkin masih berjalan, menyimpan business logic yang penting, dan menjadi bagian dari operasional sehari-hari, tetapi di sisi lain mulai sulit dikembangkan, sulit diintegrasikan dengan aplikasi baru, membutuhkan banyak pekerjaan manual, atau tidak mampu mengikuti kebutuhan bisnis yang semakin kompleks. Kondisi seperti ini sering memunculkan pertanyaan: apakah perusahaan harus mengganti sistem lama dengan sistem baru, atau cukup memodernisasinya? Dalam konteks enterprise, jawabannya tidak selalu berupa replacement. Enterprise software modernization merupakan pendekatan untuk memperbarui aplikasi, architecture, code, integration, maupun infrastructure yang sudah ada agar dapat memenuhi kebutuhan bisnis saat ini dan mendukung pengembangan di masa depan. IBM mendefinisikan application modernization sebagai proses mengubah sistem yang sudah ada menjadi aplikasi yang lebih modern, efisien, maintainable, dan scalable, dengan pendekatan yang dapat mencakup assessment, planning, implementation, testing, hingga monitoring. IBM — What Is Application Modernization?

Hal yang perlu dipahami adalah bahwa usia sebuah sistem tidak otomatis menentukan apakah sistem tersebut sudah harus diganti. Sebuah aplikasi yang berusia sepuluh tahun dapat tetap memberikan business value apabila architecture-nya stabil, security-nya terkelola, performanya memadai, dan masih mampu mendukung kebutuhan bisnis. Sebaliknya, sistem yang relatif lebih baru dapat menjadi technical constraint apabila dibangun tanpa mempertimbangkan scalability, integration, maintainability, atau perubahan kebutuhan bisnis. Karena itu, keputusan modernisasi sebaiknya tidak didasarkan pada umur software semata, tetapi pada kemampuan sistem dalam mendukung arah bisnis, kemampuan berintegrasi dengan ecosystem teknologi, risiko operasional, technical debt, dan biaya untuk mempertahankan kondisi saat ini.

Modernisasi bukan berarti membuang sistem lama. Modernisasi berarti memperbaiki kemampuan sistem agar tetap relevan terhadap kebutuhan bisnis yang terus berubah.

Mengapa Sistem yang Dulu Cukup Bisa Menjadi Hambatan?

Sistem enterprise biasanya tidak berubah dalam satu waktu. Sistem dibangun, kemudian mendapatkan fitur baru, integrasi baru, database tambahan, customization, dan berbagai workaround untuk memenuhi kebutuhan yang muncul selama bertahun-tahun. Setiap perubahan mungkin masuk akal ketika dibuat, tetapi akumulasi perubahan tersebut dapat menghasilkan architecture yang semakin kompleks. Business logic dapat tersebar di berbagai modul, dokumentasi tidak lagi lengkap, dependency antarsistem menjadi sulit dipahami, dan perubahan kecil membutuhkan effort yang semakin besar.

IBM menjelaskan bahwa legacy applications sering menjadi hambatan bagi organisasi karena outdated technology dan architecture dapat mengurangi kemampuan perusahaan dalam merespons perubahan kebutuhan bisnis sekaligus meningkatkan security dan operational risk. IBM — What Is Legacy Application Modernization? Dalam kondisi seperti ini, persoalannya bukan semata-mata bahwa teknologi yang digunakan sudah lama, melainkan bahwa sistem tersebut mulai membatasi kemampuan perusahaan untuk berubah.

Misalnya, perusahaan ingin menambahkan customer portal baru yang membutuhkan akses real-time terhadap data dari existing ERP. Jika ERP tidak mempunyai API yang memadai dan data hanya dapat diakses melalui proses batch atau mekanisme lama, project customer portal akan membutuhkan workaround tambahan. Jika kondisi serupa terjadi pada beberapa aplikasi lain, setiap innovation initiative akhirnya membawa integration complexity sendiri.

Pada titik tersebut, modernization bukan lagi sekadar agenda IT. Modernization menjadi bagian dari kemampuan perusahaan untuk menjalankan strategi bisnis.

7 Tanda Sistem Enterprise Mulai Membutuhkan Modernisasi

Tidak semua perusahaan membutuhkan modernization program besar. Namun, ada beberapa indikator yang dapat digunakan untuk menilai apakah existing software mulai menjadi constraint.

1. Setiap Perubahan Membutuhkan Waktu yang Semakin Lama

Salah satu tanda paling jelas adalah ketika perubahan sederhana pada aplikasi membutuhkan waktu yang tidak proporsional. Penambahan satu fitur dapat memengaruhi banyak modul, membutuhkan regression testing yang panjang, atau harus melibatkan banyak dependency yang sulit dipetakan.

Masalah ini sering terjadi pada aplikasi yang telah berkembang secara incremental selama bertahun-tahun. AWS menjelaskan bahwa legacy applications dapat memiliki tightly coupled dependencies, dokumentasi yang terbatas, dan business logic yang tersebar di berbagai bagian codebase, sehingga proses memahami sistem sebelum melakukan perubahan menjadi semakin sulit. AWS — Codebase Analysis for Modernization

Jika development team semakin banyak menghabiskan waktu untuk memahami bagaimana sistem bekerja daripada membangun capability baru, perusahaan perlu mulai mengevaluasi architecture-nya.

2. Sistem Sulit Terhubung dengan Aplikasi Baru

Modern enterprise jarang menggunakan satu aplikasi saja. CRM perlu berkomunikasi dengan ERP. E-commerce perlu terhubung dengan inventory. HRIS perlu terhubung dengan payroll. Customer service membutuhkan customer dan transaction data.

Ketika existing system tidak mempunyai interface yang baik, integration dapat berubah menjadi proyek tersendiri setiap kali perusahaan ingin menambahkan aplikasi baru.

Idealnya, existing system dapat mengekspos business capability melalui API atau integration layer yang terkontrol. Dengan demikian, aplikasi baru tidak perlu mengetahui detail internal sistem lama.

Crocodic menggunakan pendekatan serupa dalam layanan Enterprise System Upgrade, yaitu meningkatkan sistem yang sudah berjalan dengan memperkuat scalability, multi-user capability, dan API integration tanpa harus selalu membangun ulang sistem dari awal.

3. Proses Manual Terus Bertambah di Sekitar Sistem

Kadang masalah bukan terlihat dari aplikasi utama, tetapi dari pekerjaan yang dilakukan manusia setelah menggunakan aplikasi.

Contohnya, employee harus:

Export data → Edit Excel → Kirim email → Menunggu approval → Input kembali ke sistem

Aplikasi sebenarnya berjalan, tetapi workflow di sekitarnya masih manual.

Jika kondisi tersebut terjadi pada proses yang memiliki volume tinggi, perusahaan mungkin tidak membutuhkan aplikasi baru. Yang dibutuhkan bisa berupa workflow modernization, integration, atau automation.

Inilah alasan assessment modernization sebaiknya tidak hanya melihat source code, tetapi juga melihat business process yang menggunakan aplikasi tersebut.

4. Sistem Tidak Mampu Mengikuti Pertumbuhan Volume

Aplikasi yang dibangun untuk 100 pengguna mungkin bekerja dengan baik ketika perusahaan masih kecil. Ketika jumlah user, transaction, data, atau business unit bertambah, architecture yang sama dapat mulai mengalami performance bottleneck.

Gejalanya dapat berupa response time yang meningkat, downtime ketika traffic tinggi, proses batch semakin lama, atau kebutuhan infrastructure yang meningkat secara tidak efisien.

Microsoft menjelaskan bahwa application modernization dapat membantu meningkatkan performance, scalability, security, dan kesiapan aplikasi terhadap kebutuhan seperti cloud computing dan AI adoption. Microsoft Azure — What Is Application Modernization?

Namun, scaling problem tidak selalu berarti harus mengganti aplikasi. Assessment perlu menentukan apakah bottleneck berada pada code, database, infrastructure, architecture, integration, atau cara aplikasi tersebut digunakan.

5. Sistem Sulit Mendukung AI dan Analytics

AI membuat kebutuhan modernization menjadi semakin terlihat.

Perusahaan mungkin ingin membuat AI assistant yang dapat menjawab pertanyaan berdasarkan data internal. Tetapi existing system mungkin:

• tidak mempunyai API,
• data tersebar di beberapa database,
• business logic berada di dalam aplikasi monolithic,
• access control belum granular,
• atau tidak tersedia mekanisme audit yang memadai.

Dalam kondisi tersebut, AI project dapat terhambat bukan karena model AI, tetapi karena existing application architecture belum siap menyediakan data dan capability yang dibutuhkan.

Modernization kemudian dapat menjadi cara untuk membuat existing system lebih accessible dan interoperable tanpa harus mengganti seluruh core application.

IBM juga menempatkan application modernization sebagai bagian penting dari upaya organisasi dalam memanfaatkan hybrid cloud, AI, meningkatkan productivity, dan mengurangi technical debt. IBM — Application Modernization Services

6. Biaya Maintenance Terus Meningkat

Maintenance cost tidak selalu terlihat sebagai satu angka besar. Biayanya dapat tersebar dalam bentuk developer hours, infrastructure, vendor support, operational workaround, testing, incident handling, dan opportunity cost karena tim tidak memiliki cukup waktu untuk membangun capability baru.

Karena itu, perusahaan sebaiknya tidak hanya bertanya:

“Berapa biaya mengganti sistem?”

Tetapi juga:

“Berapa biaya mempertahankan sistem dalam kondisi sekarang selama tiga sampai lima tahun ke depan?”

AWS menyarankan agar modernization dinilai berdasarkan business objectives, termasuk cost, efficiency, dan pemanfaatan existing investment, bukan hanya karena teknologi yang digunakan sudah dianggap tua. AWS — Ten Steps to Modernizing Legacy Monoliths

Dengan membandingkan cost of modernization dan cost of doing nothing, keputusan menjadi lebih objektif.

7. Tim IT Semakin Sulit Memelihara Sistem

Technology stack yang sudah terlalu tua dapat menciptakan dependency terhadap orang tertentu. Hanya beberapa developer yang memahami sistem secara mendalam, dokumentasi tidak lengkap, dan knowledge sulit ditransfer ke anggota team baru.

Ini menjadi operational risk ketika key person meninggalkan perusahaan.

Modernization dapat digunakan untuk mengurangi dependency tersebut melalui documentation, refactoring, modularization, API exposure, automated testing, dan architecture improvement.

Jadi modernization bukan hanya tentang membuat software lebih modern secara teknis, tetapi juga membuat knowledge dan maintenance capability perusahaan lebih sustainable.

Apakah Semua Legacy System Harus Diganti?

Tidak.

Ini salah satu prinsip paling penting dalam enterprise software modernization.

Sistem lama dapat dikategorikan berdasarkan business value dan technical condition. Sistem yang masih strategic dan stabil mungkin cukup dipertahankan. Sistem yang masih valuable tetapi sulit terhubung dapat diperkuat melalui integration. Sistem yang architecture-nya mulai menjadi constraint dapat direfactor atau direarchitect. Sedangkan sistem yang sudah tidak memberikan business value dan terlalu mahal untuk dipertahankan dapat dipertimbangkan untuk diganti.

Secara sederhana:

Pendekatan seperti ini membantu perusahaan menghindari keputusan ekstrem berupa replace everything.

IBM juga menguraikan beberapa strategi modernization, mulai dari rehosting, refactoring, replatforming, re-architecting, hingga rebuilding atau replacement, dengan pilihan yang bergantung pada kondisi aplikasi, budget, dan business objectives. IBM — Legacy Application Modernization Strategies

Strategi Enterprise Software Modernization yang Bisa Dipilih

Tidak ada satu strategi yang cocok untuk semua aplikasi. Setiap sistem membutuhkan pendekatan berdasarkan kondisi dan tujuan bisnisnya.

Rehosting

Aplikasi dipindahkan ke environment baru dengan perubahan minimal pada code. Pendekatan ini dapat digunakan ketika perusahaan ingin memindahkan workload dengan cepat, tetapi belum ingin melakukan perubahan architecture yang besar.

Replatforming

Aplikasi dipindahkan ke platform yang lebih modern dengan beberapa perubahan agar dapat memanfaatkan kemampuan platform baru.

Refactoring

Code diperbaiki dan disusun ulang tanpa mengubah business functionality utama. Tujuannya biasanya meningkatkan maintainability, performance, atau reliability.

Re-architecting

Architecture aplikasi diubah secara lebih fundamental. Misalnya aplikasi monolithic secara bertahap dipisahkan berdasarkan business capability.

Rebuilding

Aplikasi dibangun ulang ketika architecture lama sudah terlalu sulit dipertahankan atau tidak lagi mampu memenuhi kebutuhan bisnis.

Replacing

Aplikasi digantikan dengan solusi lain, termasuk commercial software atau SaaS, ketika replacement memberikan business value yang lebih baik daripada mempertahankan existing application.

Pilihan tersebut sebaiknya ditentukan setelah assessment, bukan sebelum assessment.

Modernisasi Tidak Harus Dilakukan Sekaligus

Untuk sistem yang sangat critical, pendekatan big-bang modernization dapat memiliki risiko tinggi. Perusahaan mungkin tidak dapat menghentikan operational system hanya untuk mengganti seluruh architecture sekaligus.

Pendekatan incremental dapat menjadi alternatif.

AWS, misalnya, menjelaskan penggunaan pendekatan bertahap untuk modernisasi legacy monolith, termasuk memecah modernization berdasarkan business process atau business capability sehingga existing dan modernized components dapat berjalan berdampingan selama masa transisi. AWS — Modernizing Legacy Monoliths

Gambaran sederhananya:

Existing System

↓

Identify Critical Capability

↓

Build Modern Component

↓

Integrate with Existing System

↓

Move Functionality Gradually

↓

Retire Old Component

Pendekatan tersebut memungkinkan perusahaan mempertahankan continuity sambil secara bertahap mengurangi dependency terhadap sistem lama.

Contoh: Memodernisasi ERP Tanpa Mengganti ERP

Bayangkan sebuah perusahaan memiliki ERP yang sudah digunakan selama bertahun-tahun. ERP masih menjadi system of record untuk finance dan inventory, sehingga menggantinya secara total memiliki risiko besar.

Namun perusahaan mulai mengalami beberapa masalah:

ERP sulit diintegrasikan dengan aplikasi baru.

User membutuhkan export data manual.

Reporting membutuhkan proses tambahan.

Customer portal membutuhkan data real-time.

AI assistant tidak dapat mengakses data dengan cara yang aman.

Dalam situasi seperti ini, modernization tidak harus dimulai dengan mengganti ERP.

Architecture dapat dikembangkan menjadi:

ERP Existing

→ API / Integration Layer

→ Modern Applications

→ Data Platform

→ Analytics & AI

Dengan pendekatan tersebut, ERP tetap menjalankan fungsi core-nya sementara capability baru dibangun di sekitarnya.

Ini merupakan contoh brownfield modernization: memperbaiki dan mengembangkan landscape teknologi yang sudah ada daripada selalu memulai dari greenfield.

Dari Legacy Application ke Connected Enterprise

Modernization menjadi semakin menarik ketika dikombinasikan dengan integration.

Sebuah aplikasi lama mungkin awalnya berdiri sendiri:

Legacy Application

Namun setelah modernization:

Legacy Core → API → Integration Layer → Modern Applications

Kemudian data dapat digunakan oleh:

Analytics → Dashboard → Automation → AI

Architecture tersebut memungkinkan existing investment tetap digunakan sambil membuka ruang untuk capability baru.

Dalam konteks ini, modernization tidak hanya membuat aplikasi lebih modern. Modernization dapat mengubah peran aplikasi lama dalam enterprise architecture.

Sistem yang sebelumnya menjadi closed application dapat berubah menjadi salah satu core services dalam connected enterprise.

Kapan Modernisasi Lebih Baik daripada Replacement?

Pertanyaan ini penting karena replacement sering terlihat lebih sederhana di awal.

Modernization cenderung menarik ketika existing system masih mempunyai business logic yang sangat penting, data historis yang bernilai, integration dengan banyak systems, customization yang telah disesuaikan dengan proses perusahaan, atau operational dependency yang membuat replacement berisiko.

Sebaliknya, replacement dapat lebih masuk akal jika application sudah tidak mampu memenuhi kebutuhan fundamental, technology stack tidak lagi sustainable, business process telah berubah secara signifikan, atau terdapat solusi baru yang mampu memberikan capability lebih baik dengan total cost dan risk yang lebih rendah.

Keputusan seharusnya tidak dibuat berdasarkan preferensi terhadap teknologi tertentu.

Gunakan pertanyaan:

Business Value + Technical Condition + Cost + Risk + Future Requirement

Jika hasil assessment menunjukkan bahwa business value existing system masih tinggi tetapi technical condition membutuhkan improvement, modernization dapat menjadi pilihan yang lebih rasional.

Modernization Assessment: Apa yang Perlu Diperiksa?

Sebelum melakukan perubahan, perusahaan sebaiknya membuat baseline kondisi existing system.

Assessment dapat mencakup:

Business Assessment

Apakah aplikasi masih mendukung proses bisnis utama?

Application Assessment

Bagaimana struktur aplikasi, module, dependency, dan maintainability?

Technology Assessment

Apakah technology stack masih sustainable dan supported?

Data Assessment

Bagaimana database, data quality, ownership, dan accessibility?

Integration Assessment

Bagaimana aplikasi terhubung dengan sistem lain?

Security Assessment

Apakah authentication, authorization, encryption, dan monitoring sudah memadai?

Infrastructure Assessment

Apakah infrastructure mampu mendukung scalability dan availability yang dibutuhkan?

Operational Assessment

Berapa banyak pekerjaan manual dan workaround yang bergantung pada aplikasi?

AI Readiness Assessment

Apakah sistem sudah mampu menyediakan data dan business capabilities untuk AI?

Hasil assessment kemudian dapat digunakan untuk menentukan apakah application perlu keep, integrate, modernize, atau replace.

Modernization Roadmap yang Lebih Aman

Untuk sistem enterprise yang critical, roadmap dapat dibuat secara bertahap.

Phase 1 — Assess

Petakan application, architecture, data, integration, process, dependency, dan technical debt.

Phase 2 — Prioritize

Tentukan bagian yang paling memberikan business impact atau paling besar menjadi constraint.

Phase 3 — Stabilize

Perbaiki reliability, security, observability, testing, dan operational issue yang kritis.

Phase 4 — Integrate

Bangun API atau integration layer untuk menghubungkan existing system dengan ecosystem baru.

Phase 5 — Modernize

Refactor, replatform, rearchitect, atau rebuild component yang memang membutuhkan perubahan.

Phase 6 — Automate & Enable AI

Setelah foundation cukup siap, tambahkan workflow automation, analytics, AI assistant, predictive capability, atau AI agents sesuai use case.

Phase 7 — Scale

Gunakan architecture pattern yang sudah terbukti untuk modernization pada application atau business unit berikutnya.

Pendekatan seperti ini lebih realistis dibandingkan mencoba menyelesaikan seluruh legacy landscape dalam satu project.

Apa Hubungannya dengan AI?

AI membuat modernization menjadi semakin strategis karena AI membutuhkan application dan data environment yang dapat menyediakan context, access, dan business capability secara aman.

Bayangkan AI agent perlu memeriksa status customer, inventory, invoice, dan delivery. Jika setiap sistem tidak dapat berkomunikasi dengan baik, AI akan membutuhkan banyak workaround.

Sebaliknya, jika modernization telah menghasilkan:

Modern API

Structured Data Access

Clear Business Rules

Identity & Access Control

Observable Workflow

maka AI dapat ditempatkan di atas architecture tersebut.

Karena itu, perusahaan yang ingin membangun AI capability tidak selalu harus memulai dengan membangun sistem AI baru. Dalam beberapa kasus, memodernisasi sistem yang sudah ada justru menjadi langkah penting untuk membuat enterprise siap terhadap AI.

IBM juga menyoroti pendekatan brownfield modernization yang menggabungkan modernization existing applications dengan AI untuk membantu mengurangi technical debt dan meningkatkan kemampuan enterprise dalam mengembangkan sistem yang sudah ada. IBM — Brownfield Application Modernization

Bagaimana Menentukan Prioritas Modernisasi?

Jika perusahaan mempunyai puluhan aplikasi, tidak realistis untuk memodernisasi semuanya sekaligus. Buat prioritas berdasarkan kombinasi business criticality, technical risk, integration dependency, modernization effort, dan future value.

Contohnya:

Pendekatan ini membuat modernization menjadi portfolio decision, bukan keputusan teknis yang hanya dibuat oleh IT.

Indikator Keberhasilan Modernisasi

Modernization tidak seharusnya dinilai hanya dari apakah aplikasi baru sudah berhasil deploy.

Indikator yang lebih bermakna dapat berupa:

• waktu pengembangan fitur baru lebih cepat,
• integration dengan aplikasi lain lebih mudah,
• operational incident berkurang,
• system performance meningkat,
• scalability membaik,
• pekerjaan manual berkurang,
• data lebih mudah diakses secara terkontrol,
• security posture meningkat,
• maintenance effort menurun,
• atau AI dan automation dapat diimplementasikan pada workflow yang sebelumnya tidak memungkinkan.

AWS menekankan bahwa modernization yang baik seharusnya dikaitkan dengan tujuan bisnis seperti peningkatan agility, scalability, efficiency, dan pengurangan cost atau technical constraint, bukan sekadar perubahan teknologi. AWS — Strategy for Modernizing Applications

Dengan demikian, KPI modernization sebaiknya menghubungkan technical improvement → operational improvement → business outcome.

Modernization Bukan Project Sekali Jadi

Salah satu perubahan penting dalam cara perusahaan melihat modernization adalah menganggapnya sebagai continuous capability, bukan project yang selesai setelah aplikasi baru diluncurkan.

Technology terus berubah. Business requirement juga berubah. AI mempercepat perubahan tersebut.

Karena itu, architecture yang modern hari ini belum tentu menjadi architecture yang optimal beberapa tahun mendatang.

Pendekatan continuous modernization memungkinkan perusahaan melakukan improvement secara bertahap berdasarkan kebutuhan:

Monitor → Identify → Prioritize → Improve → Measure → Repeat

Dengan cara ini, perusahaan tidak perlu menunggu sistem menjadi terlalu tua sebelum melakukan modernization berikutnya.

AWS bahkan kini menggunakan konsep continuous modernization untuk menggambarkan pendekatan modernisasi yang berlangsung sepanjang lifecycle application, termasuk penggunaan automation dan AI untuk mempercepat berbagai aktivitas modernization. AWS — From Migration to Continuous Modernization

Kesimpulan: Pertahankan Nilai Lama, Bangun Kemampuan Baru

Pertanyaan “Apakah perusahaan harus mengganti sistem lama?” sebenarnya bukan pertanyaan pertama yang perlu dijawab ketika menghadapi legacy software.

Pertanyaan yang lebih penting adalah:

“Apa yang masih bernilai dari sistem ini, dan bagian mana yang mulai menghambat bisnis?”

Jika business logic, data, dan fungsi inti masih relevan, modernization dapat menjadi cara untuk mempertahankan investasi tersebut sambil memperbaiki scalability, integration, maintainability, security, dan kemampuan untuk mendukung teknologi baru.

Pendekatannya dapat berupa:

Keep → Integrate → Refactor → Replatform → Rearchitect → Rebuild → Replace

Tidak semua sistem harus melewati seluruh tahapan tersebut.

Bagi perusahaan yang sedang melakukan digital transformation, enterprise software modernization sebaiknya dipandang sebagai strategi untuk mengurangi technology constraint sekaligus membuka business capability baru. Existing system dapat tetap menjadi fondasi, sementara API, integration, modern applications, data platform, automation, dan AI dibangun secara bertahap di sekitarnya.

Dengan pendekatan tersebut, modernization tidak lagi menjadi proyek untuk sekadar membuat teknologi terlihat lebih baru. Tujuannya adalah membuat sistem perusahaan lebih mudah berkembang, lebih mudah terhubung, lebih aman, lebih scalable, dan lebih siap mendukung perubahan bisnis berikutnya.

Crocodic menerapkan prinsip “strengthen what exists, not start from scratch” melalui layanan Enterprise System Upgrade, terutama untuk perusahaan yang memiliki sistem existing yang masih penting tetapi mulai menghadapi keterbatasan scalability, integration, multi-user access, automation, maupun kebutuhan AI.

Pada akhirnya, keputusan terbaik bukan selalu membangun baru atau mempertahankan lama. Dalam banyak kasus enterprise, strategi yang lebih tepat adalah mempertahankan apa yang masih memberikan nilai, memodernisasi apa yang menjadi constraint, dan menghubungkannya dengan capability baru yang dibutuhkan bisnis.