— А что вам позволяет делать такие выводы?
— Собственный опыт. В частности, даже приводимые «справочники» дались не легко.
Главное отличие json от xsd — это отсутствие комплексных типов. Чтобы это отсутствие компенсировать, нужно будет использовать ключевые слова, обеспечивающие ссылочность схем. И то ограничение, что схема — это тип элемента «объект», может накладывать некоторые ограничения при включении ее в другую схему, там, к примеру, где нужно использовать другой тип. В xsd — это комплексный тип, который мы можем назначить элементу, а в json это, по факту, подключение элемента (типа object).
Т.е. приходится думать немного иначе, чем, когда проектируется xsd схема.
И есть сложность с описанием, например, дефолтных параметров, если они в списке задаются.
Плюс, популярный формат OpenAPI (aka Swagger) с JSON Schema совместим лишь частично, что вынуждает писать две очень похожих схемы или пользоваться только пересечением возможностей.
Думаю, это повод, чтобы обратиться к сообществу OpenAPI (aka Swagger) и предложить доработаться :)
Добрый день.
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
все что я вижу тут и в репозитории это метамодель с описанием типовых 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 раскладывается на уровни:
Возможно, приведенное представление будет Вам интересно в ваших стремлениях разложения по уровням представлений архитектуры.
Реляционная модель тут не причем, это чисто математическая модель (реляционная алгебра), она замкнута – все операции в ней прописаны.
Добрый день.
Спасибо за проявленный интерес к статье.
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 странице (и далее).
— Собственный опыт. В частности, даже приводимые «справочники» дались не легко.
Главное отличие json от xsd — это отсутствие комплексных типов. Чтобы это отсутствие компенсировать, нужно будет использовать ключевые слова, обеспечивающие ссылочность схем. И то ограничение, что схема — это тип элемента «объект», может накладывать некоторые ограничения при включении ее в другую схему, там, к примеру, где нужно использовать другой тип. В xsd — это комплексный тип, который мы можем назначить элементу, а в json это, по факту, подключение элемента (типа object).
Т.е. приходится думать немного иначе, чем, когда проектируется xsd схема.
И есть сложность с описанием, например, дефолтных параметров, если они в списке задаются.
Не очень удобно, на мой взгляд, так как описание не поддерживается в таком случае средствами визуализации. Но тем не менее, решение есть.
Думаю, это повод, чтобы обратиться к сообществу OpenAPI (aka Swagger) и предложить доработаться :)
Спасибо за ваше мнение.
По моему собственному опыту, то, что бывает очевидно мне, не всегда может быть очевидно другим людям. И наоборот.
И опыт же показывает, что, к сожалению, даже такое очевидное утверждение, что «в организации следует планировать, вести проектную деятельность» не всегда бывает очевидно на уровне управления. И привнесение этой мысли с опорой на стандарт может быть принято куда менее болезненно, нежели если это будет исходить только от одного из сотрудников.
Да, данный домен не самый заполненный. По-моему мнению, разработчики 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-модель, реализующая реляционную модель».
По остальным вашим комментариям я не отвечаю, т.к. считаю, что это ваша точка зрения, и она имеет право на существование.
Спасибо за проявленный интерес к статье.
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 странице (и далее).