Архитектурная подборка для тех, кто еще умеет читать книги.

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

#архитектура

Архитектурная зарисовка на тему проектирования процесса обработки платежей для абстрактного цифрового сервиса. Нужен VPN

#архитектура

Верните анализ в аналитиков

На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят.

Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.

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

Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.

Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4

2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.

3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.

4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.

Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Сомнительно.

Как видят BPMN начинающие аналитики

#конфа

Flow. Spring 2024
Во вторник провел на воркшоп о влиянии НФТ на выбор технологий интеграции. Судя по отзывам участников, получилось хорошо, но совсем не так, как планировал.

Дополнительные материалы, которые обещал
Модель зрелости REST-сервисов https://martinfowler.com/articles/richardsonMaturityModel.html

Спецификация JSON-RPC 2.0 https://www.jsonrpc.org
Инструмент для документирования JSON-RPC https://news.1rj.ru/str/another_sa/78

Краткий обзор GraphQL с хорошими ссылками: https://habr.com/ru/post/326986/
Стрим об особенностях использования GraphQL: https://youtu.be/gfSYKLo0P5E?si=4OluWLZVg61ACAA1

Просто о Websockets: https://mcs.mail.ru/blog/websocket-kogda-sleduet-ispolzovat-i-preimushhestva
Сравнение WebSockets и gRPC: https://dev.by/blogs/godel-technologies-europe/articles/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket

Большая база материалов по интеграции систем: https://systems.wiki/integration

Сравнение REST и RPC стилей API
В защиту REST: https://habr.com/ru/post/476576
В защиту JSON-RPC: https://habr.com/en/post/441854
Стрим REST vs RPC https://youtu.be/JS96oEB4bWc?si=6TaOXjq1K96r3P-z

Идея поиска работы

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

Вспомнил, как несколько лет назад искал мидлов в компанию, и мне написало в личку два кандидата в формате: “Я не прохожу под все требования, но есть такой-то опыт, давай попробуем поговорить”. Поговорить согласился, просто потому что не засцали написать.
В итоге наняли обоих, и успешно работали несколько лет.

К чему это? Мне регулярно пишут с предложениями разместить рекламу в канале, иногда сами покупаем рекламу курсов. Пост в каналах на 3-5к подписчиков может стоить около 5.000р. На 10-15к подписчиков около 10.000р.

Что мешает сделать классное резюме, подготовить короткий яркий пост с самопрезентаций и опубликовать в канале для аналитиков? Сходу могу вспомнить четыре таких канала, где сидит по 7-10к подписчиков. Причем среди них лиды и нанимающие менеджеры. Даже если таких 1% получим аудиторию в 70-150 лидов, к которым мы обратимся напрямую без HR и SMS. Если на них конверсия будет в 10%, то имеем 7-15 контактов для дальнейшего диалога.

Выглядит неплохо. Правда, это больше для специалистов middle и выше, которые уже могут рассказать про какие-то результаты. И главное - не сцать.

Если интересно попробовать - маякните в комментах, готов помочь с авантюрой.

UML умер, но никто этого не заметил?

Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.

Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)

Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.

Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.

Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".

Интересными мне показались два поинта в статье:

1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.

2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.

Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.

В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.

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

А вы применяете UML? Насколько часто, и что именно из него?

Околообразование для аналитиков

Интересно наблюдать за развитием инфобиза в аналитической тусе. Как это было для меня.

2012-2019. Тишь да Вигерс
Из открытого обучения есть базовый курс ШСА и 2-3 коротких тренинга, плюс несколько центров корп обучения при крупных интеграторах. В основном все фокусируются на базовых техниках работы с требованиями: ФТ, НФТ, Use Cases и вот это все.

2020-2021. Интеграция расправляет плечи
Стартуют первые курсы по интеграции систем для аналитиков у ШСА и Com-Practice. Фокус смещается на “технику”, в основном на HTTP-based сервисы и SOAP, народ задорно обсуждает что такое REST, и как его правильно готовить.

2021. Вторжение титанов
На волне роста онлайн-образования в тему SA/BA заходят гиганты эдтеха в духе БрикФактори и им подобных. Многие закидывают их камнями и помидорами, ибо качество вызывает вопросы.

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

Хозяйке на заметку: сегодня пост в канале на ~10к подписчиков стоит 10-15к рублей. По моим наблюдениям канал может приносить 50-200к в месяц в зависимости от сезона. И не нужно заморачиваться с курсом.
А с открытыми LLM это реально автоматизировать.

2021-2023. Образовательная лихорадка
Не только лишь каждый аналитик запустил свой инди-курс в одном и популярных форматов: от записи на степике, которая приносит небольшую копеечку, до живых когортных курсов с активным маркетингом. Ибо собрать и продать курс стало значительно проще, чем до ковида.

За это время качество локального бутикового (Денис, спасибо за термин, каждый раз ржу) образования сблизилось с большими игроками: брикфактори подтянули качество, а в андергрунде появились курсы по архитектуре от аналитиков с 3-5 летним стажем.

2023-2024. Пост-пост, мета-мета
Курсы плодятся, запускать легко, но нужно продавать - много конкурентов.

Появляются курсы вида “как пройти собеседование на SA”, “как найти работу аналитиком”, “как построить карьеру в IT” и т.п.
Подход мегаразумный - продать техническое обучение куда сложнее, чем продать буст карьеры. Участники тратят меньше времени на обучение, а результат намного понятнее и проще измерять. Тем более брикфактори и другие стабильно поставляют клиентов - специалистов с завышенными ожиданиями.

Есть даже курс по подготовке IT-спикеров. Не знаю, как продается, имхо рынок слишком маленький - по конференциям кочует всего несколько сотен спикеров.

Среди каналов случился первый эксперимент с платной подпиской. Контент классный, но не особо летит. Возможно, народ привык к халявному контенту.

2024 - …
Вангую тренд на мета-скиллы и обучение-без-курсов будет развиваться, а начинающим авторам будет проще запрыгнуть в них, чем в стандартные технические курсы.


P.S. Хронология или причинно-следственные связи в вашей версии реальности могут отличаться, поделитесь же ими.

Designing High-Performance APIs - с одной стороны поверхностная и капитанская статья, с другой - полезные вопросы на подумать при проектировании API. Можно пробежаться и покопать незнакомые темы.

#API

Через неделю еду в Сибирь релизить и молиться.

И вы заходите - там секция по анализу вернулась.

🧪 Секция System analysis

🔹 Олеся Пахомова расскажет об архитекторе решений: что это, чем отличается от других видов архитектур и причём здесь бизнес-анализ.

🔹 Андрей Шапиро поделится авторским методом схематизации процесса и пользовательского опыта.

🔹 Кирилл Кашин и Сергей Хованов продемонстрируют, как можно перепроектировать системы с помощью ТРИЗ и извлекать максимум из ограниченных ресурсов.

🔹 С Андреем Бураковым обсудим, как требования и ограничения влияют на выбор технологии интеграции.

🔹 С Анной Вичуговой поговорим про инженерию данных и важность для системных аналитиков.

🔹 Роман Селезнёв разложит по полочкам тему выбора средств визуализации информации и почему это важно при разработке информационных систем.

🔹 С Викторией Лузиной обсудим проблему некорректной документации, роли технического писателя и как выглядит документация, за которую не стыдно.

Вся программа 👉 https://14.codefest.ru/program

#спикеры_CodeFest14

Хардкорный разбор работы протокола HTTP/2 на уровне обмена сообщениями фреймами.
Написано классно и интересно. Но зачем вам это, я не знаю

Вспомнил, что яжепродакт, и завел канал для всякого продуктового. Будут собирать интересные ссылочки, рассуждать про финтех, около-образование, экспериментировать с иишечкой. Все как здесь 4 года назад.

Веллкам, если интересно: https://news.1rj.ru/str/fake_product

А сегодня реально важный контент от автора предыдущей статьи - разбор работы TLS, где он последовательно выдает всю необходимую базу:

• Способы атак, что и зачем защищаем

• Синхронное и асинхронное шифрование, ключи, подписи

• Обмен ключами, протокол Диффи-Хелмана

• Сертификаты и центры сертификации CA

Наглядно и со схемами. Кто метит в архитекторы или техлиды - читать обязательно.

Есть хардкорное продолжение, где рассматривает процесс на уровне сообщений со схемами и примерами кода.

#интеграция

#подслушано

Хорошо по процессу работать - не надо париться за сроки и результаты, просто сидишь и задачи клепаешь.

Я смотрю, среди около-аналитических конференций продолжает появляться новое и интересное.

Наташа Семенова организует первый Smart Speaker Conf - живая конфа для лидов и экспертов из айтишечки, где будут говорить не об архитектуре и требованиях, а о мышлении, мета-навыках, и есть ли жизнь после работы.

Вот такие темы будут:
▪️Лидерство в IT
▪️Кросс-ролевые софт-скиллы
▪️Профессиональная самореализация
▪️Работа и карьера в разрезе полноты жизни
▪️Выход на новый уровень мышления
▪️Использование проф. инструментов в жизни

Сам не попаду из-за пересечения с кодфестом, но если будете в Петербурге, заходите:

🔗 Регаться тут
📆 26 мая, начало в 09:00
📍 Санкт-Петербург, Невский проспект, д.54

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

На выхах 15-16го проводим последний перед летними каникулами тренинг System Design. Основы проектирования архитектуры систем. Будем познавать балансировку, кеширование, CDN и прочие способы масштабирования.

А еще поговорим о способах интеграции, выборе хранилища и влиянии бизнес-метрик на архитектуру. Все через практику, как обычно.

Тренинг ведет Даша Колесова - участница моего рейтинга топ-1 по наглядности подачи технических материалов.