Как работают IT-архитекторы – наши примеры и задачи

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

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

    Мы в SimbirSoft развиваем собственный архитектурный комитет – в нем уже 54 опытных разработчика. Делимся опытом, чем у нас занимаются архитекторы и на каких проектах они нужны.



    Задачи IT-архитектора


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

    Его задачи:

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

    Говоря о хорошей архитектуре, обычно имеют в виду:

    Гибкость

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

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

    Соответствие

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

    Качество

    Обеспечение при проработке архитектуры оптимальных значений атрибутов качества продукта.
    Рассмотрим несколько ситуаций, в которых необходима проработка IT-архитектуры.

    Когда нужен IT-архитектор


    По мере развития продукта зачастую возникают новые требования, а старых решений уже не хватает.

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

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

    Как правило, бизнес заказывает разработку архитектуры в IT-компании в следующих случаях:

    1. Нужно разработать ПО с учетом требований законодательства.
    2. Нужно с нуля разработать ПО, при этом снизить риски ошибок, срыва сроков, увеличения стоимости реализации.
    3. Требуется повысить гибкость системы.
    4. Система не отвечает требованиям масштабирования, нагрузки, безопасности.
    5. Нет ресурсов для разработки IT-архитектуры.


    Как выбрать архитектуру


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

    Коробочное или кастомное решение?


    Кастомная разработка с нуля требует времени и тщательного планирования. «Коробки» – например, такие как «1С: Бухгалтерия» – подходят для компаний с простыми и стандартными бизнес-процессами, но их возможности развития ограничены. При необходимости дальнейшей кастомизации коробка может обойтись даже дороже, чем разработка с нуля, сразу заточенная под нужды компании.

    Монолитная или микросервисная архитектура?


    • Монолит

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

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

    • Микросервисы

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

    Риски: сложность разработки влечет за собой дополнительные требования к квалификации сотрудников. Для микросервисов наличие CI/CD – обязательное условие. Время на разработку будет выше, чем при работе с монолитом (при условии, что архитектурная структура монолита позволяет быстро вносить изменения).

    Пример реализации


    Один из наших клиентов-банков использовал коробочную систему дистанционного банковского обслуживания (ДБО). Добавить новые функции (и даже передвинуть кнопки) можно было только с помощью вендора. А значит, во-первых, релизы выходили редко (один раз в квартал), во-вторых, вся экспертиза была сосредоточена у вендора, а не в банке. Кроме того, из-за сложной балансировки клиентов монолитной архитектуры приложение работало со сбоями. Из-за этого банк обратился к нам для проработки нового решения.

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


    Как работает архитектурный комитет


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

    У нас в разработке параллельно десятки проектов, и мы стремимся поддерживать внутреннее комьюнити экспертов и обмен опытом. Для этого мы создали архитектурный комитет – отдельную группу со своим руководителем.

    Архитектурный комитет – это команда, в которую входят наиболее опытные разработчики Backend, Frontend, Mobile. Сейчас у нас 54 таких специалиста, их число постепенно растет.

    Мы уже писали на Хабре, как мы разбираем входящие запросы и оцениваем сроки разработки. Расскажем, как в этом участвуют архитекторы.



    Этапы работы


    • Анализ требований

    На старте проекта мы собираем функциональные, нефункциональные, системные и бизнес-требования.

    • Проектирование архитектуры

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

    • Внутренний контроль

    Дополнительная проверка выбранного решения 3-5 участниками архитектурного комитета. При необходимости – доработка решения с учетом рекомендаций.

    • Презентация заказчику

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

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

    • Архитектурный надзор при разработке

    На начальном этапе разработки каждого проекта архитектор помогает заложить каркас системы и курирует архитектуру.

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



    Несколько участников архитектурного комитета SimbirSoft

    Вывод


    С помощью архитектурного комитета мы проработали уже более сотни проектов. По нашим наблюдениям, такой подход к архитектуре обеспечивает IT-компании и заказчику несколько важных преимуществ:

    • Сокращение срока выпуска продукта на рынок MVP (Minimum Viable Product)
    • Сокращение времени на выпуск новых фич (time-to-market).
    • Независимость заказчика: возможность выбирать любого подрядчика или вести разработку самостоятельно.
    • Минимизация количества сбоев в продукте.
    • Возможность найти оптимальное решение для каждой проблемы и гибкость при внедрении новой функциональности.

    Спасибо за внимание! Надеемся, что статья была вам полезна.
    SimbirSoft
    Лидер в разработке современных ИТ-решений на заказ

    Comments 10

      +4
      IMO много воды, мало конкретики и реально интересных вещей. Не заметил упоминания темы vendor lock-in, выбора корректной базы данных исходя из load pattern приложения и многих других вещей. Приведённый пример вообще выглядит как маркетинг для клиента.
      Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.

      1. Сомневаюсь, что микросервисы с отдельными базами могут обеспечить доступность всего приложения. Его частей — безусловно.
      2. За счёт чего в 5 раз меньше сбоев? Какого рода сбои? Почему отдельные базы сервисы и базы их решили?
      3. Про экспертизу на сторона клиента читается как «когда мы меняли архитектуру, мы не нагородили там такого треша, что клиент не смог бы потом поддерживать». Ну, круто.

      Хотелось бы более комплексных историй. Например, возьмём, сравнение разных message queues для конкретного юз-кейса. Поэтапно: вот была такая задача, мы решили что нужна очередь, так мы выбирали. Смотрели, скажем, на скорость, на то, есть ли у клиента опыт с этой конкретной технологией, на интеграцию технологии с нашим стеком, etc.

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

        Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))
        0
        Как суммаризация вполне интересно, только в MVP — разве внутренний контроль тоже только из 3-5 человек?
          0
          Стоит уточнить, что любой MVP делают с расчетом на полноценный продукт, да и внутренний контроль при проработке архитектуры нужен всегда: как ни крути, один человек не может знать все технологии, а вот группа специалистов – может.

          Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.

          Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
          0
          Мне кажется архитектура — не совсем системно правильная конструкция. Т.е. все, что описано выше — опирается только на good will людей. Но у людей нет мотиваторов делать правильно/неправильно. Архитектура не несет риск от принятых ими решений. И то выражается в том, что крайне сложно архитектурным подразделениям поставить хоть какие-то цели/kpi.
            0
            Ключевое преимущество нашей компании в том, что мы имеем дело с очень разными предметными областями, подходами и даже областями. Таким образом, нам удается поддерживать интерес, а значит и мотивацию архитекторов на высоком уровне. Каждая задача на проработку архитектуры уникальна, это вызов для архитектора.

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

            Безусловно, иногда встречаются моменты, когда команда сталкивается со сложностями и приходится корректировать архитектуру «на ходу», но даже в таком случае архитектор, прикрепленный к проекту, участвует в выборе решения и несет за это ответственность.
              0
              >> мы имеем дело с очень разными предметными областями, подходами и даже областями
              И?

              >> архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их
              А зачем это надо, если есть команда, которая отвечает за end-to-end продукт? Это дело команды искать правильный trade offs. И у этой команды есть все мотиваторы, так как именно им дальше поддерживать разрабатываемое решение.
                0
                Не совсем понятен ваш первый вопрос, мы постарались дать максимально подробный ответ)

                Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
            0
            Не хабровская статья, ну видно же что писалось для продажи клиенту своей экспертизы. Молодцы, подход с выделением отдельного комитета при таком-то опыте отличная и вполне логичная мера. Но в статье хотелось бы больше подробностей технических, а не рекламных, про процессы, взаимодействие, подходы и решения.
              0
              Спасибо! Мы уже опубликовали одну статью по ДБО с техническими деталями, насколько позволило NDA, с ней можно ознакомиться здесь: habr.com/ru/company/simbirsoft/blog/512310. В будущем мы будем продолжать публиковать статьи, где постараемся раскрыть кейсы, с которыми сталкиваемся

            Only users with full accounts can post comments. Log in, please.