Так как я заметил, что ты, Цезарь, уже много построил и продолжаешь строительство, я разработал определенные правила, чтобы ты сам смог оценить качество как уже существующих, так и будущих зданий.
Витрувий, архитектор времен Римской империи
Успешность и стабильность развития любого предприятия напрямую связаны с наличием у него качественной бизнес-архитектуры, которая включает в себя утверждения по поводу миссии и целей организации, основные факторы успеха, бизнес-стратегии, -структуры и -процессы.
В телекоммуникационных компаниях России давно уже прижилась практика применения референтной модели 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» описывают подходы работы со стандартом. В состав руководств на момент написания статьи входит:
- BIAN How-to Guide – INTRODUCTION TO BIAN V6.0
- BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0 – Документ ориентирован на бизнес-архитекторов и системных архитекторов. Здесь объясняются подходы для применения и реорганизации процессов с помощью стандарта BIAN.
- BIAN How-to Guide – DEVELOPING CONTENT V6.0 – Документ предназначен для участников рабочей группы BIAN. Объясняет принципы, шаблоны и инструменты, используемые при разработке стандарта.
- BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 – Целевой аудиторией документа являются технические специалисты, которым предстоит применение подходов BIAN при непосредственном внедрении (развертывании) систем.
- 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» иерархически сформирована из следующих представлений:
- Business Area (Бизнес – направление);
- Business Domain (Бизнес – область);
- 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)
ggo
23.10.2018 10:11Прочитал статью сегодня второй раз, (вчера в первый).
Эту штуку имхо можно было (наверно) продать надцать лет назад.
А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».
Да и в целом, имхо, подход:
Применение международного стандарта BIAN позволит «оголить слабые места» в архитектуре всего предприятия
переворачивает с ног на голову.
Имхо, слабые места известны, и дальше начинается история по устранению слабых мест с… (тут какие-то ограничения). И если эта история масштабна и растянута по времени, и затрагивает разные уровни предприятия, то тут уже и появляется потребность в формальном описании задействованных в истории артефактов, действующих и будущих. Т.е. не схема выявляет слабые места, а согласно схеме движемся вперед для устранения слабых мест.Archi-Blair Автор
23.10.2018 14:53Добрый день.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
gimatdinov
Вот это да, целый живой архитектор предприятия на хабре.
А у меня к Вам есть следующие вопросы:
1.1 Почему модель BIAN Вы называет «референсной моделью»? Поясню. В тех открытых материалах, которые указали Вы и доступны на сайте BIAN, нет никаких конечных моделей какого-либо домена. Всё что я вижу это архитектурный фреймворк, который выдвигает предположение и методику, по которой всю деятельность банка можно представить независимыми сервисными доменами. И предлагается сервисный ландшафт из этих доменов. Если зайти в репозиторий BIAN, то там можно увидеть так называемые спецификации доменов, которые настолько верхнеуровневые, скудные и настолько технические, что показывать их представителям бизнеса я бы не решился.
Разве это «референсная модель»? Это даже не референсная архитектура, это какой-то фреймворк с набором шаблонов. Где на сайте BIAN говорится что BIAN model это референсная модель?
1.2 Почему нет иерархии представлений (как уровни в eTOM)?
2.1 На рисунке 1. «Принципы и методы проектирования» указано: «Вся бизнес-деятельность может быть представлена в виде обмена услугами (сервис-операциями) между сервисными доменами». Вопрос: Вы действительно считаете, что посредством сервисов можно представить управление предприятием, в данном случае банком?
2.2 В пункте «Экскурсия по стандарту» вашей статьи Вы рассматриваете бизнес-домен «Business Direction» это по как раз «Управление». Там есть сервисный домен «Непрерывное планирование». Вопрос: Как с помощью сервисов организовать непрерывное планирование?
3 В статье есть такое предложение:
Про какой именно стандарт SOA Вы говорите?
Archi-Blair Автор
Добрый день.
(определение взяла здесь).Спасибо за проявленный интерес к статье.
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 странице (и далее).
gimatdinov
Не удовлетворит. Это сервисный домен «Бизнес-архитектура» из бизнес-домена «Управление бизнесом», все что я вижу тут и в репозитории это метамодель с описанием типовых CRUD операций над объектом «Спецификация архитектуры» + функции для отчета по архитектуре. Так можно сделать для любой абстрактной вещи в вакууме: CRUD + Report.
Как организовать нормальную работу над архитектурой? Как же многоуровневостью архитектуры по подразделениям? Как согласовывается архитектора? Кто исполнитель? Где другие сервисные операции? Где работа с архитектурным репозиторием, бизнес-доменами, ABB, SBB?
Реляционная модель тут не причем, это чисто математическая модель (реляционная алгебра), она замкнута – все операции в ней прописаны. В случае с BIAN вопрос не «Как?», а «Что?». И пока я вижу, «что» пусто.
Такой же тощий как сервисный домен «Бизнес-архитектура». Вообще, я считаю, что тот, кто писал этот домен, слабо представляет планирование в крупной организации.
Там говориться про Open Group, видимо, имеется виду Open Group SOA-RA, в котором есть процессный слой. Так что из Вашего ответа что:
Которая соответствует стандартам, следует что модель BIAN может условно «покрыть» только сервисный слой SOA-RA. Остальные нерешенные проблемы на откуп банку. А те схемы, что есть в документах BIAN, с компоновкой сервисов – это типичный шаблон «Хореография сервисов», который имеет свои проблемы сложности и не оптимальности.
Archi-Blair Автор
Да, данный домен не самый заполненный. По-моему мнению, разработчики 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 и сценарии значительно расширяют стандарт.
Для ответов на данные вопросы, могу предложить обратиться к методологии TOGAF в сочетании с BIAN. При таком подходе домен будет раскрыт полностью. И это не противоречит BIAN. Если что-то Вы находите недостаточно описанным, можно сочетать его с другими методологиями/стандартами.
Также сама архитектура BIAN раскладывается на уровни:
Возможно, приведенное представление будет Вам интересно в ваших стремлениях разложения по уровням представлений архитектуры.
Согласна, некорректно выразилась: «Концептуальная ER-модель, реализующая реляционную модель».
По остальным вашим комментариям я не отвечаю, т.к. считаю, что это ваша точка зрения, и она имеет право на существование.