На самом деле простое и элегантное решение. Я пару недель назад прикрутил к нашему проекту Онто MCP сервер и теперь могу документировать элементы разработки непосредственно из интерфейса JetBrains используя ту нейросеть на которой у меня остались токены к примеру. Никак не дойдут руки до использования в агентной среде чата, но даже имеющиеся функции мне позволяют быстро серфить по графу знаний находя нужные мне модули и связи их с другими компонентами такими как фичи или пользовательские истории
возьмите опять же статьи Steve Andriole о ценности корпоративной архитектуры. Раз уж мы об этом взялись рассуждать. Корпоративная архитектура это способ поговорить двум командам? не дорогой ли переводчик с русского на русский? Может ему нужно зарплату уменьшить?
ну мы то все остальные в основном по детским садам работали. Поэтому да, примем ваши утверждения на веру. У меня есть утверждение генерального конструктора одного из банков побольше чем ваша организация раз в 20: корпоративная архитектура это когда не найдешь кто за что отвечает. Я вам привожу конкретный пример с сильным доменом которому наплевать на все идеи корпархитектуры. И у вас нет ни одного шанса сломать их родмап для включения в беклог хотя бы одной фичи которую их бизнес считает не целевой.
на стадии MVP есть код. В чем противоречия? Этот код должен быть обязательно развиваемым как решение. Тут тоже нет противоречий. Но этот код должен обеспечить уровень качества достаточным что бы переход от MVP к разработке не приводил к переходу от agile к водопаду как часто бывает. И не требовал построения космического корабля на старте. Если архитектор не может сбалансировать эти два требования возможно он так же профнепригоден
я прямо именно так и написал "Архитектор как фасилитатор у команд". Есть уровень решения (на земле) и тут архитектор тоже должен построить конвейер взаимодействия с экспертами не местах. К сожалению, чаще всего это происходит иначе. Болезнь башни из слоновой кости косит наши ряды особенно у неофитов которых вдруг назначили архитекторами, но не объяснили что есть такая вещь как польза. На уровне кроссдоменного взаимодействия тоже работает не всегда, мы же понимаем что есть жизнь и продакты сегмента КиБов легко шлют на*ер все мнения корпоративной архитектуры компании.
Тот факт, что мы продолжаем обсуждать проблемы, характерные для позапрошлого века, был очевиден уже из самой концепции шины данных. Замечу, что ещё в начале 2000-х годов я получил один из первых сертификатов Oracle по данной тематике.
Говорить сегодня о замене одной информационной системы на другую — по меньшей мере странно, учитывая, что подавляющее большинство компаний уже давно внедряют микросервисные архитектуры, а многие даже начали отходить и от них, переходя к новым парадигмам построения ИТ-ландшафта.
Я нигде не утверждал, что ИТ-концепции в принципе не нужны. Моё замечание касалось лишь того, что апеллировать к этим подходам как к некоему фундаментальному, монументальному достижению — когда соответствующие решения давно описаны, реализованы и внедрены в индустрии — выглядит, мягко говоря, не вполне современно.
Давайте упростим ситуацию, потому что, похоже, она действительно сложна вам для понимания.
Начну с вашего утверждения о какой-то мифической интеграции между системами — интеграции, о которой никто не знает, как она работает, но почему-то она работает. У этих систем что, нет собственных команд развития? Это уже многое говорит о "здоровье" ИТ-подразделения. Руководитель такого ИТ, на мой взгляд, профессионально непригоден и с точки зрения собственников должен быть заменен. Ему нельзя доверять ничего, кроме замены картриджей в принтере — это максимум его компетенций.
Дальше вы говорите, что существуют две системы, А и Б, между которыми уже построено пять разных интеграций в рамках предыдущих решений. Появляется новая концепция и еще одно решение, которое предполагает новый принцип интеграции. Но предыдущие пять интеграций никто не отменяет, просто добавляется шестая, по другому принципу. Это «зоопарк» — и именно он порождает интеграционный технический долг, тормозит agility, создаёт нерасторопность в будущем.
По оценке LinkedIn, в технологической сфере средняя продолжительность работы сотрудников составляет примерно 2–3 года, а среди разработчиков и инженеров — около 2 лет.
Когда жизненный цикл системы измеряется десятками лет, а сотрудники остаются в проекте в среднем 2 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция? Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Архитектор как фасилитатор у команд. Очень классная и дорогая елочка на зеркале. Если он не выводит команду на самостоятельное принятие решений и формирование реализуемых концепций то грош ему цена. Команда всегда сильнее, умнее и качественнее одного человека.
"Предварительная оптимизация - абсолютное зло." Полностью согласен. Еще и оптимизация на сервисах не несущих значимой прибыли для бизнеса. Есть огромное число проектов которые делают ради проектов а не ради клиентов.
Миф 6, или «Архитектор должен писать код» И это не Миф. Человек не связанный с ИТ не понимает обычно что все изменения нужно вести через череду POC кроме того доказывая что ситуация классифицирована верно иначе речь будет идти об огромных затратах на техдолг. Поэтому - кто не программирует тот не айтишник
это вовсе не миф. Большинство проектов и ИС внутри компаний не требуют никакой архитектурной поддержки. Ну если конечно команду набрали из вменяемых людей. Архитектура нужна там где есть нагрузка и ответственность. А если это сервис аффектит на сегмент 0.000001 выручки то зарплата архитектора это и есть удорожание проекта
На самом деле простое и элегантное решение. Я пару недель назад прикрутил к нашему проекту Онто MCP сервер и теперь могу документировать элементы разработки непосредственно из интерфейса JetBrains используя ту нейросеть на которой у меня остались токены к примеру. Никак не дойдут руки до использования в агентной среде чата, но даже имеющиеся функции мне позволяют быстро серфить по графу знаний находя нужные мне модули и связи их с другими компонентами такими как фичи или пользовательские истории
а так в целом отличное решение hope4b/mcp: mcp-server для работы с Онто
возьмите опять же статьи Steve Andriole о ценности корпоративной архитектуры. Раз уж мы об этом взялись рассуждать. Корпоративная архитектура это способ поговорить двум командам? не дорогой ли переводчик с русского на русский? Может ему нужно зарплату уменьшить?
ну мы то все остальные в основном по детским садам работали. Поэтому да, примем ваши утверждения на веру. У меня есть утверждение генерального конструктора одного из банков побольше чем ваша организация раз в 20: корпоративная архитектура это когда не найдешь кто за что отвечает. Я вам привожу конкретный пример с сильным доменом которому наплевать на все идеи корпархитектуры. И у вас нет ни одного шанса сломать их родмап для включения в беклог хотя бы одной фичи которую их бизнес считает не целевой.
что насчет пользы от техдолга? Или допустим надежности?
на стадии MVP есть код. В чем противоречия? Этот код должен быть обязательно развиваемым как решение. Тут тоже нет противоречий. Но этот код должен обеспечить уровень качества достаточным что бы переход от MVP к разработке не приводил к переходу от agile к водопаду как часто бывает. И не требовал построения космического корабля на старте. Если архитектор не может сбалансировать эти два требования возможно он так же профнепригоден
вообще непонятно на какое утверждение и кому вы оппонировали. Пишите лучше!
я прямо именно так и написал "Архитектор как фасилитатор у команд". Есть уровень решения (на земле) и тут архитектор тоже должен построить конвейер взаимодействия с экспертами не местах. К сожалению, чаще всего это происходит иначе. Болезнь башни из слоновой кости косит наши ряды особенно у неофитов которых вдруг назначили архитекторами, но не объяснили что есть такая вещь как польза.
На уровне кроссдоменного взаимодействия тоже работает не всегда, мы же понимаем что есть жизнь и продакты сегмента КиБов легко шлют на*ер все мнения корпоративной архитектуры компании.
Тот факт, что мы продолжаем обсуждать проблемы, характерные для позапрошлого века, был очевиден уже из самой концепции шины данных. Замечу, что ещё в начале 2000-х годов я получил один из первых сертификатов Oracle по данной тематике.
Говорить сегодня о замене одной информационной системы на другую — по меньшей мере странно, учитывая, что подавляющее большинство компаний уже давно внедряют микросервисные архитектуры, а многие даже начали отходить и от них, переходя к новым парадигмам построения ИТ-ландшафта.
Я нигде не утверждал, что ИТ-концепции в принципе не нужны. Моё замечание касалось лишь того, что апеллировать к этим подходам как к некоему фундаментальному, монументальному достижению — когда соответствующие решения давно описаны, реализованы и внедрены в индустрии — выглядит, мягко говоря, не вполне современно.
Давайте упростим ситуацию, потому что, похоже, она действительно сложна вам для понимания.
Начну с вашего утверждения о какой-то мифической интеграции между системами — интеграции, о которой никто не знает, как она работает, но почему-то она работает. У этих систем что, нет собственных команд развития? Это уже многое говорит о "здоровье" ИТ-подразделения. Руководитель такого ИТ, на мой взгляд, профессионально непригоден и с точки зрения собственников должен быть заменен. Ему нельзя доверять ничего, кроме замены картриджей в принтере — это максимум его компетенций.
Дальше вы говорите, что существуют две системы, А и Б, между которыми уже построено пять разных интеграций в рамках предыдущих решений. Появляется новая концепция и еще одно решение, которое предполагает новый принцип интеграции. Но предыдущие пять интеграций никто не отменяет, просто добавляется шестая, по другому принципу. Это «зоопарк» — и именно он порождает интеграционный технический долг, тормозит agility, создаёт нерасторопность в будущем.
По оценке LinkedIn, в технологической сфере средняя продолжительность работы сотрудников составляет примерно 2–3 года, а среди разработчиков и инженеров — около 2 лет.
Когда жизненный цикл системы измеряется десятками лет, а сотрудники остаются в проекте в среднем 2 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция?
Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Архитектор как фасилитатор у команд. Очень классная и дорогая елочка на зеркале. Если он не выводит команду на самостоятельное принятие решений и формирование реализуемых концепций то грош ему цена. Команда всегда сильнее, умнее и качественнее одного человека.
или не достигнет тк бизнес свою гипотезу пропилотирует и решит что результат не тот что нужен для продолжения.
"Предварительная оптимизация - абсолютное зло." Полностью согласен. Еще и оптимизация на сервисах не несущих значимой прибыли для бизнеса. Есть огромное число проектов которые делают ради проектов а не ради клиентов.
Миф 6, или «Архитектор должен писать код»
И это не Миф. Человек не связанный с ИТ не понимает обычно что все изменения нужно вести через череду POC кроме того доказывая что ситуация классифицирована верно иначе речь будет идти об огромных затратах на техдолг. Поэтому - кто не программирует тот не айтишник
кому станет легче от вашей концепции? какую бизнес-пользу она принесет?
Миф 4, или «И без архитектора справимся»
это вовсе не миф. Большинство проектов и ИС внутри компаний не требуют никакой архитектурной поддержки. Ну если конечно команду набрали из вменяемых людей. Архитектура нужна там где есть нагрузка и ответственность. А если это сервис аффектит на сегмент 0.000001 выручки то зарплата архитектора это и есть удорожание проекта
Не встречал такой формат пока, можно конвертнуть в owl похоже https://habr.com/ru/articles/270857/
А в каком формате выгружает? Если в owl то можно без потерь в Онто загрузить и продолжить с того места где остановились
странно что Онто указали что нет интеллект-карт. Онто это один огромный граф знаний визуализируемый интеллект картами.