Привет, друзья! На связи Даниил, я руководитель направления ИТ-архитектуры и хочу поделиться с вами опытом в выборе архитектуры для продуктовой реализации. Сразу скажу, что я приверженец кайдзен — поэтому рассказывать буду с точки зрения философии непрерывных улучшений и совершенствования бизнес-процессов.
Эта статья — часть серии, где я буду делиться практическими подходами к построению современных продуктовых решений: от выбора архитектуры и технологий до логирования в условиях ограничений. Но сейчас поговорим именно о выборе архитектуры.
я не описываю в статье процесс создания продукта или публикации в Росреестре, а рассказываю о выборе технологий, архитектуры разработки и развития продукта на основе личного опыта.
Я часто замечаю одни и те же ошибки в различных решениях — как по работе, так и в жизни. Зачастую многие думают, что сейчас сделают прототип, а потом допилят, но не учитывают, как будет развиваться решение и что лучше взять за основу. Поэтому эта статья будет полезна не только архитекторам при выборе основы, но и разработчикам для понимания более важных и ценных задач. А также проектным менеджерам — чтобы создать верную стратегию развития.
Разберём на примере — к вам приходит задача:
Перенести часть системы из альфа продукта в новую экосистему бета с сохранением функциональности и новых потребностей запроса пользователей по шаблону через конструктор запросов в UI.
Для работы по кайдзен я использую элементы подхода TOGAF, в частности — подход к описанию бизнес-способностей (business capabilities). Он помогает понять, какие компетенции и процессы формируют ценность компании и где лежат точки роста. На основе этого можно развивать систему поэтапно и детализировать архитектуру каждого слоя.
Но изучение всего подхода может занять больше времени, чем поиск истины в философии дзена или путешествие по древним храмам Китая в поисках себя. Поэтому вместо этого мы просто обращаемся к концепции Agile и ее этапу стратегического планирования архитектуры системы. Почему? Потому что основные идеи Agile:
люди и общение важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
готовность к изменениям важнее следования плану.
сотрудничество с заказчиком важнее согласований условий контракта
На этом и сосредоточимся: люди и общение нужны для создания работающего продукта, который может меняться.
Я не настаиваю на использовании этих методик — делюсь информацией исключительно для понимания, почему я выбрал именно это решение, и для возможности самостоятельного изучения процесса.
Ключевые преимущества стратегической архитектуры для Agile-предприятия
Понимание контекста организации, чтобы определять стратегические темы и направления.
Выявление потоков ценности и требований.
Подтверждение принципов, определяющих границы продукта или услуги.
Определение организационных возможностей: навыков, инструментов, управления.
Формирование целостного представления об архитектурном ландшафте для дорожных карт планирования миграции, если есть слабосвязанные компоненты. Это позволяет реализовать взаимодействие между командами и интеграцию.
Создание информационной базы, чтобы планировать следующие этапы. Это облегчает детализацию задач и построение планов развития.
В свою очередь, стратегическая архитектура создает основу для архитектурных приложений более низкого уровня в архитектуре сегмента (в функциональной области, в которой мы проектировали). Если сконцентрироваться на пункте «выявление потоков ценности и требований» — ключевой шаг в подходе SAFe, который позволяет связать архитектуру с бизнес-результатами. В отличие от классического TOGAF, где акцент делается на формальную последовательность фаз и артефактов, как-раз набор готовых шаблонов в SAFe обеспечивает постоянную синхронизацию между бизнесом и командами. Это делает архитектуру не статичной схемой, а живой моделью, которая развивается вместе с продуктом.
Чтобы понимать достижение своих показателей, мы анализируем : карту бизнес способностей (business capabilities) компании и потоки ценностей (value streams). На основе этого формируется целевая архитектура. Это описание будущего состояния функциональной области, где определены взаимосвязи, требования и ожидаемые изменения. Именно она становится ориентиром для Agile-команд.
Чтобы оценивать достижение показателей и понимать, где развивать бизнес, мы начинаем с анализа бизнес-способностей — того, что компания умеет делать сегодня и какие процессы можно автоматизировать или улучшить. На основе этого строим целевую архитектуру — не просто перечень решений, а взаимосвязанную модель бизнес-способностей и ИТ-систем, показывающую, как существующие процессы будут меняться и в какой целевой вид должны перейти.
Компоненты архитектуры предприятия
Основная часть Flow
Сбор требований. Многие его игнорируют, говорят: «Я же технарь». Но без понимания задачи и потребностей заказчика разработка рискует стать бессмысленной — это будет «путь самурая» (как мы знаем у самурая нет цели, а есть только путь — но это не то, что нам нужно).
Оформление требований. Собрать — половина дела, важно оформить их в виде нефункциональных требований (НФТ) и прописать ожидаемые уровни обслуживания (SLR). Нам это поможет на цифрах понимать критерии и ограничения, а не опираться на субъективное мнение.
Факторная модель вариантов решения и «верхнеуровневая» оценка. Это поможет структурировать информацию о возможных решениях, сравнить альтернативы и принять обоснованное решение с учётом критериев и ограничений. Так мы снизим риски — выявим потенциальные проблемы заранее и минимизируем их.
Выбор варианта в зависимости от стратегии. Это покажет, какое решение будет наиболее эффективным для наших целей, поможет сфокусироваться на приоритетных задачах и оптимально использовать ресурсы.
Декомпозиция. Когда мы уже выбрали варианты, нам нужно сделать декомпозицию и определить зависимости в задачах, чтобы планировать следующие шаги и управлять реализацией проекта.
Только после этого можно приступить к разработке, чтобы не делать работу ради работы, а создать ценный для бизнеса продукт. Знаю, что многие привыкли делать по-старому, но технологии развиваются. Поэтому советую подходить к этому упражнению каждый раз, смотреть на решения свежим взглядом и собирать все НФТ как впервые.
Переходим к процессу
1. Мы всё собрали — и что дальше?
На этом этапе важно не просто зафиксировать требования, но и сохранить работоспособность существующей системы, если речь идёт о переносе функциональности. Поэтому мы моделируем текущее состояние (As-Is) с описанием бизнес-процессов и потоков данных, а затем проектируем целевое (To-Be) — с новой архитектурой и связями. Это помогает не потерять функции, данные и зависимости при миграции, а также задать основу для будущего развития.
Вспомним нашу задачу (тут ссылка на прокрутку). Допустим, по ней мы собрали такие требования:
все текущие отчёты должны остаться;
скорость должна стать быстрее, а то долго ждать, когда отчёт выгрузится;
хотим оптимизировать команду, а то слишком много команд делают одно и тоже;
хотим быстро получать новый отчёт и не ждать разработки по полгода;
возможно, будем эту функциональность использовать и в других системах.
Под такие обширные требования можно предложить практически что угодно. Нам нужно больше конкретики — поэтому мы добавили нефункциональные требования (НФТ) и прописали ожидаемые уровни обслуживания (SLR).
2. Как мы добавили конкретики и прозрачности?
Используем на основании готовых отчётов рассчитанные меры в виде различных агрегатных функций: сумма, среднее, максимальное и 3х шаблона. В системе должна быть возможность загрузить шаблон в формате XSLS и указать, какие меры и куда заполнять.
Скорость открытия страницы 3s устроит бизнес. Но если будет более 5s — уже будет некомфортно, т. е. SLR отклика системы 3–5s при условии максимальной нагрузки.
В системе будет одновременно 100 работающих сотрудников, и она должна работать стабильно.
Стек технологий должен использоваться аналогичный текущему решению.
В системе должен быть конструктор запросов для администратора.
Запланированные постепенные тиражирования и система должна иметь возможность масштабирования и иметь слабые связи, т.к. должна быть отдельным независимым сервисом.
Выжимаем из этого получившиеся технические требования и возможности самой компании:
только технологии, разрешенные в компании, т.к. не готовы ждать апробации новых решений;
первоисточник данных должен иметь возможность также масштабироваться, т.к. объём данных планируется увеличивать в разы.
1. Что с этим делать и как найти варианты?
Архитектура программного обеспечения — это всегда поиск компромиссов. Опытные архитекторы Нил Форд, Марк Ричардс, Прамод Садаладж и Жамак Дехгани как-то обсуждали стратегии выбора подходящей архитектуры для разных случаев на примере вымышленной группы специалистов Sysops Squad. Подробно про это можно прочитать в книге «Современный подход к программной архитектуре: сложные компромиссы», а здесь я дам лишь малую часть процесса, исходя из своего опыта и задачи.
Из требований мы выделили несколько частей реализации для себя:
часть, отвечающая за источник данных — так как есть требования о том, что он может поменяться и на него вырастет нагрузка;
часть, отвечающая за препроцессинг и расчёт мер, с учётом неохотной скорости реализации и ожиданий пользователей;
часть самого конструктора, которая должна подключаться к источнику данных и встраиваться как независимый сервис в новое приложение;
внутренние сервисы, которые должны предоставить возможность генерации отчётов на основе запросов из конструктора.
Мы собрали все требования в таблицу, немного их декомпозировали на встрече с архитекторами, и у нас появились идеи реализации. Всю задачу разбили на 3х крупных блока:
интерфейс – далее не рассматривается
интеграция и взаимодействия с данными – далее рассматриваем выбор
работа с данными – далее нет описано в статье
Тут рассмотрим не все части, а только интеграция и взаимодействия с данными, т.к. это более важная часть, которая даёт требования к источнику данных и подключаемым интерфейсам.
Полдела сделано, и мы уже понимаем, какие варианты у нас есть. Выбираем по факторам, подсвеченным в таблице.
Для архитекторов существует множество инструментов, которые помогают учитывать нотации моделирования архитектуры и различные факторы при проектировании решений. Среди них можно выделить ArchiMate и ARIS — они дают возможность визуализировать и анализировать архитектуру системы, учитывая её сложность и взаимосвязь компонентов. Однако есть и более простые решения, такие как Draw.io или PlantUML. Они могут быть полезны для создания базовых диаграмм и схем, но их функциональность ограничена по сравнению с более продвинутыми инструментами.
Важно понимать, что выбор инструмента зависит не только от его возможностей, но и от основных принципов моделирования архитектуры. Необходимо учитывать специфику проекта, требования к системе и цели. Только тогда можно выбрать наиболее подходящий инструмент для проектирования.
Схема MVP приложения
Так мы с вами получаем несколько DRAF вариантов реализации с верхнеуровневой оценкой и сразу отвечаем на вопрос — как будет проходить интеграция, какие компоненты и где нужно размещать.
Конечно, тут нужна оценка задачи. К примеру, мы сразу можем понять, что третий из вариантов самый дорогой и бизнес к нему не готов. А некоторые варианты могут содержать технологии, несогласованные в компании — в нашем случае это варианты 4.1 и 5.
При выборе учитываются такие критерии, как стоимость владения, гибкость доработки, интеграция с текущими системами, безопасность и поддержка в долгосрочной перспективе. В нашем случае мы выбрали гибридное решение в виде собственной сборки на основании open-source компонентов, но при этом регулярно анализируем рынок, чтобы понимать, какие готовые решения могли бы закрыть будущие задачи быстрее и выгоднее. Обязательно всегда учитывайте в выборе факторов все решения, в данном примере выбор был только из тех которые вошли в бюджет.
4. Как выбрать вариант?
«Был бы бюджет, можно сделать всё! Но попробуйте то же самое без денег», — скажут вам. Цена, качество и скорость — частый компромисс в архитектуре, да и в жизни.
Для объективного выбора я обычно использую подход Cynefin. Он особенно актуален для современных ИТ-руководителей, которым приходится сталкиваться с запутанностью, порой даже парадоксальностью, хаосом и неопределенностью, что не снимает с них необходимость принимать управленческие решения. Каждый может доработать подход под себя.
Модель Cynefin
Процесс очень простой и интересный. Нужно разбить доску на четыре квадрата по следующему принципу:
всё, что выше — очень важно для бизнеса;
всё, что ниже — не очень важно;
слева — то, что дёшево;
справа — то, что дорого.
Разложите все варианты по этим квадратам (можно использовать стикеры разных цветов). В правом верхнем углу окажутся варианты, которые важны для бизнеса, но требуют больших затрат. В левом верхнем углу — важные для бизнеса варианты, которые можно получить за небольшой бюджет.
В нашем случае мы будем делать все, что написано на зеленых стикерах. Все жёлтые не критичны, а только занимают время, поэтому можно отложить их на второй этап. Все синие — как раз предмет обсуждения и поиска вариантов, как можно сделать дешевле. Ну и все красные — это менее значимые функциональности для продукта, которые мы можем развивать после MVP.
И, как мы видим, второй вариант проигрывает из-за отсутствия компетенций и понимания технологии — мы не сможем развивать далее все красные стикеры, а синие передвинуть влево. А варианты 1 и 4 на удивления близки к реализации.
Советую как классический метод Cynefin, так и его вариации.
Расширение количества доменов. В классической модели Cynefin есть четыре домена: «известное» (Simple), «запутанное» (Complicated), «сложное» (Complex) и «хаос» (Chaos). В некоторых вариациях добавляют пятый домен — «порядок» (Order) или рассматривают другие возможные состояния систем.
Интеграция с другими методологиями. Метод Cynefin можно комбинировать с такими подходами и инструментами, как Agile, Lean, Design Thinking и другими, чтобы создать более комплексную и эффективную систему управления.
Разработка новых инструментов и техник. На основе метода Cynefin можно создавать новые инструменты и техники для анализа и решения сложных проблем, например, модифицированные диаграммы, шаблоны и т. д.
Адаптация под специфические задачи. В зависимости от конкретной задачи или проекта можно адаптировать метод Cynefin, изменяя его параметры, критерии и подходы к анализу и решению проблем.
5. У нас осталось два варианта. Как выбрать оптимальный и чем можно пожертвовать?
Не существует универсальных решений, которые подошли бы для любой ситуации. Выбор всегда зависит от конкретных условий и времени.
Для принятия решения я советую следующую методику: разделить факторы на несколько критериев. Это поможет систематизировать информацию и упростить процесс выбора. Критерии могут быть такими:
работает и без — факторы, которые уже функционируют и не требуют дополнительных изменений или вложений;
сможем добавить — факторы, которые можно внедрить или улучшить в будущем;
не сможем развивать — факторы, развитие которых невозможно или нецелесообразно по каким-либо причинам;
нужно для старта — факторы, необходимые для начала работы или реализации проекта.
В оценке можно использовать следующие методы:
экспертная оценка — привлечение экспертов для получения профессионального мнения и анализа ситуации;
мозговой штурм — коллективное обсуждение и генерация идей;
теория игр — анализ возможных стратегий и последствий;
метод декомпозиции — разделение сложной проблемы на более простые составляющие и детальный анализ.
В нашем случае основное отличие двух оставшихся вариантов только в движке, который будет выступать за препроцессинг и подготовку данных.
| Вариант 1 | Вариант 4 |
Экспертная оценка | Считаем, что на текущую схему базу данных можно настроить без доработок или переработок.
| Считаем, что на текущую схему базу данных можно настроить без доработок или переработок.
|
Мозговой штурм | Решили, что можно масштабировать добавлением новых нод в кластере.
| Решили, что однозначно можно будет масштабировать.
|
Теория игр | Стратегически использование языка и технологии даёт больше экспертизы и возможности доработок. | Стратегически компания использует, но нет компетенций у конкретной команды. |
Декомпозиция | Можно реализовывать поэтапно — нет зависимостей и пользователь сможет получать реализацию порциями и раньше.
| Не смогли получить порционные реализации меньшего размера относительно варианта 1. |
Вот таким нехитрым способом у нас остался только вариант 1!
6. Декомпозируем и оцениваем?
Наконец мы выбрали вариант для реализации, и что же делать дальше?
Морти, конечно, молодец, но нам нужна не импровизация, а системность. Мы определяем стратегическую архитектуру, а затем формируем спецификацию для команд разработки. Это документ, описывающий, что и как должно быть реализовано – своего рода техническое задание (ТРЗ), где фиксируются функциональные и нефункциональные требования, оценка трудозатрат и приоритеты задач. Такой подход помогает командам реалистично планировать и фокусироваться на результате в рамках архитектурных принципов.
Распределение времени в идеальном мире:
4 часа (50%) — программирование и написание кода;
30 минут (6.25%) — перерывы;
1 час (12.5%) — код-ревью и обмен знаниями;
1 час (12.5%) — координация и планирование;
1,5 часа (18.75%) — обучение и саморазвитие.
Но распределение времени сотрудника не так линейно. Поэтому не забываем, что даже чистые 4 часа у нас не получится заложить 😉
Можно долго рассуждать о переключении контекста и концентрации на одной задаче. Но чтобы эффективно организовать работу, достаточно просто использовать дорожную карту. На ней следует спланировать задачи, обозначить их зависимости и расставить приоритеты в соответствии с их значимостью.
Также важно определить результат в каждом случае. Это поможет команде сосредоточиться на наиболее важных задачах и чётко понимать, к чему нужно стремиться.
Так мы с вами выберем нужный вариант и поймем, к какому сроку какую часть задачи мы сможем показать бизнесу.
Итоги
При создании продуктового решения для меня важно учитывать принципы философии кайдзен, которая предполагает постоянное совершенствование бизнес-процессов.
В выборе архитектуры и технологий для разработки продукта учитывайте стратегические цели и возможности организации.
Подход TOGAF и концепция Agile могут быть полезны для проектирования и развития системы поэтапно, с возможностью адаптации к изменениям.
Сбор и анализ требований, включая нефункциональные требования и ожидаемые уровни обслуживания — это ключевые шаги для успешного проектирования.
Структурировать информацию и выбрать подходящий вариант помогут факторная модель вариантов решения и верхнеуровневая оценка.
Выбирайте вариант решения на основе стратегии развития и учитывайте приоритеты и ресурсы организации.
Декомпозиция и определение зависимостей в задачах помогают эффективно планировать и управлять реализацией проекта.
Инструменты для моделирования архитектуры, такие как ArchiMate и ARIS, могут помочь визуализировать и анализировать архитектуру системы.
Выбор инструмента для моделирования зависит от специфики проекта, требований к системе и целей.
Принять обоснованное решение помогут такие методы, как экспертная оценка, мозговой штурм, теория игр и метод декомпозиции.
