Arsitektur Power Platform untuk Solusi Enterprise yang Kompleks bersama Ian Tweedie [MVP]

Microsoft Power Platform sering digambarkan sebagai platform low-code. Namun apa yang terjadi ketika aplikasi yang Anda bangun menjadi kritis bagi bisnis, sangat terintegrasi, dan terlalu kompleks untuk pendekatan sederhana yang berfokus pada maker?Dalam episode ini dari M365 FM, Mirko Peters berbincang dengan Power Platform Solution Architect Ian Tweedie tentang apa yang terjadi ketika Power Platform melampaui aplikasi low-code sederhana dan menjadi bagian dari arsitektur enterprise yang serius.

LOW-CODE TIDAK BERARTI ARSITEKTUR RENDAH
Power Platform dapat memberikan sebagian besar nilai bisnis dengan cepat, tetapi solusi enterprise hampir selalu memiliki kebutuhan yang melampaui kemampuan low-code standar.Ian menjelaskan mengapa low-code tidak boleh disamakan dengan no-code — dan mengapa prinsip arsitektur perangkat lunak tradisional tetap penting ketika membangun dengan Power Apps, Power Automate, Dataverse, custom connector, API, dan layanan Azure.

KETIKA POWER PLATFORM MENJADI PERANGKAT LUNAK ENTERPRISE
Tidak selalu ada batas yang jelas antara "low-code" dan "enterprise."Kompleksitas mulai meningkat ketika aplikasi melibatkan banyak alur pengguna, tim pengembang, integrasi, persyaratan keamanan, proses bisnis kritis, dan layanan yang saling terhubung.Pada titik itu, arsitektur menjadi esensial.Ian menjelaskan mengapa solusi sebaiknya dibagi menjadi fitur dan modul yang terdefinisi dengan jelas serta memiliki antarmuka yang bersih, alih-alih menjadi satu aplikasi besar yang saling terhubung.

MENGATASI MASALAH PENGEMBANGAN "WHACK-A-MOLE"
Perbaiki satu bug, dan muncul bug lain di tempat lain.Masalah pengembangan yang familiar ini sering kali merupakan gejala dari arsitektur yang terlalu terikat satu sama lain (tightly coupled).Ian membahas bagaimana desain modular dapat mengisolasi fungsionalitas dan mengurangi ketergantungan yang tidak diinginkan. Dengan menggunakan pengiriman email sebagai contoh, ia menjelaskan bahwa memisahkan proses bisnis dari mekanisme pengiriman dapat membuat aplikasi lebih mudah diuji, dipelihara, diganti, dan diskalakan.

LOW-CODE + PRO-CODE = ARSITEKTUR HIBRIDA
Power Platform tidak harus bersaing dengan pengembangan perangkat lunak tradisional.Frontend Power Apps mungkin hanya merupakan sebagian kecil dari aplikasi yang jauh lebih besar yang menggunakan Azure, AWS, GCP, API, atau layanan kustom.Pertanyaan arsitektur yang penting bukanlah apakah sesuatu itu "low-code" atau "pro-code."Yang penting adalah teknologi mana yang paling sesuai untuk setiap fitur.

CITIZEN DEVELOPER, MAKER DAN ARSITEKTUR
Citizen developer membawa sesuatu yang sangat berharga: pengetahuan mendalam tentang proses bisnis yang mereka jalankan setiap hari.Namun keahlian bisnis tidak otomatis menghasilkan arsitektur aplikasi yang baik.Ian membahas keseimbangan antara memberdayakan maker dan menerapkan arsitektur, tata kelola, normalisasi, dan tinjauan teknis yang cukup untuk mencegah solusi menjadi sulit dipelihara.

TATA KELOLA TANPA MEMATIKAN INOVASI
Tata kelola yang terlalu longgar menciptakan kekacauan.Tata kelola yang terlalu ketat menciptakan gesekan — dan dapat mendorong karyawan ke solusi tidak resmi seperti spreadsheet, VBA, dan shadow IT.Tantangannya adalah menemukan tingkat tata kelola yang tepat berdasarkan risiko organisasi, tingkat kekritisan aplikasi, pengguna, dan dampak bisnis.

POWER PLATFORM, API DAN AZURE
Di mana logika bisnis sebaiknya berada?Apakah secret sebaiknya disimpan di dalam Power Platform? Kapan Azure Key Vault, Azure Functions, atau API Management menjadi bagian dari arsitektur?Ian menjelaskan mengapa arsitektur selalu harus dimulai dari masalah yang ingin diselesaikan, bukan menambahkan layanan Azure hanya karena tersedia.

GIT, KONTROL SUMBER DAN CI/CD
Seiring pengembangan Power Platform menjadi semakin kolaboratif, praktik pengembangan tradisional menjadi semakin relevan.Percakapan ini membahas Git, repositori, lingkungan pengembangan, pipeline, kontrol sumber, isolasi fitur, ketergantungan silang, dan CI/CD.Mungkin tidak selalu ada pendekatan yang sempurna untuk kontrol sumber di Power Platform — terkadang tujuannya adalah memilih "opsi yang paling tidak buruk" untuk proyek tersebut.

PLAYBOOK ARSITEKTUR POWER PLATFORM DARI IAN

Prinsip inti Ian sangat sederhana:Pecah solusi menjadi fitur dan modul.Setiap fitur sebaiknya memiliki alasan keberadaan yang jelas dan idealnya menjalankan satu tanggung jawab yang spesifik.Kemudian tentukan bagaimana fitur-fitur tersebut berkomunikasi, di mana logika harus dijalankan, bagaimana fitur tersebut diuji, dan teknologi mana yang paling sesuai untuk mengimplementasikannya.

BABAK TANYA JAWAB CEPAT
Mirko mengajukan serangkaian pertanyaan singkat kepada Ian:Apakah setiap aplikasi enterprise harus menggunakan Dataverse?Bisakah Power Platform membangun aplikasi kritis misi?Bisakah Power Automate menggantikan Logic Apps?Apakah low-code secara otomatis mengurangi technical debt?Bisakah Power Platform menggantikan pengembangan aplikasi tradisional?Dan mungkin yang paling penting: apa yang sebaiknya dipesan saat berkunjung ke Newcastle?

KESIMPULAN UTAMA
Low-code tidak berarti arsitektur rendah.Seiring solusi Power Platform menjadi lebih besar, lebih terhubung, dan lebih penting bagi bisnis, prinsip dasar rekayasa perangkat lunak tetap relevan.Arsitektur itu penting.Pemodelan data itu penting.Tata kelola itu penting.Keamanan itu penting.Desain API itu penting.DevOps itu penting.Dan pengembangan Power Platform enterprise yang sukses semakin bergantung pada pemahaman bagaimana low-code, pro-code, Azure, API, otomasi, dan praktik rekayasa perangkat lunak tradisional bekerja bersama-sama.

Jadilah pendukung podcast ini: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.