В заметке "Как осуществлять изменения в коллективе" я говорил о том, что:
> "Важно уметь не внедрить изменения, а инициировать и подпитывать их. Больше слушать, спрашивать, меньше говорить."
Mike Cohn в своей вчерашней статье "My Favorite Hard Questions to Ask When Making a Decision" разделяет эту тактику, и даже конкретизирует список вопросов, которые нужно задавать для осуществления влияния.
#Management #SoftSkills
> "Важно уметь не внедрить изменения, а инициировать и подпитывать их. Больше слушать, спрашивать, меньше говорить."
Mike Cohn в своей вчерашней статье "My Favorite Hard Questions to Ask When Making a Decision" разделяет эту тактику, и даже конкретизирует список вопросов, которые нужно задавать для осуществления влияния.
#Management #SoftSkills
Mountain Goat Software
Helpful Questions to Nudge Teams Toward Good Decisions
Use my list of questions to inspire (rather than command) your teams to think clearly and decide intelligently.
👍6🔥5🤩1
Forwarded from DDDevotion
Андрей Ганичев @Ami_G0 запостил перевод статьи Камиля Гржибека про модульный монолит https://habr.com/en/company/dododev/blog/650721/
Читайте, комментируйте, нажимайте стрелочку вверх ⬆️
Читайте, комментируйте, нажимайте стрелочку вверх ⬆️
Habr
Модульный монолит. Начало
Слово переводчика Привет, меня зовут Андрей и я разработчик. Наша команда работает над мобильным приложением для стартапа Dodo Brands — сети кофеен Дринкит. Несмотря на популярность микросервисов, при...
👍7🔥1🤩1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Forget monoliths vs. microservices. Cognitive load is what matters." от авторов книги "Team Topologies" - https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters Thanks to @romanvt #Microservices #TeamTopologies…
📝 "For some companies, the abstract terminology of Domain-Driven Design is a barrier to adoption.
Independent Service Heuristics from @TeamTopologies is a good alternative which helps a diverse group to collaboratively explore stream and domain boundaries.
https://github.com/TeamTopologies/Independent-Service-Heuristics
It's also a great tool for getting people to see the value of DDD techniques like Event Storming 😀"
-- Nick Tune
https://twitter.com/ntcoding/status/1492487513591721990?t=5T2EyF2fXcHPU7JR3aieng&s=19
P.S.: архитектура все больше и больше становится неотделимой от управления.
#DDD #TeamTopologies #SoftwareArchitecture #SoftwareDesign
Independent Service Heuristics from @TeamTopologies is a good alternative which helps a diverse group to collaboratively explore stream and domain boundaries.
https://github.com/TeamTopologies/Independent-Service-Heuristics
It's also a great tool for getting people to see the value of DDD techniques like Event Storming 😀"
-- Nick Tune
https://twitter.com/ntcoding/status/1492487513591721990?t=5T2EyF2fXcHPU7JR3aieng&s=19
P.S.: архитектура все больше и больше становится неотделимой от управления.
#DDD #TeamTopologies #SoftwareArchitecture #SoftwareDesign
GitHub
GitHub - TeamTopologies/Independent-Service-Heuristics: The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for…
The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. - ...
👍8🔥1🤩1
Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids) by Dimitri Fontaine
- https://github.com/dimitri/pgcopydb
#PostgreSQL
- https://github.com/dimitri/pgcopydb
#PostgreSQL
GitHub
GitHub - dimitri/pgcopydb: Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids)
Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids) - dimitri/pgcopydb
Red Hat Portfolio Architecture Examples
This repository provides examples of customer implementations using Red Hat product portfolio. These architectural blueprints can be used as is or adapted to meet the customer requirements. The architectural diagrams are created using the open source tool draw.io.
https://gitlab.com/redhatdemocentral/portfolio-architecture-examples
Thanks to @pantafive
#SoftwareArchitecture
This repository provides examples of customer implementations using Red Hat product portfolio. These architectural blueprints can be used as is or adapted to meet the customer requirements. The architectural diagrams are created using the open source tool draw.io.
https://gitlab.com/redhatdemocentral/portfolio-architecture-examples
Thanks to @pantafive
#SoftwareArchitecture
GitLab
Red Hat Demo Central / Portfolio Architecture - Examples · GitLab
Example diagrams, pieces of diagrams, and examples for importing with URL feature of tooling.
👍8😁1
Forwarded from Блог Сергея Баранова
Закон Конвея. Перевод статьи «How Do Committees Invent?»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
👍5
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Test-first vs test-last approaches" by Vladimir Khorikov https://khorikov.org/posts/2022-01-24-test-first-vs-test-last-approaches/ P.S.: Обсуждали недавно эту тему в чате канала. #TDD #SoftwareDesign
Володя осветил один из частых вопросов:
"Collections and Primitive Obsession" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/collections-primitive-obsession/
#DDD #SoftwareDesign
"Collections and Primitive Obsession" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/collections-primitive-obsession/
#DDD #SoftwareDesign
Enterprise Craftsmanship
Collections and Primitive Obsession
Does the primitive obsession anti-pattern apply to collections? In other words, should you introduce a custom class for a collection?
👍6👎1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Два новых перевода от хабраюзера ArkadiyXIII на статьи Vladik Khononov (@vladik_kh): "Преодоление сложности в CQRS" - https://habr.com/ru/post/588803/ "Распутывание микросервисов или балансировка сложности в распределенных системах" - https://habr.com/ru/post/590165/…
Новый перевод от ArkadiyXIII:
- "Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов"
#DDD #SoftwareArchitecture #SoftwareDesign #Microservices
- "Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов"
#DDD #SoftwareArchitecture #SoftwareDesign #Microservices
Хабр
Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов
Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts». Далее не будут переводится следующие фразы: Notifications...
🔥6👍3👎2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Сравнение брокеров сообщений - https://docs.nats.io/compare-nats #DistributedSystems #SoftwareArchitecture #Microservices #DDD
"Error Handling Patterns for Apache Kafka Applications" by Gerardo Villeda
- https://www.confluent.io/blog/error-handling-patterns-in-kafka/
Неплохая статья, которая затрагивает в т.ч. и проблему очередности доставки сообщений.
#DistributedSystems #SoftwareArchitecture #Microservices #DDD
- https://www.confluent.io/blog/error-handling-patterns-in-kafka/
Неплохая статья, которая затрагивает в т.ч. и проблему очередности доставки сообщений.
#DistributedSystems #SoftwareArchitecture #Microservices #DDD
Confluent
Error Handling Patterns in Kafka
From dead letter queues to related events processed out of order, here are 5 common issues in event streaming applications, and how to fix them with sequential retries.
👍7🔥2👎1
"Software Design: Tidy First?" - новая книга, над которой работает Kent Beck. Читать главы можно уже сейчас:
- https://tidyfirst.substack.com/archive?sort=new
#SoftwareDesign
- https://tidyfirst.substack.com/archive?sort=new
#SoftwareDesign
Substack
Archive - Software Design: Tidy First?
Full archive of all the posts from Software Design: Tidy First?.
👍7🔥2👎1
Forwarded from Архитектура ИТ-решений
Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
publications.opengroup.org
TOGAF® Series Guide: Microservices Architecture (MSA)
This document is part of the TOGAF Standard, 10th Edition.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
👍1
Forwarded from Блог Сергея Баранова
Гипотезу Данбара про 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. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
👍19
Архитектура ИТ-решений
Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д.…
Btw, коллекция (почти) всех гайдов одним архивом:
TOGAF® Series Guide Full Set
This is the set of TOGAF® Series Guides. They contain detailed guidance on how to use the TOGAF framework, and are expected to be the most rapidly developing part of the TOGAF documentation set.
- https://publications.opengroup.org/guides/togaf/togaf-series-guides/t180
#SoftwareArchitecture
TOGAF® Series Guide Full Set
This is the set of TOGAF® Series Guides. They contain detailed guidance on how to use the TOGAF framework, and are expected to be the most rapidly developing part of the TOGAF documentation set.
- https://publications.opengroup.org/guides/togaf/togaf-series-guides/t180
#SoftwareArchitecture
publications.opengroup.org
TOGAF® Series Guide Set (The TOGAF® Standard, Version 9.2)
This set of TOGAF® Series Guides is specific to the TOGAF Standard, Version 9.2. Updated versions of some of the TOGAF Series Guides are available in the TOGAF Standard, 10th Edition (C220).
This is a set of TOGAF Series Guides containing detailed guidance…
This is a set of TOGAF Series Guides containing detailed guidance…
👍4
"Data Mesh" by Zhamak Dehghani
Released April 2022
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781492092391
https://www.oreilly.com/library/view/data-mesh/9781492092384/
#SoftwareArchitecture
Released April 2022
Publisher(s): O'Reilly Media, Inc.
ISBN: 9781492092391
https://www.oreilly.com/library/view/data-mesh/9781492092384/
#SoftwareArchitecture
O’Reilly Online Learning
Data Mesh
We're at an inflection point in data, where our data management solutions no longer match the complexity of organizations, the proliferation of data sources, and the scope of our... - Selection from Data Mesh [Book]
👍7🔥2
Когда спрашивают зачем нужен слой абстракции от БД:
😁11👍3
Forwarded from SecurityLab.ru
❌ФСТЭК отзовет более 50 продуктов иностранных разработчиков, которые приостановили свою деятельность в России
— Приостановлены сертификаты на решения от IBM, Microsoft, Oracle, SAP, Vmware, ESET, Trend Micro и другие.
— Действие сертификатов будет прекращено, если компании не возобновят поддержку продуктов в течение 90 дней.
— Теперь государственным информационным системам и объектам критической информационной инфраструктуры придётся ещё быстрее искать замену зарубежным системам.
https://www.securitylab.ru/news/530814.php?r=1
— Приостановлены сертификаты на решения от IBM, Microsoft, Oracle, SAP, Vmware, ESET, Trend Micro и другие.
— Действие сертификатов будет прекращено, если компании не возобновят поддержку продуктов в течение 90 дней.
— Теперь государственным информационным системам и объектам критической информационной инфраструктуры придётся ещё быстрее искать замену зарубежным системам.
https://www.securitylab.ru/news/530814.php?r=1
SecurityLab.ru
ФСТЭК оставит иностранные компании без сертификатов
ФСТЭК отзовет более 50 продуктов иностранных разработчиков, которые приостановили свою деятельность в России, если они не смогут за 90 дней гарантировать обеспечение техподдержки своих систем.
😁13👍3🎉2🤔1🤯1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Запись первого offline DDD-meetup после пандемии: - https://youtu.be/ybYtgII151g?t=27m10s Было здорово! После митапа выпили пива в дружеской обстановке. Вживую познакомился с грамотными и перспективными ребятами, образующими костяк сообщества. Удивила высокая…
Коллеги, какие у вас настроения по поводу очной архитектурной встречи в обозримом будущем (м.Вернадского)?
Anonymous Poll
27%
Поддерживаю, давно пора собраться, готов присутствовать очно
51%
Поддерживаю, но приму участие только в online-формате
22%
Лучше не надо - обстоятельства не располагают
Ребята, вчерашний пост я удалил вскоре после публикации, потому что некоторым показалось наличие в нем политического подтекста, хотя он отражал исключительно мой личный опыт без намека на какие бы то ни было параллели.
Мне жаль, что эту ценную информацию, которая сильно облегчила мою архитекторскую деятельность по разрешению противоречий, сегодня не все могут рассматривать без политической призмы. Поэтому, я публикую укороченную версию вчерашнего поста:
Мне жаль, что эту ценную информацию, которая сильно облегчила мою архитекторскую деятельность по разрешению противоречий, сегодня не все могут рассматривать без политической призмы. Поэтому, я публикую укороченную версию вчерашнего поста: