🖇️ 👩🏽‍🤝‍👨🏾 😨 Model referensi BIAN. Apa yang baru dan berguna untuk arsitektur perusahaan bank yang ditawarkannya? 💥 🧚🏻 🆗

BIAN ... betapa sedikit yang ada dalam suara ini untuk jantung orang Rusia ... Ya, itu bukan kebetulan bahwa saya parafrase klasik terkenal. Popularitas model referensi BIAN masih rendah di Rusia, terutama dibandingkan dengan model Enhanced Telecom Operations Map (eTOM), yang tersebar luas di industri telekomunikasi, yang berada di depan pengembangannya. Sementara itu, model BIAN mengembangkan, meningkatkan dan mendapatkan popularitas di luar Rusia dan di komunitas industri perbankan internasional.

Saya tidak akan lagi mengganggu pembaca dengan penyimpangan liris, saya hanya akan mengatakan bahwa peninjauan model BIAN dan dokumen yang menyertai standar ada di artikel pertama saya di BIAN, di sini saya akan mencoba memberi tahu bagaimana BIAN dapat bermanfaat bagi manajer bisnis, arsitek bisnis, arsitek perusahaan, arsitek solusi, spesialis TI, dan semua orang lain yang tertarik dalam mengelola seluruh arsitektur perusahaan keuangan. Dan juga tentang transformasi yang berguna kuncinya, menurut saya.

Apa yang baru dan menarik?

BIAN menjadi lebih terjangkau

Salah satu perubahan terpenting dan utama yang terjadi dengan model referensi BIAN , menurut saya, adalah terjemahannya ke dalam notasi Archimate . Ini menjadi lebih mudah dibaca. Para pengembang BIAN, tampaknya, tidak bisa tidak mengenali kebutuhan untuk menggunakan notasi standar untuk menggambarkannya agar lebih menyebar di kalangan profesional . Model persepsi telah menjadi lebih jelas bagi para arsitek, karena digambarkan dalam bahasa yang dapat dimengerti oleh para arsitek. Dengan demikian, versi BIAN 8.0 disajikan dalam bahasa ArchiMate 3 . Model berada dalam domain publik . Dengan mendaftar di www.opengroup.org , semua orang bisa mandiriUnduh deskripsi model BIAN dan semua komponennya dalam notasi Archimate.

Implementasi BIAN dalam API

Poin penting lainnya yang perlu disebutkan adalah bahwa Asosiasi Standar Nirlaba Independen ( Perbankan Arsitektur Industri Arsitektur (BIAN) ) memelihara dan memperbarui repositori API untuk domain bisnis lanskapnya.
Pengembang BIAN bertujuan untuk membuat repositori API dan layanan mikro berkualitas tinggi yang terjangkau untuk membantu bank memutakhirkan dengan cepat dan hemat biaya.
File sumber untuk API dari repositori juga diterbitkan dan tersedia untuk diunduh setelah mendaftar di portal (jika seseorang mengalami kesulitan mendaftar, cobalah mendaftar dalam mode penyamaran browser Anda).

Selanjutnya, kita akan memeriksa secara lebih rinci metamodel BIAN dalam notasi Archimate dan implementasinya sebagai API.

Metamodel BIAN dalam notasi Archimate

Pada bagian ini, saya mengusulkan untuk mempertimbangkan struktur lanskap BIAN saat ini dalam notasi Archimate berdasarkan dokumen dari OpenGroup . Dokumen ini menawarkan opsi untuk pengembangan arsitektur perbankan yang fleksibel, ramping, dan stabil menggunakan bahasa ArchiMate dan BIAN.

Jadi, mari kita mulai dengan menggambarkan metamodel BIAN.

Elemen Lansekap BIAN

Gambar 1. Overlay dari BIAN Jasa Landscape di metamodel

The BIAN Layanan Landscape lanskap hirarki terbentuk dari komponen dasar kunci berikut:

Area Bisnis - Hijau
Domain Bisnis (Area Bisnis) - Oranye;
Domain Layanan - Biru.

Area Bisnis dalam hal Archimate dinyatakan oleh elemen Pengelompokan . Domain Bisnis dan Domain Layanan tercermin dalam diagram oleh elemen Kemampuan .
Menurut aturan notasi, Kemampuan digunakan untuk mewakili pada tingkat tinggi kemampuan saat ini dan yang diinginkan organisasi dalam kaitannya dengan strateginya.

The Area Business (Area Business) diposisikan pada tingkat tertinggi hirarki dari lanskap BIAN dan digunakan untuk sorot dan kelompok di blok bidang utama pembangunan di lembaga keuangan.
BIAN mengidentifikasi area bisnis berikut dalam model referensi BIAN:

data referensi;
penjualan dan layanan;
operasi dan eksekusi;
risiko dan kepatuhan (+ analitik);
dukungan bisnis.

Area Bisnis (Domain Bisnis) yang ditentukan oleh para arsitek perusahaan perbankan sebagai penguraian bisnis perbankan menjadi satu kesatuan yang saling eksklusif, dalam totalitasnya benar-benar melelahkan peluang bisnis perusahaan. Area bisnis menentukan segmen bank yang dipertimbangkan oleh arsitek bisnis perbankan dari sudut pandang fungsional, arsitektur, dan teknis.

Sebuah Layanan Domain adalah sebuah blok bangunan fungsional SD atau atom dalam lanskap BIAN.
Setiap domain layanan menawarkan serangkaian layanan (Grup Layanan). Set ini termasuk Operasi Layanan. Domain layanan adalah serangkaian operasi layanan yang bersama-sama mengelola seluruh siklus hidup suatu aset (Jenis Aset).

2. BIAN

Functional Pattern, Asset Type Action Term

Teknik utama yang digunakan untuk “mengisolasi” domain layanan BIAN (yaitu, untuk mengisolasi sebagai atom, satuan terpisahkan dari lanskap) adalah untuk menerapkan sebuah Pola Fungsional ke sumber daya (Asset Type).
Jika kita melihat definisi elemen Archimate, kita akan melihat bahwa Interaksi Bisnis digunakan untuk Pola Fungsional , dan objek bisnis digunakan untuk Jenis Aset .

Jenis Aset - segala sesuatu yang berwujud atau tidak berwujud di mana bank memiliki hak kepemilikan dan / atau pengaruh, dan memiliki satu atau lebih kegunaan atau tujuan integral yang menciptakan nilai komersial.
Pola fungsional- perilaku atau mekanisme yang dapat diterapkan pada sumber daya apa pun dalam melakukan kegiatan komersial (misalnya, merancang, mengarahkan, mengelola, mendaftar, dll.)

Gambar 3. Templat fungsional khusus

BIAN juga mendefinisikan serangkaian tindakan standar ( Jangka Waktu Tindakan ) mencirikan berbagai jenis operasi layanan. Setiap operasi layanan melakukan tepat satu tindakan.
Daftar lengkap Term Action (direpresentasikan sebagai fungsi bisnis ArchiMate) diberikan di bawah ini.

Gambar 4. Kumpulan tindakan standar ( Istilah Aksi )

Seperangkat tindakan (Istilah Aksi), yang bersama-sama membentuk jenis perilaku berulang, disebut template fungsional.
The BIAN standar menyediakan matriks sangat nyaman dan intuitif komunikasi antara pola fungsional dan operasi standar:

Gambar 5. Komunikasi dari pola fungsional dan operasi standar

Itulah apa ide utamanya? Kami dapat merancang dan mengimplementasikan hampir semua aktivitas bank melalui serangkaian operasi tertentu yang diberikan!
Setiap domain layanan pada saat yang sama hanya berisi satu templat fungsional utama dengan satu jenis sumber daya. Dan kami mendapatkan sumber daya untuk menerapkan template ini atau itu. Apalagi jumlah template juga tentu tidak terlalu besar dibandingkan dengan jumlah domain bisnis di lanskap!
Lebih lanjut, kita melihat dari metamodel BIAN bahwa templat fungsional yang mengagregasi sekumpulan operasi standar tertentu dan mengimplementasikan operasi layanan (berwarna ungu ditunjukkan pada gambar di bawah), termasuk dalam kelompok layanan yang juga mengimplementasikan fungsi domain layanan:

Gambar 6. Hubungan pola fungsional dan operasi layanan
Dan, seperti yang sudah kami jelaskan di atas, serangkaian operasi layanan bersama-sama mengendalikan seluruh siklus hidup sumber daya tertentu ( Jenis Aset ).
Secara total, kami mendapatkan koneksi: Layanan Domain - domain layanan (fungsionalitas yang kami butuhkan untuk bisnis) -> Jenis Aset - sumber daya yang ditentukan dari domain layanan (dengan mana kami akan bekerja untuk mengimplementasikan tugas kami, misalnya, pinjaman hipotek) -> Pola Fungsional - template fungsional (tindakan karakterisasi karakter dengan sumber daya kami). "

Artefak Generik dan Catatan Kontrol

Sekarang perhatikan kelompok elemen metamodel lain, ditunjukkan pada gambar di bawah ini dengan menyoroti.

Gambar 7. Artefak umum dan catatan kontrol
Template fungsional adalah tingkat abstraksi yang agak tinggi (juga jelas dari metamodel bahwa itu diimplementasikan oleh operasi layanan yang lebih spesifik, tetapi saya akan membicarakan hal ini nanti ketika kita mempertimbangkan koneksi menggunakan contoh tertentu).
Dan artefak yang secara langsung mempengaruhi juga abstrak. Ini disebut artefak generik ( Artefak Generik ). Untuk setiap templat fungsional, BIAN mengidentifikasi artefak umum, seperti yang ditunjukkan di bawah ini:

Gambar 8. Satu set artefak umum,

Entri Kontrol ( Catatan Kontrol) adalah informasi yang diperlukan untuk menyelesaikan masalah internal domain layanan. Ini adalah semacam log informasi tentang siklus hidup sumber daya yang diakses oleh templat fungsional sesuai dengan turunan artefak umum atau sebagai hasil dari mana ia dibuat.
Jika, misalnya, sumber daya adalah "akun berjalan", templat fungsional adalah " pemenuhan ", dan artefak umum yang terkait adalah " Kewajiban ", maka catatan Audit spesifik adalah "Kewajiban untuk memenuhi (tugas untuk) akun saat ini."
Nama catatan audit adalah kombinasi dari nama sumber daya dan nama artefak umum. Domain layanan "akun saat ini" akan menyediakan layanan yang terkait dengan "organisasi pelaksanaan akun saat ini."
Catatan kontrol dapat dianggap sebagai informasi tentang siklus hidup "sumber daya yang memenuhi syarat", di mana kualifikasi adalah artefak umum.

Gambar 9. Contoh domain " akun saat ini "

Operasi layanan

"Operasi layanan" adalah tindakan khusus yang dilakukan pada sumber daya yang diberikan. Ini adalah layanan dasar.
Dalam contoh " akun saat ini " akun layanan, domain layanan dapat mengeksekusi "intiateCurrentAccountFulfillment", "executeCurrentAccountFulfillment", dll., Yang merupakan istilah tindakan yang dikumpulkan dalam templat fungsional dan diterapkan pada catatan kontrol.
Itu jika kita menempatkan kelompok layanan pada sebuah matriks dengan operasi, akan menjadi jelas tindakan apa yang perlu kita lakukan dengan sumber daya kita:

Gambar 10. Contoh melapiskan Istilah Tindakan pada Grup
Layanan Operasi layanan untuk mengeksekusi "akun berjalan" berasal dari kondisi templat fungsional. Operasi layanan diatur dalam kelompok layanan.

Pesan dan Ketentuan

Operasi layanan hanya dimungkinkan melalui antarmuka yang jelas. Setiap operasi layanan memerlukan acara untuk dapat "memberikan" layanan. Acara ini akan menjadi jenis pesan yang disebut Pesan Masuk . Operasi layanan akan dilaksanakan melalui beberapa pemrosesan internal, mungkin mendelegasikan beberapa tugas ke operasi layanan lainnya. Akibatnya, layanan akan mengeluarkan respons sebagai pesan keluar. Pesan yang merupakan pesan input untuk satu operasi pemeliharaan mungkin merupakan pesan output untuk operasi pemeliharaan lainnya.

Gambar 11. Pesan masuk / keluar dan kondisi pelaksanaan layanan

Domain layanan juga menjelaskan dependensi yang ada pada domain lain.
Secara khusus, contoh daftar domain layanan yang kami harapkan menerima pesan masuk:

Gambar 12. Contoh komunikasi dengan domain lain untuk

Total "Current Account" , kami memeriksa semua elemen metamodel BIAN. Dan inilah saatnya untuk beralih ke implementasi model BIAN pada API. Tetapi sebelum melakukan ini, saya ingin menarik perhatian pada kenyataan bahwa model tersebut mengandung lebih banyak representasi dari deskripsinya. Ada deskripsi objek, diagram urutan, gambar rangka, dan lainnya.
Saya mengundang pembaca untuk membiasakan diri dengan referensi mereka .
Dan juga dengan perbandingan model dan kerangka kerja Togaf .

Menerapkan Model BIAN melalui API

Sebagaimana disebutkan di atas, komunitas pengembang BIAN mengembangkan dan secara teratur mengisi kembali repositori layanan REST yang mematuhi prinsip-prinsip standar BIAN.
Untuk kenalan, perlu mendaftar di portal , pergi ke repositori dan unduh file sumber, atau pergi ke konsol untuk pengenalan.

Gambar 13. Contoh navigasi melalui repositori API BIAN

Dalam mode konsol dapat membaca dokumentasi di Swagger:

Gambar 14. Contoh repositori API Navigasi BIAN untuk domain layanan Akun Berjalan
baik untuk bekerja dengan kode:

Gambar 15. Akses ke penyimpanan file API asli BIAN

Untuk penyederhanaan memahami cara menggunakan API, Anda dapat membaca dokumen. Saya mengundang pembaca dan pengembang untuk sudah menguasai bagian ini bekerja dengan BIAN secara mandiri, atau untuk berpartisipasi dalam webinar, yang akan diadakan dalam waktu dekat, di mana akan ada kesempatan untuk mendapatkan informasi tangan pertama dan mengajukan pertanyaan di akhir webinar .
Konten utama akan disajikan di webinar dan perubahan, peningkatan dan ekstensi yang diperkenalkan ke standar BIAN dalam edisi terbaru akan disorot.

Kemungkinan pendekatan untuk penerapan standar

Saya akan menjelaskan pendekatan tingkat atas menggunakan model referensi BIAN:
Hal utama yang harus Anda perhatikan adalah bahwa model tersebut menyarankan tidak menggunakan pendekatan proses, tetapi pendekatan layanan-mikro.

Itu lanskap adalah seperangkat batu bata tingkat tinggi tertentu (domain layanan),
setiap domain memiliki seperangkat alat sendiri (operasi layanan)
untuk bekerja dengan artefak tertentu (sumber daya).

Dan kami sudah mengumpulkan proses yang kami butuhkan dari batu bata ini. Namun kami juga terbantu dalam hal ini dengan rangkaian diagram urutan, gambar rangka, dan model objek yang telah dirancang.
Itu melalui representasi ini untuk banyak proses komunikasi telah dirancang.

Adalah mungkin bagi perusahaan untuk:
1. mempelajari lanskap secara rinci, menyorotnya secara visual (dalam warna, bingkai atau dengan cara lain) domain-domain yang diperlukan untuk tujuan fungsionalnya (dimungkinkan untuk melapiskan dan memahami tingkat sistem di mana sistem data diduplikasi, Sebagai contoh, ini adalah salah satu pertanyaan sulit, menurut pendapat saya, yang muncul ketika mendesain arsitektur layanan-mikro, dan model BIAN menyarankan agar kita memikirkannya di tingkat bisnis).
2. Untuk mempelajari metamodel BIAN untuk memahami cara kerja setiap domain (saya harap ini akan membantu ulasan saya, yang saya lakukan di atas pada metamodel).
3. Unduh API yang diperlukan dari portal (atau pertama-tama pastikan bahwa set yang diperlukan sudah ada).
4. Jelajahi representasi lain dari model BIAN.
4. Gambarkan peta migrasi dengan mempertimbangkan arsitektur saat ini di perusahaan untuk transisinya ke layanan mikro.

Arsitek sistem,
© Irina Blazhina

Model referensi BIAN. Apa yang baru dan berguna untuk arsitektur perusahaan bank yang ditawarkannya?