Книги, которые стоит прочитать, если хочешь стать solution-архитектором

1. "Patterns of Enterprise Application Architecture" — Martin Fowler
Эта книга — классика для архитекторов, работающих с enterprise системами. Она учит, как проектировать системы, которые легко развивать и поддерживать, даже в условиях большой нагрузки и сложности.

💡Что даст:
- Знание ключевых паттернов проектирования для создания масштабируемых и поддерживаемых enterprise-приложений.
- Понимание, как применять эти паттерны в реальных системах.
- Умение разделять компоненты системы для повышения модульности и гибкости.

2. "Technology Strategy Patterns: Architecture as Strategy" — Gregor Hohpe
Solution-архитектор должен не только проектировать системы, но и понимать, как они вписываются в бизнес-стратегию. Эта книга поможет мыслить стратегически.

💡Что даст:
- Понимание, как выстраивать технологическую стратегию, которая соответствует бизнес-целям.
- Научит разбираться в том, как снижать затраты, внедрять инновации и удерживать систему и организацию от размывания.
- Навыки создания технологического roadmap для приоритизации инициатив и инвестиций.

3. "Software Requirements" — Karl E. Wiegers
Архитектор должен уметь работать с требованиями. Эта книга поможет лучше понимать, как требования формируют архитектуру.

💡Что даст:
- Навыки работы с требованиями: их сбор, анализ, спецификация и валидация.
- Понимание, как требования влияют на архитектуру системы.
- Умение использовать моделирование, прототипирование и тестирование для проверки требований.

4. "Impact Mapping: Making a big impact with software products and projects" — Gojko Adzic
Еще одна книга о взгляде на разработку со стороны бизнеса. Она научит, как проектировать системы, которые приносят реальную пользу бизнесу.

💡Что даст:
- Навыки создания impact maps для выравнивания разработки с бизнес-целями.
- Понимание, как фокусироваться на результатах, а не на функциональности.
- Умение работать с минимально жизнеспособными продуктами (MVP) для быстрого получения обратной связи.

Работа SA – не только о технике, а еще о взаимодействии с людьми и выстраивании долгосрочной стратегии. Эти книги помогут заполнить пробелы и увереннее подходить к архитектурным задачам.

О книгах с фокусом именно на проектирование архитектуры мы писали в одном из прошлых постов.

📈 Поговорим о росте и развитии архитектора

✅ Как различаются взгляды на систему у Senior разработчика, техлида, Solution и Enterprise архитектора?
✅ Чем занимаются Solution, Enterprise, Data, ML, Cloud, Integration и другие архитекторы?
✅ Как архитектор переходит от технических решений к бизнес-фокусу, начинает масштабировать архитектуру и выстраивать технологическую стратегию компании?
✅ Как балансировать между time-to-market и техдолгом, справляться с legacy, со сложной бизнес-логикой, с ростом бизнеса и с влиянием корпоративной культуры
✅ Как архитектору эффективно взаимодействовать с low-code/no-code решениями и интегрировать AI-инструменты в архитектуру компании.

А также представим обновленную программу курса [Solution Architect in the Wild] v3

📅 Дата: 26 марта
⏰ Время: 20:00(GMT+3)

Ведущие:
Павел Вейник - Solution Architect, Staff Engineer
Антон Дворников - Principal Solution Architect

🔗 Регистрируйтесь по ссылке

Будущее профессии Solution Architect: что ждет нас в ближайшие годы?

Профессия архитектора меняется вместе со всей индустрией IT. Две недели назад мы затронули эту тему вместе с участниками круглого стола о роли Solution Architect. Вот краткие выводы:

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

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

⚖️ Во-вторых, индустрия IT быстро оптимизируется и стандартизируется после периода взрывного роста, который был до 2022 года. Это касается сокращения людей и ролей в компаниях, а также внедрения подходов вроде "архитектура как код" и "документация как код".

🗣 В-третьих, работа архитектора по большей части не о проектировании, а о взаимодействии с людьми: бизнес-стейкхолдерами, менеджерами, разработчиками. Никакая автоматизация не сможет полностью заменить человеческое общение.

Что изучать, чтобы не отстать?

ИИ, автоматизация и no-code/low-code. Новые инструменты уже меняют индустрию. Чтобы оставаться эффективным и конкурентоспособным, архитектору нужно знать, как ими пользоваться.

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

Архитектурные паттерны и best practices. Несмотря на любые изменения в работе SA, чтобы проектировать хорошие системы, нужно знать, как их сделать хорошими.

🗓 26 марта мы встретимся с Павлом Вейником и Антоном Дворниковым, чтобы поговорить о роли Solution Architect:

🔹 Карьерный путь к архитектуре. Рост и развитие Solution Architect.
🔹 Типы архитекторов и зоны ответственности.
🔹 Работа в команде архитекторов и реальные вызовы в этой работе.
🔸 Как архитектору эффективно взаимодействовать с low-code/no-code решениями и интегрировать AI-инструменты в архитектуру компании.

🔗 Регистрируйтесь по ссылке и задавайте свои вопросы!

Как ИИ и автоматизация вытесняют middle-разработчиков — и что с этим делать

1️⃣ Что уже произошло: ИИ, low-code и автоматизация меняют рынок

IT перестаёт быть «особенной» отраслью — теперь это просто бизнес, где каждый процесс оптимизируют под эффективность. ИИ, low-code и автоматизация уже сейчас забирают куски работы у разработчиков:

🔹Джуны и слабые middle-разработчики становятся не нужны. ИИ справляется с рутинным кодом, шаблонными задачами и тестированием. No-code-платформы позволяют бизнесу собирать приложения без программистов.

🔹Тестировщики и продакт-оунеры под ударом. А менеджеры, не разбирающиеся в технике, теряют ценность.

🔹Архитекторы и senior-разработчики тоже не в безопасности. Компании сокращают бюджеты, и дорогие специалисты теперь должны доказывать, что их работа критически важна.

2️⃣ Что будет дальше?

Через несколько лет рынок изменится ещё сильнее:

🔸Прикладная разработка превратится в «конструктор». Менеджеры будут собирать приложения из готовых блоков, а код писать только для сложных модулей.

🔸Порог входа в IT резко вырастет. Чтобы попасть в индустрию, нужно будет сразу обладать навыками сегодняшнего middle+.

🔸Останутся только две категории разработчиков:
- Те, кто автоматизирует автоматизацию (пишут инструменты для ИИ и low-code).
- Те, кто работает с фундаментальными системами (базы данных, инфраструктура, AI/ML).

3️⃣ Что делать middle-разработчику, чтобы выжить?

Краткий ответ – расти до сеньора. Для этого:

✅ Развивайте системное мышление. Учитесь видеть проект целиком, и не просто писать код, а осознавать, как он вписывается в архитектуру, а она, в свою очередь, строится исходя из бизнес-требований.

✅ Прокачивайте soft skills. Учитесь понимать стейкхолдеров, объяснять и отстаивать свои технические решения. Разбирайтесь в процессах разработки и людях, которые их создают и поддерживают.

✅ Разбирайтесь в AI и автоматизации. Передайте рутинные задачи ИИ, а сами сфокусируйтесь на сложных вещах.

📆 2 апреля на митапе [из Middle в Senior] подробно поговорим о том, какие навыки отличают сеньора от мидла, что изучать, чтобы перейти на следующий грейд, и чего не хватает именно вам.

Ведущие:
Павел Вейник - Solution Architect, Staff Engineer
Светлана Семёнова - Senior Software Engineer

Регистрируйтесь по ссылке и увидимся в среду!

Как проходят курсы в Hard&Soft Skills? Посмотрим, что обсуждают участники [Технического Лидера]

Немного приподнимем занавес и посмотрим, о чем говорили на одном из практических занятий курса.

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

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

🔸Выделять проблемные места и предлагать несколько вариантов их решения.
🔸Формулировать идеи так, чтобы их понимали не только разработчики, но и менеджеры.
🔸Учитывать критерии выбора: надежность, производительность, стоимость, удобство поддержки.

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

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

2. End-to-end тесты и перегруженная очередь сообщений

На занятии разобрали кейс, где end-to-end тесты генерировали огромное количество событий, а RabbitMQ не успевал их обрабатывать. Это привело к падению тестов из-за тайм-аутов.

Как это получилось решить?

🔹 Внедрили пирамиду тестирования:

– Много юнит-тестов (десятки тысяч).
– Меньше компонентных тестов (сотни/тысячи).
– Совсем немного end-to-end тестов (десятки). Их задача — проверить взаимодействие сервисов, а не логику внутри компонентов.

🔹 Постепенно заменили тяжелые end-to-end тесты на моки или тесты более низкого уровня.

В результате время тестирования сократилось с 60 часов до 2-3 часов, просто за счет пересмотра подхода и удаления лишних end-to-end проверок. При этом качество контроля только выросло.

3. Код-ревью

Вопрос о код-ревью вызвал оживленную дискуссию. Вот ключевые моменты:

🔸Для mission-critical проектов будьте строги: код должен соответствовать стандартам, шаблонам и нефункциональным требованиям.
🔸В стартапах можно быть гибче: главное — скорость и проверка работоспособности, а мелкие недочеты иногда можно пропустить.
🔸Для обучения разработчиков важно давать развернутые комментарии, но без излишней жесткости.

❗️Важно:
Если разработчики «дают слабину», возможно, проблема в мотивации или культуре команды, а не в код-ревью как таковом. Код-ревью — не просто формальность, а инструмент роста.

Друзья, завтра встречаемся на новый H&S Conclave доклад "RUST: панацея или просто ещё один язык?"

Rust продолжает набирать популярность, но стоит ли он хайпа? Разбираемся без иллюзий:

🔸 Ожидания от Rust — реальные и завышенные:
Кому на самом деле нужен Rust, за что его так ценят, и почему не все готовы переписывать свои системы на Rust.

🔸 Обзор принципов языка:
Четыре столпа Rust — это революция или просто эволюция? Как Rust обеспечивает безопасность и производительность на практике.

🔸 Как стать Rust-инженером:
Порог вхождения, подводные камни и советы тем, кто хочет освоить Rust.

🔸 Выводы:
Стоит ли переключаться на Rust прямо сейчас? И что важно знать перед тем, как сделать этот шаг.

Приходите! Регистрация по ссылке ⚙️🦀

🔥 Уже сегодня вечером поговорим о лучших практиках Code Review! Приходите послушать опыт спикера и поделиться своими инсайтами.

🗓 Когда: 10 апреля, в 20:00 (GMT +3)

🎙 Спикер: Виктория Телюк — Senior Java Backend Developer, Code Quality Advocate

💡 В программе доклада:

‣ Статистика из реального кейса
Насколько нам удалось улучшить качество кода и какую роль сыграл post review.

‣ Проверенные практики для эффективного code review в команде.

‣ Топ-10 самых частых проблем при ревью кода
Рейтинг типичных ошибок и как их выявлять и предотвращать.

‣ Обмен опытом
Как организован процесс code review в разных командах: делимся подходами и обсуждаем, что работает лучше всего.

👉 Зарегистрироваться и оставить вопрос спикеру — по ссылке. До встречи!

Когда можно считать себя senior-разработчиком?

Эту тему мы обсуждали в прошлом году за круглым столом о роли senior. Senior-разработчик — это не только техническая экспертиза, но и зрелость в принятии решений, понимание бизнес-контекста и способность вести за собой команду.

Вот ключевые признаки senior-а:

Автономность и ответственность. Senior способен самостоятельно ставить цели, планировать их достижение и нести ответственность за результат. Senior не просто пишет код, а думает о том, как его работа влияет на бизнес.

Сеньор — это тот, кто берет задачу, доводит её до конца и видит, какую ценность это приносит компании.

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

Soft skills. Умение общаться с коллегами из других отделов (продукт, дизайн, маркетинг), менторить junior-разработчиков и доносить свои идеи — критически важно.

Чем выше уровень, тем больше обсуждений и компромиссов с бизнесом.

Умение исправлять ошибки (и свои, и чужие) и делать из них выводы.

Ты перестаёшь ныть о "неправильных" процессах и начинаешь думать, как улучшить бизнес. Это и есть переход в сеньорство

Можно ли считать себя senior, если не работал в этой должности, но запускал свои стартапы?

Если вы были единственным разработчиком в стартапе, это, безусловно, даёт богатый опыт. Вы учились быстро принимать решения, брали на себя всё: от DevOps и тестирования до релиз-менеджмента.

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

Когда ты работаешь в одиночку, твой код никто не проверяет. Ты можешь думать, что ты сеньор — но это не факт. Без взаимодействия и фидбэка расти трудно.

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

Как бороться с синдромом самозванца?

Хорошая новость – почти все с ним сталкиваются. Плохая – до конца избавиться от него невозможно. Но можно научиться жить с ним так, чтобы он не мешал:

Отделяйте себя от навыка. Если не получилось — это не вы «плохой», просто пока нет нужного опыта.

Ведите дневник достижений. Записывайте положительные фидбэки, успешно завершённые задачи и ситуации, где вы проявили инициативу.

Разговаривайте с коучем или ментором. Иногда нужен кто-то со стороны, кто поможет объективно оценить ваши навыки.

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

Не сравнивайте себя с идеалом. Всегда найдется кто-то круче. Важно сравнивать себя с собой в прошлом.

Помните, что senior — это не "всезнайка". Senior-разработчик тоже учится и ошибается. Главное — уметь быстро находить решения и исправлять ошибки.

Используйте синдром как мотивацию. Легкая неуверенность может подталкивать к развитию. Главное — не давать ей парализовать себя.

Senior — это не звание, а образ мышления

Если этого еще недостаточно, чтобы развеять сомнения в своей сеньорности, – записывайтесь на консультацию. За 15-30 минут с преподавателем вы определите свои сильные и слабые стороны, составите план развития и узнаете, чем на этом пути вам поможет курс [из Middle в Senior]. Подробности по ссылке 🔗

Навыки техлида: критическое мышление и problem solving

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

🧠 Критическое мышление для техлида — это способность подвергать сомнению очевидные решения, видеть потенциальные риски и задавать правильные вопросы команде и бизнесу. Техлид с развитым критическим мышлением не принимает решения на автомате, а осмысленно подходит к любой задаче: от выбора фреймворка до построения архитектуры системы.

💡 Problem solving — это способность находить решения даже в условиях неопределенности и ограниченных ресурсов. Для техлида это значит не просто "погасить пожар", а разобраться в первопричине проблемы, чтобы избежать её повторения в будущем, а зачастую – предвидеть проблему заранее. Это включает умение четко формулировать проблему, быстро исследовать возможные подходы и выбирать наиболее эффективное и рациональное решение.

Как меняется навык от middle до техлида?

Middle-разработчик владеет навыками problem solving на уровне конкретных задач. Он решает проблемы самостоятельно в рамках заданного контекста.

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

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

Как развивать критическое мышление и problem solving?

1️⃣ Практикуйте глубокий анализ. Вместо того, чтобы использовать первое попавшееся решение, всегда задавайте вопрос: "Почему именно так?" Рассматривайте альтернативы и их последствия.

2️⃣ Учитесь задавать правильные вопросы. Чем выше уровень вашей позиции, тем важнее качество задаваемых вопросов. Учитесь докапываться до сути проблемы.

3️⃣ Разбирайте кейсы и ошибки. Проводите ретроспективы и post-mortem-аналитику. Разбор реальных кейсов помогает увидеть слабые места в логике решений и выработать навык системного подхода к решению задач.

4️⃣ Развивайте системное мышление. Не смотрите на проблему изолированно. Учитесь видеть взаимосвязи между компонентами системы, их влияние друг на друга и долгосрочные последствия решений.

5️⃣ Работайте с ментором или коучем. Иногда необходим взгляд со стороны, чтобы понять, где вы мыслите шаблонно и упускаете возможности. Профессиональное менторство существенно ускоряет развитие этих навыков.

6️⃣ Приходите на курс [Технический Лидер] и развивайте эти навыки на практических задачах и в обсуждениях с преподавателем и другими senior+ инженерами. Записывайтесь на консультацию!

🚀 AI в разработке: от хайпа к реальности

ИИ уже не просто игрушка — он реально пишет код, помогает ускорять команды и меняет подход к разработке. Но как всё это выглядит вживую, а не в презентациях?

Приходите завтра на доклад — Денис Филипкин поделиться личным опытом. Поговорим:

🧩 AI в коде — как он меняет игру и чего ждать дальше

🧩 Мой опыт — где AI помог, а где только мешал

🧩 Кейс с Cline — конкретный проект и что получилось

🧩 Q&A + обмен опытом — обсудим, кто как работает с AI

📅 22.04 в 20.00 GMT+3

Зарегестрироваться и оставить свои вопросы можно по ссылке. До встречи!

👉 Друзья, мы уже стартанули доклад про опыт использования AI в разработке, успевайте присоединиться к нам в Google meet

🎙 GenAI under Control: Evaluation & Guardrails. Part 2

Сегодня встречаемся в 20:00 GMT+3 на докладе H&S Conclave!

Продолжаем разбираться, как контролировать поведение LLM-моделей в боевых условиях. После теоретической базы — переходим к практике.
Во второй части доклада:
🔹 Что такое evals и как они помогают оценивать точность и релевантность промптов
🔹 Как использовать guardrails — для управления, фильтрации и ограничения поведения модели

📺 Если пропустили первую часть — запись доступна на YouTube!

👤 Спикер: Вадим Гацура, VP of Engineering @ Viio

👉 Зарегистрироваться на ивент и оставить свой вопрос можно по ссылке