Panduan ArchiMate: Membedakan Layanan Bisnis dan Layanan Aplikasi dalam ArchiMate

Rangka kerangka Arsitektur Perusahaan menyediakan struktur yang diperlukan untuk memahami bagaimana organisasi berfungsi. Di antara yang lain, spesifikasi ArchiMate menonjol karena kemampuannya memodelkan hubungan kompleks di berbagai lapisan. Salah satu perbedaan paling krusial dalam kerangka ini melibatkan konsep Layanan. Secara khusus, memahami perbedaan antara Layanan Bisnis dan Layanan Aplikasi sangat mendasar untuk pemodelan yang akurat.

Ketika arsitek mengaburkan kedua jenis ini, model yang dihasilkan kehilangan ketepatan. Pihak terkait dapat salah menafsirkan aliran nilai dibandingkan dengan pengiriman kemampuan teknis. Panduan ini mengeksplorasi nuansa layanan-layanan ini, hubungan antar mereka, serta implikasinya terhadap desain arsitektur.

🔍 Konsep Layanan dalam ArchiMate

Sebelum membahas jenis-jenis tertentu, perlu mendefinisikan apa yang membentuk Layanan dalam konteks ini. Dalam ArchiMate, Layanan bukan sekadar fungsi perangkat lunak. Ia merupakan representasi abstrak dari apa yang disediakan kepada penerima tertentu.

• Penyediaan:Layanan adalah sesuatu yang disediakan oleh struktur aktif.

• Penggunaan:Layanan adalah sesuatu yang digunakan oleh struktur pasif.

• Antarmuka:Layanan direalisasikan melalui Antarmuka.

Definisi ini berlaku secara universal di seluruh lapisan. Namun, sifat penyedia dan penerima berubah tergantung pada konteksnya. Layanan Bisnis disediakan oleh Aktor Bisnis atau Fungsi Bisnis. Layanan Aplikasi disediakan oleh Fungsi Aplikasi atau Komponen Aplikasi.

🏢 Layanan Bisnis: Proposisi Nilai

Layanan Bisnis mewakili nilai yang disampaikan organisasi kepada pelanggan atau pemangku kepentingan internalnya. Mereka merupakan wujud nyata dari kemampuan bisnis dalam tindakan. Ketika pelanggan berinteraksi dengan organisasi, mereka sedang menggunakan Layanan Bisnis.

Layanan-layanan ini bersifat menghadap ke luar atau menghadap ke dalam, tetapi selalu berkaitan dengan hasil bisnis. Mereka tidak tergantung pada implementasi teknis. Sebagai contoh, kemampuan untuk memproses pembayaran adalah Layanan Bisnis. Apakah pembayaran tersebut diproses oleh mainframe, API cloud, atau buku catatan manual tidak relevan terhadap definisi layanan itu sendiri.

Ciri-ciri Layanan Bisnis

• Fokus:Hasil bisnis dan penciptaan nilai.

• Penyedia:Aktor Bisnis atau Fungsi Bisnis.

• Penerima:Aktor Bisnis, Peran Bisnis, atau Fungsi Bisnis lainnya.

• Kerapatan:Sering kali kasar, mewakili proses bisnis yang signifikan.

• Stabilitas:Relatif stabil seiring waktu, meskipun teknologi berubah.

Pertimbangkan skenario ritel. Layanan “Proses Pesanan Pelanggan” adalah layanan Bisnis. Ini menggabungkan logika menerima pesanan, memverifikasi stok, dan memulai pemenuhan. Perangkat lunak tertentu yang digunakan untuk mencatat pesanan adalah layanan Aplikasi. Layanan Bisnis tetap sama terlepas dari alat yang digunakan.

💻 Layanan Aplikasi: Pendorong Teknis

Layanan Aplikasi berada di Lapisan Aplikasi. Mereka mewakili fungsionalitas yang disediakan oleh lingkungan TI. Layanan ini mendukung realisasi Layanan Bisnis. Mereka adalah mekanisme teknis yang memungkinkan logika bisnis untuk dieksekusi.

Jika Layanan Bisnis adalah “apa”, maka Layanan Aplikasi adalah “bagaimana”. Ini menggambarkan kemampuan spesifik yang ditawarkan oleh lingkungan perangkat lunak. Sebagai contoh, “Validasi Kartu Kredit” adalah layanan aplikasi. Ini adalah fungsi spesifik dalam tumpukan perangkat lunak pembayaran.

Karakteristik Layanan Aplikasi

• Fokus:Fungsionalitas teknis dan pemrosesan data.

• Penyedia:Fungsi Aplikasi atau Komponen Aplikasi.

• Penerima:Fungsi Aplikasi lainnya, Fungsi Bisnis, atau Aktor Bisnis.

• Kerapatan: Dapat berkisar dari kasar hingga halus.

• Stabilitas: Lebih rentan terhadap perubahan dibandingkan Layanan Bisnis karena perkembangan teknologi.

Layanan Aplikasi sering mengekspos dirinya melalui Antarmuka. Mereka bisa diakses oleh Fungsi Bisnis yang mengoordinasikan alur kerja, atau oleh layanan aplikasi lain yang memecah tugas yang kompleks.

🆚 Perbedaan Utama: Analisis Perbandingan

Memahami perbedaan ini memerlukan melihat bagaimana layanan-layanan ini berinteraksi dengan bagian lain dari model. Tabel berikut ini menjelaskan perbedaan utama.

Fitur	Layanan Bisnis	Layanan Aplikasi
Lapisan	Lapisan Bisnis	Lapisan Aplikasi
Tujuan Utama	Menghadirkan Nilai	Mengaktifkan Kemampuan
Realisasi	Direalisasikan oleh Proses/Fungsi Bisnis	Direalisasikan oleh Fungsi/Komponen Aplikasi
Ketergantungan	Tergantung pada Layanan Aplikasi	Mendukung Layanan Bisnis
Contoh	Kelola Akun Pelanggan	Perbarui Basis Data Akun
Konsumen	Aktor Bisnis, Peran Bisnis	Fungsi Aplikasi, Fungsi Bisnis

Perhatikan alur ketergantungan. Layanan Bisnis bergantung pada Layanan Aplikasi untuk berfungsi. Jika Layanan Aplikasi gagal, Layanan Bisnis tidak dapat disampaikan. Ketergantungan ini dimodelkan secara eksplisit dalam ArchiMate untuk melacak dampaknya.

🔗 Hubungan dan Koneksi

Hubungan antara layanan-layanan ini sangat penting untuk memahami arsitektur. ArchiMate mendefinisikan jenis hubungan tertentu yang menjelaskan bagaimana layanan saling berinteraksi.

Realisasi

Hubungan Realisasihubungan ini adalah tautan paling umum antar lapisan. Menunjukkan bahwa konsep tingkat tinggi diimplementasikan oleh konsep tingkat rendah.

• Realisasi Layanan Bisnis:Layanan Bisnis direalisasikan oleh Fungsi Bisnis atau Proses Bisnis.

• Realisasi Layanan Aplikasi:Layanan Aplikasi direalisasikan oleh Komponen Aplikasi atau Fungsi Aplikasi.

• Realisasi Silang Lapisan:Pentingnya, Layanan Bisnis direalisasikan oleh Layanan Aplikasi.

Realisasi silang lapisan ini menentukan rantai nilai inti arsitektur. Menunjukkan secara tepat bagaimana lingkungan TI mendorong nilai bisnis. Sebagai contoh, Layanan Bisnis ‘Kirim Produk’ direalisasikan oleh Layanan Aplikasi ‘Hasilkan Label Pengiriman’.

Akses

Hubungan Akseshubungan ini mendefinisikan bagaimana satu struktur menggunakan fungsionalitas struktur lain. Sering digunakan untuk menunjukkan bahwa Fungsi Bisnis mengakses Layanan Aplikasi.

• Fungsi Bisnis Mengakses Layanan Aplikasi:Ini umum terjadi dalam proses yang didorong manusia di mana pengguna berinteraksi dengan sistem.

• Fungsi Aplikasi Mengakses Layanan Aplikasi: Ini terjadi dalam alur kerja otomatis di mana satu komponen perangkat lunak memanggil yang lain.

Komunikasi

Hubungan Komunikasi hubungan menggambarkan aliran informasi antara struktur. Meskipun kurang umum untuk layanan secara langsung, ini relevan ketika layanan bertukar data.

• Aliran Data: Sebuah Layanan Bisnis mungkin berkomunikasi data ke Layanan Bisnis lainnya.

• Interaksi Sistem: Sebuah Layanan Aplikasi mungkin berkomunikasi dengan Layanan Aplikasi backend untuk mengambil data.

🧠 Praktik Terbaik Pemodelan

Untuk menjaga kejelasan dan manfaat dalam model ArchiMate Anda, patuhi praktik terbaik ini. Ambiguitas dalam pemodelan layanan menyebabkan kebingungan selama implementasi dan pemeliharaan.

1. Konvensi Penamaan

• Layanan Bisnis: Gunakan frasa kata benda yang menggambarkan nilai bisnis. Contoh: “Kelola Persediaan,” “Proses Klaim,” “Berikan Dukungan.”

• Layanan Aplikasi: Gunakan frasa kata kerja-benda yang menggambarkan tindakan teknis. Contoh: “Simpan Data Pelanggan,” “Hitung Tingkat Pajak,” “Tampilkan Dashboard.”

Penamaan yang konsisten membantu pemangku kepentingan mengidentifikasi lapisan dengan cepat. Jika Anda melihat “Hitung Tingkat Pajak,” itu mengimplikasikan Layanan Aplikasi. Jika Anda melihat “Tentukan Kewajiban Pajak,” itu mengimplikasikan Layanan Bisnis.

2. Hindari Penyeberangan Lapisan

Kesalahan umum adalah menempatkan Layanan Aplikasi di Lapisan Bisnis atau sebaliknya. Pastikan setiap elemen ditempatkan di lapisan yang benar. Jika suatu layanan bersifat teknis, maka layanan tersebut termasuk dalam Lapisan Aplikasi, meskipun mendukung tujuan bisnis.

• Periksa: Siapa yang menyediakan layanan ini?

• Periksa: Apa hasil utamanya?

• Periksa: Apakah implementasinya tergantung pada perangkat lunak?

3. Konsistensi Granularitas

Jaga konsistensi granularitas dalam satu lapisan. Jangan mencampur strategi bisnis tingkat tinggi dengan operasi data tingkat rendah dalam daftar layanan yang sama. Kelompokkan layanan yang terkait menjadi kelompok logis.

• Pengelompokan: Kelompokkan Layanan Aplikasi berdasarkan domain (misalnya, “Domain Manajemen Pesanan,” “Domain Keuangan”).

• Pengelompokan: Kelompokkan Layanan Bisnis berdasarkan rantai nilai (misalnya, “Pembelian,” “Penjualan,” “Pemenuhan”).

🚧 Kesalahan Umum dan Kesalahpahaman

Bahkan arsitek berpengalaman bisa terjatuh saat membedakan layanan-layanan ini. Mengenali kesalahan-kesalahan ini membantu dalam menyempurnakan model.

Kesalahan 1: Proses Bisnis “Kotak Hitam”

Seringkali, arsitek memodelkan suatu Proses Bisnis tanpa menjelaskan Layanan Aplikasi yang mendukungnya. Hal ini menciptakan kotak hitam. Hubungan antara “Apa” dan “Bagaimana” hilang.

• Solusi:Selalu pastikan bahwa Layanan Bisnis utama direalisasikan oleh Layanan Aplikasi tertentu. Lacak jalur dari nilai ke kode.

Kesalahan 2: Berpikir Fungsional vs. Berpikir Layanan

Arsitek terkadang memodelkan fungsi alih-alih layanan. Fungsi adalah struktur aktif yang melakukan pekerjaan. Layanan adalah hasil dari pekerjaan tersebut yang disediakan kepada penerima.

• Perbedaan: Suatu Fungsi Bisnis “Memproses Pesanan” adalah struktur aktif. Layanan Bisnis “Pemrosesan Pesanan” adalah nilai yang disediakan. Layanan Aplikasi “Validasi Pesanan” adalah kemampuan teknis.

• Dampak:Mengaburkan perbedaan ini menghasilkan model yang tampak seperti bagan alir alih-alih peta arsitektur.

Kesalahan 3: Mengabaikan Antarmuka

Layanan direalisasikan melalui Antarmuka. Mengabaikan lapisan Antarmuka membuat sulit untuk menentukan kontrak dan protokol.

• Persyaratan:Tentukan Antarmuka untuk setiap Layanan Aplikasi.

• Persyaratan:Tentukan Antarmuka untuk Layanan Bisnis jika mereka berinteraksi dengan pihak eksternal.

📈 Dampak terhadap Strategi dan Implementasi

Perbedaan antara Layanan Bisnis dan Layanan Aplikasi bukan hanya teoritis. Ini memiliki implikasi langsung terhadap perencanaan strategis dan implementasi teknis.

Penyelarasan Strategis

Ketika Layanan Bisnis didefinisikan dengan jelas, strategi menjadi terukur. Anda dapat memetakan tujuan bisnis langsung ke layanan. Jika tujuannya adalah “Mengurangi Waktu Pesanan”, Anda dapat melacaknya ke Layanan Bisnis “Memproses Pesanan”. Kemudian, Anda dapat mengidentifikasi layanan aplikasi mana yang menjadi hambatan.

• Investasi:Membantu memprioritaskan investasi TI berdasarkan nilai bisnis.

• Optimisasi:Memungkinkan optimisasi yang terfokus pada Layanan Aplikasi tertentu tanpa mengubah Layanan Bisnis.

Implementasi Teknis

Bagi tim pengembangan, Layanan Aplikasi menentukan mikroservis atau modul yang harus dibangun. Definisi yang jelas memastikan bahwa kode selaras dengan tujuan arsitektur.

• Modularitas: Layanan Aplikasi mendorong desain modular.

• Integrasi:Antarmuka yang ditentukan pada Layanan Aplikasi membimbing kontrak API.

🔄 Evolusi dan Pemeliharaan

Arsitektur tidak statis. Layanan berkembang seiring waktu. Memahami lapisan-lapisan membantu mengelola evolusi ini.

Migrasi Teknologi

Ketika melakukan migrasi dari sistem on-premise ke awan, Layanan Aplikasi dapat berubah. Namun, Layanan Bisnis seharusnya tetap stabil secara besar-besaran.

• Stabilitas: Layanan Bisnis “Kelola Langganan” tetap sama.

• Perubahan: Layanan Aplikasi “Simpan Data Langganan” berpindah dari server basis data ke layanan penyimpanan awan.

Pemisahan ini memastikan kelangsungan bisnis tetap terjaga meskipun teknologi dasar berubah.

Pemecahan Layanan

Seiring organisasi tumbuh, layanan yang kasar sering dipecah. Layanan Bisnis tingkat tinggi mungkin dibagi menjadi beberapa Layanan Aplikasi.

• Contoh: “Kelola Identitas Pengguna” mungkin terpecah menjadi Layanan Aplikasi “Autentikasi Pengguna” dan “Kelola Profil”.

• Hasil: Layanan Bisnis tetap sama, tetapi implementasi teknis menjadi lebih halus.

📊 Ringkasan Hubungan

Untuk memvisualisasikan alirannya, pertimbangkan hierarki berikut:

• Strategi Bisnis: Menentukan kebutuhan akan layanan.

• Layanan Bisnis: Memberikan nilai kepada pelanggan.

• Layanan Aplikasi: Menyediakan kemampuan teknis.

• Komponen Aplikasi: Melaksanakan Layanan Aplikasi.

• Infrastruktur: Menyediakan tempat bagi Komponen Aplikasi.

Setiap tingkatan mendukung tingkatan di atasnya. Lapisan Aplikasi adalah ruang mesin, tetapi Lapisan Bisnis adalah tujuan akhir.

🛠️ Aplikasi Praktis dalam Pemodelan

Ketika membangun model, ikuti langkah-langkah berikut untuk memastikan perbedaan yang benar.

1. Identifikasi Pemangku Kepentingan: Siapa yang menggunakan layanan ini? Jika pelanggan atau karyawan, kemungkinan besar ini adalah Layanan Bisnis.

2. Identifikasi Penyedia: Siapa yang menyediakan layanan ini? Jika komponen perangkat lunak, maka ini adalah Layanan Aplikasi.

3. Tentukan Antarmuka: Bagaimana layanan ini diakses? Tentukan protokol atau titik interaksi.

4. Peta Realisasi: Hubungkan Layanan Bisnis dengan Layanan Aplikasi menggunakan panah realisasi.

5. Validasi Aliran: Pastikan tidak ada siklus yang melanggar prinsip lapisan.

Dengan mengikuti pendekatan yang terdisiplin ini, model tetap jelas dan dapat dijalankan. Ini menghindari jebakan penggunaan istilah teknis di lapisan bisnis dan istilah bisnis di lapisan teknis.

🌐 Implikasi yang Lebih Luas

Perbedaan ini mendukung kerangka arsitektur lainnya. Saat mengintegrasikan ArchiMate dengan TOGAF atau Zachman, lapisan Layanan berfungsi sebagai jembatan.

• TOGAF: Arsitektur Bisnis menentukan layanan; Arsitektur Sistem Informasi menentukan aplikasi.

• ITIL: Manajemen Layanan berfokus pada Layanan Bisnis; Operasi TI berfokus pada Layanan Aplikasi.

Interoperabilitas ini memungkinkan organisasi menggunakan satu sumber kebenaran tunggal di berbagai metodologi.

🔒 Keamanan dan Tata Kelola

Kontrol keamanan sering diterapkan pada tingkat Layanan Aplikasi, tetapi melindungi nilai Layanan Bisnis.

• Autentikasi: Diterapkan pada Antarmuka Layanan Aplikasi.

• Audit: Diterapkan pada penggunaan Layanan Bisnis.

• Kepatuhan: Memastikan Layanan Aplikasi memenuhi persyaratan Layanan Bisnis.

Memahami lapisan-lapisan ini membantu dalam menetapkan tanggung jawab keamanan secara tepat. Pemilik bisnis memiliki nilai; pemilik TI memiliki kemampuan.

📝 Pikiran Akhir tentang Pemodelan Layanan

Keterangkapan yang diberikan oleh membedakan Layanan Bisnis dan Layanan Aplikasi sangat diperlukan untuk arsitektur perusahaan yang sukses. Ini menciptakan peta yang dapat dibaca pemangku kepentingan dan diikuti pengembang. Tanpa perbedaan ini, model menjadi diagram abstrak yang gagal membimbing implementasi.

Fokus pada nilai yang diberikan oleh Layanan Bisnis dan kemampuan yang disediakan oleh Layanan Aplikasi. Pertahankan lapisan yang terpisah tetapi terhubung. Disiplin ini memastikan bahwa arsitektur tetap relevan seiring perkembangan organisasi.

Dengan mematuhi prinsip-prinsip ini, arsitek membangun model yang bukan hanya dokumentasi, tetapi alat untuk transformasi.