Добрый день ! Спасибо. 1. Да, мы дополняем ADR контекстом стандартов. Первым пошел интеграционный стандарт. По поводу "описания бизнес-домена". Контекст нам кажется существует на разных уровнях принятия решений, соответственно контекст соответствует все тем же разным уровням архитектуры: от стратегической до системы. Например, на уровне стратегической архитектуры используем карту ИТ-ландшафта: cписок всех систем, их владельцев и зоны ответственности. Это нужно, чтобы агент понимал, куда можно интегрироваться, а куда — нет. Ну и далее по всем уровням... 2. Обновление репозиторием (для обновления контекста) правильнее нам кажется делать в run/delivery процессах 3. Что касается создания контекста для агентских систем, то здесь наверное появился повод еще одну статью написать ) если кратко, то там все крутится вокруг репозитория (git), ĸаĸ базовой единицей ĸонтеĸста, в границах ĸоторой фиĸсируются изменения, ограничения и архитеĸтурные решения
itGuevara4 часа назад, спасибо, что потратили время и прочитали :) спасибо за вопросы !
Ответы ниже:
Есть ли DSL-язык для описания архитектуры (текстовый и для человека) и онтология, метаМодель, но более проработанная, чем в TOGAF \ ArchiMate? При наличии такого DSL и с ИИ было бы удобнее разговаривать.
В качестве DSL сейчас используем YAML-описание связей ИТ-компонентов (и их API) с шагами бизнес-процессов, но это отдельный проект, ориентированный больше на бизнес-мониторинг и создание контекста для ИИ. В самом же EA Tool присутствует ИИ-ассистент, использующий RAG, на основе данных микросервисов, образующий репозиторий (данные , конечно, кладет в векторную базу и далее по референсной схеме).
Метамодель (онтология) конечно же есть, в ней сейчас более 30 сущностей, охватывающих в основном бизнес-архитектуру, архитектуру данных и прикладную ИТ-архитектуру.
Как ваш EA Tool связан с 072 формой, которую сдаете в ЦБ? В ней же основная архитектура «до винтика» прописана, включая привязку к бизнес-процессам, звенья ИС, источник \ получатель данных между ИС и т.п.
Мы воспринимаем форму 072 просто как еще один viewpoint/отчет на основе репозитория (я бы не сказал, что в ней вся архитектура "до винтика"). Данные для этого нашей метамоделью предусмотрены. Ну и скажу, что архитектура - все это пирог слоистый и описать, как выглядит сбор любой формы, например, 072, можно по разному: можно для уровня Правления, можно для мидл-уровня, можно "до винтиков" для команд - для этого нужны разные объекты репозитория.
сейчас российский рынок сконцентрирован на рутинной замене устаревших инструментов типа Sparx, Alfabet или ARIS.
Чем же они устаревшие? Желательно списочек устаревшего.
Если коротко, они устарели прежде всего морально, т.к. изначально строились под EAM фреймворки типа TOGAF, которые по мне так не отвечают современным требованиям (отдельная занятная дискуссия для исследователей TOGAF: а был ли когда-то вообще смысл в этих фреймворках для организаций, если убрать плюсы сертификации для личного брендинга ?). А теперь к ним спешно прикручивают сбоку ИИ (опять таки в рекламных целях, без особенного понимания, как будет выглядеть сама профессия архитектора в связи с появлнием ИИ). Вообще перечислять здесь слишком долго (монолит опять таки со всеми вытекающими; морока в событийку с инструментами производственного процесса или инструментами динамической инфраструктуры; не ясно, как встраивать в корпоративные стандарты разработки пользовательских сервисов, сохраняя единый клиентский путь; как Architecture as a Code прикручивать к условному alfabet мне тоже не очевидно; если мы везде про API-first культуру, то как работать с "вшитыми" API из "коробок" тоже вопросы и пр.). Думаю, что стоит посвятить этой теме отдельную статью.
В сторону семантики смотрели (не совсем ЕА, но принцип такой-же, а нотацию \ онтологию можно любую добавить)?
Смотрим и очень активно, т.к. понимаем, что для AI-driven предприятия нужно стоить не просто цифровой двойник, а именно семантический !
Информационные системы сразу привязываются к бизнес-способностям. Вся эта структура в EA
Вообще ссылки на opengroup.org лучше не давать - к многим материалам не пускают без регистрации (и регистрация там тоже не простая). Лучше ссылки на копию \ зеркало с материалами.
Понимаю. Вообще на тему бизнес-способностей правильнее было дать ссылку на BizBOK, но он платный, поэтому ограничились TOGAF. Ссылка дана в общеобразовательном смысле. На наш взгляд техника Capability based planning для многих крупных корпораций остается чем-то "инновационным" и не заслуженно забытым :(
Вся эта структура в EA Tool напрямую мапится на нашу референсную модель, построенную на базе собственного архитектурного фреймворка. Благодаря этому, мы говорим с бизнесом на одном языке и чётко видим, какие конкретно ИТ-активы поддерживают ту или иную ценность для клиента. Архитектура перестаёт быть сухой схемой и становится оцифрованным бизнес-активом.
Не верится. Есть, что показать? Прикажите ИИ хотя бы сформировать и выгрузить онтологию вашего EA Tool в OWL и положите на github (она не будет содержать ваших данных по системам, только МетаМодель).
У нас есть Value Stream Maps для ключевых потоков ценности (VS), на которых отображается связь стадий VS с бизнес-способностями и далее бизнес-функциями, ИТ-системами и бизнес-данными. По сути это ключевая модель для общения с теми, кто за доходную часть бюджета отвечает :) Представление метамодели в виде OWL у нас есть, возможно опубликуем когда-нибудь после обсуждения с нашей ИБ и compliance.
Где ссылка на github вашего "волшебного" EA Tool? Вообще, к какому прототипу наиболее близок ваш EA Tool?
Наружу пока не выкладывали и честно говоря не планировали. Насчет прототипа сложно определенно сказать, поскольку EA Tool «затачивается» под наши процессы, но в целом наверное можно сказать, что это model-first EAM инструмент.
Неужели без ИИ \ RAG не собрать хороший EA Tool? Кстати тут обзор EA.
Спасибо за ссылку. У нас есть собственный опыт изучения и эксплуатации (в организациях, в которых работали ранее) некоторых из EAM-платформ, таких как Alfabet, Sparx, Bizzdesign, iServer, ADOIT. Я уверен, что дело не в тулах, а в целевом architecture governance. Он уже меняется , тулы просто будут следом меняться.
Добрый день ! Спасибо.
1. Да, мы дополняем ADR контекстом стандартов. Первым пошел интеграционный стандарт. По поводу "описания бизнес-домена". Контекст нам кажется существует на разных уровнях принятия решений, соответственно контекст соответствует все тем же разным уровням архитектуры: от стратегической до системы. Например, на уровне стратегической архитектуры используем карту ИТ-ландшафта: cписок всех систем, их владельцев и зоны ответственности. Это нужно, чтобы агент понимал, куда можно интегрироваться, а куда — нет. Ну и далее по всем уровням...
2. Обновление репозиторием (для обновления контекста) правильнее нам кажется делать в run/delivery процессах
3. Что касается создания контекста для агентских систем, то здесь наверное появился повод еще одну статью написать ) если кратко, то там все крутится вокруг репозитория (git), ĸаĸ базовой единицей ĸонтеĸста, в границах ĸоторой фиĸсируются изменения, ограничения и архитеĸтурные решения
itGuevara4 часа назад, спасибо, что потратили время и прочитали :) спасибо за вопросы !
Ответы ниже:
В качестве DSL сейчас используем YAML-описание связей ИТ-компонентов (и их API) с шагами бизнес-процессов, но это отдельный проект, ориентированный больше на бизнес-мониторинг и создание контекста для ИИ. В самом же EA Tool присутствует ИИ-ассистент, использующий RAG, на основе данных микросервисов, образующий репозиторий (данные , конечно, кладет в векторную базу и далее по референсной схеме).
Метамодель (онтология) конечно же есть, в ней сейчас более 30 сущностей, охватывающих в основном бизнес-архитектуру, архитектуру данных и прикладную ИТ-архитектуру.
Мы воспринимаем форму 072 просто как еще один viewpoint/отчет на основе репозитория (я бы не сказал, что в ней вся архитектура "до винтика"). Данные для этого нашей метамоделью предусмотрены. Ну и скажу, что архитектура - все это пирог слоистый и описать, как выглядит сбор любой формы, например, 072, можно по разному: можно для уровня Правления, можно для мидл-уровня, можно "до винтиков" для команд - для этого нужны разные объекты репозитория.
Если коротко, они устарели прежде всего морально, т.к. изначально строились под EAM фреймворки типа TOGAF, которые по мне так не отвечают современным требованиям (отдельная занятная дискуссия для исследователей TOGAF: а был ли когда-то вообще смысл в этих фреймворках для организаций, если убрать плюсы сертификации для личного брендинга ?). А теперь к ним спешно прикручивают сбоку ИИ (опять таки в рекламных целях, без особенного понимания, как будет выглядеть сама профессия архитектора в связи с появлнием ИИ). Вообще перечислять здесь слишком долго (монолит опять таки со всеми вытекающими; морока в событийку с инструментами производственного процесса или инструментами динамической инфраструктуры; не ясно, как встраивать в корпоративные стандарты разработки пользовательских сервисов, сохраняя единый клиентский путь; как Architecture as a Code прикручивать к условному alfabet мне тоже не очевидно; если мы везде про API-first культуру, то как работать с "вшитыми" API из "коробок" тоже вопросы и пр.). Думаю, что стоит посвятить этой теме отдельную статью.
Смотрим и очень активно, т.к. понимаем, что для AI-driven предприятия нужно стоить не просто цифровой двойник, а именно семантический !
Понимаю. Вообще на тему бизнес-способностей правильнее было дать ссылку на BizBOK, но он платный, поэтому ограничились TOGAF. Ссылка дана в общеобразовательном смысле. На наш взгляд техника Capability based planning для многих крупных корпораций остается чем-то "инновационным" и не заслуженно забытым :(
У нас есть Value Stream Maps для ключевых потоков ценности (VS), на которых отображается связь стадий VS с бизнес-способностями и далее бизнес-функциями, ИТ-системами и бизнес-данными. По сути это ключевая модель для общения с теми, кто за доходную часть бюджета отвечает :) Представление метамодели в виде OWL у нас есть, возможно опубликуем когда-нибудь после обсуждения с нашей ИБ и compliance.
Наружу пока не выкладывали и честно говоря не планировали. Насчет прототипа сложно определенно сказать, поскольку EA Tool «затачивается» под наши процессы, но в целом наверное можно сказать, что это model-first EAM инструмент.
Спасибо за ссылку. У нас есть собственный опыт изучения и эксплуатации (в организациях, в которых работали ранее) некоторых из EAM-платформ, таких как Alfabet, Sparx, Bizzdesign, iServer, ADOIT. Я уверен, что дело не в тулах, а в целевом architecture governance. Он уже меняется , тулы просто будут следом меняться.
Спасибо !