Comments 6
Вот это да, целый живой архитектор предприятия на хабре.
А у меня к Вам есть следующие вопросы:
1.1 Почему модель BIAN Вы называет «референсной моделью»? Поясню. В тех открытых материалах, которые указали Вы и доступны на сайте BIAN, нет никаких конечных моделей какого-либо домена. Всё что я вижу это архитектурный фреймворк, который выдвигает предположение и методику, по которой всю деятельность банка можно представить независимыми сервисными доменами. И предлагается сервисный ландшафт из этих доменов. Если зайти в репозиторий BIAN, то там можно увидеть так называемые спецификации доменов, которые настолько верхнеуровневые, скудные и настолько технические, что показывать их представителям бизнеса я бы не решился.
Разве это «референсная модель»? Это даже не референсная архитектура, это какой-то фреймворк с набором шаблонов. Где на сайте BIAN говорится что BIAN model это референсная модель?
1.2 Почему нет иерархии представлений (как уровни в eTOM)?
2.1 На рисунке 1. «Принципы и методы проектирования» указано: «Вся бизнес-деятельность может быть представлена в виде обмена услугами (сервис-операциями) между сервисными доменами». Вопрос: Вы действительно считаете, что посредством сервисов можно представить управление предприятием, в данном случае банком?
2.2 В пункте «Экскурсия по стандарту» вашей статьи Вы рассматриваете бизнес-домен «Business Direction» это по как раз «Управление». Там есть сервисный домен «Непрерывное планирование». Вопрос: Как с помощью сервисов организовать непрерывное планирование?
3 В статье есть такое предложение:
Про какой именно стандарт SOA Вы говорите?
А у меня к Вам есть следующие вопросы:
1.1 Почему модель BIAN Вы называет «референсной моделью»? Поясню. В тех открытых материалах, которые указали Вы и доступны на сайте BIAN, нет никаких конечных моделей какого-либо домена. Всё что я вижу это архитектурный фреймворк, который выдвигает предположение и методику, по которой всю деятельность банка можно представить независимыми сервисными доменами. И предлагается сервисный ландшафт из этих доменов. Если зайти в репозиторий BIAN, то там можно увидеть так называемые спецификации доменов, которые настолько верхнеуровневые, скудные и настолько технические, что показывать их представителям бизнеса я бы не решился.
Разве это «референсная модель»? Это даже не референсная архитектура, это какой-то фреймворк с набором шаблонов. Где на сайте BIAN говорится что BIAN model это референсная модель?
1.2 Почему нет иерархии представлений (как уровни в eTOM)?
2.1 На рисунке 1. «Принципы и методы проектирования» указано: «Вся бизнес-деятельность может быть представлена в виде обмена услугами (сервис-операциями) между сервисными доменами». Вопрос: Вы действительно считаете, что посредством сервисов можно представить управление предприятием, в данном случае банком?
2.2 В пункте «Экскурсия по стандарту» вашей статьи Вы рассматриваете бизнес-домен «Business Direction» это по как раз «Управление». Там есть сервисный домен «Непрерывное планирование». Вопрос: Как с помощью сервисов организовать непрерывное планирование?
3 В статье есть такое предложение:
В совокупности руководства в деталях раскрывают подход стандарта BIAN для внедрения базовой модели ИТ-инфраструктуры, создаваемой по стандартам сервис-ориентированной архитектуры (SOA).
Про какой именно стандарт SOA Вы говорите?
Добрый день.
Спасибо за проявленный интерес к статье.
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.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.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, с компоновкой сервисов – это типичный шаблон «Хореография сервисов», который имеет свои проблемы сложности и не оптимальности.
все что я вижу тут и в репозитории это метамодель с описанием типовых 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-модель, реализующая реляционную модель».
По остальным вашим комментариям я не отвечаю, т.к. считаю, что это ваша точка зрения, и она имеет право на существование.
Прочитал статью сегодня второй раз, (вчера в первый).
Эту штуку имхо можно было (наверно) продать надцать лет назад.
А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».
Да и в целом, имхо, подход:
переворачивает с ног на голову.
Имхо, слабые места известны, и дальше начинается история по устранению слабых мест с… (тут какие-то ограничения). И если эта история масштабна и растянута по времени, и затрагивает разные уровни предприятия, то тут уже и появляется потребность в формальном описании задействованных в истории артефактов, действующих и будущих. Т.е. не схема выявляет слабые места, а согласно схеме движемся вперед для устранения слабых мест.
Эту штуку имхо можно было (наверно) продать надцать лет назад.
А сейчас… слабо представляю себе CEO, который бы поизучал подобные схемы и такой: «о-о-о, да у нас формирование стратегии провисло», или «о-о-о, да у нас оценка продуктов и услуг на боку».
Да и в целом, имхо, подход:
Применение международного стандарта BIAN позволит «оголить слабые места» в архитектуре всего предприятия
переворачивает с ног на голову.
Имхо, слабые места известны, и дальше начинается история по устранению слабых мест с… (тут какие-то ограничения). И если эта история масштабна и растянута по времени, и затрагивает разные уровни предприятия, то тут уже и появляется потребность в формальном описании задействованных в истории артефактов, действующих и будущих. Т.е. не схема выявляет слабые места, а согласно схеме движемся вперед для устранения слабых мест.
Добрый день.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
Sign up to leave a comment.
«Референтная модель BIAN» для банковской индустрии или как перестать изобретать велосипед