Проект "Архитектурные этюды" неожиданно обрел для себя новое качество, в виде площадки по найму специалистов.

Мне видится эта тенденция положительной, т.к. она способна уменьшить проблему "лимонов и персиков" на рынке труда.

[UPDATE]: после регистрации требуется пройти спам-тест в главном топике https://www.tgoop.com/archicases/1 за 60 сек.

Друзья!

В связи с последними событиями с youtube, какие теперь есть варианты с предоставлением доступа к видео с ArchDays?

Из уже рассмотренных вариантов:
- rutube не подходит, так как в нем нет ни целевой аудитории, ни каких-либо инструментов для продвижения видео/аналитики
- vk не подходит по тем же причинам

И то и другое не подходит в том числе потому, что там нет западной аудитории, а одна из целей еще и в том, чтобы повышать осведомленность в мире о наших достижениях.

Варианты?

Нашел в своих старых заметках

Если рассматривать организацию или команду как единую систему, то при оценке навыков членов команд навык обучения других становится более важным, чем уровень навыка каждого конкретного члена команды в отдельности.
Если один разработчик выполняет задачу в 10 раз быстрее, чем остальные, но не умеет передавать знания — это хуже, чем если он же выполняет в 5 раз быстрее и может научить других делать так же быстро и эффективно.
В первом случае получаем потенциальное бутылочное горлышко и в перспективе: 10x, 1x, 1x, 1x
Во второму случае в перспективе: 5x, 5x, 5x, 5x и рост всех до 10x - это вопрос значительно более короткого промежутка времени.

20 августа 19:00 по мск “Learning Domain-Driven Design Часть III. Применение DDD на практике (Глава 10-13) / Сергей Баранов”

В самом начале обсудим историю перевода. После разберемся как быстро определять какой паттерн из DDD соответствующих сложности предметной области и ее потребностям. Рассмотрим практику EventStorming. И обсудим самый главный вопрос - как внедрить DDD в уже существующий проект, как его поддерживать и сопровождать.

В обсуждении нам поможет невероятный гость - Сергей Баранов 🔥 Занимается развитием направления DevOps и ИТ-архитектуры, партнер ScrumTrek с 2015 года. Он является основателем и идейным вдохновителем конференции ArchDays, председателем РОО «Объединение ИТ-Архитекторов», а также признанным экспертом в практике проведения сессий Event Storming.

Подключайтесь в вторник в 19:00 к обсуждению в Zoom или к YouTube трансляции

А в комментариях к этому посту оставляйте свои вопросы, которые хотели бы задать Сергею ⤵️

Подскажите аналог Miro, который можно развернуть on-premise.

Важнейшее требование - возможность одновременной работы участников.

Кто у себя в компании/продукте/системе интегрировал любые AI решения, какие архитектурные особенности вы заметили, которые важно учитывать, если интегрируется именно AI-компонент, как они на общую архитектуру влияют?

Вы только посмотрите, о какой крутой штуке сегодня рассказали:
https://regexcrossword.com

Судя по всему, используется активно, предлагаю в комментариях к этому треду поделиться как именно используете в формате:

Какая LLM
Как использую

Польза в том, чтобы пошарить между собой сценарии, почти наверняка у каждого есть какой-то уникальный сценарий, о котором не подумали другие :)

#события #москва #онлайн #бесплатно

AlfaArchMeetup #1
Митап от solution-архитекторов Альфа-Банка
25 октября 18:00, Москва + онлайн

- Архитектурная стратегия. Чем она помогает компании
- Проект MLM / История создания «Свой в Альфе»
- Как мы развиваем архитектуру и архитекторов
- Невероятная жизнь архитектора решений

Ссылка

24 октября (чт) в 19:00 по МСК пройдет вебинар на тему «Саги как инструмент управления сложными бизнес-процессами: от теории к практике на примерах из финтеха и других отраслей» на котором Михаил Натаров, системный архитектор и Engineering Manager, подробно разберёт примеры использования саг в различных доменах и покажет, что этот паттерн применим в любом бизнесе.

Этот вебинар будет особенно полезен:
— Системным аналитикам, которые хотят углубить своё понимание сложных бизнес-процессов и улучшить взаимодействие с разработчиками и архитекторами.
— Архитекторам и разработчикам, работающим с распределёнными системами и микросервисами.
— Руководителям IT-проектов, которые заинтересованы в эффективном управлении проектированием и поддержкой отказоустойчивых систем.
— Специалистам из различных отраслей (финтех, маркетплейсы, логистика, и т.д.), которые сталкиваются с управлением сложными процессами и распределёнными транзакциями.

🚀 План вебинара
1. Введение в паттерн саги
2. Пример: типичный сценарий платежа в маркетплейсе.
3. Сложности внешних вызовов: таймауты, разница в состоянии систем, идемпотентность.
4. Компенсационные механизмы в саге
5. Различные срезы для анализа при проектировании саги
6. Когда сага не нужна

У всех слушателей будет возможность задать вопросы в режиме реального времени

Регистрация

#вебинар

Коллеги, хочу предложить к обсуждению один вопрос, который часто поднимается архитекторами в профильных чатах.

Заключается он в том, что архитектору нужно доказывать правоту своей позиции перед лицом команды или менеджмента. Причем, судя по обсуждениям, зачастую это заканчивается безуспешно, несмотря на всю правильность и обоснованность его позиции. О таких проблемах нередко пишут достаточно авторитетные в сообществе ребята с хорошей глубиной знаний.

Собственно, о такой ситуации писали и всемирно известные авторы в области ИТ-архитектуры (Nick Tune, Gregor Hohpe, Neal Ford и др.)

Мне кажется, что корень проблемы лежит не в том, что говорит архитектор, а в том, что он из себя представляет. Как только он начинает что-то доказывать, он тем самым занижает свою значимость, и завышает значимость своего оппонента. Ставит себя в подчиненную позицию. Тем самым он занижает ценность своих аргументов.

Задача архитектора заключается прежде всего в том, чтобы сформировать свою ценность в глазах окружения. Не доказывать, а создать такие предпосылки, при которых к нему сами обращались бы с вопросами.

Я часто говорю, что лучший формат общения архитектора - это не утверждения, а вопросы. Такие вопросы, которые делали бы очевидными достоинства его решения. Тут есть и психологический момент - задавая вопросы, архитектор не ставит себя в позицию "снизу", не занижает своей значимости. А оппонент, дошедший до правильного решения самостоятельно, под воздействием правильных вопросов, будет чувствовать себя причастным к этому решению, что устраняет предпосылки для психологической защиты и сопротивления.

А лучшим помощником архитектора является нагрузочное тестирование, которое делает предполагаемые проблемы явными. Если проанализировать подобные дискуссии в профильных пабликах, то можно обнаружить, что чаще всего проблемы возникают там, где нагрузочное тестирование не организовано.

Что думаете по этому поводу? Какой у вас опыт?

[UPDATE]: Ранее уже были посты по этой теме:
- https://www.tgoop.com/ru_arc/77
- https://www.tgoop.com/ru_arc/76

Много материалов по ADR:
https://github.com/joelparkerhenderson/architecture-decision-record

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

При этом как ни удивительно, книга интересна и актуальна до сих пор и для разработчиков и для архитекторов и для системных аналитиков.

Можно сказать, что книга прошла почти незамеченной в широкой профессиональной среде, в частности, никогда не переводилась на русский язык.

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Достаточно сложно писать спагетти-код, когда уже освоил навыки написания чистого кода.

Фактически, написание плохого кода становится более энергозатратным :)