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

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

Архитектуру в 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 тоже делаются только по одному заранее определенному принципу (но это тема для отдельного разговора). 

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

Оценка таких решений проходит через специальную процедуру — «архитектурный комитет». Это помогает находить оптимальный вариант реализации на пересечении всех интересов.

Внутреннее Соглашение

Мы одновременно запустили инвентаризацию информационных систем и начали разработку внутреннего «Соглашения о моделировании». Это документ, в котором мы договариваемся о том, как будет выглядеть описание архитектуры.

Я против излишнего углубления в нотации, как таковые, и слепого следования им. Лучше мы потом в «Соглашении о моделировании» что-то поправим, чем будем тратить время на излишние описания. Продуктивнее заранее определить и ограничить зону детализации описаний, опираясь на Соглашение, и прямо это зафиксировать, чтобы не описывать лишнего.

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

Архитектурные схемы

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

Для описания AS IS архитектуры часто используют OpenTracing. Это удобный инструмент — добавил в код, и картина визуализировалась. Однако, мы решили не фокусироваться на нем, так как:

• для внедрения требуются значительные ресурсы по разработке;

• нужны значительные вычислительные ресурсы, чтобы обрабатывать такой поток данных;

• OpenTracing можно внедрить не во все готовые решения (конечно нет ничего невозможного, но потратиться придется изрядно);

• и ключевое — в такой визуализации невозможно проводить проектирование, и, de facto, нам все равно потребуются дополнительные схемы.

Так что мы взяли опенсорсный ArchiMate и крупными мазками накидали то, что узнали о системах и взаимосвязях, а затем постепенно углубляли свое представление, переходя с одного уровня С4 model на другой.

В результате мы получили карту всего IT-ландшафта со связями и артефактами.

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

Чтобы внедрить детализацию в уже давно работающей компании с обширным легаси мы действуем в рамках определенного цикла:

• обозначаем приоритетные направления и отрабатываем по ним детализации;

• проверяем нет ли новых задач;

• если есть, то занимаемся ими и детализацией систем с которыми пересекаемся;

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

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

Мы также развернули web-представление, для «популяризации» архитектурных схем, подобно тому, как это предложено в одном из постов об ArchiMate, и уделили много внимания автоматизации Archi (но это тема для отдельного разговора).

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

Что по результатам и планам

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

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

• Благодаря шаблонизации и стандартизации мы значительно уменьшили time to market. Когда приходит задача, мы оперативно ее раскладываем и со всеми артефактами отдаем в разработку. И у бизнеса, и у разработчиков реже возникают дополнительные вопросы.

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

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

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