Studi kasus transisi sistem skala besar dan strategi pemisahan

baeba · 2025-05-13T10:00:11+09:00

Poin Penting Transisi berhasil diwujudkan melalui pemisahan bertahap tanpa harus mengganti seluruh sistem lama sekaligus. Sistem data real-time berbasis CDC menggantikan akses langsung ke mainframe. GraphQL digunakan alih-alih REST untuk menghapus banyak lapisan BFF serta memperoleh fleksibilitas dan kemudahan pemeliharaan. Struktur tim berpusat pada domain (Team Topologies) memperjelas tanggung jawab dan kepemilikan tim. Melalui deployment bertahap dan otomatisasi, sistem dapat ditransisikan tanpa risiko dan nilai dapat disampaikan secara stabil. Contoh penerapan: separuh sistem tetap bertahan bahkan saat terjadi gangguan Gangguan pada mainframe sempat terjadi, tetapi UI baru tetap berfungsi normal berkat arsitektur streaming berbasis cloud. Meski sistem lama down, sistem baru tetap menjaga pengalaman pelanggan dan membuktikan resiliensinya. Strategi inti: pemisahan berlapis (Decoupling) Domain-Driven Design (DDD): membangun ulang model yang berpusat pada mainframe agar lebih ramah terhadap bisnis Team Topologies: beralih ke organisasi tim yang berpusat pada fungsi Arsitektur berbasis event: mengurangi coupling antar sistem dengan pendekatan asinkron Change Data Capture (CDC): mendeteksi perubahan data secara real-time untuk menghubungkan sistem lama dan sistem baru Struktur sebelumnya: Unified Web Portal 1.0 Berbagai data mainframe diintegrasikan melalui ETL lalu disediakan lewat SQL DB dan SaaS, namun muncul masalah seperti kurangnya real-time, penurunan kualitas data, dan pemanggilan langsung ke mainframe. Permasalahan Keterlambatan data akibat ETL Koneksi sinkron ke mainframe yang tidak elastis Terlalu banyak API BFF yang harus dibuat Bottleneck dan keterlambatan rilis akibat struktur organisasi Saat trafik melonjak, beban berlebih pada mainframe memicu gangguan pada seluruh layanan Penetapan tujuan baru Tujuan teknis: memisahkan mainframe dan web, menghapus BFF, dan memastikan otonomi tim Tujuan bisnis: mengurangi pertanyaan ke call center, menekan biaya lisensi, dan meningkatkan kepuasan pelanggan Gambaran arsitektur baru Mainframe tetap menjadi system of record CDC → Kafka → domain DB (CosmosDB) GraphQL + REST API → BFF → UI Semua komponen dihubungkan melalui struktur berbasis event dan message broker Langkah 1: Change Data Capture Membangun system of reference melalui streaming data real-time Mainframe → Kafka → transformasi → domain DB → disajikan melalui API Memperoleh struktur data yang fleksibel tanpa bergantung pada skema mainframe Langkah 2: Domain-Driven Design + GraphQL Mendefinisikan model domain dengan DDD (Entity, Command, Event) Tiap domain disusun sebagai node GraphQL, lalu supergraph dibangun melalui schema stitching Mendukung struktur kueri optimal yang hanya mengambil data yang dibutuhkan Perubahan struktur organisasi: Team Topologies Ditata ulang menjadi stream-aligned team yang berpusat pada fungsi Area kompleks (misalnya integrasi mainframe) dikelola oleh tim khusus Tim Enablement dioperasikan untuk dukungan teknis Ekspansi berbasis event: event domain internal + pola saga Event dipicu saat terjadi perubahan domain melalui pola Outbox Parallel Saga menyinkronkan pekerjaan mainframe dan CDC Workflow berbasis state machine dibangun untuk menangani alur yang kompleks Tantangan Perlu perubahan cara pandang di dalam organisasi terhadap penerapan struktur berbasis event Observabilitas menjadi keharusan karena struktur asinkron Pekerjaan batch mainframe → memicu beban berlebih pada pipeline CDC Kompleksitas pengelolaan schema GraphQL serta pertimbangan adopsi federated approach Concern lintas sistem seperti autentikasi/logging dikelola lewat paket terpisah dan otomatisasi Strategi rilis: release train + Feature Flag Tiap tim melakukan deployment secara independen, lalu diintegrasikan di repositori deployment Pipeline deployment per lingkungan dibangun dengan Kustomize Feature flag memisahkan rilis fitur dan keamanan, sambil mempertahankan pengembangan trunk-based Penerapan arsitektur hibrida UWP 1.0 dan UWP 2.0 dibuat hidup berdampingan sambil menjalankan transisi bertahap Routing di edge mengalihkan permintaan pengguna ke sistem baru secara bertahap Kesimpulan: membangun platform yang dapat berevolusi Pemisahan penuh antara frontend dan mainframe Struktur berpusat pada tim untuk memperoleh kecepatan dan stabilitas Peningkatan kepuasan pelanggan dan efisiensi biaya operasional Fondasi yang fleksibel, sehingga penggantian mainframe di masa depan pun dimungkinkan

(infoq.com)

9 poin oleh baeba 2025-05-13 | 1 komentar | Bagikan ke WhatsApp

Poin Penting

Transisi berhasil diwujudkan melalui pemisahan bertahap tanpa harus mengganti seluruh sistem lama sekaligus.
Sistem data real-time berbasis CDC menggantikan akses langsung ke mainframe.
GraphQL digunakan alih-alih REST untuk menghapus banyak lapisan BFF serta memperoleh fleksibilitas dan kemudahan pemeliharaan.
Struktur tim berpusat pada domain (Team Topologies) memperjelas tanggung jawab dan kepemilikan tim.
Melalui deployment bertahap dan otomatisasi, sistem dapat ditransisikan tanpa risiko dan nilai dapat disampaikan secara stabil.

Contoh penerapan: separuh sistem tetap bertahan bahkan saat terjadi gangguan

Gangguan pada mainframe sempat terjadi, tetapi UI baru tetap berfungsi normal berkat arsitektur streaming berbasis cloud.
Meski sistem lama down, sistem baru tetap menjaga pengalaman pelanggan dan membuktikan resiliensinya.

Strategi inti: pemisahan berlapis (Decoupling)

Domain-Driven Design (DDD): membangun ulang model yang berpusat pada mainframe agar lebih ramah terhadap bisnis
Team Topologies: beralih ke organisasi tim yang berpusat pada fungsi
Arsitektur berbasis event: mengurangi coupling antar sistem dengan pendekatan asinkron
Change Data Capture (CDC): mendeteksi perubahan data secara real-time untuk menghubungkan sistem lama dan sistem baru

Struktur sebelumnya: Unified Web Portal 1.0

Berbagai data mainframe diintegrasikan melalui ETL lalu disediakan lewat SQL DB dan SaaS,
namun muncul masalah seperti kurangnya real-time, penurunan kualitas data, dan pemanggilan langsung ke mainframe.

Permasalahan

Keterlambatan data akibat ETL
Koneksi sinkron ke mainframe yang tidak elastis
Terlalu banyak API BFF yang harus dibuat
Bottleneck dan keterlambatan rilis akibat struktur organisasi
Saat trafik melonjak, beban berlebih pada mainframe memicu gangguan pada seluruh layanan

Penetapan tujuan baru

Tujuan teknis: memisahkan mainframe dan web, menghapus BFF, dan memastikan otonomi tim
Tujuan bisnis: mengurangi pertanyaan ke call center, menekan biaya lisensi, dan meningkatkan kepuasan pelanggan

Gambaran arsitektur baru

Mainframe tetap menjadi system of record
CDC → Kafka → domain DB (CosmosDB)
GraphQL + REST API → BFF → UI
Semua komponen dihubungkan melalui struktur berbasis event dan message broker

Langkah 1: Change Data Capture

Membangun system of reference melalui streaming data real-time
Mainframe → Kafka → transformasi → domain DB → disajikan melalui API
Memperoleh struktur data yang fleksibel tanpa bergantung pada skema mainframe

Langkah 2: Domain-Driven Design + GraphQL

Mendefinisikan model domain dengan DDD (Entity, Command, Event)
Tiap domain disusun sebagai node GraphQL, lalu supergraph dibangun melalui schema stitching
Mendukung struktur kueri optimal yang hanya mengambil data yang dibutuhkan

Perubahan struktur organisasi: Team Topologies

Ditata ulang menjadi stream-aligned team yang berpusat pada fungsi
Area kompleks (misalnya integrasi mainframe) dikelola oleh tim khusus
Tim Enablement dioperasikan untuk dukungan teknis

Ekspansi berbasis event: event domain internal + pola saga

Event dipicu saat terjadi perubahan domain melalui pola Outbox
Parallel Saga menyinkronkan pekerjaan mainframe dan CDC
Workflow berbasis state machine dibangun untuk menangani alur yang kompleks

Tantangan

Perlu perubahan cara pandang di dalam organisasi terhadap penerapan struktur berbasis event
Observabilitas menjadi keharusan karena struktur asinkron
Pekerjaan batch mainframe → memicu beban berlebih pada pipeline CDC
Kompleksitas pengelolaan schema GraphQL serta pertimbangan adopsi federated approach
Concern lintas sistem seperti autentikasi/logging dikelola lewat paket terpisah dan otomatisasi

Strategi rilis: release train + Feature Flag

Tiap tim melakukan deployment secara independen, lalu diintegrasikan di repositori deployment
Pipeline deployment per lingkungan dibangun dengan Kustomize
Feature flag memisahkan rilis fitur dan keamanan, sambil mempertahankan pengembangan trunk-based

Penerapan arsitektur hibrida

UWP 1.0 dan UWP 2.0 dibuat hidup berdampingan sambil menjalankan transisi bertahap
Routing di edge mengalihkan permintaan pengguna ke sistem baru secara bertahap

Kesimpulan: membangun platform yang dapat berevolusi

Pemisahan penuh antara frontend dan mainframe
Struktur berpusat pada tim untuk memperoleh kecepatan dan stabilitas
Peningkatan kepuasan pelanggan dan efisiensi biaya operasional
Fondasi yang fleksibel, sehingga penggantian mainframe di masa depan pun dimungkinkan

1 komentar

mhj5730 2025-05-13

Perbaikan bertahap dan ekstraksi microservices secara bertahap memang sangat penting... melihat tulisan seperti ini membuat saya merasa bahwa PM yang memimpin proyek tersebut benar-benar sangat penting dan luar biasa. Mengelola sebanyak ini itu benar-benar gila.