В статье я пишу не про использование конкретного фреймворка или инструмента ( такого как 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 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция? Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Архитектор как фасилитатор у команд. Очень классная и дорогая елочка на зеркале. Если он не выводит команду на самостоятельное принятие решений и формирование реализуемых концепций то грош ему цена. Команда всегда сильнее, умнее и качественнее одного человека.
"Предварительная оптимизация - абсолютное зло." Полностью согласен. Еще и оптимизация на сервисах не несущих значимой прибыли для бизнеса. Есть огромное число проектов которые делают ради проектов а не ради клиентов.
Миф 6, или «Архитектор должен писать код» И это не Миф. Человек не связанный с ИТ не понимает обычно что все изменения нужно вести через череду POC кроме того доказывая что ситуация классифицирована верно иначе речь будет идти об огромных затратах на техдолг. Поэтому - кто не программирует тот не айтишник
это вовсе не миф. Большинство проектов и ИС внутри компаний не требуют никакой архитектурной поддержки. Ну если конечно команду набрали из вменяемых людей. Архитектура нужна там где есть нагрузка и ответственность. А если это сервис аффектит на сегмент 0.000001 выручки то зарплата архитектора это и есть удорожание проекта
В статье я пишу не про использование конкретного фреймворка или инструмента ( такого как 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 года, велика вероятность, что инициаторы стратегии интеграции никогда не увидят её результаты. Это создает долговую нагрузку, осложняет сопровождение, снижает скорость адаптации и повышает риски переноса знаний.
Возникает вопрос: зачем всё это? Какую пользу бизнесу и бюджету ИТ даст очередная концепция?
Если каждое новое решение строится на принципе «сложнее просто потому что так требует концепция», без пересмотра предыдущей логики, интеграционный зоопарк становится нарастающим долговым обществом: предыдущие связи остаются, добавляются новые, а компетентность команды — неумолимо меняется.
а раз старые интеграции не будут выведены в один день то у вас уже образуется зоопарк из того что вы сейчас считаете целевым решением и существующими подходами ) Ну и где тут простота поддержки? напоминает классический труд про управление вселенной. Скорее всего существующие решения по интеграции вам придется переделывать целиком это приведет к каскадному росту стоимости проектов. Либо все так же будут продолжать поддерживаться два, а когда вы уволитесь то и три и четыре подхода.
у вас компания не в чистом поле стоит. Оценивать нужно разницу с существующим решением. А не архитектурные кричалки использовать. Единая концепция интеграции может привести к тому что у вас потом будет департамент поддерживающий эту интеграцию как единая точка отказа (у них есть свой капасити) и удорожание всех решений за счет накладных расходов на унификацию интеграционных подходов.
Архитектор как фасилитатор у команд. Очень классная и дорогая елочка на зеркале. Если он не выводит команду на самостоятельное принятие решений и формирование реализуемых концепций то грош ему цена. Команда всегда сильнее, умнее и качественнее одного человека.
или не достигнет тк бизнес свою гипотезу пропилотирует и решит что результат не тот что нужен для продолжения.
"Предварительная оптимизация - абсолютное зло." Полностью согласен. Еще и оптимизация на сервисах не несущих значимой прибыли для бизнеса. Есть огромное число проектов которые делают ради проектов а не ради клиентов.
Миф 6, или «Архитектор должен писать код»
И это не Миф. Человек не связанный с ИТ не понимает обычно что все изменения нужно вести через череду POC кроме того доказывая что ситуация классифицирована верно иначе речь будет идти об огромных затратах на техдолг. Поэтому - кто не программирует тот не айтишник
кому станет легче от вашей концепции? какую бизнес-пользу она принесет?
Миф 4, или «И без архитектора справимся»
это вовсе не миф. Большинство проектов и ИС внутри компаний не требуют никакой архитектурной поддержки. Ну если конечно команду набрали из вменяемых людей. Архитектура нужна там где есть нагрузка и ответственность. А если это сервис аффектит на сегмент 0.000001 выручки то зарплата архитектора это и есть удорожание проекта