Belajar Enterprise Architect - EA Repository & Documentation

#Pendahuluan

Setelah di episode 9 kalian mendesain mesin governance — prinsip, ARB, policy, exception — ada pertanyaan yang menentukan apakah semuanya bertahan lebih dari enam bulan: di mana hasil kerja EA disimpan dan ditemukan? Tanpa jawaban itu, capability map usang di laptop seseorang, keputusan ARB tersebar di chat, dan setiap analisis baru dimulai dari nol.

Episode ini membangun EA repository: tempat tunggal yang mutakhir untuk model, keputusan, dan standar. Ini juga pemenuhan janji episode 0 — folder ea-lab/ kalian kini kita angkat menjadi repository yang layak produksi — plus pembahasan kapan tool komersial seperti LeanIX masuk akal.

#Prinsip Repository yang Hidup

Sebelum struktur folder, tiga prinsip yang membedakan repository hidup dari kuburan dokumen:

• Single source of truth per artefak — satu tempat resmi; salinan di slide diperbolehkan asal ditandai tanggal snapshot dan merujuk sumber.
• Mutakhir adalah wajib, bukan ideal — baseline landscape berubah saat ARB mengesahkan perubahan, bukan saat "ada waktu". Kaitkan pembaruan ke alur governance (episode 9), bukan ke niat baik.
• Cari dulu, baru buat — aturan mainnya: sebelum artefak baru dibuat, wajib mencari di repository. Duplikasi artefak adalah bentuk paling halus dari pemborosan EA.

Uji sederhana apakah repository hidup: minta tiga orang menemukan daftar aplikasi yang memproses data pelanggan. Kalau jawabannya butuh menghubungi seseorang — bukan membuka satu URL — repository kalian gagal fungsinya.

#Struktur Repository: Dari ea-lab ke Produksi

Folder ea-lab/ dari episode 0 sudah punya tulang punggungnya. Versi produksi menambahkan lapisan governance dan keputusan:

ea-lab/
├── principles/             # prinsip arsitektur terverifikasi versi
├── standards/              # tier list teknologi, template wajib
├── decisions/              # ADR enterprise + exception records
│   ├── adr/
│   └── exceptions/
├── models/                 # file .archimate + ekspor HTML per domain
├── case-study/             # baseline & target per domain (ep 4-7)
├── views/                  # view ArchiMate siap-presentasi per audiens
└── meta/
    ├── glossary.md         # kamus istilah & definisi resmi
    └── changelog.md        # apa berubah tiap iterasi ADM

Tiga keputusan desain yang penting:

• Model ArchiMaster dipisah dari view — satu master model berisi seluruh elemen dan relasi; presentasi dibuat sebagai view terpisah per audiens. Mencampurnya menghasilkan file monster yang tak bisa dirawat.
• Keputusan sebagai rekaman atomik — ADR satu file satu keputusan dengan status; mudah dirujuk ARB, mudah diaudit, mudah dicari.
• Changelog sebagai jurnal iterasi — tiap siklus ADM (episode 2) menulis ringkasan perubahan; ini yang menyelamatkan kalian saat auditor atau direksi bertanya "peta ini data dari kapan?"

#Dokumentasi Minimalis yang Benar-Benar Dibaca

Kebencian industri terhadap "dokumentasi EA" sah — target kemarahannya benar: dokumen tebal yang tak dibaca. Disiplin yang saya pakai:

Aturan penulisan yang menjaga kualitas: mulai dari tujuan pembaca (pertanyaan apa yang harus terjawab?), satu pesan per diagram, dan hapus setiap paragraf yang tidak mengubah keputusan siapa pun. Dokumen EA terbaik sering kali satu tabel plus satu gambar.

#Metadata: Agar Bisa Dicari

Model yang tak bisa dicari sama saja tidak ada. Minimal, setiap elemen penting di Archi dan setiap file di repository punya metadata konsisten: nama standar (konvensi penamaan tertulis), owner, tanggal update, dan relasi eksplisit ke elemen lain — aplikasi terhubung ke kapabilitas yang didukungnya, data store terhubung ke klasifikasi datanya. Di Archi, manfaatkan fitur query/diagram otomatis: begitu relasi terjaga, "tampilkan semua aplikasi yang memproses data personal" adalah satu klik — persis pertanyaan uji hidup-mati repository di awal episode.

Untuk skala besar, inilah nilai tool EA komersial seperti LeanIX/SAP LeanIX atau Bizzdesign: inventaris sebagai database dengan workflow pembaruan, report bawaan (obsolescence, SaaS sprawl), integrasi discovery otomatis dari CMDB/cloud. Kriteria waktu tepatnya beralih: portofolio melewati ±100 aplikasi, lebih dari satu tim EA harus bekerja paralel, atau regulator menuntut laporan berkala yang reproducible. Di bawah ambang itu, disiplin lebih menentukan daripada tools — spreadsheet dan Archi yang dirawat mengalahkan platform mahal yang ditelantarkan.

#Sinkron dengan Realita

Repository yang bagus tetap bisa berbohong jika landscape berubah tanpa jejak. Tiga sumber sinkronisasi rutin: (1) alur change management TOGAF fase H — perubahan signifikan wajib lewat ARB yang sekaligus memicu update model; (2) discovery otomatis — tarik daftar resource cloud dan SaaS tiap kuarter, bandingkan dengan inventaris, selisihnya investigasi (shadow IT muncul di sini); (3) review berkala per domain — owner domain menandatangani bahwa baseline domainnya masih benar tiap enam bulan.

#Praktik: Bangun EA Repository Kalian

Kerjakan langsung di ea-lab/:

1. Restrukturisasi — sesuaikan folder ke struktur produksi di atas; pindahkan ADR-EA-001 (episode 4), prinsip data (episode 5), disposisi TIME (episode 6), prinsip teknologi (episode 7), dan framework governance (episode 9) ke tempat resminya.
2. Master model Archi — bangun satu file .archimate berisi minimal: kapabilitas L1-L2, aplikasi utama beserta relasi ke kapabilitas, dan data store utama; buat tiga view: business overview (untuk kepala divisi), application landscape (untuk CIO), data sensitivity (untuk security).
3. Glossary — definisikan minimal 15 istilah resmi grup: pelanggan, order aktif, settlement, dsb. — sinkron dengan kamus data episode 5.
4. Changelog iterasi 1 — ringkas semua yang berubah sejak episode 4 dalam sepuluh baris.

#Tanda Repository Mulai Sakit

Deteksi dini sebelum repository menjadi kuburan dokumen: artefak terbaru tak bisa ditemukan tanpa bertanya orang; ada dua versi capability map dan keduanya diklaim resmi; changelog berhenti dua iterasi lalu; view presentasi diedit langsung di master model; dan keputusan ARB mulai tersimpan di chat. Semua gejala itu punya akar yang sama — pembaruan tidak lagi terikat ke proses governance — dan satu obat: kembalikan disiplin episode 9, jangan tambah tool baru. Jadwalkan "uji pencarian" ini sebagai latihan lima menit tiap review kuarteran: satu pertanyaan acak tentang landscape harus terjawab dari repository dalam satu klik.

Rutinitas rawat minimum yang terbukti cukup untuk menjaga hidupnya:

• Mingguan: triage artefak baru hasil ARB agar masuk folder dan metadata yang benar
• Bulanan: laporan artefak tanpa owner dan view yang tak pernah dibuka
• Kuarteran: uji pencarian acak plus pensiun-kan artefak yang usang

#Penutup

Inti yang harus dibawa pulang:

• Repository hidup punya tiga sifat: single source of truth, pembaruan terikat ke proses governance (bukan niat baik), dan kebiasaan cari-sebelum-buat.
• Struktur produksi memisahkan master model dari view, menyimpan keputusan sebagai ADR atomik, dan mencatat changelog per iterasi.
• Dokumentasi minimalis berorientasi keputusan: format pendek, satu pesan per diagram, metadata tanggal-status wajib di semua artefak.
• Tool komersial dibeli saat skalanya menuntut — di atas ±100 aplikasi atau tuntutan audit reproducible; sebelum itu, disiplin mengalahkan tools.

Rumah EA kalian sudah berdiri dan terisi. Di episode 11 selanjutnya kita latih keterampilan yang menentukan apakah semua artefak ini berguna: stakeholder management dan komunikasi — memetakan pemangku kepentingan, menyesuaikan pesan per audiens ala disiplin Zachman, dan membangun presentasi eksekutif yang menggerakkan keputusan. Sampai jumpa di episode 11!