Референтная модель BIAN. Что нового и полезного для корпоративной архитектуры банка она предлагает?



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

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

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


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



    Одним из самых важных и кардинальный изменений, случившихся с референтной моделью BIAN, на мой взгляд, стал перевод ее в нотацию Archimate. Ее стало проще читать. Разработчики BIAN, видимо, не смогли не признать необходимость использования стандартной нотации для ее описания в целях дальнейшего распространения в профессиональных кругах. Модель для восприятия стала понятнее архитекторам, так как она описана на понятном архитекторам языке. Таким образом, версия BIAN 8.0 представлена на языке ArchiMate 3. Модель лежит в открытом доступе. Зарегистрировавшись в www.opengroup.org, каждый может самостоятельно скачать описание модели BIAN и всех ее компонентов в нотации Archimate.

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



    Следующий важный аспект, о котором стоит говорить, — это то, что Независимая некоммерческая ассоциация стандартов (Banking Industry Architecture Network (BIAN)) поддерживает и обновляет хранилище API для своих бизнес-доменов ландшафта.
    Разработчики BIAN нацелены на то, чтобы создать доступное хранилище качественных API и микросервисов, чтобы помогать банкам быстро и экономически эффективно модернизироваться.
    Исходные файлы для API из хранилища также опубликованы и доступны для скачивания после регистрации на портале (если у кого-то возникнут сложности с регистрацией — попробуйте зарегистрироваться в режиме «инкогнито» вашего браузера).

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

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


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

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

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



    Рисунок 1. Наложение BIAN Service Landscape на метамодель

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

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

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


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

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

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

    Functional Pattern, Asset Type и Action Term


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

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

    Рисунок 3. Выделенные функциональные шаблоны

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

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

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

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

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

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

    Generic Artifact и Control Record


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

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

    Рисунок 8. Набор общих артефактов

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

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

    Service Operations


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

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

    Message и Condition


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


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

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

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

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

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


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

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

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

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

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

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

    Возможный подход к применению стандарта


    Опишу верхнеуровневый подход применения референтной модели BIAN:
    Главное, на что стоит обратить внимание, — что модель предлагает использовать не процессный подход, а микросервисный.
    1. Т.е. ландшафт — это некий набор высоуровневых кирпичиков (сервисных доменов),
    2. каждый домен имеет свой набор инструментов (сервисных операций)
    3. для работы с некими артефактами (ресурсами).

    И мы из этих кирпичиков уже собираем нужный нам процесс. Но нам в этом еще и помогает уже спроектированный набор диаграмм последовательностей, wireframes, объектная модель.
    Т.е. через эти представления для многих процессов связи уже спроектированы.

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

    Системный архитектор,
    © Ирина Блажина
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 3

      +1
      Потрясающая статья! Спасибо! В дополнение можно сказать что не только BIAN двигается навстречу TOGAF. Но и TOGAF двигается навстречу… микросервисам. Уже вышел драфт намечающегося стандарта The Open Group Agile Architecture Framework™ Draft Standard, который можно скачать publications.opengroup.org/s192
        0
        Спасибо за обратную связь! И за полезную информацию! Очень интересно!
        +1
        Спасибо Вам! Ваши статьи опережают время… текущее в России иначе чем в мире.
        Вариант 7-ой версии модели в формате ArchiTool также можно скачать здесь github.com/wilmerkrisp/bian.
        В настоящее время компания RedHat планирует построить open source рефернсную имплементацию и демку использующую модули и BIAN компоненты. Ждем с нетерпением!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое