Мы последовательно внедряем архитектурный подход в давно работающей компании, буквально на ходу — это напоминает починку работающего двигателя. Здесь неизбежны некоторые особенности, о которых стоит поговорить. Спойлер: процесс идет, мы набили шишки и выработали подходы, которые хочется показать и обсудить с коллегами. Этот пост — первый из серии статей, где я изложу свое видение работы архитектора и пошагово расскажу, как мы внедряли и практикуем архитектурный подход. Меня зовут Даниил Кирилин, директор IT-архитектуры в Hoff Tech. Когда меня спрашивают о работе, я провожу аналогию между архитектурой и строительством. Строительный проект — это взаимосвязанная документация, которая дает представление о размещении, физических параметрах и свойствах объектов. Так же и IT архитектура — это технологическая и документальная организация системы, с описанием элементов, их взаимосвязей и принципов развития.  Сложно представить строительство без проекта. И без IT-архитектуры, похоже, уже не обойтись — думаю, нет крупных компаний, где технологии внедряются бессистемно. И Hoff Tech не исключение — за витриной гипермаркета Hoff скрывается сложный IT-ландшафт, который нужно планомерно упорядочивать, обслуживать и развивать. И это задача архитекторов. Существует базовая классификация IT-архитекторов, но она постоянно обрастает новыми узкопрофильными специализациями. Границы между ними размыты, не говоря уже о том, что функциональные обязанности архитекторов заметно различаются от компании к компании. Поэтому очень важно договориться об определении и обозначить зону ответственности. Для удобства я разделяю архитекторов на технических и бизнесовых. Технари отвечают за производство ИТ решений, а бизнесовые — про стратегию, процессы и все, что с этим связано. Технический архитектор по определению — специалист, который отвечает за проектирование IT-систем компании и формирует требования к ним: как они взаимосвязаны, из чего состоят и как будут реализованы.  С течением времени, как показывает практика, технические специалисты, разработчики зачастую все больше охватывают бизнес и руководство процессами, а вот со стороны бизнес-архитекторов погружение в техническую сторону — редкость. При этом архитекторам, так или иначе, приходится работать с бизнесом, ведь именно он и есть заказчик архитектуры. Зачастую, задача архитектора — внедриться в уже идущие процессы, например, когда в компании есть департамент бизнес-анализа, который общается с заказчиками, продумывает бизнес-процесс под задачу и дальше идет с этим к разработчикам.  Проблема в том, что аналитики мало знают техническую часть вопроса, а разработчики не всегда понимают, чего от них хотят по бизнес-процессам и в перспективе. И здесь архитекторы как раз выступают связующим звеном, консультантами с широким кругозором и компетенциями, потому что работают на стыке нескольких сфер в роли «координаторов» или «переводчиков».  Абстрактно работа IT-архитектора выглядит так: Впрочем, это теория, а на практике все гораздо сложнее и интереснее. Проектирование начинается со сбора и анализа требований. Это тот момент, когда мы общаемся с бизнес-аналитиками (для нас они являются входной точкой) и собираем набор артефактов: функциональные требования, нефункциональные требования, описание бизнес-процессов и, если задействован графический интерфейс, то его схематичное представление и т. п. В структуре Hoff Tech уже был департамент бизнес-анализа, так что оптимальным местом для внедрения инфраструктуры было пространство между ним и разработкой. Мы выстроили стратегию по описанию и документированию архитектуры исходя из зон ответственности и движения по слоям в развитии архитектуры: Собрав требования, в качестве основной задачи архитекторов в Hoff Tech мы выделили информационные системы и их интеграции с детализацией. Под детализацией мы понимаем все ключевые объекты, которые задействованы, например, API и базы данных, и тщательное картирование их взаимодействий.  Иногда нас спрашивают, зачем мы подробно описываем все джейсоны на вход и выход, почему это происходит на этапе архитектуры, а не в процессе разработки? Вообще, если говорить об архитектуре, как таковой, типах моделирования, существующих методологиях и нотациях, то ничего из этого не используется в чистом и неизменном виде. С кем бы из коллег я ни обсуждал этот вопрос — все говорят, что методологии кастомизируются и подгоняются под конкретного клиента. То есть каждый сам определяет для себя глубину погружения и остановки по ходу работы. Еще в архитектуре есть паттерны без четкого руководства и определения. Паттерн дает принципы, которые еще нужно додумать с точки зрения реализации. Вот как иногда бывает в некоторых компаниях: архитекторы рисуют «квадратики» — здесь мы сделаем сервис 1 и сервис 2 — и сразу отдают на реализацию. А уже в разработке выясняется, что эти сервисы нельзя соединить, пока мы не спустимся в детали: какое поле взять, где оно будет, где джоин идет, где агрегирование данных и т. д.  То есть, опять же, как и в строительстве или при ремонте, нужен проект с учетом деталей и нюансов реализации, а не просто эскизные зарисовки и желание сделать хорошо. Одними «квадратиками» здесь не обойтись, иначе в итоге получается примерно такое:   Поэтому описывая все входные и выходные связи, прежде чем идти в разработку, мы отслеживаем перетекание из одной системы в другую и гарантируем целесообразность и возможность реализации. Также, в перспективе, подход позволяет контролировать распространенность и зависимость мастер-данных до конкретных полей. Выбор подхода к проектированию зависит от специфики бизнеса, организации процессов и выбора самой компании. Например, в банках много обязательной документации, от которой никуда не деться. И архитектуру надо расписать по полной, потом пройти десять кругов согласований всех артефактов и только тогда отдавать в разработку. А вот для маркетплейсов создание артефактов и множество описаний излишни. Там путь от задумки до реализации в принципе может быть гораздо короче. Это как две крайности: где давят регуляторы, там архитекторы погружены в документацию, и компания страдает от длинного time to market. Там, где много свободы — возникает +100500 работающих систем без понимания, как они связаны. Время на архитектуру не тратится, зато возникает хаос с точки зрения инвентаризации систем. В Hoff Tech мы выбрали компромиссный вариант — не зацикливаемся на документации, но основные описания должны быть обязательно. Есть такой метод графической записи — С4 model, мы внедрили его урезанный, адаптированный под нас, вариант, за основу взяв только принципы и первые три уровня:  С1, как правило, применяется при поступлении идеи, первом упоминании задачи для того, чтобы определить, какие системы и процессы будут затронуты изменениями. Бизнес-анализ может оперировать и опираться на этот уровень в своих требованиях, особенно если речь идет о существующей функциональности. Верхнеуровневая архитектура располагается на уровне С2, а детализированная — С3, с частичным использованием С4, в рамках описания входящих и исходящих точек. Ну а полноценно четвертый уровень отдан в ведение разработчиков. Чтобы упорядочить разработку и добиться стандартизации, мы разработали оптимальные, шаблонные подходы для ряда случаев. Условно, для синхронизации двух сервисов выбран один способ, и другие мы не рассматриваем. И взаимодействия API тоже делаются только по одному заранее определенному принципу (но это тема для отдельного разговора).  При выборе мы руководствуемся старыми-добрыми критериями — быстро, дешево, качественно. Учитываем, что ресурсы у нас не безграничны и существуют рамки, которых надо придерживаться. Да, мы сознательно лишаем себя свободы выбора, но зато экономим время и ресурсы. Оценка таких решений проходит через специальную процедуру — «архитектурный комитет». Это помогает находить оптимальный вариант реализации на пересечении всех интересов. Когда приходит задача, ее сначала берет в работу архитектор: накидывает верхнеуровневую концепцию, «квадратики» + поля с их взаимосвязями, и проектирует то, что в итоге должно получиться. Ключевое — проектирует несколько вариантов реализации, в пределах треугольника быстро-дешево-качественно, например: 1. Самый простой и быстрый вариант — монолит. Без паттернов и микросервисов и делается за 2 часа, но можно потерять в отказоустойчивости и увеличить задержки.  2. Идеальный и канонический способ, но здесь надо сделать 3 сервиса и поднять 2 базы данных. И это месяц разработки с перспективой дивидендов когда-то в будущем. 3. Компромиссный вариант, где мы немного идем в сервисы, что-то выносим из монолита, чтобы сделать лучше и ничего не испортить, и все это за 2 недели. В комиссию входят: IT-директор, руководители разработки и бизнес-анализа, представители заказчика и ключевые участники. Мы коллективно принимаем решение и определяем вариант, который будет стандартом. Далее уходим в детализацию этого варианта.   Мы одновременно запустили инвентаризацию информационных систем и начали разработку внутреннего «Соглашения о моделировании». Это документ, в котором мы договариваемся о том, как будет выглядеть описание архитектуры. Я против излишнего углубления в нотации, как таковые, и слепого следования им. Лучше мы потом в «Соглашении о моделировании» что-то поправим, чем будем тратить время на излишние описания. Продуктивнее заранее определить и ограничить зону детализации описаний, опираясь на Соглашение, и прямо это зафиксировать, чтобы не описывать лишнего. Еще один нюанс связан с тем, что мы работаем в рамках одной большой модели, в рамках единого репозитория, в который занесены все IT-системы. Там могут случаться коллизии по объектам, особенно если эти объекты описывают одну сущность, но с разных сторон и в разных контекстах. Чтобы разрешать эти проблемы, мы добавили в Соглашение пункт, который регламентирует наименование объектов. Чтобы проще и быстрее менять и дорабатывать инфраструктуру, нужна не просто статичная схема, а интерактивное представление, которое мы сможем менять без лишних затрат и усилий. Для описания AS IS архитектуры часто используют OpenTracing. Это удобный инструмент — добавил в код, и картина визуализировалась. Однако, мы решили не фокусироваться на нем, так как: для внедрения требуются значительные ресурсы по разработке; нужны значительные вычислительные ресурсы, чтобы обрабатывать такой поток данных; OpenTracing можно внедрить не во все готовые решения (конечно нет ничего невозможного, но потратиться придется изрядно); и ключевое — в такой визуализации невозможно проводить проектирование, и, de facto, нам все равно потребуются дополнительные схемы. Так что мы взяли опенсорсный ArchiMate и крупными мазками накидали то, что узнали о системах и взаимосвязях, а затем постепенно углубляли свое представление, переходя с одного уровня С4 model на другой. В результате мы получили карту всего IT-ландшафта со связями и артефактами. Благодаря этому решению, всегда можно посмотреть архитектурную схему и быстро понять, какие системы отвечают, например, за заказы. Наша архитектура включает в себя несколько схем разного уровня детализации: одна показывает существующие взаимосвязи с другими сервисами, другая — эти связи на уровне точек входа. Третья позволяет проследить, с какими данными работают эти точки. Чтобы внедрить детализацию в уже давно работающей компании с обширным легаси мы действуем в рамках определенного цикла: обозначаем приоритетные направления и отрабатываем по ним детализации; проверяем нет ли новых задач; если есть, то занимаемся ими и детализацией систем с которыми пересекаемся; если нет, то обозначаем следующий набор приоритетных направлений. Чтобы наше представление об архитектуре не устаревало, описав какую-то систему, мы тут же включаемся в процесс ее разработки и поддержки. Так что в дальнейшем любое изменение проводится только через архитектора. Например, если разработчик хочет добавить еще одно поле в базу данных или в контракты Api, то в рамках задачи всегда есть пункт «согласование с архитектором». О том, как мы отслеживаем и контролируем актуальность описания. Для этого в рабочий процесс включен такой этап, как «архитектурная приемка». Он следует после разработки и тестирования, но до выхода на прод.  Мы встречаемся с разработкой и сравниваем заявленную ранее детализацию с фактической реализацией. Если различия несущественные, то мы просто вносим их в документацию, а кардинальные изменения, не согласующиеся архитектурой, оформляются как технический долг и возвращаются на разработку, не доходя до продакшена. Мы также развернули web-представление, для «популяризации» архитектурных схем, подобно тому, как это предложено в одном из постов об ArchiMate, и уделили много внимания автоматизации Archi (но это тема для отдельного разговора). Пока еще мы не достигли полного покрытия, инвентаризация некоторых систем продолжается, но уже можно сказать, что ничего не меняется и не происходит без нашего ведома. Глобально описанные процессы, процентов на восемьдесят, подходят для решения любых проектных и продуктовых задач, вне зависимости от того, где вы работаете. Но все равно может показаться, что внедрение архитектурного подхода в большой компании слишком сложно и приносит мало пользы, ведь оно не влияет на бизнес-процессы напрямую. Однако, вклад в архитектуру окупается со временем, сокращая сроки и затраты на разработку и реализацию. Теперь, когда описание, детализация и взаимосвязи систем задокументированы, можно сравнить работу до внедрения архитектурного подхода в Hoff и после. Разница очевидна: Благодаря шаблонизации и стандартизации мы значительно уменьшили time to market. Когда приходит задача, мы оперативно ее раскладываем и со всеми артефактами отдаем в разработку. И у бизнеса, и у разработчиков реже возникают дополнительные вопросы. С помощью «архитектурного комитета» мы сократили общее время коммуникаций IT-подразделений: сразу делаем техническую оценку и прикидываем варианты реализации. Есть задел для увеличения производительности, стабильности и гибкости сервисов, а также на ведение техрадара.  Стало гораздо удобнее отдавать задачи на аутсорс, потому от архитекторов исходит практически полное техническое задание с готовыми спецификациями — подрядчики читают проект и сразу включаются в работу. Им не нужно самостоятельно собирать и согласовывать требования, и это сильно облегчает и ускоряет разработку. Думаю, теперь вы понимаете, почему в наших планах и дальше стандартизировать и автоматизировать подходы к проектированию. Но об этом я подробно расскажу уже в другом посте — отдельная тема и по ней слишком много материала.  Директор ИТ архитектуры