Arsitektur perusahaan mengharuskan ketepatan. Saat mengelola lingkungan TI yang kompleks, kemampuan untuk memvisualisasikan bagaimana aplikasi mendukung tujuan bisnis sangat penting. Notasi ArchiMate menyediakan bahasa standar untuk memodelkan struktur ini. Dengan menerapkan kerangka kerja ini secara benar, arsitek dapat mengubah inventaris yang kacau menjadi portofolio yang dapat dipahami. Panduan ini menjelaskan proses pembuatan model aplikasi yang jelas dan dapat dipelihara tanpa bergantung pada alat vendor tertentu.
Memahami Lapisan Aplikasi 🧩
Lapisan Aplikasi adalah inti dari setiap model arsitektur TI. Ini mewakili sistem perangkat lunak, layanan, dan komponen yang memberikan fungsi kepada bisnis. Berbeda dengan daftar sederhana aset perangkat lunak, portofolio ArchiMate menggambarkan hubungan dan layanan yang diberikan oleh aset-aset ini.
Kejelasan dimulai dengan menentukan batas. Portofolio aplikasi seharusnya bukan sekadar tumpukan semua biner yang terpasang. Sebaliknya, fokusnya harus pada pengiriman nilai. Setiap entri dalam portofolio mewakili unit fungsional yang berbeda yang dapat dipahami oleh pemangku kepentingan. Perbedaan ini memisahkan portofolio dari inventaris teknis.
Prinsip utama untuk Lapisan Aplikasi meliputi:
- Abstraksi: Kelompokkan aplikasi yang saling terkait ke dalam domain logis atau domain tanggung jawab.
- Standarisasi: Gunakan konvensi penamaan yang konsisten di seluruh model.
- Manajemen Status: Lacak status siklus hidup setiap aplikasi (misalnya, Direncanakan, Aktif, Dihentikan).
- Konektivitas: Tentukan bagaimana aplikasi berinteraksi satu sama lain dan dengan Lapisan Bisnis.
Elemen Inti ArchiMate untuk Aplikasi 📋
Untuk membangun portofolio yang kuat, seseorang harus memahami blok bangunan khusus yang tersedia dalam notasi ini. Menggunakan jenis elemen yang benar memastikan model tetap akurat secara semantik.
| Jenis Elemen | Deskripsi | Kasus Penggunaan |
|---|---|---|
| Komponen Aplikasi | Bagian modular dari suatu aplikasi yang dapat dikembangkan dan diimplementasikan secara independen. | Microservices, modul internal, atau perpustakaan yang berbeda. |
| Fungsi Aplikasi | Perilaku khusus yang disediakan oleh suatu komponen aplikasi. | Pelaporan, Manajemen Pengguna, Pemrosesan Transaksi. |
| Layanan Aplikasi | Seperangkat fungsi yang disediakan oleh suatu aplikasi kepada aktor atau aplikasi lain. | Titik akhir API eksternal, akses data bersama. |
| Antarmuka Aplikasi | Titik interaksi antara suatu aplikasi dan sistem eksternal. | API REST, titik akhir SOAP, adapter file. |
Saat mengisi portofolio, hindari spesifikasi berlebihan. Suatu Fungsi Aplikasi sering terlalu rinci untuk tampilan portofolio tingkat tinggi. Suatu Layanan Aplikasi biasanya tingkat yang tepat bagi pemangku kepentingan untuk memahami apa yang dapat mereka gunakan. Sebagai contoh, suatu “Sistem Penagihan” adalah Komponen Aplikasi. “Hasilkan Faktur” adalah Fungsi Aplikasi. “Berikan Data Penagihan” adalah Layanan Aplikasi.
Menggunakan tingkat detail yang tepat mencegah model menjadi tidak dapat dibaca. Portofolio yang mencantumkan setiap fungsi akan gagal menyampaikan niat strategis. Portofolio yang hanya mencantumkan komponen mungkin melewatkan ketergantungan kritis.
Menentukan Hubungan dan Ketergantungan 🔗
Aplikasi tidak ada secara terpisah. Nilainya berasal dari bagaimana mereka terhubung ke proses bisnis dan sistem TI lainnya. ArchiMate mendefinisikan jenis hubungan tertentu untuk memodelkan interaksi ini secara akurat.
| Hubungan | Arah | Makna |
|---|---|---|
| Realisasi | Layanan → Fungsi | Fungsi tersebut merealisasikan layanan tersebut. |
| Akses | Komponen Aplikasi → Fungsi Aplikasi | Komponen tersebut mengakses fungsi tersebut. |
| Melayani | Aplikasi → Proses Bisnis | Aplikasi tersebut mendukung proses tersebut. |
| Ketergantungan | Aplikasi A → Aplikasi B | A bergantung pada B untuk berfungsi. |
| Aliran | Objek Data → Aplikasi | Data mengalir masuk atau keluar dari aplikasi. |
Ketergantungan sering menjadi bagian paling kritis dalam manajemen portofolio. Saat menilai risiko atau merencanakan migrasi, mengetahui aplikasi mana yang bergantung pada aplikasi lain sangat penting. Perubahan pada aplikasi basis data inti bisa memengaruhi lima alat pelaporan di hilir. Tanpa memetakan ketergantungan ini, analisis dampak menjadi tebakan.
Gunakan Ketergantungan hubungan secara bijak. Hanya boleh digunakan ketika kegagalan satu aplikasi secara langsung mencegah aplikasi lain berfungsi. Jangan bingungkan ini dengan aliran data. Jika Aplikasi A mengirim data ke Aplikasi B, gunakan Aliran Data atau Aliran Komunikasi. Jika Aplikasi A membutuhkan Aplikasi B berjalan untuk berfungsi, gunakan Ketergantungan.
Menyelaraskan dengan Kemampuan Bisnis 🚀
Portofolio aplikasi yang jelas harus menjawab pertanyaan: ‘Kemampuan bisnis apa yang didukung oleh ini?’ Penyelarasan ini dicapai dengan menghubungkan Lapisan Aplikasi ke Lapisan Bisnis.
Kemampuan Bisnis mewakili apa yang dilakukan organisasi, bukan bagaimana. Aplikasi mewakili bagaimanaorganisasi melaksanakan kemampuan-kemampuan tersebut. Dengan memetakan aplikasi ke kemampuan, arsitek dapat mengidentifikasi celah dan tumpang tindih.
Pertimbangkan skenario di mana dua departemen berbeda menggunakan aplikasi terpisah untuk ‘Manajemen Pelanggan’. Jika kemampuan bisnisnya hanya ‘Kelola Hubungan Pelanggan’, adanya dua aplikasi menunjukkan tumpang tindih. Wawasan ini mendorong strategi konsolidasi.
Langkah-langkah menyelaraskan aplikasi dengan kemampuan:
- Identifikasi Kemampuan Inti: Tentukan kemampuan bisnis tingkat tinggi yang dibutuhkan untuk strategi.
- Peta Aplikasi: Gambar hubungan pelayanan dari aplikasi ke kemampuan.
- Analisis Tumpang Tindih: Cari aplikasi ganda yang melayani kemampuan yang sama.
- Evaluasi Kesehatan: Evaluasi apakah aplikasi yang mendukung kemampuan tersebut stabil, usang, atau dapat diskalakan.
Pemetaan ini memberikan konteks. Aplikasi tanpa kaitan kemampuan bisnis merupakan kerugian. Ini adalah pusat biaya tanpa nilai strategis yang terlihat. Sebaliknya, kemampuan tanpa kaitan aplikasi menunjukkan celah di mana proses manual atau IT bayangan mungkin beroperasi.
Mengatur untuk Kejelasan 📊
Organisasi visual sangat penting untuk kemudahan baca. Daftar aplikasi datar sulit dianalisis. Mengatur portofolio menjadi tampilan memungkinkan pemangku kepentingan berbeda melihat apa yang penting bagi mereka.
Strategi Pengelompokan
Kelompokkan aplikasi berdasarkan domain logis. Pengelompokan umum meliputi:
- Domain Fungsional: Keuangan, SDM, Rantai Pasok.
- Lapisan Teknis: Sistem Inti, Front-End, Lapisan Data.
- Kepemilikan:Batasan departemen.
Jangan mencampur pengelompokan ini dalam satu tampilan. Pertahankan arsitektur yang bersih. Gunakan diagram sub atau tampilan untuk memisahkan masalah. Misalnya, tampilan ‘Front-End’ bisa menampilkan semua aplikasi yang ditampilkan pengguna, sementara tampilan ‘Back-End’ menampilkan penyimpanan data dan mesin inti.
Konsistensi Penamaan
Penamaan yang tidak konsisten menciptakan kebingungan. Terapkan format standar untuk semua nama aplikasi. Pola yang direkomendasikan adalah:
<Domain> – <Fungsi> – <Jenis>
Contoh: SDM - Gaji - Sistem Inti. Ini memungkinkan pemfilteran dan pencarian yang mudah. Hindari singkatan yang tidak dipahami secara luas dalam organisasi. Jika suatu tim menggunakan ‘CRM’, pastikan organisasi yang lebih luas memahami bahwa ini merujuk pada ‘Manajemen Hubungan Pelanggan.’
Tantangan Pemodelan Umum ⚠️
Bahkan dengan kerangka yang kuat, terdapat jebakan. Arsitek sering mengalami kesulitan dalam mengelola kompleksitas. Berikut ini adalah masalah umum dan cara mengatasinya.
Pemodelan Berlebihan
Mencoba memodelkan setiap antarmuka antar aplikasi menghasilkan diagram yang berantakan. Model menjadi tidak dapat dibaca. Fokus pada jalur kritis. Jika Aplikasi A berbicara dengan Aplikasi B, tetapi hanya untuk pekerjaan latar belakang yang berjalan sekali sehari, mungkin tidak perlu dimasukkan dalam tampilan utama portofolio. Dokumentasikan dalam spesifikasi teknis terpisah.
Mengabaikan Status Siklus Hidup
Portofolio berubah. Aplikasi dihentikan, diganti, atau dihentikan sementara. Model ArchiMate harus mencerminkan keadaan saat ini. Gunakan atribut Siklus Hidup Aplikasi untuk menandai aplikasi sebagai:
- Direncanakan:Dalam pertimbangan atau pengembangan.
- Aktif:Digunakan dalam produksi.
- Tidak lagi digunakan:Ditjadwalkan untuk dihapus.
- Dihentikan:Tidak lagi digunakan.
Pihak terkait perlu mengetahui apakah suatu sistem aktif. Portofolio yang hanya menampilkan sistem aktif memberikan gambaran jelas tentang kondisi saat ini. Portofolio yang mencampur sistem aktif dan yang telah dihentikan tanpa penandaan yang jelas menciptakan kebisingan.
Kurangnya Konteks Bisnis
Model teknis yang tidak memiliki konteks bisnis akan diabaikan. Jika model hanya menampilkan ketergantungan teknis, pemimpin bisnis tidak akan terlibat. Pastikan setiap aplikasi utama memiliki setidaknya satu tautan ke Proses Bisnis atau Fungsi Bisnis. Ini memastikan model berbicara dalam bahasa bisnis.
Menciptakan Tampilan yang Efektif 👁️
Satu tampilan tidak dapat menampilkan semua hal. Kekuatan notasi terletak pada penciptaan tampilan khusus untuk audiens tertentu. Tampilan adalah subset yang difilter dari arsitektur yang menangani kekhawatiran tertentu.
Tampilan Eksekutif: Fokus pada Lapisan Aplikasi dan Lapisan Bisnis. Tampilkan aplikasi tingkat tinggi dan kemampuan yang didukungnya. Sembunyikan antarmuka teknis dan aliran data. Tampilan ini menjawab pertanyaan strategis mengenai investasi dan cakupan kemampuan.
Tampilan Teknis: Fokus pada Lapisan Aplikasi dan Lapisan Teknologi. Tampilkan antarmuka, aliran data, dan node penempatan. Sembunyikan kemampuan bisnis. Tampilan ini menjawab pertanyaan implementasi mengenai integrasi dan infrastruktur.
Tampilan Migrasi: Tampilkan kondisi saat ini dan kondisi tujuan. Gunakan garis putus-putus atau warna berbeda untuk menunjukkan perubahan yang direncanakan. Tampilan ini sangat penting untuk proyek transformasi.
Saat membuat tampilan ini, gunakan konvensi tampilan ArchiMate standar. Jangan menciptakan simbol baru. Jika Anda perlu menunjukkan status tertentu, gunakan stereotip standar atau konvensi warna yang terdokumentasi dalam panduan gaya Anda.
Manajemen Siklus Hidup dan Pemeliharaan 🔄
Model arsitektur adalah dokumen yang hidup. Ia membutuhkan pemeliharaan agar tetap berguna. Model statis menjadi usang dalam waktu beberapa bulan. Tetapkan proses tata kelola untuk pembaruan.
Manajemen Perubahan
Ketika aplikasi baru diperkenalkan, harus ditambahkan ke portofolio. Ketika aplikasi lama dihapus, harus ditandai sebagai dihentikan. Tim arsitektur harus menjadi bagian dari Dewan Penasihat Perubahan (CAB). Ini memastikan model mencerminkan kenyataan.
Siklus Tinjauan
Atur tinjauan rutin. Tinjauan kuartalan memastikan model tetap terkini. Selama tinjauan ini, validasi:
- Apakah semua aplikasi aktif telah didokumentasikan?
- Apakah hubungan tetap diperbarui?
- Apakah tautan kemampuan bisnis akurat?
Alat penemuan otomatis dapat membantu mengidentifikasi aplikasi aktif. Namun, mereka tidak dapat memvalidasi tujuan bisnis. Tinjauan manusia diperlukan untuk memastikan hubungan semantik.
Integrasi dengan Teknologi dan Data 🖥️
Meskipun fokus di sini adalah Lapisan Aplikasi, lapisan ini berada dalam konteks yang lebih luas. Memahami keterkaitannya dengan Teknologi dan Data menambah kedalaman pada portofolio.
Lapisan Teknologi:Aplikasi berjalan pada teknologi. Memetakan aplikasi ke node, perangkat, atau awan memberikan wawasan mengenai kebutuhan infrastruktur. Jika suatu aplikasi bergantung pada komponen perangkat keras tertentu, hal ini harus terlihat. Ini membantu dalam perencanaan kapasitas dan pemulihan bencana.
Lapisan Data:Aplikasi memproses data. Objek Data mewakili entitas informasi. Menghubungkan aplikasi ke Objek Data menjelaskan kepemilikan data. Jika suatu aplikasi membuat ‘Catatan Pelanggan’, maka aplikasi tersebut memiliki data tersebut. Aplikasi lain yang menggunakan catatan tersebut memiliki ketergantungan pada skema dan integritas data tersebut.
Kepemimpinan dan Standar 📜
Untuk menjaga kejelasan, standar wajib diterapkan. Tanpa standar, setiap arsitek akan memodelkan portofolio secara berbeda, yang mengakibatkan fragmentasi.
Tentukan panduan gaya. Dokumen ini harus mencakup:
- Kode Warna:Warna apa yang mewakili status siklus hidup apa?
- Penggunaan Font:Tebal untuk komponen, miring untuk antarmuka.
- Aturan Tata Letak:Aliran kiri-ke-kanan, penyelarasan pengelompokan.
- Aturan Notasi:Kapan menggunakan Komposisi dibandingkan dengan Asosiasi.
Pelatihan juga sangat penting. Pastikan semua arsitek memahami makna dari notasi tersebut. Penggunaan salah jenis hubungan dapat menyebabkan analisis dampak yang salah. Sebuah Ketergantungan tidak sama dengan Asosiasi. Ketepatan sangat penting.
Mengukur Keberhasilan 📏
Bagaimana Anda tahu portofolio tersebut jelas? Cari masukan dari pemangku kepentingan. Jika pemimpin bisnis dapat melihat model dan memahami investasi, maka portofolio tersebut efektif. Jika tim teknis dapat menggunakannya untuk merencanakan migrasi, maka portofolio tersebut bermanfaat.
Metrik kunci untuk portofolio yang sehat meliputi:
- Kelengkapan:Persentase aplikasi aktif yang didokumentasikan.
- Akurasi:Jumlah ketidaksesuaian yang dilaporkan selama audit.
- Kemudahan Penggunaan:Waktu yang dibutuhkan untuk menjawab pertanyaan arsitektur tertentu.
- Adopsi:Frekuensi pembaruan model dan akses pemangku kepentingan.
Portofolio yang hanya diletakkan di rak adalah kegagalan. Portofolio tersebut harus terintegrasi ke dalam alur kerja harian organisasi. Ini membutuhkan dukungan dari manajemen dan aksesibilitas bagi tim yang membangun sistem.
Pertimbangan Masa Depan 🌐
Lanskap arsitektur perusahaan terus berkembang. Paradigma baru seperti arsitektur berbasis cloud dan mikroservis mengubah cara aplikasi dibangun. Notasi ArchiMate cukup fleksibel untuk menyesuaikan perubahan ini.
Untuk lingkungan cloud, fokuslah pada aplikasi logis daripada instance fisik. Sebuah mikroservis adalah Komponen Aplikasi. Fungsi serverless juga merupakan Komponen Aplikasi. Hubungan tetap sama. Infrastruktur berubah, tetapi tujuan fungsionalnya tidak berubah.
Seiring organisasi beralih ke konektivitas berbasis API, Antarmuka Aplikasi menjadi semakin krusial. Pastikan portofolio menonjolkan layanan yang terbuka. Visibilitas ini mendukung ekosistem mitra dan pengembang yang menggunakan arsitektur tersebut.
Pikiran Akhir tentang Disiplin Pemodelan 🧘
Membangun portofolio aplikasi yang jelas adalah latihan dalam disiplin. Diperlukan ketahanan terhadap dorongan untuk memasukkan setiap detail. Diperlukan pengambilan keputusan tentang apa yang ditampilkan dan apa yang disembunyikan. Diperlukan komunikasi terus-menerus dengan pemangku kepentingan untuk memastikan model tetap relevan.
Dengan mematuhi notasi ArchiMate dan mengikuti panduan struktural ini, Anda menciptakan model yang berfungsi sebagai sumber kebenaran yang dapat dipercaya. Kejelasan ini mengurangi risiko, meningkatkan komunikasi, dan memungkinkan pengambilan keputusan strategis yang lebih baik. Notasi ini bukan hanya alat menggambar; ini adalah metode untuk berpikir tentang kompleksitas.
