HimeraSearchDB
Carding_EbayThief
triada
CrackerTuch
d-shop
HimeraSearchDB

НОВОСТИ BIAN… как мало в этом звуке для сердца русского…

Bonnie
Оффлайн
Регистрация
12.04.17
Сообщения
19.095
Реакции
107
Репутация
0
ci9cxwwcuxckbswufnsvj3wisf4.png


Да, я не случайно перефразировала всем известного классика. В России популярность референтной модели BIAN все еще низкая, особенно в сравнении с моделью Enhanced Telecom Operations Map (eTOM), распространенной в опережающей по своему развитию телекоммуникационной отрасли. А между тем, модель BIAN развивается, совершенствуется и набирает за пределами России и в международном сообществе банковской индустрии.

Не стану более отвлекать читателя на лирические отступления, скажу только, что обзор модели BIAN и сопроводительных документов стандарта есть в первой моей , здесь же постараюсь рассказать о тех изменениях, которые произошли с моделью.

Что нового и интересного?


BIAN стал доступнее


r3jsv7vidqtywbuyufhyqmrocls.png

Одним из самых важных и кардинальный изменений, случившихся с , стал перевод ее в . Очевидно, что разработчики BIAN не смогли не признать необходимость использования стандартной нотации для ее описания в . Модель для восприятия архитекторам, так как она описана на понятном архитекторам языке. Таким образом, версия представлена на языке . Модель лежит в . Более того, зарегистрировавшись в , каждый может самостоятельно модели BIAN и всех ее компонентов в нотации Archimate.

Имплементация BIAN в API


otf1i5_qlwgs0uonz5e_xbvry-y.png

Следующий важный аспект, о котором стоит говорить, — это то, что Независимая некоммерческая ассоциация стандартов ( ) поддерживает и обновляет бизнес-доменов ландшафта.
Согласно BIAN, банк делится на три ключевых слоя:
  1. Инфраструктурный уровень охватывает общие услуги и функции;
  2. Прикладной уровень представляет собой ландшафт информационных технологий со всеми его приложениями и связями;
  3. Бизнес-уровень охватывает направление деятельности банка и его бизнес-возможности.

«Мы очень рады объявить о новых дополнениях, внесенных в наше . После запуска портала в октябре прошлого года команда продолжила напряженную работу по разработке новых API, предназначенных для решения насущных бизнес-задач, с которыми банки сталкиваются в настоящее время. Мы по-прежнему нацелены на то, чтобы создать доступное хранилище высококачественных API и микросервисов, чтобы помочь банкам быстро и экономически эффективно модернизироваться.”, — .
Исходные файлы для также опубликованы и доступны для скачивания после регистрации на портале (если у кого-то возникнут сложности с регистрацией — попробуйте зарегистрироваться в режиме „инкогнито“ вашего браузера).



BIAN-это совместная некоммерческая экосистема, созданная ведущими банками, поставщиками технологий, консультантами и учеными со всего мира. И теперь BIAN предлагает свою . Но не бесплатно).
Эта сертификация предназначена для тех предприятий, бизнес-архитекторов и архитекторов решений в сфере финансовых услуг (FSI), которые заинтересованы в применении отраслевого стандарта BIAN в своей организации.
Более подробно каждый может ознакомиться .

И на закуску...


Учредители BIAN периодически проводят открытые вебинары, но не так часто, как хотелось бы. Чаще проводятся закрытые. Так вот, в ближайшее время как раз .
КогдаО чем

5xp9lrwuc2gvruibnszek0re6ls.png


На вебинаре будет представлен
основной контент и освещены изменения,
усовершенствования и расширения,
внесенные в стандарт BIAN в последней редакции.
Последнее руководство пользователя
BIAN Semantic API (
доступно последнее неизмененное издание) отражает все извлеченные уроки,
а также поправки и усовершенствования
к спецификациям BIAN, сделанные в результате опыта последних 18 месяцев нашими членами,
разрабатывающими API BIAN.

В руководстве рассматриваются
основные концепции
и результаты проектирования BIAN,
различные типы технических сред,
которые необходимо учитывать при разработке API,
а также представлены некоторые высокоуровневые
рекомендации по реализации спецификаций
для проектов разработки.

Мне хочется успеть поделиться с читателями последними новостями, и, возможно, кто-то захочет самостоятельно задать вопросы на вебинаре. Поэтому я буду спешить опубликовать статью за несколько дней до его начала, но из-за этого что-то в моей статье может выйти скомкано или неаккуратно. Прошу меня не судить за это строго.

Далее подробнее изучим метамодель BIAN в нотации Archimate и ее имплементацию в виде API.

Метамодель BIAN в нотации Archimate


В данной части я предлагаю рассмотреть текущую структуру в нотации Archimate с опорой . Этот документ является практическим руководством для бизнес-менеджеров, бизнес-архитекторов, менеджеров по изменению бизнеса, ИТ-директоров, корпоративных архитекторов, архитекторов решений, ИТ-руководителей, ИТ-специалистов и всех лиц, интересующихся управлением всей архитектуры финансового предприятия. Он предлагает варианты гибкой, бережливой и стабильной разработки банковской архитектуры с использованием языка ArchiMate и BIAN.

Итак, начнем с описания BIAN.

Элементы ландшафта BIAN


ga8sle4g5jr0iyq4fmoigwqau0c.jpeg

Рисунок 1. Наложение на

Ландшафт иерархически сформирован из следующих ключевых базовых компонентов:
  • Business Area (Бизнес – направление) — зеленый;
  • Business Domain (Бизнес – область) — оранжевый;
  • Service Domain (Сервисный домен) — голубой.

Business Area в терминах Archimate выражена . Business Domain и Service Domain отражены на схеме элементом .
По правилам нотации Capability используется для представления на высоком уровне текущих и желаемых возможностей организации в отношении ее стратегии.

Бизнес–направление (Business Area) позиционируется на самом высоком уровне иерархии ландшафта BIAN и используется для выделения и группирования в блоки ключевых направлений развития в финансовых институтах.
BIAN определила следующие бизнес-направления в рамках эталонной модели BIAN:
  1. справочные данные;
  2. продажи и обслуживание;
  3. операции и исполнение;
  4. риски и комплаенс (+аналитика);
  5. поддержка бизнеса.


Бизнес–области (Business Domains) архитекторы банковских предприятий определяют как разложение банковского бизнеса на совокупность взаимоисключающих, в своей совокупности полностью исчерпывающих бизнес-возможности предприятия. Бизнес–области определяют сегменты банка, рассматриваемые архитекторами банковского бизнеса с функциональной и архитектурно-технической точки зрения.

Сервисный домен (Service Domain) — это элементарный или атомарный функциональный строительный блок в рамках ландшафта BIAN.
Каждый сервисный домен предлагает набор сервисов (Service Group). Этот набор включает в себя сервисные операции (Service Operation). Сервисный домен — это набор сервисных операций, которые совместно управляют полным жизненным циклом некого ресурса (Asset Type).
0dypnalgeqxmwnkqcoanr2pshpa.png

Рисунок 2. Ключевые элементы сервисного домена на метамодели BIAN

Functional Pattern, Asset Type и Action Term


Главный прием, используемый для „изоляции“ сервисного домена BIAN (т.е. выделения его в качестве атомарной, неделимой единицы ландшафта), заключается в применении (Functional Pattern) к ресурсу (Asset Type).
Если мы посмотрим определение элементов Archimate, то увидим, что для Functional Pattern используется , а для Asset Type — .

Asset Type — какая-либо материальная или нематериальная вещь, на которую банк имеет право собственности и/или влияние, и имеет одно или несколько неотъемлемых видов использования или целей, создающих коммерческую ценность.
Functional Pattern — поведение или механизм, который может быть применен к какому-либо ресурсу при осуществлении коммерческой деятельности (например, проектировать, направлять, управлять, регистрировать и т.д.)
rulht_guvfad8gea9p8twnx_alg.png

Рисунок 3. Выделенные

BIAN также определил стандартный набор действий (Action Term), характеризующих различные виды сервисных операций. Каждая сервисная операция выполняет ровно одно действие.
Полный список Action Term (представленных в виде бизнес-функций ArchiMate) приведен ниже.
ckiwpki7tt27b4a_vb2ykdmjeqo.png

Рисунок 4. Стандартный набор действий ( )

Набор действий (Action Term), которые вместе образуют повторяющийся тип поведения, называется функциональным шаблоном.
В стандарте BIAN приводится очень удобная и наглядная матрица связи функциональных шаблонов и стандартных операций:
3s8mq0hi9b0rd7rpkynqsf2-zhs.png

Рисунок 5. Связь функциональных паттернов и стандартных операций

Т.е. в чем основная идея? Мы можем практически любую деятельность банка спроектировать и реализовать через заданный, ограниченный набор операций!
Каждый сервисный домен при этом содержит только один основной функциональный шаблон с одним типом ресурса. И мы получаем ресурс, к которому мы можем применить тот или иной шаблон. При этом число шаблонов также конечно и весьма не велико в сравнении с числом бизнес-доменов на ландшафте!
Далее мы видим из метамодели BIAN, что функциональный шаблон, агрегирующий в себе некий набор стандартных операций как раз и реализует сервисные операции (фиолетовым обозначено на рисунке ниже), включенные в сервисную группу, также реализующую функциональность сервисного домена:
pcsiegxufe176nqkuyyqruxkgqi.png

Рисунок 6. Связь функциональных паттернов и сервисных операций
А как мы уже выяснили выше, набор сервисных операций совместно управляют полным жизненным циклом некого ресурса (Asset Type).
Итого, мы получаем связь: Service Domain — сервисный домен (функциональность, которая нам нужна для бизнеса) -> Asset Type — заданный ресурс сервисного домена (с чем мы будем работать для реализации нашей задачи, например, ипотечный кредит) -> Functional Pattern — функциональный шаблон (поведение, характеризующее действия с нашим ресурсом)».

Generic Artifact и Control Record


Теперь рассмотрим еще одну группу элементом метамодели, обозначенных на рисунке ниже выделением цветом.
kopmanqg4ddig8sxvskqdftrvo8.png

Рисунок 7. Общий артефакт и контрольная запись
Функциональный шаблон — это достаточно высокий уровень абстракции (из метамодели также ясно, что он реализуется более конкретными сервисными операциями, но об этом я еще скажу позже, когда мы рассмотрим связь на конкретном примере).
И поэтому артефакт, на который он непосредственно воздействует, также абстрактен. Он называется общим артефактом (Generic Artifact). Для каждого функционального шаблона BIAN определил один общий артефакт, как показано на рисунке ниже:
49zj2skyiq8g4y6-ewbjwrjcip4.png

Рисунок 8.

Контрольная запись (Control Record) представляет собой информацию, необходимую для решения внутренних задач сервисного домена. Это некий журнал сведений о жизненном цикле ресурса, к которому обращается функциональный шаблон в соответствии с экземпляром общего артефакта или в результате которого он создается.
Если, например, ресурс — «текущий счет», функциональный шаблон — " ", а связанный общий артефакт — " ", то конкретная Контрольная запись — ”Обязательство выполнения (задач для) текущего счета".
Имя контрольной записи — это объединение имени ресурса и имени общего артефакта. Сервисный домен «текущий счет» будет предоставлять услуги, связанные с «организацией исполнения текущего счета».
Контрольную запись можно рассматривать как информацию о жизненном цикле «квалифицированного ресурса», где квалификатором является общий артефакт.
oyb4r9ygh9znsx4bhskedbcmrq4.png

Рисунок 9. Пример домена " "

Service Operations


«Сервисная операция» — это конкретное действие, исполненное на заданном ресурсе. Это элементарная услуга.
В примере сервисного домена " " сервисный домен способен выполнять «intiateCurrentAccountFulfillment», «executeCurrentAccountFulfillment» и т. д., которые представляют собой термины действия, агрегированные в функциональном шаблоне и применяемые к контрольной записи.
Т.е. если мы наложим сервисные группы на матрицу с операциями, то будет понятно, какие действия нам необходимо выполнять с нашим ресурсом:
lvt2hocofcp_irauhzidrcf7i8y.png

Рисунок 10. Пример наложения Action Term на Service Group
Сервисные операции по исполнению «текущего счета» являются производными от условий действия функционального шаблона. Сервисные операции организованы в сервисные группы.

Message и Condition


Исполнение сервисных операций возможно только через четко определенные интерфейсы. Каждая сервисная операция требует возникновения события, чтобы иметь возможность «доставить» услугу. Этим событием будет тип сообщения, который называется (Message). Сервисная операция будет реализована посредством некоторой внутренней обработки, возможно, делегирования некоторых задач другим сервисным операциям. В результате сервис выдаст ответ в качестве выходящего сообщения. Сообщение, которое является входным сообщением для одной операции обслуживания, может быть выходным сообщением для другой операции обслуживания.

we_k96g5vmakmf6v1eu6b263q48.png

Рисунок 11. Входящие/исходящие сообщения и условия исполнения сервисных операций

В описании сервисного домена также приводятся существующие зависимости от других доменов.
В частности, пример , из которых ожидаем получения входящего сообщения:
wsztqwae9advd_ll5rtwqimzqbc.png

Рисунок 12. Пример связи с другими доменами для «Текущего счета»

Итого, мы рассмотрели все элементы метамодели BIAN. И пора уже переходить к имплементации модели BIAN на API. Но перед тем, как это сделать, хочу обратить внимание, что модель содержит в себе гораздо больше представлений ее описания. Есть как объектное описание, диаграммы последовательностей, wireframes и другие.
Предлагаю читателям ознакомиться с ними самостоятельно по .
А также с сравнением .

Реализация модели BIAN через API


Как и было сказано выше, сообществом разработчиков BIAN разрабатывается и регулярно пополняется хранилище REST сервисов, соответствующих принципам стандарта BIAN.
Для ознакомления, необходимо зарегистрироваться на (я уже это сделала), перейти в хранилище и либо скачать исходные файлы, либо для ознакомления перейти в консоль.
ushooelvuvay-xgv6klshckfakc.png

Рисунок 13. Пример навигации по хранилищу API BIAN

В режиме консоли возможно ознакомиться с документацией в Swagger:
9biv6lv0sup_hnlqwnxe65_ydla.png

Рисунок 14. Пример навигации по хранилищу API BIAN для сервисного домена Current Account
Либо поработать с кодом:
kcpgcjvsuvmyff7t74hg9eqvua4.png

Рисунок 15. Доступ к исходным файлам API хранилища BIAN

Для упрощения понимания, как воспользоваться интерфейсами API, можно прочесть . Предлагаю читателям и разработчикам уже освоить эту часть работы с BIAN самостоятельно, либо участвовать в вебинаре, где будет возможность получить информацию из первых уст, и задать интересующие вопросы в конце вебинара.
Что касается меня, то я также бы хотела дождаться вебинара перед тем, как делать детальное описание технической составляющей.

Системный архитектор,
© Ирина Блажина
 
Сверху Снизу