Спасибо за ваш комментарий. Мы действительно хотели создать инструмент, который помогает описывать сложный мир просто — без упрощенчества, которое стирает смысл. Не «заметая знания под ковёр», как это часто происходит в заметочниках, на досках или в обычных диаграммных инструментах, а позволяя сохранять их структуру, связи и эволюцию.
Обсидиан действительно сильно ограничивает возможности пользователя тк это все же записочник. Мы уже несколько лет командой ведем различные модели ( как самого продукта, так и для синхронизации множества команд которые я сопровождаю как архитектор ) например я рассказывал об этом подходе на Knowledge Conf KnowledgeConf 2025 - Профессиональная конференция по управлению знаниями
В одно лицо база знаний действительно собирается крайне плохо и не эффективно
В статье я пишу не про использование конкретного фреймворка или инструмента ( такого как mind-map, BPML-диаграмм ), а о том как можно описать контекст бизнес-ситуации.
mind-map вам не дает классификацию, bpmn вообще инструмент другого назначения. наиболее близким здесь является UML диаграмма вариантов использования. Сама по себе статья продолжает предыдущую про управление контекстами при переходе от бизнес языка к c4. Но они были на других платформах, в последствии я её тоже перенесу .
Добрый день! Да, всё верно — это взаимодополняющие инструменты. Александр как раз отмечает: «Если BPMN показывает лишь последовательность шагов процесса без возможности увидеть его архитектуру и детализацию на уровне межсистемного обмена, то C4 позволяет дополнить эту картину (а точнее, начать её формирование: сначала определить, что делаем, а уже затем — в какой последовательности). Особенно это полезно, если вы используете одинаковые лексические конструкции в названиях шагов процессов и бизнес-сервисов».
На самом деле простое и элегантное решение. Я пару недель назад прикрутил к нашему проекту Онто MCP сервер и теперь могу документировать элементы разработки непосредственно из интерфейса JetBrains используя ту нейросеть на которой у меня остались токены к примеру. Никак не дойдут руки до использования в агентной среде чата, но даже имеющиеся функции мне позволяют быстро серфить по графу знаний находя нужные мне модули и связи их с другими компонентами такими как фичи или пользовательские истории
возьмите опять же статьи Steve Andriole о ценности корпоративной архитектуры. Раз уж мы об этом взялись рассуждать. Корпоративная архитектура это способ поговорить двум командам? не дорогой ли переводчик с русского на русский? Может ему нужно зарплату уменьшить?
ну мы то все остальные в основном по детским садам работали. Поэтому да, примем ваши утверждения на веру. У меня есть утверждение генерального конструктора одного из банков побольше чем ваша организация раз в 20: корпоративная архитектура это когда не найдешь кто за что отвечает. Я вам привожу конкретный пример с сильным доменом которому наплевать на все идеи корпархитектуры. И у вас нет ни одного шанса сломать их родмап для включения в беклог хотя бы одной фичи которую их бизнес считает не целевой.
на стадии MVP есть код. В чем противоречия? Этот код должен быть обязательно развиваемым как решение. Тут тоже нет противоречий. Но этот код должен обеспечить уровень качества достаточным что бы переход от MVP к разработке не приводил к переходу от agile к водопаду как часто бывает. И не требовал построения космического корабля на старте. Если архитектор не может сбалансировать эти два требования возможно он так же профнепригоден
я прямо именно так и написал "Архитектор как фасилитатор у команд". Есть уровень решения (на земле) и тут архитектор тоже должен построить конвейер взаимодействия с экспертами не местах. К сожалению, чаще всего это происходит иначе. Болезнь башни из слоновой кости косит наши ряды особенно у неофитов которых вдруг назначили архитекторами, но не объяснили что есть такая вещь как польза. На уровне кроссдоменного взаимодействия тоже работает не всегда, мы же понимаем что есть жизнь и продакты сегмента КиБов легко шлют на*ер все мнения корпоративной архитектуры компании.
Тот факт, что мы продолжаем обсуждать проблемы, характерные для позапрошлого века, был очевиден уже из самой концепции шины данных. Замечу, что ещё в начале 2000-х годов я получил один из первых сертификатов Oracle по данной тематике.
Говорить сегодня о замене одной информационной системы на другую — по меньшей мере странно, учитывая, что подавляющее большинство компаний уже давно внедряют микросервисные архитектуры, а многие даже начали отходить и от них, переходя к новым парадигмам построения ИТ-ландшафта.
Я нигде не утверждал, что ИТ-концепции в принципе не нужны. Моё замечание касалось лишь того, что апеллировать к этим подходам как к некоему фундаментальному, монументальному достижению — когда соответствующие решения давно описаны, реализованы и внедрены в индустрии — выглядит, мягко говоря, не вполне современно.
Давайте упростим ситуацию, потому что, похоже, она действительно сложна вам для понимания.
Начну с вашего утверждения о какой-то мифической интеграции между системами — интеграции, о которой никто не знает, как она работает, но почему-то она работает. У этих систем что, нет собственных команд развития? Это уже многое говорит о "здоровье" ИТ-подразделения. Руководитель такого ИТ, на мой взгляд, профессионально непригоден и с точки зрения собственников должен быть заменен. Ему нельзя доверять ничего, кроме замены картриджей в принтере — это максимум его компетенций.
Дальше вы говорите, что существуют две системы, А и Б, между которыми уже построено пять разных интеграций в рамках предыдущих решений. Появляется новая концепция и еще одно решение, которое предполагает новый принцип интеграции. Но предыдущие пять интеграций никто не отменяет, просто добавляется шестая, по другому принципу. Это «зоопарк» — и именно он порождает интеграционный технический долг, тормозит agility, создаёт нерасторопность в будущем.
По оценке LinkedIn, в технологической сфере средняя продолжительность работы сотрудников составляет примерно 2–3 года, а среди разработчиков и инженеров — около 2 лет.
Когда жизненный цикл системы измеряется десятками лет, а сотрудники остаются в проекте в среднем 2 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция? Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Спасибо за ваш комментарий. Мы действительно хотели создать инструмент, который помогает описывать сложный мир просто — без упрощенчества, которое стирает смысл. Не «заметая знания под ковёр», как это часто происходит в заметочниках, на досках или в обычных диаграммных инструментах, а позволяя сохранять их структуру, связи и эволюцию.
Здравствуйте. На канале проекта есть видео туториалы и ссылки на вебинары. В том числе и про OntoAI.
не знаю
Обсидиан действительно сильно ограничивает возможности пользователя тк это все же записочник. Мы уже несколько лет командой ведем различные модели ( как самого продукта, так и для синхронизации множества команд которые я сопровождаю как архитектор ) например я рассказывал об этом подходе на Knowledge Conf KnowledgeConf 2025 - Профессиональная конференция по управлению знаниями
В одно лицо база знаний действительно собирается крайне плохо и не эффективно
здорово что у вас получилось )
ну вот тут я вообще без промпта разбирал
этот документ
nasa.gov/wp-content/uploads/2015/03/2020_nasa_technology_taxonomy_lowres.pdf?emrc=becddb
было
стало
вот как на визуальном контексте выглядит Onto TX01 Propulsion Systems Context
В статье я пишу не про использование конкретного фреймворка или инструмента ( такого как mind-map, BPML-диаграмм ), а о том как можно описать контекст бизнес-ситуации.
mind-map вам не дает классификацию, bpmn вообще инструмент другого назначения. наиболее близким здесь является UML диаграмма вариантов использования. Сама по себе статья продолжает предыдущую про управление контекстами при переходе от бизнес языка к c4. Но они были на других платформах, в последствии я её тоже перенесу .
.
Добрый день! Да, всё верно — это взаимодополняющие инструменты. Александр как раз отмечает: «Если BPMN показывает лишь последовательность шагов процесса без возможности увидеть его архитектуру и детализацию на уровне межсистемного обмена, то C4 позволяет дополнить эту картину (а точнее, начать её формирование: сначала определить, что делаем, а уже затем — в какой последовательности). Особенно это полезно, если вы используете одинаковые лексические конструкции в названиях шагов процессов и бизнес-сервисов».
На самом деле простое и элегантное решение. Я пару недель назад прикрутил к нашему проекту Онто MCP сервер и теперь могу документировать элементы разработки непосредственно из интерфейса JetBrains используя ту нейросеть на которой у меня остались токены к примеру. Никак не дойдут руки до использования в агентной среде чата, но даже имеющиеся функции мне позволяют быстро серфить по графу знаний находя нужные мне модули и связи их с другими компонентами такими как фичи или пользовательские истории
а так в целом отличное решение hope4b/mcp: mcp-server для работы с Онто
возьмите опять же статьи Steve Andriole о ценности корпоративной архитектуры. Раз уж мы об этом взялись рассуждать. Корпоративная архитектура это способ поговорить двум командам? не дорогой ли переводчик с русского на русский? Может ему нужно зарплату уменьшить?
ну мы то все остальные в основном по детским садам работали. Поэтому да, примем ваши утверждения на веру. У меня есть утверждение генерального конструктора одного из банков побольше чем ваша организация раз в 20: корпоративная архитектура это когда не найдешь кто за что отвечает. Я вам привожу конкретный пример с сильным доменом которому наплевать на все идеи корпархитектуры. И у вас нет ни одного шанса сломать их родмап для включения в беклог хотя бы одной фичи которую их бизнес считает не целевой.
что насчет пользы от техдолга? Или допустим надежности?
на стадии MVP есть код. В чем противоречия? Этот код должен быть обязательно развиваемым как решение. Тут тоже нет противоречий. Но этот код должен обеспечить уровень качества достаточным что бы переход от MVP к разработке не приводил к переходу от agile к водопаду как часто бывает. И не требовал построения космического корабля на старте. Если архитектор не может сбалансировать эти два требования возможно он так же профнепригоден
вообще непонятно на какое утверждение и кому вы оппонировали. Пишите лучше!
я прямо именно так и написал "Архитектор как фасилитатор у команд". Есть уровень решения (на земле) и тут архитектор тоже должен построить конвейер взаимодействия с экспертами не местах. К сожалению, чаще всего это происходит иначе. Болезнь башни из слоновой кости косит наши ряды особенно у неофитов которых вдруг назначили архитекторами, но не объяснили что есть такая вещь как польза.
На уровне кроссдоменного взаимодействия тоже работает не всегда, мы же понимаем что есть жизнь и продакты сегмента КиБов легко шлют на*ер все мнения корпоративной архитектуры компании.
Тот факт, что мы продолжаем обсуждать проблемы, характерные для позапрошлого века, был очевиден уже из самой концепции шины данных. Замечу, что ещё в начале 2000-х годов я получил один из первых сертификатов Oracle по данной тематике.
Говорить сегодня о замене одной информационной системы на другую — по меньшей мере странно, учитывая, что подавляющее большинство компаний уже давно внедряют микросервисные архитектуры, а многие даже начали отходить и от них, переходя к новым парадигмам построения ИТ-ландшафта.
Я нигде не утверждал, что ИТ-концепции в принципе не нужны. Моё замечание касалось лишь того, что апеллировать к этим подходам как к некоему фундаментальному, монументальному достижению — когда соответствующие решения давно описаны, реализованы и внедрены в индустрии — выглядит, мягко говоря, не вполне современно.
Давайте упростим ситуацию, потому что, похоже, она действительно сложна вам для понимания.
Начну с вашего утверждения о какой-то мифической интеграции между системами — интеграции, о которой никто не знает, как она работает, но почему-то она работает. У этих систем что, нет собственных команд развития? Это уже многое говорит о "здоровье" ИТ-подразделения. Руководитель такого ИТ, на мой взгляд, профессионально непригоден и с точки зрения собственников должен быть заменен. Ему нельзя доверять ничего, кроме замены картриджей в принтере — это максимум его компетенций.
Дальше вы говорите, что существуют две системы, А и Б, между которыми уже построено пять разных интеграций в рамках предыдущих решений. Появляется новая концепция и еще одно решение, которое предполагает новый принцип интеграции. Но предыдущие пять интеграций никто не отменяет, просто добавляется шестая, по другому принципу. Это «зоопарк» — и именно он порождает интеграционный технический долг, тормозит agility, создаёт нерасторопность в будущем.
По оценке LinkedIn, в технологической сфере средняя продолжительность работы сотрудников составляет примерно 2–3 года, а среди разработчиков и инженеров — около 2 лет.
Когда жизненный цикл системы измеряется десятками лет, а сотрудники остаются в проекте в среднем 2 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция?
Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.