В предновогоднем тексте я заметил, что современный учебный курс по архитектуре решений не может обойтись без хорошего примера. И даже предложил в качестве такого примера известную архитектурную кату Отряд сисопов (Sysop Squad). Но не удосужился перечислить обязательные или крайне желательные характеристики такого примера. Сегодня я постараюсь исправить этот пробел и сформулировать список таких характеристик. Возможно, он будет полезен не только мне и будущему новому курсу, но и пригодится кому-нибудь при подборе задач для собеседования архитектора решений или как набор критериев при подборе других архитектурных кат именно для тренировки навыков Solution Architecture. Итак, приступим
- Унаследованные строительные блоки. Архитектура решений, по крайней мере в сравнении с другими видами архитектур, в наибольшей степени ориентирована на повторное использование систем, технологий, команд разработки, процессов и прочих активов. В большинстве случаев мы готовим решение из ингредиентов заказчика. Это как каша из топора: щепоточка данных из имеющихся систем, пучок внедренных технологий, пара ложек стандартных процессов: управление подписками и выставление счетов клиентам, связка справочников: типов клиентов, продуктов, сегментов, кампаний, вода и котелок: инфраструктура развертывания и система мониторинга, сервисы аутентификации и протоколирования. Одним словом, новое решение процентов на 80 это готовые возможности или небольшие доработки унаследованных приложений. Подозреваю, что в значительной мере популярность solution architecture в корпорациях вызвана именно тем, что не предполагает разработку всего с нуля, а рачительно использует имеющиеся ИТ-активы. Пример должен быть непременно таким
- Проблема. Самое важное в работе архитектора не в том, чтоб предложить правильное решение, а в том, что обосновать его необходимость и целесообразность. Все наши компоненты, обеспечивающие их технологии, развивающиеся между ними сложные многошаговые взаимодействия; способы структурирования данных и декомпозиция функций по отдельным модулям или сервисам, одним словом, вся архитектурная конструкция должна служить некоторой важной цели. Если у нас нет проблемы, то у нас и не будет оправданий. Не определив преследуемую цель крайне сложно убедить кого-либо в необходимости выделения каких-то компонент, выстраивании правильных взаимодействий, обеспечении слабой связности и уж тем более таких неочевидных вещей, как инверсия зависимостей. Что бы мы не делали наше действие должно сопровождаться ответом на вопрос – зачем мы это делаем. В саге про отряд сисопов проблема четко обозначена (а в книжке про сложные компромиссы проиллюстрирована рассказом про важное совещание; но у нас вместо совещания будет зум 🙂
- Альтернативы и опции. Ну, конечно, у реальных проблем не бывает единственного очевидного и правильного решения (Это только в упомянутой книжке важных и признанных менторов все более-менее однозначно). Если мы посмотрим вариант победителей архитектурных состязаний O’Reilly весны 2021 то увидим великолепный прием. Ребята нарисовали сначала целевую архитектуру. Всю из себя такую правильную, распределенную и микросервисную. А потом добавили еще один раздел Transition Architecture, предварив его такими словами:
The solution proposed in the Target Architecture section is the final ambition that solves most of the problems and risks, but can require significant development efforts because of the database split required. Thus, we can divide the whole work into two phases
На самом деле, это не единственное возможное плато и не единственная транзитная архитектура. В рассматриваемом примере напрашивается несколько вариантов, даже если заморозить требования. А если немного походить в управление продуктами и порассуждать как синтегрировать нашу подписку в более широкие продуктовые линейки, то опций нарисуется множество.
- Разные группы заинтересованных лиц. А это уже веяние архитектуры предприятия. В примере они выделены не столь четко. Зато предложенные реализации не оставляют эту тему без внимания. Увидим мы в них и менеджеров, собирающих отчеты и сотрудников контакт-центра и маркетологов с опросами. А главное, что все эти персонажи хотят довольно разных вещей.
- Финальный пункт этого короткого перечисления я озаглавлю B2С продукт. Конечно, далеко не все решения представляют собой высоконагруженные сервисы для миллионов внешних клиентов. Есть крайне сложные и интересные B2B системы. Есть интересные внутрикорпоративные приложения. Есть много чего еще. Но, тем не менее, в последние несколько лет типовой пример задачки для архитектора — это решение(solution), предоставляющее многоканальный сервис, через веб-сайт или мобильное приложение, миллионам клиентов. Ну, вот жанр у нас такой: много клиентов, разные каналы, не слишком замороченные сценарии – типичный B2C сервис, прям как в банке, телекоме или e-commerce. Потому на нем и остановимся.
Возможно, я сформулировал далеко не все характеристики нормального примера для проработки архитектуры решения. Даже наверняка не все. Дополните меня в комментариях, предложите свои критерии. С удовольствием пообсуждаю. Ну а следующий текст постараюсь сделать о том, в каких формах воплотится архитектура решения. Что за артефакты предстоит создать архитектору.