Наткнулся. Оффтопик, но пожалуй оно стоит того, чтобы запостить сюда :)
— Гендальф! – перекрикивая рев орков позвал Арагорн, – Остановись, планерка!
– Что? – удивился волшебник сбавляя темп бега.
– Планерка!
– Вы с ума сошли?! За нами гонятся орки! Давайте потом…
– Планерка проводится каждое утро! – менторским тоном перебил догнавший их мужчина.
Едва он успел договорить, как в него врезался Гимли, пачка хоббитов и Боромир. Только Леголас сумел затормозить перед неожиданно возникшим препятствием.
– Мы стоим на мосту посреди пропасти и за нами гонятся все орки Мории! Нет времени на планерку! – возмутился Гендальф.
– Я Энеджер, сын Менеджера, брат Инвестора, владыка Канбана! – стряхнув с себя хоббитов и приняв властную позу заявил мужчина, – Властью данной мне Эмбиеем объявляю планерку! И должен сразу отметить, Гендальф, что для планерки время есть всегда! Итак, первый вопрос для обсуждения. За нами гонятся орки, как мы пришли к такому, очевидно не устраивающему нас результату? Я не устану напоминать, что необходимо регулярно проводить мониторинг и корректировать наши действия соответственно полученным результатам.
Все молчали, нервно переглядываясь и прислушиваясь к реву, отражающемуся от сводов подземелья.
– Тук уронил ведро в колодец, нашумел, это услышали орки и подняли тревогу… – стал нетерпеливо объяснять Арагорн, но его прервал Энеджер.
– Не так токсично! Легко сваливать ответственность на другого! Лучше скажи как ты лично связан с этим результатом! Мы команда и каждый внес свой вклад в то, чтобы возникла такая ситуация. Ответственность и планирование!
– Я… Ну…
– Если мы будем тут стоять, то нас прибьют орки! – воззвал к голосу разума Гендальф.
– Самое простое – это лихорадочно бегать! – возразил Энеджер, – И я понимаю, почему инвесторы прислали меня чтобы усилить вашу команду. Очевидно раньше вы вообще не занимались планированием! Очевидно, что сейчас проект идет не совсем так, как было задумано.
– Да нет же!
– То есть забеги по подземельям с орками – это часть проекта? Можно посмотреть документацию?
– Нет, просто такое случается иногда! – заорал Арагорн.
– У меня нет. – возразил Энеджер, – Итак, очевидно нам надо немного подкорректировать проект в соответствии с нынешней ситуацией. Я изучил все данные, произвел расчеты и стало очевидно, что вы поставили перед собой слишком амбициозную задачу.
– И что? – хором спросили все.
– Нужно представить инвесторам новый план. Опять таки, я все посчитал. Мы уже потратили больше ресурсов чем планировали. А в график не укладываемся. Предлагаю отказаться от нереализуемых пунктов плана и сделать только то, что реально. Но четко к сроку.
Все непонимающе переглянулись. Леголас задумчиво пристрелил подбегающего к ним орка.
– И что конкретно мы должны сделать? – поинтересовался Гендальф.
– Я все посчитал. До Мордора мы не успеем добраться, а вот до Лориена вполне.
– Но нам же надо отнести его в Мордор! — возразил Арагорн.
– Слишком большие риски, да и все уже идет не по плану! Нужно смотреть на вещи реально! – возразил Энеджер.
– Но кольцо можно уничтожить только в Мордоре! У нас нет выбора!
– Не берите на себя слишком большую ответственность. – успокоил всех Энеджер, – Просто делайте свое дело. Решено, мы дойдем до Лориэна. И отчитаемся о проделанной работе. Как минимум 50% проекта мы реализуем. Это лучше, чем завалить все, не так ли? Управление рисками.
– И что дальше? – не понял Гендальф.
– Ну, нужно будет провести стратсессию, составить дорожную карту, привлечь консультантов и понять как отнести кольцо в Мордор. Да и нужно ли вообще нести.
– Что значит нужно ли? – нахмурился Гендальф.
– Вин-вин, всегда есть место сотрудничеству, понимаете?
Гендальф посмотрел на Арагорна. Тот кивнул.
– Ну что же, думаю можем продолжать двигаться. Объявляю планерку завершенной. Давайте побыстрее перейдем этот мост. А то как бы нас орки не догнали. Да и хлипковато выглядит эта конструкция, если честно.
Братство кольца с облегчением рвануло по мосту. Все кроме Гендальфа. Он придержал за локоть Энеджера, подождал пока все остальные удалятся и заглянув ему в глаза сказал.
– Ты не пройдешь.
— Гендальф! – перекрикивая рев орков позвал Арагорн, – Остановись, планерка!
– Что? – удивился волшебник сбавляя темп бега.
– Планерка!
– Вы с ума сошли?! За нами гонятся орки! Давайте потом…
– Планерка проводится каждое утро! – менторским тоном перебил догнавший их мужчина.
Едва он успел договорить, как в него врезался Гимли, пачка хоббитов и Боромир. Только Леголас сумел затормозить перед неожиданно возникшим препятствием.
– Мы стоим на мосту посреди пропасти и за нами гонятся все орки Мории! Нет времени на планерку! – возмутился Гендальф.
– Я Энеджер, сын Менеджера, брат Инвестора, владыка Канбана! – стряхнув с себя хоббитов и приняв властную позу заявил мужчина, – Властью данной мне Эмбиеем объявляю планерку! И должен сразу отметить, Гендальф, что для планерки время есть всегда! Итак, первый вопрос для обсуждения. За нами гонятся орки, как мы пришли к такому, очевидно не устраивающему нас результату? Я не устану напоминать, что необходимо регулярно проводить мониторинг и корректировать наши действия соответственно полученным результатам.
Все молчали, нервно переглядываясь и прислушиваясь к реву, отражающемуся от сводов подземелья.
– Тук уронил ведро в колодец, нашумел, это услышали орки и подняли тревогу… – стал нетерпеливо объяснять Арагорн, но его прервал Энеджер.
– Не так токсично! Легко сваливать ответственность на другого! Лучше скажи как ты лично связан с этим результатом! Мы команда и каждый внес свой вклад в то, чтобы возникла такая ситуация. Ответственность и планирование!
– Я… Ну…
– Если мы будем тут стоять, то нас прибьют орки! – воззвал к голосу разума Гендальф.
– Самое простое – это лихорадочно бегать! – возразил Энеджер, – И я понимаю, почему инвесторы прислали меня чтобы усилить вашу команду. Очевидно раньше вы вообще не занимались планированием! Очевидно, что сейчас проект идет не совсем так, как было задумано.
– Да нет же!
– То есть забеги по подземельям с орками – это часть проекта? Можно посмотреть документацию?
– Нет, просто такое случается иногда! – заорал Арагорн.
– У меня нет. – возразил Энеджер, – Итак, очевидно нам надо немного подкорректировать проект в соответствии с нынешней ситуацией. Я изучил все данные, произвел расчеты и стало очевидно, что вы поставили перед собой слишком амбициозную задачу.
– И что? – хором спросили все.
– Нужно представить инвесторам новый план. Опять таки, я все посчитал. Мы уже потратили больше ресурсов чем планировали. А в график не укладываемся. Предлагаю отказаться от нереализуемых пунктов плана и сделать только то, что реально. Но четко к сроку.
Все непонимающе переглянулись. Леголас задумчиво пристрелил подбегающего к ним орка.
– И что конкретно мы должны сделать? – поинтересовался Гендальф.
– Я все посчитал. До Мордора мы не успеем добраться, а вот до Лориена вполне.
– Но нам же надо отнести его в Мордор! — возразил Арагорн.
– Слишком большие риски, да и все уже идет не по плану! Нужно смотреть на вещи реально! – возразил Энеджер.
– Но кольцо можно уничтожить только в Мордоре! У нас нет выбора!
– Не берите на себя слишком большую ответственность. – успокоил всех Энеджер, – Просто делайте свое дело. Решено, мы дойдем до Лориэна. И отчитаемся о проделанной работе. Как минимум 50% проекта мы реализуем. Это лучше, чем завалить все, не так ли? Управление рисками.
– И что дальше? – не понял Гендальф.
– Ну, нужно будет провести стратсессию, составить дорожную карту, привлечь консультантов и понять как отнести кольцо в Мордор. Да и нужно ли вообще нести.
– Что значит нужно ли? – нахмурился Гендальф.
– Вин-вин, всегда есть место сотрудничеству, понимаете?
Гендальф посмотрел на Арагорна. Тот кивнул.
– Ну что же, думаю можем продолжать двигаться. Объявляю планерку завершенной. Давайте побыстрее перейдем этот мост. А то как бы нас орки не догнали. Да и хлипковато выглядит эта конструкция, если честно.
Братство кольца с облегчением рвануло по мосту. Все кроме Гендальфа. Он придержал за локоть Энеджера, подождал пока все остальные удалятся и заглянув ему в глаза сказал.
– Ты не пройдешь.
В техническом компоненте у вас будет time2prod environment
В бизнес-компоненте к нему прибавится time2market (потому что дорога к рынку - это еще и маретологи, реклама, контент, позиционирование)
В бизнесе как таковом, явно или неявно, интересен time2value.
По сути это синоним LeadTime из Lean.
И как же сильно его не хотят замерять :)
Ну а что, вот у нас три команды, сервисы пилят, очень понятный у них output - написать код и в отправить в прод.
А как мы «требование» придумываем, анализируем, подтверждаем, выделяем, убеждаем - «вы не понимаете, это другое».
А это не другое :)
В этом процессе отношение времени разработки ко всему остальному в пределе может стремиться к нулю, и если это так, то разработка - не то, с чего имеет смысл начинать.
Был кейс с запросом на переход на микросервисы. Тайм2маркет сократить. Провел предварительный аудит-исследование. Баги пролетали от своего появления в джире до прода за пару дней, максимум 3-4 дня. А вот то, что действительно важно, что позволяет зарабатывать больше и у чего максимальный потенциал - от задумки до прода 2-3 месяца. Из них разработка - около 2-х недель (спринт). Разработка - около 15% времени. Решать проблему хотели переходом на микросервисы, оставим мотивацию за скобками.
Правда, тут один нюанс. Посмотрите внимательно на описанный кейс. Без изменения процесса (от идеи до получения клиентом ценности) с переходом на микросервисную(или любую другую) архитектуру, изменится ли time2value?
В бизнес-компоненте к нему прибавится time2market (потому что дорога к рынку - это еще и маретологи, реклама, контент, позиционирование)
В бизнесе как таковом, явно или неявно, интересен time2value.
По сути это синоним LeadTime из Lean.
И как же сильно его не хотят замерять :)
Ну а что, вот у нас три команды, сервисы пилят, очень понятный у них output - написать код и в отправить в прод.
А как мы «требование» придумываем, анализируем, подтверждаем, выделяем, убеждаем - «вы не понимаете, это другое».
А это не другое :)
В этом процессе отношение времени разработки ко всему остальному в пределе может стремиться к нулю, и если это так, то разработка - не то, с чего имеет смысл начинать.
Был кейс с запросом на переход на микросервисы. Тайм2маркет сократить. Провел предварительный аудит-исследование. Баги пролетали от своего появления в джире до прода за пару дней, максимум 3-4 дня. А вот то, что действительно важно, что позволяет зарабатывать больше и у чего максимальный потенциал - от задумки до прода 2-3 месяца. Из них разработка - около 2-х недель (спринт). Разработка - около 15% времени. Решать проблему хотели переходом на микросервисы, оставим мотивацию за скобками.
Правда, тут один нюанс. Посмотрите внимательно на описанный кейс. Без изменения процесса (от идеи до получения клиентом ценности) с переходом на микросервисную(или любую другую) архитектуру, изменится ли time2value?
Технические зависимости (на уровне данных и интерфейсов) сложно разорвать в том числе из-за отсутствия бизнес-семантики. На основе технической зависимости мы может только сделать вывод о ее наличии, но не можем определить, должна она присутствовать по бизнес-контексту или нет.
Материалы с Service-Oriented Computing 19th International Conference, ICSOC 2021 🧐
https://link.springer.com/content/pdf/10.1007%2F978-3-030-91431-8.pdf
https://link.springer.com/content/pdf/10.1007%2F978-3-030-91431-8.pdf
Всех девушек поздравляю с 8 марта! 🌹
Счастья, добра, любви, мира, крепких связей и надежных людей рядом! 🌟🌻☀️
Счастья, добра, любви, мира, крепких связей и надежных людей рядом! 🌟🌻☀️
vuca&bani.pdf
62.2 KB
Пару лет назад составил себе шпаргалку по VUCA и BANI.
VUCA - модель описания происходящего для принятия решений (sense-making framework), появившаяся в 1987.
Несколько лет назад была предложена новая модель описания – BANI. Она описывает ситуации, в которых условия не просто нестабильны, – они хаотичны. В которых результаты не просто трудно предвидеть, они совершенно непредсказуемы. Или, если использовать язык этих фреймворков, ситуации, когда то, что происходит, не просто двусмысленно (не определено; ambiguous), оно непостижимо.
Делюсь заметками. Считаю, что VUCA актуальна, а BANI рассматриваю как гипотезу.
Все свойства прекрасно перекладываются на архитектуру, особенно на распределенную. В жизни же возможность разложить ситуации по свойствам модельки – это та самая работа с атрибутами качества и стратегиями их достижения, фундамент работы архитектора.
VUCA - модель описания происходящего для принятия решений (sense-making framework), появившаяся в 1987.
Несколько лет назад была предложена новая модель описания – BANI. Она описывает ситуации, в которых условия не просто нестабильны, – они хаотичны. В которых результаты не просто трудно предвидеть, они совершенно непредсказуемы. Или, если использовать язык этих фреймворков, ситуации, когда то, что происходит, не просто двусмысленно (не определено; ambiguous), оно непостижимо.
Делюсь заметками. Считаю, что VUCA актуальна, а BANI рассматриваю как гипотезу.
Все свойства прекрасно перекладываются на архитектуру, особенно на распределенную. В жизни же возможность разложить ситуации по свойствам модельки – это та самая работа с атрибутами качества и стратегиями их достижения, фундамент работы архитектора.
Микросервисы / распределенные системы
vuca&bani.pdf
Вообще, Крис Ричардсон назвал VUCA одним из трендов, которые привели к появлению микросервисов: https://chrisrichardson.net/post/microservices/2020/02/18/why-microservices-part-1.html
Компании сегодня должны быть гораздо более гибкими и внедрять инновации гораздо быстрее. А поскольку инновационные продукты и услуги основаны на программном обеспечении, IT должны выпускать ПО гораздо быстрее, чаще и надежнее.
Одна из причин, по которой производительность IT коррелирует с производительностью бизнеса, заключается в том, что чем меньше время внесения изменений и чем выше частота развертываний, тем больше и чаще проходят эксперименты, направленные на поиск функциональности, увеличивающей доход.
Микросервисы+DevOps нам все это дают.
Компании сегодня должны быть гораздо более гибкими и внедрять инновации гораздо быстрее. А поскольку инновационные продукты и услуги основаны на программном обеспечении, IT должны выпускать ПО гораздо быстрее, чаще и надежнее.
Одна из причин, по которой производительность IT коррелирует с производительностью бизнеса, заключается в том, что чем меньше время внесения изменений и чем выше частота развертываний, тем больше и чаще проходят эксперименты, направленные на поиск функциональности, увеличивающей доход.
Микросервисы+DevOps нам все это дают.
Подробно про дебаг ошибок, связанныз с SSL-сертификатами.
https://www.netmeister.org/blog/debugging-certificate-errors.html
https://www.netmeister.org/blog/debugging-certificate-errors.html
В open source решениях находят все больше политической малвари. По ссылке – пополняемый список.
Рекомендуется отключить обновления apt, rpm, brew, npm и так далее для latest версий.
https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview
Рекомендуется отключить обновления apt, rpm, brew, npm и так далее для latest версий.
https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview
ECommerce Microservices is a fictional eCommerce, based on different software architecture and technologies like Microservices Architecture, Vertical Slice Architecture, CQRS pattern, Domain Driven Design, Event Driven Architecture, Inbox and Outbox Pattern and using Postgres for write side and MongoDb for read side and etc.
https://github.com/mehdihadeli/e-commerce-microservices
https://github.com/mehdihadeli/e-commerce-microservices
Гипотезу Данбара про 150 контактов опровергли.
https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
Опровержение научное, наборы данных общедоступны. Опровергнуть удалось за счет использования современных вычислительных мощностей, которые были недоступны во время, когда Данбар формулировал свою гипотезу.
Почему это важно?
В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.
В итоге выяснилось, что одним числом показатели выразить невозможно, даже границы (от и до) кол-ва приятельских отношений (те самые 150) определить статистически не удалось, там от нуля и до неизвестно скольки сверху.
В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
Опровержение научное, наборы данных общедоступны. Опровергнуть удалось за счет использования современных вычислительных мощностей, которые были недоступны во время, когда Данбар формулировал свою гипотезу.
Почему это важно?
В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.
В итоге выяснилось, что одним числом показатели выразить невозможно, даже границы (от и до) кол-ва приятельских отношений (те самые 150) определить статистически не удалось, там от нуля и до неизвестно скольки сверху.
В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
Про метрики
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDANCE_20220301.PDF
906.6 KB
Свеженький гайд по безе подъехал
Микросервисы / распределенные системы
Photo
Казалось бы, причем тут микросервисы. Но если прочитать внимательно определение, сформулированное Мартином Фаулером в 2014-м году (https://tttttt.me/microservices_arch/87) удивительным образом, практически один-в-один повторяет принципы построения архитектуры Amazon, изложенные Безосом в 2002-м. И неспроста в каждой третьей статье про микросервисы в пример приводят именно Amazon.
Давно не писал в канал, не мог найти времени, а все от того, что параллельно работаем над такими вещами, как:
- референс-архитектуры, в том числе микросервисные, в том числе ддд-compliant (детали тут: https://tttttt.me/emacsway_log/888)
- возрождение архитектурных ката, попробуем перезапустить с @Kirill_vet
- российская сертификация/база знаний в области разработки и проектирования (от сообщества для сообщества). Понятно, что нет такого понятия, как «российская специфика», но есть определенный базис, который нужен и хорошо, если мы сможем его давать внутри страны 👍получится - хорошо, не получится - чему-то научимся :)
- ddd проникает во все большее число компаний, растет интерес к применению ddd для отображения в орг структуру. Чему я несказанно рад, потому что при проектировании микросервисов так или иначе всегда строили модель предметной области, а вот предложение перенести эту модель в орг структуру и бизнес-архитектуру принималось через раз (где принималось, те понимают о чем я 😉). Готовлю выступление «оргдизайн через ddd». Кстати, это буквально воплощение закона Конвея.
- со дня на день стартует подготовка к archdays. Оффлайн🤞, наверное все же с онлайном, ибо странно не использовать этот канал совсем. Уже есть заявки, ждем еще 👀
- референс-архитектуры, в том числе микросервисные, в том числе ддд-compliant (детали тут: https://tttttt.me/emacsway_log/888)
- возрождение архитектурных ката, попробуем перезапустить с @Kirill_vet
- российская сертификация/база знаний в области разработки и проектирования (от сообщества для сообщества). Понятно, что нет такого понятия, как «российская специфика», но есть определенный базис, который нужен и хорошо, если мы сможем его давать внутри страны 👍получится - хорошо, не получится - чему-то научимся :)
- ddd проникает во все большее число компаний, растет интерес к применению ddd для отображения в орг структуру. Чему я несказанно рад, потому что при проектировании микросервисов так или иначе всегда строили модель предметной области, а вот предложение перенести эту модель в орг структуру и бизнес-архитектуру принималось через раз (где принималось, те понимают о чем я 😉). Готовлю выступление «оргдизайн через ddd». Кстати, это буквально воплощение закона Конвея.
- со дня на день стартует подготовка к archdays. Оффлайн🤞, наверное все же с онлайном, ибо странно не использовать этот канал совсем. Уже есть заявки, ждем еще 👀
Пошла жара вокруг ДДД. Имхо когда мы говорим о какой-то практике, нужно четко разделять:
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение
Поясню на примере ДДД.
Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).
И так с любой практикой, имхо. Есть популярный узкоспециализированный приклад, есть принципы и основы на которых он построен и их знание позволяет подстраиваться под любые специализации в рамках области определения и есть еще более фундаментальные основы, которые дают понимание самых базовых принципов.
Менеджмент становится намного проще при знании мат аппарата теории массового обслуживания (теории очередей) просто потому, что знание что там в числителе, что в знаменателе, что от чего зависит позволяет быстро оценить зависимости по переменным для любого контекста. Это не обязательно, конечно, и не всем нужно, но для обучения менеджменту (в моем понимании - и архитектуре), для понимания как работать с потоком создания ценности, это имхо прям must have знания.
Туда же микросервисы, где для создания написания кода сервисов важнее прикладные навыки, а для проектирования уже важны и фундаментальные знания, причем чем в большем спектре они перейдут в проф. интуицию, тем лучше.
Буду рад обсудить в коментах.
1. Академическую часть
2. Приклад
3. Контекстно-зависимое применение
Поясню на примере ДДД.
Академическая часть - это Эванс, Вернон, работы о самом ДДД, теория сложных адаптивных систем, моделирование, системное мышления и проячее. Академическая часть нужна для того чтобы:
- развивать фундаментальные основы, независимо от приклада
- обучать прикладным вещам (да, для этого важно понимать, на чем они основаны)
2. Приклад. Например, - дизайн организационной структуры, принятие управленческих решений на основе типов доменов (что инхаус разрабатывать, что отдать на аутсорс), проектирование микросервисного решения
3. Контексто-зависимый приклад - например, Банк, CRM, ритейл, Поиск. Для применения здесь не нужно даже знать терминологию ДДД, и даже вообще знать что есть какое-то ДДД, но тому кто будет проектировать или строить модели, проводить совместное исследование домена, безусловно, нужны знания и на академическом и на прикладном уровне (а вот контекстно-зависимый приклад уже не так важен, его нужно структурировать усилиями участников совместной практики).
И так с любой практикой, имхо. Есть популярный узкоспециализированный приклад, есть принципы и основы на которых он построен и их знание позволяет подстраиваться под любые специализации в рамках области определения и есть еще более фундаментальные основы, которые дают понимание самых базовых принципов.
Менеджмент становится намного проще при знании мат аппарата теории массового обслуживания (теории очередей) просто потому, что знание что там в числителе, что в знаменателе, что от чего зависит позволяет быстро оценить зависимости по переменным для любого контекста. Это не обязательно, конечно, и не всем нужно, но для обучения менеджменту (в моем понимании - и архитектуре), для понимания как работать с потоком создания ценности, это имхо прям must have знания.
Туда же микросервисы, где для создания написания кода сервисов важнее прикладные навыки, а для проектирования уже важны и фундаментальные знания, причем чем в большем спектре они перейдут в проф. интуицию, тем лучше.
Буду рад обсудить в коментах.