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

Витрувий, архитектор времен Римской империи

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

В телекоммуникационных компаниях России давно уже прижилась практика применения референтной модели Enhanced Telecom Operations Map (eTOM), ориентированной на бизнес-процессы операторов услуг и других представителей индустрии информационно-коммуникационных технологий. Модель используется как шаблон для управления и реорганизации процессов, а так же для упрощения взаимодействия с партнерами и другими операторами услуг. В банковской же индустрии, к сожалению, на просторах России не применяют подход построения и анализа процессов с опорой на референтные модели, разрабатываемые международными организациями. Как небольшие микрофинансовые предприятия, так и крупные банки строят свои процессы, основываясь на опыте и ошибках своих сотрудников. Поисковый запрос о применении стандартизированных методик (международного уровня) для построения и анализа архитектуры предприятия в банковской индустрии в России выдает лишь одну компанию – поставщика IT-решений для финансового сектора (на момент написания данной статьи), принимающей участие как в разработке самого стандарта BIAN, так и при анализе своих решений. При этом часто встречается информация о том, что таких моделей попросту не существует, хотя это не так. Возможно, это связано с отсутствием в достаточной мере такого рода информации в русскоязычных специализированных (интернет-) сообществах.

Целью моей статьи является привлечение внимания к одной из таких моделей, а именно, к референтной модели BIAN, о которой пойдет речь ниже.

В своей статье для верхнеуровнего обзора стандарта BIAN я прибегну к частичному переводу документа «BIAN How-to Guide – INTRODUCTION TO BIAN V6.0» с акцентом на ключевые аспекты стандарта. Ознакомиться с документом можно по ссылке. Также при переводе я буду позволять себе делать отступления от оригинала и давать свои комментарии там, где посчитаю это необходимым.

1. Введение в BIAN (Banking Industry Architecture Network)


Banking Industry Architecture Network (BIAN) – это ассоциация архитекторов банков, поставщиков банковского программного обеспечения и провайдеров услуг с общей целью создания стандартной семантической среды банковских сервисов. По ожиданиям разработчиков BIAN классификация бизнес-функций и взаимодействий внутри любого банка в оформленном стандарте принесёт значительную пользу отрасли.

Основные документы, составляющие и дополняющие стандарт BIAN:

  • высокоуровневая карта сервисов «BIAN Service Landscape» — «Ландшафт сервисов»;
  • коллекция документов «BIAN How-to Guide»;
  • метамодель «BIAN Metamodel»;
  • определение бизнес-сценариев «BIAN Business Scenario»;
  • классификация на бизнес функции/области (сервис-домены) и их услуги (сервис-операции) «BIAN Service Domain Definitions»;
  • бизнес-словарь «BIAN business vocabulary»;
  • и объектная модель «BIAN Business Object Model».

Стандарт BIAN публикуется в репозитории с доступом на чтение к HTML версии, обратиться к нему можно через навигацию по веб-сайту BIAN bian.org. Кроме того, с каждой опубликованной версией стандарта BIAN ведется и выпускается сборник сопроводительных документов, включая серию руководств «How-to Guide».

Часто стандарт участниками ассоциации именуется как «BIAN Service Landscape». Более формальное название – «BIAN SOA Framework». Описание для разработчиков самого стандарта представлено во втором документе BIAN «How to Guide – Developing Content».

Содержание руководств «How-to Guide»


Документы «How-to Guide» описывают подходы работы со стандартом. В состав руководств на момент написания статьи входит:

  1. BIAN How-to Guide – INTRODUCTION TO BIAN V6.0
  2. BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0 – Документ ориентирован на бизнес-архитекторов и системных архитекторов. Здесь объясняются подходы для применения и реорганизации процессов с помощью стандарта BIAN.
  3. BIAN How-to Guide – DEVELOPING CONTENT V6.0 – Документ предназначен для участников рабочей группы BIAN. Объясняет принципы, шаблоны и инструменты, используемые при разработке стандарта.
  4. BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 – Целевой аудиторией документа являются технические специалисты, которым предстоит применение подходов BIAN при непосредственном внедрении (развертывании) систем.
  5. BIAN How-to Guide – SEMANTIC API V6.0 — Данный документ описывает, как стандарт BIAN может использоваться для разработки интерфейса прикладных программ (API). В ближайшее время планируется практическое руководство для разработчиков.

Каждый документ рассчитан на свою аудиторию.

В совокупности руководства в деталях раскрывают подход стандарта BIAN для внедрения базовой модели ИТ-инфраструктуры, создаваемой по стандартам сервис-ориентированной архитектуры (SOA).
Также стоит отметить, что совсем недавно стандарт BIAN рассматривался в контексте спецификации интерфейсов прикладного ПО (API) и адаптации его для микросервисных «архитектур».

Далее приводится краткий обзор по документам из серии «BIAN How-to Guide» под номерами 2, 3 и 4 из списка выше.

2. Принципы и методы проектирования (Design principles and techniques)


В стандарте BIAN для проектирования бизнес-архитектуры используется подход выделения областей бизнеса (сервисных доменов) и связанных услуг (сервис-операций), которые могут быть выделены и объединены в модели любого банка (или финансового предприятия). Модель BIAN является «канонической», что означает, что её можно использовать любым банком независимо от её последующих технических реализаций. Для определения «канонической модели BIAN» подход к её проектированию должен принципиально отличаться от более традиционных процессно-ориентированных методов. BIAN использует подход сервис-ориентированной архитектуры (SOA).

Схема ниже описывает ключевые идеи проектирования, используемые в стандарте BIAN:

Рисунок 1. Принципы и методы проектирования

С детальным описанием каждого блока на схеме можно ознакомиться непосредственно в BIAN How-to Guide – INTRODUCTION TO BIAN V6.0.

3. Разработка стандарта (Developing Content)


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


Рисунок 2. Разработка стандарта BIAN

С детальным описанием каждого блока схемы рисунка 2 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

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


Рисунок 3. Разработка содержимого стандарта BIAN

4. Применение стандарта BIAN (BIAN How-to Guide – Applying the BIAN Standard)


Стандарт BIAN выполняет общее разбиение бизнес-сферы по бизнес-функциям (на сервисные домены) и их услуги (семантические сервис-операции). Чтобы сопоставить эти стандартные модели с конкретной организацией, их нужно адаптировать, выбирая нужные домены, и объединять в соответствии с операционными возможностями и структурой организации. Затем концептуальные модели BIAN высокого уровня могут быть сопоставлены с более подробными техническими реализациями. Сервисные домены BIAN также могут использоваться в качестве «строительных» блоков при составлении «бизнес-плана» предприятия, который, в свою очередь, может использоваться при планировании и анализе. В третьем документе «Практического руководства BIAN» представлены первоначальные рекомендации по применению модели BIAN. На рисунке ниже представлена схема основных рекомендаций по применению стандарта на предприятии.


Рисунок 4. Применение стандарта BIAN

С детальным описанием каждого блока схемы рисунка 4 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Экскурсия по стандарту


И здесь же я хочу привести пример, демонстрирующий некоторые описываемые подходы из приведенных диаграмм руководства.

Карта сервисов «BIAN Service Landscape» иерархически сформирована из следующих представлений:

  1. Business Area (Бизнес – направление);
  2. Business Domain (Бизнес – область);
  3. Service Domain (Сервисный домен).

На карте самым «элементарным» компонентом является сервисный домен. Он же и считается неделимым.

Рассмотрим бизнес-направление «Поддержка бизнеса». В частности, посмотрим на бизнес-область «Направления бизнеса» с акцентом на сервисный домен (функцию) «Business Architecture» (Рисунок 5).


Рисунок 5. BIAN Service Landscape

При навигации по карте сервисов «BIAN Service Landscape» перейдем к обзору сервисного домена «Бизнес-архитектуры».


Рисунок 6. Обзор сервисного домена «Business Architecture»

Домен «Business Architecture» выделяет одноименный объект (Asset) «Business Architecture» с функциональным паттерном работы (pattern) над ним «Design». Артефактом будет являться спецификация «Specification».

Важно отметить, что любой домен на карте сервисов «BIAN Service Landscape» раскладывается на составляющие, описываемые в семантических терминах (таких как Asset Type, Functional pattern и др.) и переиспользуемые в других доменах.

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

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

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

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

Комментарии (6)


  1. gimatdinov
    21.10.2018 23:15

    Вот это да, целый живой архитектор предприятия на хабре.
    А у меня к Вам есть следующие вопросы:
    1.1 Почему модель BIAN Вы называет «референсной моделью»? Поясню. В тех открытых материалах, которые указали Вы и доступны на сайте BIAN, нет никаких конечных моделей какого-либо домена. Всё что я вижу это архитектурный фреймворк, который выдвигает предположение и методику, по которой всю деятельность банка можно представить независимыми сервисными доменами. И предлагается сервисный ландшафт из этих доменов. Если зайти в репозиторий BIAN, то там можно увидеть так называемые спецификации доменов, которые настолько верхнеуровневые, скудные и настолько технические, что показывать их представителям бизнеса я бы не решился.
    Разве это «референсная модель»? Это даже не референсная архитектура, это какой-то фреймворк с набором шаблонов. Где на сайте BIAN говорится что BIAN model это референсная модель?
    1.2 Почему нет иерархии представлений (как уровни в eTOM)?
    2.1 На рисунке 1. «Принципы и методы проектирования» указано: «Вся бизнес-деятельность может быть представлена в виде обмена услугами (сервис-операциями) между сервисными доменами». Вопрос: Вы действительно считаете, что посредством сервисов можно представить управление предприятием, в данном случае банком?
    2.2 В пункте «Экскурсия по стандарту» вашей статьи Вы рассматриваете бизнес-домен «Business Direction» это по как раз «Управление». Там есть сервисный домен «Непрерывное планирование». Вопрос: Как с помощью сервисов организовать непрерывное планирование?
    3 В статье есть такое предложение:

    В совокупности руководства в деталях раскрывают подход стандарта BIAN для внедрения базовой модели ИТ-инфраструктуры, создаваемой по стандартам сервис-ориентированной архитектуры (SOA).

    Про какой именно стандарт SOA Вы говорите?


    1. Archi-Blair Автор
      22.10.2018 12:07

      Добрый день.
      Спасибо за проявленный интерес к статье.
      1.1 Да, все верно, подход BIAN предлагает архитектурный фреймворк с методикой покрытия всей деятельности финансового предприятия в виде независимых сервисных доменов и сервисных операций для организации взаимодействия между ними, + ландшафт сервисов. А так же руководств по применению модели.
      Ответ на ваш вопрос содержится в самом определении референтной модели.

      Референтная модель — концептуальная модель, формализующая рекомендованные практики ведения бизнеса в определенной области.
      (определение взяла здесь).
      Моделью является карта сервисов «BIAN Service Landscape»
      С опорой на карту сервисов можно и нужно строить коммуникации с бизнесом. Самым высокоуровневым подходом будет выделение на карте тех сервисных доменов, которые в организации реализованы, плохо реализованы, или могут быть взяты на вооружение для дальнейшего развития (как пример). Так же в руководстве "BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0" приводятся другие примеры работы с моделью.
      Вы пишите: «нет никаких конечных моделей какого-либо домена» — не очень понимаю, какую именно модель домена Вы ожидаете увидеть. Возможно, рисунок 6 из данной статьи при внимательном рассмотрении Вас удовлетворит.
      Так же хочу обратить внимание, что модель является концептуальной. Она не предлагает готовых технических решений. Она задает единый подход. К примеру, реляционная модель данных в свое время позволила решить вопросы с организацией хранения данных без указания того, как должны реализовываться указанные в ней «правила».
      1.2 Данный вопрос скорее стоит адресовать разработчикам модели. Но возьму на себя смелость дать ответ за них. eTOM — это карта процессов, это референтная процессная модель, в то время как BIAN — это референтная сервисная (функциональная) модель. Разные типы моделей, разные виды представлений.
      2.1 Да, я разделяю мнение разработчиков BIAN.
      2.2 Согласно BIAN «непрерывное планирование» осуществляется через паттерн «управление» с наличием артефакта — «плана управления». + ряд сервисных операций. Так же фреймворк представляет Wireframe-ы, пользовательские сценарии, «вспомогательные» диаграммы (в фреймворке, например, BIAN_ISO20022->Helper Diagrams->Management Processes). Хотя стоит отметить, что и не для всех доменов есть доп.структуры. Но модель продолжают развивать.
      В чем именно вести проектную деятельность, модель не скажет, но какие минимальные функции у внедряемого/используемого инструмента должны быть, она укажет.
      3. Поддерживаемые подходы SOA детально описаны в BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 на 12 странице (и далее).


      1. gimatdinov
        22.10.2018 21:27

        1.1 …не очень понимаю, какую именно модель домена Вы ожидаете увидеть. Возможно, рисунок 6 из данной статьи при внимательном рассмотрении Вас удовлетворит.

        Не удовлетворит. Это сервисный домен «Бизнес-архитектура» из бизнес-домена «Управление бизнесом», все что я вижу тут и в репозитории это метамодель с описанием типовых CRUD операций над объектом «Спецификация архитектуры» + функции для отчета по архитектуре. Так можно сделать для любой абстрактной вещи в вакууме: CRUD + Report.
        Как организовать нормальную работу над архитектурой? Как же многоуровневостью архитектуры по подразделениям? Как согласовывается архитектора? Кто исполнитель? Где другие сервисные операции? Где работа с архитектурным репозиторием, бизнес-доменами, ABB, SBB?
        К примеру, реляционная модель данных в свое время позволила решить вопросы с организацией хранения данных без указания того, как должны реализовываться указанные в ней «правила».

        Реляционная модель тут не причем, это чисто математическая модель (реляционная алгебра), она замкнута – все операции в ней прописаны. В случае с BIAN вопрос не «Как?», а «Что?». И пока я вижу, «что» пусто.
        2.2 Согласно BIAN «непрерывное планирование» осуществляется через паттерн «управление» с наличием артефакта — «плана управления». + ряд сервисных операций.

        Такой же тощий как сервисный домен «Бизнес-архитектура». Вообще, я считаю, что тот, кто писал этот домен, слабо представляет планирование в крупной организации.
        3. Поддерживаемые подходы SOA детально описаны в BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 на 12 странице (и далее).

        Там говориться про Open Group, видимо, имеется виду Open Group SOA-RA, в котором есть процессный слой. Так что из Вашего ответа что:
        BIAN — это референтная сервисная (функциональная) модель.

        Которая соответствует стандартам, следует что модель BIAN может условно «покрыть» только сервисный слой SOA-RA. Остальные нерешенные проблемы на откуп банку. А те схемы, что есть в документах BIAN, с компоновкой сервисов – это типичный шаблон «Хореография сервисов», который имеет свои проблемы сложности и не оптимальности.


        1. Archi-Blair Автор
          23.10.2018 14:45

          все что я вижу тут и в репозитории это метамодель с описанием типовых CRUD операций над объектом «Спецификация архитектуры» + функции для отчета по архитектуре.

          Да, данный домен не самый заполненный. По-моему мнению, разработчики BIAN больше уделяют внимание доменам, приносящим добавленную стоимость организации, с «каркасами» в BIAN-> Wireframes, а не на процесс управления. При этом стоит понимать, что домены могут переиспользоваться в разных процессах из разных бизнес-направлений. К примеру, домен Document Services (Business Support-> Document Management and Archive) будет переиспользован из других бизнес-направлений, как показано на диаграмме последовательности бизнес-сценария (BIAN-> Wireframes-> Semantic API -> 1st Order Iteractions ->Document Services Invocation — Request Document Verification <>). Whireframes и сценарии значительно расширяют стандарт.
          Как организовать нормальную работу над архитектурой? Как же многоуровневостью архитектуры по подразделениям? Как согласовывается архитектора? Кто исполнитель? Где другие сервисные операции? Где работа с архитектурным репозиторием, бизнес-доменами, ABB, SBB?

          Для ответов на данные вопросы, могу предложить обратиться к методологии TOGAF в сочетании с BIAN. При таком подходе домен будет раскрыт полностью. И это не противоречит BIAN. Если что-то Вы находите недостаточно описанным, можно сочетать его с другими методологиями/стандартами.
          Также сама архитектура BIAN раскладывается на уровни:

          Возможно, приведенное представление будет Вам интересно в ваших стремлениях разложения по уровням представлений архитектуры.
          Реляционная модель тут не причем, это чисто математическая модель (реляционная алгебра), она замкнута – все операции в ней прописаны.

          Согласна, некорректно выразилась: «Концептуальная ER-модель, реализующая реляционную модель».

          По остальным вашим комментариям я не отвечаю, т.к. считаю, что это ваша точка зрения, и она имеет право на существование.


  1. ggo
    23.10.2018 10:11

    Прочитал статью сегодня второй раз, (вчера в первый).
    Эту штуку имхо можно было (наверно) продать надцать лет назад.
    А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».

    Да и в целом, имхо, подход:

    Применение международного стандарта BIAN позволит «оголить слабые места» в архитектуре всего предприятия

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


    1. Archi-Blair Автор
      23.10.2018 14:53

      Добрый день.
      Спасибо за ваше мнение.
      По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
      И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.