Rangkaian Arsitektur Perusahaan seperti TOGAF (The Open Group Architecture Framework) secara tradisional dikaitkan dengan perencanaan yang rinci, dokumentasi yang luas, dan visi jangka panjang. Metodologi Agile, sebaliknya, mengutamakan pengiriman iteratif, kemampuan beradaptasi, dan umpan balik pelanggan. Bagi banyak organisasi, mengintegrasikan dua pendekatan yang berbeda ini menciptakan ketegangan. Konflik yang dirasakan terletak pada ketegangan antara kebutuhan akan tata kelola arsitektur dan keinginan untuk iterasi yang cepat.
Panduan ini mengeksplorasi bagaimana organisasi dapat berhasil menerapkan prinsip-prinsip TOGAF dalam lingkungan Agile. Kami akan meninjau strategi praktis untuk menyelaraskan Metode Pengembangan Arsitektur (ADM) dengan siklus pengembangan iteratif, memastikan bahwa struktur mendukung fleksibilitas, bukan menghambatnya. Dengan memahami nuansa dari kedua kerangka kerja ini, para pemimpin dapat membangun sistem yang kokoh namun tetap responsif terhadap perubahan.
🧩 Memahami Kerangka Utama
Untuk mengintegrasikan secara efektif, kita harus terlebih dahulu memahami sifat dasar dari setiap pendekatan tanpa mengandalkan istilah-istilah populer.
🏛️ Metode Pengembangan Arsitektur TOGAF
TOGAF menyediakan pendekatan terstruktur untuk merancang, merencanakan, menerapkan, dan mengelola arsitektur informasi perusahaan. Inti dari kerangka kerja ini adalah siklus ADM, yang terdiri dari beberapa tahap:
- Tahap A: Visi Arsitektur – Menetapkan cakupan dan kebutuhan pemangku kepentingan.
- Tahap B: Arsitektur Bisnis – Menentukan strategi dan proses bisnis.
- Tahap C: Arsitektur Sistem Informasi – Meliputi arsitektur data dan aplikasi.
- Tahap D: Arsitektur Teknologi – Menentukan infrastruktur dan standar teknis.
- Tahap E: Peluang dan Solusi – Merencanakan peta jalan implementasi.
- Tahap F: Perencanaan Migrasi – Menyusun langkah-langkah transisi.
- Tahap G: Tata Kelola Implementasi – Memastikan solusi sesuai dengan desain.
- Tahap H: Manajemen Perubahan Arsitektur – Mengelola perubahan terhadap arsitektur.
Secara tradisional, siklus ini dipandang sebagai linier atau semi-linier, sering kali membutuhkan definisi yang lengkap sebelum implementasi dimulai. Di sinilah muncul ketegangan dengan Agile.
⚡ Pola Pikir Agile
Agile bukan sekadar sekumpulan praktik; ini adalah pola pikir yang berpusat pada Manifesto Agile. Prinsip-prinsip utama meliputi:
- Individu dan interaksi lebih penting daripada proses dan alat.
- Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang komprehensif.
- Kolaborasi dengan pelanggan lebih penting daripada negosiasi kontrak.
- Menanggapi perubahan lebih penting daripada mengikuti rencana.
Tim Agile biasanya bekerja dalam iterasi singkat (sprint) untuk menghasilkan peningkatan fungsional. Mereka mengandalkan umpan balik terus-menerus untuk menyesuaikan arah produk. Dalam konteks ini, rencana arsitektur yang kaku dapat memperlambat pengiriman nilai.
🤝 Tantangan Integrasi
Tantangan utama dalam menggabungkan TOGAF dan Agile adalah perbedaan dalam horizon waktu dan tingkat rincian perencanaan. TOGAF sering memandang tingkat perusahaan dalam jangka tahunan, sementara Agile beroperasi dalam minggu atau bulan. Jika arsitektur terlalu kaku, itu akan menghambat kemampuan tim untuk berpindah arah. Jika terlalu longgar, organisasi berisiko mengalami utang teknis dan fragmentasi.
Berikut adalah penjelasan mengenai di mana ketegangan biasanya terjadi:
| Aspek | Fokus TOGAF | Fokus Agile | Konflik Potensial |
|---|---|---|---|
| Perencanaan | Rencana jangka panjang | Daftar prioritas sprint jangka pendek | Seberapa banyak detail masa depan yang dibutuhkan? |
| Dokumentasi | Model komprehensif | Perangkat lunak yang berfungsi | Apakah beban dokumentasi tersebut dibenarkan? |
| Pengambilan Keputusan | Kepemimpinan terpusat | Pemilikan terdesentralisasi | Siapa yang menyetujui perubahan? |
| Perubahan | Evolusi terkendali | Adopsi yang dijalankan | Bagaimana mengelola penyimpangan? |
Mengenali perbedaan-perbedaan ini memungkinkan arsitek untuk merancang model hibrida yang menghargai kekuatan dari keduanya.
🔄 Menyesuaikan ADM untuk Siklus Agile
Metode Pengembangan Arsitektur tidak perlu ditinggalkan. Sebaliknya, dapat dibuat bersifat iteratif. Konsep ‘ADM iteratif’ memungkinkan pekerjaan arsitektur dilakukan bersamaan dengan pekerjaan pengembangan, bukan hanya sebelumnya secara keseluruhan.
🌱 Visi Arsitektur Iteratif
Fase A (Visi) tidak boleh menjadi kejadian satu kali. Dalam lingkungan Agile, visi diperlakukan sebagai dokumen hidup. Ia memberikan arah utama tetapi memungkinkan penyesuaian arah berdasarkan umpan balik pasar. Arsitek berkolaborasi dengan Product Owner untuk memastikan visi selaras dengan roadmap produk.
Tindakan kunci meliputi:
- Menentukan prinsip-prinsip tingkat tinggi yang tetap konstan.
- Mengidentifikasi batasan yang tidak dapat dinegosiasikan (keamanan, kepatuhan).
- Memecah visi menjadi epik arsitektur yang dapat diambil tindakan.
🏗️ Definisi Arsitektur Sesuai Kebutuhan
Dalam model tradisional, keempat domain (Bisnis, Data, Aplikasi, Teknologi) didefinisikan secara lengkap sebelum pengembangan dimulai. Agile menyarankan untuk hanya mendefinisikan apa yang diperlukan untuk melanjutkan. Ini sering disebut sebagai arsitektur ‘sesuai kebutuhan’.
Sebagai contoh:
- Sprint 1-3: Fokus pada Arsitektur Bisnis dan logika Aplikasi tingkat tinggi.
- Sprint 4-6: Haluskan Arsitektur Data seiring dibutuhkannya entitas data tertentu.
- Sprint 7+: Rinci Arsitektur Teknologi untuk lingkungan pengembangan.
Pendekatan ini mengurangi pemborosan. Arsitek tidak menghabiskan waktu memodelkan komponen yang mungkin dibuang selama iterasi.
🏗️ Landasan Arsitektur
Konsep krusial untuk integrasi ini adalah ‘Landasan Arsitektur’. Istilah ini mengacu pada infrastruktur teknis dan prinsip arsitektur yang harus tersedia untuk mendukung pengembangan fitur di masa depan. Tanpa landasan, pengembang mungkin harus berhenti dan membangun komponen dasar di tengah sprint fitur, menyebabkan penundaan.
Untuk menjaga landasan yang sehat:
- Identifikasi Pendorong: Tentukan pekerjaan teknis apa yang diperlukan untuk mendorong nilai bisnis di masa depan.
- Alokasikan Kapasitas: Cadangkan sebagian kapasitas sprint (misalnya, 20%) untuk pendorong arsitektur.
- Otomatisasi Standar: Gunakan infrastruktur sebagai kode untuk menerapkan standar teknis tanpa hambatan tinjauan manual.
Ini memastikan bahwa tim Agile memiliki alat dan kerangka kerja yang dibutuhkan tanpa harus menunggu proyek arsitektur besar selesai.
🛡️ Pengawasan Ringan
Pengawasan dalam lingkungan Agile harus ringan. Proses persetujuan yang terlalu ketat membunuh momentum. Tujuannya adalah memastikan kepatuhan dan kualitas tanpa menciptakan hambatan.
📝 Catatan Keputusan Arsitektur (ADRs)
Alih-alih dokumen arsitektur yang besar, organisasi dapat menggunakan Catatan Keputusan Arsitektur. ADR mencatat keputusan arsitektur yang signifikan beserta konteks dan konsekuensinya. Ini adalah dokumen ringan yang berada di repositori kode.
Manfaat ADR meliputi:
- Pelacakan:Mengetahui mengapa keputusan dibuat berbulan-bulan atau bertahun-tahun kemudian.
- Kolaborasi:Anggota tim dapat meninjau dan memberikan komentar pada keputusan dengan mudah.
- Transparansi:Riwayat keputusan dapat diakses oleh semua orang.
🔍 Dewan Uji Arsitektur
Dewan Uji Arsitektur (ARB) tradisional dapat menjadi hambatan. Dalam Agile, ARB seharusnya berfungsi sebagai badan konsultatif, bukan sebagai penjaga pintu. Tinjauan harus dilakukan pada milestone penting, bukan setiap sprint.
Pertimbangkan penyesuaian berikut:
- Fokus pada Risiko: Tinjau hanya keputusan berisiko tinggi yang dapat memengaruhi perusahaan.
- Tinjauan Asinkron: Izinkan arsitek untuk memberikan umpan balik secara asinkron untuk menghindari konflik jadwal.
- Tinjauan Sesama: Dorong pengembang untuk meninjau kepatuhan arsitektur satu sama lain sebelum tinjauan ARB formal.
👥 Peran dan Tanggung Jawab
Integrasi yang sukses membutuhkan definisi peran yang jelas. Peran ‘Arsitek Utama’ tradisional sering kali perlu berkembang menjadi model yang lebih terdistribusi.
🧑💼 Arsitek Perusahaan
Arsitek Perusahaan fokus pada visi jangka panjang. Mereka menentukan standar, prinsip, dan pola yang membimbing organisasi. Mereka memastikan bahwa tim-tim berbeda tidak membangun silo yang tidak kompatibel.
🧑💻 Arsitek Sistem
Arsitek Sistem bekerja lebih dekat dengan tim pengembangan. Mereka menerjemahkan prinsip perusahaan menjadi desain teknis spesifik untuk solusi tertentu. Mereka berperan sebagai jembatan antara strategi tingkat tinggi dan kode.
🏃♂️ Arsitek Agile
Beberapa organisasi menempatkan arsitek langsung ke dalam tim Agile. Orang-orang ini membantu tim mengambil keputusan yang selaras dengan strategi yang lebih luas sambil mempertahankan kecepatan pengembangan. Mereka berpartisipasi dalam perencanaan sprint dan penyempurnaan backlog.
🧭 Pemilik Produk
Pemilik Produk mewakili nilai bisnis. Mereka bekerja sama dengan arsitek untuk memastikan bahwa keterbatasan teknis dipahami dalam konteks tujuan bisnis. Mereka memprioritaskan enabler arsitektur bersamaan dengan cerita pengguna.
🚧 Kesalahan Umum yang Harus Dihindari
Bahkan dengan rencana yang kuat, integrasi bisa gagal jika kesalahan tertentu diabaikan. Mengetahui kesalahan umum ini dapat menghemat waktu dan sumber daya yang signifikan.
- Over-Engineering: Berusaha merancang untuk setiap skenario masa depan yang mungkin terjadi menyebabkan sistem menjadi berat. Rancang berdasarkan kebutuhan saat ini dengan mempertimbangkan kemampuan ekstensibilitas.
- Under-Engineering: Mengabaikan keterbatasan arsitektur menyebabkan utang teknis yang menjadi tidak terkelola. Pastikan persyaratan non-fungsional (kinerja, keamanan) diatasi.
- Kesenjangan Komunikasi: Arsitek dan pengembang sering berbicara bahasa yang berbeda. Gunakan diagram dan model yang dapat diakses oleh seluruh tim.
- Mengabaikan Hutang Teknis:Tim Agile sering memprioritaskan fitur daripada refactoring. Tetapkan aturan bahwa persentase setiap sprint harus digunakan untuk menangani hutang teknis.
- Kelebihan Alat:Jangan mengandalkan alat pemodelan yang rumit yang membutuhkan pelatihan. Pertahankan dokumentasi sederhana dan terintegrasi dengan alur kerja pengembangan.
📊 Mengukur Keberhasilan
Bagaimana Anda tahu apakah integrasi berjalan dengan baik? Anda memerlukan metrik yang mencerminkan kesehatan arsitektur dan kecepatan pengiriman.
📈 Metrik Kesehatan Arsitektur
- Tingkat Kepatuhan: Persentase solusi yang mematuhi standar yang ditetapkan.
- Rasio Hutang Teknis: Rasio pekerjaan refactoring terhadap pekerjaan fitur baru.
- Dapat Digunakan Kembali: Jumlah komponen bersama yang digunakan di berbagai proyek.
🚀 Metrik Pengiriman
- Waktu Tanggap: Waktu dari gagasan hingga penyebaran.
- Frekuensi Penyebaran: Seberapa sering kode dirilis.
- Tingkat Kegagalan Perubahan: Persentase penyebaran yang menyebabkan kegagalan.
Dengan melacak metrik-metrik ini, kepemimpinan dapat membuat keputusan berbasis data tentang di mana harus berinvestasi dalam arsitektur atau di mana harus melonggarkan kendala.
🤔 Pertanyaan yang Sering Diajukan
❓ Apakah TOGAF bisa bekerja dengan Scrum?
Ya. Tahapan ADM dapat dipetakan ke siklus Sprint. Sebagai contoh, Tahap B dan C dapat dieksplorasi dalam serangkaian sprint. Kunci utamanya adalah melihat ADM sebagai siklus penemuan, bukan sebagai alur linier yang menyerupai air terjun.
❓ Berapa banyak dokumentasi yang dibutuhkan?
Dokumentasi harus cukup untuk mempertahankan sistem tetapi tidak berlebihan. Diagram yang muat dalam satu halaman seringkali lebih baik daripada dokumen 50 halaman. Fokus pada dokumentasi yang menambah nilai dan membantu pemeliharaan.
❓ Bagaimana jika kebutuhan bisnis berubah di tengah sprint?
Ini adalah prinsip inti Agile. Arsitektur harus cukup fleksibel untuk menampung perubahan. Gunakan lapisan abstraksi dan antarmuka untuk memisahkan komponen sehingga perubahan di satu area tidak merusak seluruh sistem.
❓ Apakah kita perlu kerangka kerja Agile terpisah seperti SAFe?
Tidak selalu. Meskipun kerangka kerja seperti SAFe (Scaled Agile Framework) memberikan struktur bagi organisasi besar, TOGAF dapat disesuaikan tanpa harus mengadopsi kerangka kerja skala penuh. Pilihan tergantung pada ukuran dan kompleksitas organisasi.
❓ Bagaimana kita menangani sistem warisan?
Sistem warisan sering kali membutuhkan pendekatan yang berbeda. Anda mungkin perlu membuat pola ‘Strangler Fig’ di mana fungsi baru dibangun di sekitar sistem warisan, secara bertahap menggantinya. TOGAF membantu memetakan transisi dari kondisi warisan ke kondisi target.
🔍 Poin-Poin Utama
Mengintegrasikan TOGAF dengan Agile bukan tentang memilih satu di antara keduanya. Ini tentang menemukan keseimbangan antara struktur dan kelincahan. Dengan membuat Metode Pengembangan Arsitektur bersifat iteratif, menerapkan tata kelola ringan, dan secara jelas mendefinisikan peran, organisasi dapat mencapai stabilitas dan kecepatan secara bersamaan.
Keberhasilan tergantung pada komunikasi, fleksibilitas, dan pemahaman bersama terhadap tujuan. Ketika tim arsitektur dan tim pengembangan bekerja sebagai mitra, hasilnya adalah perusahaan yang tangguh yang dapat beradaptasi terhadap perubahan pasar tanpa mengorbankan kualitas atau kepatuhan.
Mulai kecil. Uji pendekatan ini di satu tim. Ukur hasilnya. Sesuaikan prosesnya. Ulangi. Pendekatan iteratif terhadap arsitektur itu sendiri mencerminkan filosofi Agile yang ingin didukung.
