Мы последовательно внедряем архитектурный подход в давно работающей компании, буквально на ходу — это напоминает починку работающего двигателя. Здесь неизбежны некоторые особенности, о которых стоит поговорить.
Спойлер: процесс идет, мы набили шишки и выработали подходы, которые хочется показать и обсудить с коллегами. Этот пост — первый из серии статей, где я изложу свое видение работы архитектора и пошагово расскажу, как мы внедряли и практикуем архитектурный подход.
Архитектуру в IT удобнее рассматривать на примере строительства
Меня зовут Даниил Кирилин, директор IT-архитектуры в Hoff Tech. Когда меня спрашивают о работе, я провожу аналогию между архитектурой и строительством.
Строительный проект — это взаимосвязанная документация, которая дает представление о размещении, физических параметрах и свойствах объектов. Так же и IT архитектура — это технологическая и документальная организация системы, с описанием элементов, их взаимосвязей и принципов развития.
Сложно представить строительство без проекта. И без IT-архитектуры, похоже, уже не обойтись — думаю, нет крупных компаний, где технологии внедряются бессистемно. И Hoff Tech не исключение — за витриной гипермаркета Hoff скрывается сложный IT-ландшафт, который нужно планомерно упорядочивать, обслуживать и развивать. И это задача архитекторов.
Архитекторов в IT определяет то, чем они занимаются
Существует базовая классификация 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-подразделений: сразу делаем техническую оценку и прикидываем варианты реализации. Есть задел для увеличения производительности, стабильности и гибкости сервисов, а также на ведение техрадара.
Стало гораздо удобнее отдавать задачи на аутсорс, потому от архитекторов исходит практически полное техническое задание с готовыми спецификациями — подрядчики читают проект и сразу включаются в работу. Им не нужно самостоятельно собирать и согласовывать требования, и это сильно облегчает и ускоряет разработку.
Думаю, теперь вы понимаете, почему в наших планах и дальше стандартизировать и автоматизировать подходы к проектированию. Но об этом я подробно расскажу уже в другом посте — отдельная тема и по ней слишком много материала.
