Архитектор – незаменимый специалист при создании или аудите сложных IT-решений. Его задачи – заложить фундамент проекта, обеспечить гибкость и снизить риски, а в конечном итоге – обеспечить бизнесу быструю разработку и независимость в дальнейшем выборе подрядчиков.
Архитекторы особенно нужны в крупных IT-компаниях, которые ведут много проектов и для каждого выбирают оптимальный технологический стек, с учетом долгосрочной перспективы развития, плюсов и минусов каждого варианта.
Мы в SimbirSoft развиваем собственный архитектурный комитет – в нем уже 54 опытных разработчика. Делимся опытом, чем у нас занимаются архитекторы и на каких проектах они нужны.
Архитектура – это технологическая база IT-продукта. IT-архитектор, или системный архитектор – это, прежде всего, опытный разработчик. Он знает, когда полезно использовать определенную технологию, а самое главное – когда этого не нужно делать и какие есть риски.
Его задачи:
Говоря о хорошей архитектуре, обычно имеют в виду:
Гибкость
Возможность адаптации продукта к новым требованиям бизнеса, даже если в начале процесса проектирования они не были известны в полном объеме.
Например, при создании коробочного решения для страховых компаний мы изначально заложили 4 основных вида полисов, при этом предусмотрели возможность быстро добавить и любые другие необходимые полисы.
Соответствие
Адаптация к ограничениям системы и соответствие техническим и операционным требованиям: по технологическому стеку, работе с персональными данными, Big Data, большим количеством интеграций.
Качество
Обеспечение при проработке архитектуры оптимальных значений атрибутов качества продукта.
Рассмотрим несколько ситуаций, в которых необходима проработка IT-архитектуры.
По мере развития продукта зачастую возникают новые требования, а старых решений уже не хватает.
Бывает и так, что небольшая инхаус-команда работает в рамках одного технологического стека, но для решения бизнес-задач предстоит интегрировать или разработать новую функциональность и при этом подобрать оптимальные технологии реализации. Для этого разработчикам может потребоваться помощь, поскольку сейчас технологии меняются каждые полгода, сложно быть одновременно в курсе всего и иметь экспертизу во всех языках и направлениях.
В таких ситуациях обычно обращаются к опытной команде архитекторов, которая «горит» своим делом, накопила разносторонний опыт и продолжает развивать компетенции в различных технологиях.
Как правило, бизнес заказывает разработку архитектуры в IT-компании в следующих случаях:
При выборе архитектурного решения учитывают множество факторов, в том числе ожидаемые сроки и стоимость разработки, поддержки, развития продукта. При этом нужно учитывать плюсы и минусы каждого варианта.
Кастомная разработка с нуля требует времени и тщательного планирования. «Коробки» – например, такие как «1С: Бухгалтерия» – подходят для компаний с простыми и стандартными бизнес-процессами, но их возможности развития ограничены. При необходимости дальнейшей кастомизации коробка может обойтись даже дороже, чем разработка с нуля, сразу заточенная под нужды компании.
Оптимальное решение для прототипов и простых веб-приложений (например, CRM, интранет-порталы, сайты-визитки), позволяет быстрее выпустить новый продукт на рынок и при необходимости постепенно переписывать отдельные его фрагменты. Подробнее об этом можно прочитать в нашей прошлой статье.
Риски: при увеличении функциональности приложения и количества активных пользователей монолит может перестать справляться с нагрузкой, и срок доставки новых фич будет долгим.
Подходит для крупных IT-систем, которые служат для решения большого количества сложных и разнообразных задач (например, маркетплейсы, социальные сети, мобильные банки). Выделение небольших сервисов позволяет чаще выпускать релизы, гибко масштабировать вычислительные ресурсы при увеличении нагрузки.
Риски: сложность разработки влечет за собой дополнительные требования к квалификации сотрудников. Для микросервисов наличие CI/CD – обязательное условие. Время на разработку будет выше, чем при работе с монолитом (при условии, что архитектурная структура монолита позволяет быстро вносить изменения).
У разных IT-компаний свои способы работы с архитектурой. В небольших монопродуктовых командах у специалистов есть возможность напрямую посоветоваться с коллегами, опытными в тех или иных технологиях. А когда проектов много, появляется необходимость накапливать экспертизу, поскольку при переключении сотрудников с проекта на проект теряется ценный технический контекст. Выстраивая этот процесс, мы снижаем риск ошибок и неоптимальных решений.
У нас в разработке параллельно десятки проектов, и мы стремимся поддерживать внутреннее комьюнити экспертов и обмен опытом. Для этого мы создали архитектурный комитет – отдельную группу со своим руководителем.
Архитектурный комитет – это команда, в которую входят наиболее опытные разработчики Backend, Frontend, Mobile. Сейчас у нас 54 таких специалиста, их число постепенно растет.
Мы уже писали на Хабре, как мы разбираем входящие запросы и оцениваем сроки разработки. Расскажем, как в этом участвуют архитекторы.
На старте проекта мы собираем функциональные, нефункциональные, системные и бизнес-требования.
Архитектор вместе с проектной командой выбирает оптимальное техническое решение в соответствии с планами развития продукта и бизнеса.
Дополнительная проверка выбранного решения 3-5 участниками архитектурного комитета. При необходимости – доработка решения с учетом рекомендаций.
Архитектор, ответственный за проект, формирует документ с архитектурными схемами, описанием взаимодействий и другими необходимыми материалами, обосновывает выбранное решение.
В ходе видеопрезентации заказчику архитектор рассказывает о результате своей работы, а заказчик в реальном времени задает все интересующие его вопросы.
На начальном этапе разработки каждого проекта архитектор помогает заложить каркас системы и курирует архитектуру.
Следуя описанной выше схеме работы, в каждом решении мы учитываем опыт, накопленный архитектурным комитетом при реализации предыдущих проектов.
Несколько участников архитектурного комитета SimbirSoft
С помощью архитектурного комитета мы проработали уже более сотни проектов. По нашим наблюдениям, такой подход к архитектуре обеспечивает IT-компании и заказчику несколько важных преимуществ:
Спасибо за внимание!
Авторские материалы для разработчиков и архитекторов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
Архитекторы особенно нужны в крупных IT-компаниях, которые ведут много проектов и для каждого выбирают оптимальный технологический стек, с учетом долгосрочной перспективы развития, плюсов и минусов каждого варианта.
Мы в SimbirSoft развиваем собственный архитектурный комитет – в нем уже 54 опытных разработчика. Делимся опытом, чем у нас занимаются архитекторы и на каких проектах они нужны.
Задачи IT-архитектора
Архитектура – это технологическая база IT-продукта. IT-архитектор, или системный архитектор – это, прежде всего, опытный разработчик. Он знает, когда полезно использовать определенную технологию, а самое главное – когда этого не нужно делать и какие есть риски.
Его задачи:
- Обеспечить баланс между стоимостью разработки и гибкостью решения для быстрого внедрения будущих требований.
- Обосновать выбор технологий: например, монолит или микросервисы, коробочное или комбинированное решение.
- Контролировать реализацию: заложить каркас системы и провести архитектурный надзор.
Говоря о хорошей архитектуре, обычно имеют в виду:
Гибкость
Возможность адаптации продукта к новым требованиям бизнеса, даже если в начале процесса проектирования они не были известны в полном объеме.
Например, при создании коробочного решения для страховых компаний мы изначально заложили 4 основных вида полисов, при этом предусмотрели возможность быстро добавить и любые другие необходимые полисы.
Соответствие
Адаптация к ограничениям системы и соответствие техническим и операционным требованиям: по технологическому стеку, работе с персональными данными, Big Data, большим количеством интеграций.
Качество
Обеспечение при проработке архитектуры оптимальных значений атрибутов качества продукта.
Рассмотрим несколько ситуаций, в которых необходима проработка IT-архитектуры.
Когда нужен IT-архитектор
По мере развития продукта зачастую возникают новые требования, а старых решений уже не хватает.
Бывает и так, что небольшая инхаус-команда работает в рамках одного технологического стека, но для решения бизнес-задач предстоит интегрировать или разработать новую функциональность и при этом подобрать оптимальные технологии реализации. Для этого разработчикам может потребоваться помощь, поскольку сейчас технологии меняются каждые полгода, сложно быть одновременно в курсе всего и иметь экспертизу во всех языках и направлениях.
В таких ситуациях обычно обращаются к опытной команде архитекторов, которая «горит» своим делом, накопила разносторонний опыт и продолжает развивать компетенции в различных технологиях.
Как правило, бизнес заказывает разработку архитектуры в IT-компании в следующих случаях:
- Нужно разработать ПО с учетом требований законодательства.
- Нужно с нуля разработать ПО, при этом снизить риски ошибок, срыва сроков, увеличения стоимости реализации.
- Требуется повысить гибкость системы.
- Система не отвечает требованиям масштабирования, нагрузки, безопасности.
- Нет ресурсов для разработки IT-архитектуры.
Как выбрать архитектуру
При выборе архитектурного решения учитывают множество факторов, в том числе ожидаемые сроки и стоимость разработки, поддержки, развития продукта. При этом нужно учитывать плюсы и минусы каждого варианта.
Коробочное или кастомное решение?
Кастомная разработка с нуля требует времени и тщательного планирования. «Коробки» – например, такие как «1С: Бухгалтерия» – подходят для компаний с простыми и стандартными бизнес-процессами, но их возможности развития ограничены. При необходимости дальнейшей кастомизации коробка может обойтись даже дороже, чем разработка с нуля, сразу заточенная под нужды компании.
Монолитная или микросервисная архитектура?
- Монолит
Оптимальное решение для прототипов и простых веб-приложений (например, CRM, интранет-порталы, сайты-визитки), позволяет быстрее выпустить новый продукт на рынок и при необходимости постепенно переписывать отдельные его фрагменты. Подробнее об этом можно прочитать в нашей прошлой статье.
Риски: при увеличении функциональности приложения и количества активных пользователей монолит может перестать справляться с нагрузкой, и срок доставки новых фич будет долгим.
- Микросервисы
Подходит для крупных IT-систем, которые служат для решения большого количества сложных и разнообразных задач (например, маркетплейсы, социальные сети, мобильные банки). Выделение небольших сервисов позволяет чаще выпускать релизы, гибко масштабировать вычислительные ресурсы при увеличении нагрузки.
Риски: сложность разработки влечет за собой дополнительные требования к квалификации сотрудников. Для микросервисов наличие CI/CD – обязательное условие. Время на разработку будет выше, чем при работе с монолитом (при условии, что архитектурная структура монолита позволяет быстро вносить изменения).
Пример реализации
Один из наших клиентов-банков использовал коробочную систему дистанционного банковского обслуживания (ДБО). Добавить новые функции (и даже передвинуть кнопки) можно было только с помощью вендора. А значит, во-первых, релизы выходили редко (один раз в квартал), во-вторых, вся экспертиза была сосредоточена у вендора, а не в банке. Кроме того, из-за сложной балансировки клиентов монолитной архитектуры приложение работало со сбоями. Из-за этого банк обратился к нам для проработки нового решения.
Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.
Как работает архитектурный комитет
У разных IT-компаний свои способы работы с архитектурой. В небольших монопродуктовых командах у специалистов есть возможность напрямую посоветоваться с коллегами, опытными в тех или иных технологиях. А когда проектов много, появляется необходимость накапливать экспертизу, поскольку при переключении сотрудников с проекта на проект теряется ценный технический контекст. Выстраивая этот процесс, мы снижаем риск ошибок и неоптимальных решений.
У нас в разработке параллельно десятки проектов, и мы стремимся поддерживать внутреннее комьюнити экспертов и обмен опытом. Для этого мы создали архитектурный комитет – отдельную группу со своим руководителем.
Архитектурный комитет – это команда, в которую входят наиболее опытные разработчики Backend, Frontend, Mobile. Сейчас у нас 54 таких специалиста, их число постепенно растет.
Мы уже писали на Хабре, как мы разбираем входящие запросы и оцениваем сроки разработки. Расскажем, как в этом участвуют архитекторы.
Этапы работы
- Анализ требований
На старте проекта мы собираем функциональные, нефункциональные, системные и бизнес-требования.
- Проектирование архитектуры
Архитектор вместе с проектной командой выбирает оптимальное техническое решение в соответствии с планами развития продукта и бизнеса.
- Внутренний контроль
Дополнительная проверка выбранного решения 3-5 участниками архитектурного комитета. При необходимости – доработка решения с учетом рекомендаций.
- Презентация заказчику
Архитектор, ответственный за проект, формирует документ с архитектурными схемами, описанием взаимодействий и другими необходимыми материалами, обосновывает выбранное решение.
В ходе видеопрезентации заказчику архитектор рассказывает о результате своей работы, а заказчик в реальном времени задает все интересующие его вопросы.
- Архитектурный надзор при разработке
На начальном этапе разработки каждого проекта архитектор помогает заложить каркас системы и курирует архитектуру.
Следуя описанной выше схеме работы, в каждом решении мы учитываем опыт, накопленный архитектурным комитетом при реализации предыдущих проектов.
Несколько участников архитектурного комитета SimbirSoft
Вывод
С помощью архитектурного комитета мы проработали уже более сотни проектов. По нашим наблюдениям, такой подход к архитектуре обеспечивает IT-компании и заказчику несколько важных преимуществ:
- Сокращение срока выпуска продукта на рынок MVP (Minimum Viable Product)
- Сокращение времени на выпуск новых фич (time-to-market).
- Независимость заказчика: возможность выбирать любого подрядчика или вести разработку самостоятельно.
- Минимизация количества сбоев в продукте.
- Возможность найти оптимальное решение для каждой проблемы и гибкость при внедрении новой функциональности.
Спасибо за внимание!
Авторские материалы для разработчиков и архитекторов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
