У нас было 400 различных интеграций, 250 дочерних организаций, а также целое море разноцветной документации в разных нотациях для 300 систем написанных на 1C, С#, PHP. Как построить корпоративную архитектуру?

Проблемы описания корпоративной архитектуры

Зачем нужен архитектор?

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

• Затем идет выбор технологий.

• После выбора технологий нужно обеспечить гибкость. Бизнес-требования и функциональные требования могут меняться, логика и правила – тоже, поэтому архитектура должна быть готова к этим изменениям.

• Еще одна задача архитектора – оптимизация затрат. Он должен определить, что работает неэффективно, и найти способ это исправить в рамках корпоративного ландшафта, определив, какие системы и интеграции стоит выключить или изменить.

С чего начать?

• Приходим в компанию, где 300 разных систем, множество интеграций, шин, соединений «точка-точка» – непонятно, за что браться. Возможный вариант – высадиться в команду и начать задавать вопросы конкретным людям. Но вскоре может возникнуть вопрос: «Кто вы и зачем пришли с этими расспросами? Если пройтись по всем командам, которых около 30–40, станет ясно, что это неэффективный подход: на одни разговоры уйдет месяца три.

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

• Можно встретиться с руководителями проектов и спросить про их боли. Этот вариант масштабнее и займет меньше времени – одну-две недели. Но у каждого руководителя своя боль: у одного одно, у другого другое. В итоге нельзя будет понять общую проблему корпоративной архитектуры. Люди рассказывают, что болит именно у них, но часто это не связано с общим корпоративным ландшафтом, взаимодействиями и интеграциями,

• Остается изучить документацию. На этом стоит остановиться подробнее. Посмотрим, из чего она обычно состоит и как устроена.

Это реальные обезличенные бизнес-процессы.

Есть подобие нотации C4. У нас есть система 1, система 2, система 3 – они взаимодействуют через корпоративную шину: одну, вторую, третью. Где-то используется MSSQL, где-то Rabbit. Потом система 4 на .NET подключается к MSSQL и интегрируется с системой 6, и снова отдает через корпоративную шину 1.

Это реальный процесс. Но что здесь понятно? Лично мне – ничего. Неясно, зачем они обмениваются данными, в рамках какого бизнес-процесса. А людям, которые собирались и обсуждали это несколько раз, все очевидно – они зафиксировали результат и положили документацию в Confluence или другое хранилище.

Теперь посмотрим на второй бизнес-процесс. Он не привязан к нотации: есть квадраты в Miro или другом холсте, указаны реальные, не обезличенные системы. Какие-то договоры куда-то отправляются, есть какие-то MDS, что-то создается, куда-то двигается. Есть протокол интеграции, но как все остальное рождается и движется – непонятно.

Люди, которые рисовали эту схему, все понимали и успешно запустили процесс. Но если вы приходите и пытаетесь разобраться, работает ли это оптимально и зачем вообще все устроено именно так, понять ничего невозможно. И даже те, кто проектировал, уже не могут объяснить. Ответ обычно один: «Мы все сделали, отстаньте, пожалуйста».

Третий бизнес-процесс я проектировал вместе с аналитиком. Аналитик рисовал схему: указаны системы, потоки, есть GET и даже список сущностей, из которых он состоит.

Вот здесь можно увидеть контрагентов, снова аббревиатуру из четырех букв и ИДП, списки реквизитов – это и 1С, и не 1С-системы. Процесс уже выглядит понятнее: на квадратах есть подписи, указано, что происходит и куда что выгружается. Общее представление складывается. Однако если эту схему показать кому-то со стороны, он вряд ли разберется. Скорее всего, придется созваниваться несколько раз и подробно обсуждать процесс.

На этих схемах показаны реальные процессы между пятью корпоративными системами – они действительно существуют. А теперь представим, что таких систем не пять, а триста. И написаны они на разных языках программирования, не только на 1С.

Когда архитектор работает в компании, где все на 1С, есть определенная прозрачность: Бухгалтерия, УХ, ERP – все взаимодействует, и можно разобраться хотя бы по коду или по понятным названиям. Но если системы разнородные и языки разные, становится гораздо сложнее.

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

В итоге получается картина: множество систем с разным статусом, которые как-то взаимодействуют между собой в рамках бизнес-процессов, но целостного понимания нет. Когда пытаешься ознакомиться с документацией, попадаешь в настоящий документационный ад. Документации много, она сделана в разных нотациях – BPMN, C4, Sequence и других. Эти нотации не плохие, просто каждая решает локальную задачу – например, описывает бизнес-процесс – но вписать его в общекорпоративную структуру потом крайне сложно.

Даже если схемы нарисованы идеально по всем правилам, они хранятся в разных местах: часть в Confluence, часть в xWiki, что-то в Яндекс- или Google-документах, потому что их сделали три года назад. Иногда кто-то кому-то скинул схему в Telegram в виде скриншота, и ее после этого там нужно найти.

И самое главное – часто все упирается не в систему или документацию, а в конкретного человека. Мы выяснили, что система дорабатывается, бизнес-процесс живой, и знаем, что занимался этим Ваня из отдела разработки. Приходим к нему за документацией, а он говорит: «Мне два дня осталось до увольнения, до свидания». Примерно так это обычно и происходит. Как действовать в такой ситуации?

Цели и задачи корпоративного архитектора

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

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

Нужно также выявить потенциальные проблемные точки в будущих процессах – тех, что еще не запущены. Эти точки нужно понять и предотвратить на этапе проектирования бизнес-процессов и архитектуры.

Кроме того, необходимо научить команды мыслить в единой парадигме. В IT каждый уверен, что его решение единственно верное, но важно выработать общий подход и синхронизировать мышление.

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

То есть необходимо выстроить процесс и систему управления системами.

Как это сделать? Нужно перейти к единому языку и общим правилам корпоративной архитектуры. В этом помогут:

• Процесс принятия решений – ADR и архитектурный комитет;

• Процесс и система проектирования и визуализации – Archi, TOGAF;

• Система фиксации взаимодействий – цифровой двойник, созданный на 1С;

• AI-агент, созданный на основании всех предыдущих пунктов, который сможет дать нам ответ на поставленный вопрос.

Архитектурные решения и ADR (Architecture Decision Records)

Зачем нужен ADR и как он работает?

ADR (Architecture Decision Records) – это документы, которые описывают принятые архитектурные решения в проекте или системе в области разработки программного обеспечения. То есть они фиксируют архитектурные договоренности и последствия для программной системы.

ADR важно рассматривать в контексте: разные контексты – разные условия и выводы. От контекста зависит все, включая само архитектурное решение.

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

Нет трассировки – до чего именно договорились и почему. Через три месяца уже никто не помнит деталей: «о чем-то договорились, но о чем именно – непонятно».

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

• Фиксируем контекст.

• Фиксируем варианты решений (не меньше двух). Нельзя утверждать, что одно решение единственно верное.

• Фиксируем плюсы и минусы каждого варианта решения.

• Выбираем решение исходя из плюсов/минусов контекста.

• Фиксируем дальнейшие шаги, риски и то, на что обратить внимание в дальнейшем процессе разработки.

Так мы получаем:

• Единую точку принятия и агрегации решений.

• Любое структурное изменение или интеграция не проходят без согласования техлидов, архитекторов и ключевых лиц (архитектурного комитета).

• Прозрачность и повторное использование решений. Часто бывает, что люди, не участвовавшие в обсуждении, предлагают все пересмотреть. В этом случае можно просто показать документ: в нем есть контекст, плюсы и минусы вариантов. Если есть комментарии – добавляйте их. Обычно после этого споры заканчиваются, потому что решение уже зафиксировано и обсуждать нечего.

• Сокращение «архитектурных споров» вне контекста: обсуждаем не мнения, а ADR.

Как фиксировать ADR, можно посмотреть на GitHub – https://github.com/KuzinRoman – там есть пример в формате Markdown с контекстом, вариантами решений, плюсами и минусами.

Методология TOGAF, ArchiMate и инструмент Archi

Теперь поговорим про ArchiMate и TOGAF– что это такое и зачем нужно.

• TOGAF – это методология и процесс управления корпоративной архитектурой. Она описывает, как выстраивать архитектуру и управлять ею.

• ArchiMate – это язык нотаций, чтобы эту архитектуру наглядно моделировать.

• Archi – это программное обеспечение, где создаются схемы: квадраты, стрелки и связи. Оно бесплатное и доступное для использования.

TOGAF задает «как работаем», ArchiMate – «как это красиво и точно изобразить». Процесс строится сверху вниз: от целей и требований бизнеса к сервисам и процессам, затем к приложениям, интеграциям, технологиям и, наконец, к серверам, на которых все работает. Таким образом, мы можем проследить, как конкретное бизнес-требование реализуется на уровне инфраструктуры.

Пример:

Есть исполнительный директор и директор по персоналу. У них общая цель – повысить лояльность сотрудников, перейти на безбумажный документооборот и увеличить экономическую эффективность. Есть проблема: оформление командировки занимает до трех дней и требует личного присутствия сотрудника в офисе. Это бизнес-требование, с которого все начинается.

Мы понимаем, что нужно ускорить процесс оформления командировок, повысить уровень автоматизации и сократить количество персонала. Но это еще не цель – у нее нет конкретных метрик.

Если человек будет оформлять командировку не за три дня, а за два – это успех? Скорее всего, нет. Нужно спуститься на более нижний уровень, а именно – добавить цифры:

• Ускорить процесс оформления командировки в два раза.

• Сократить количество бумажных командировок на 90% (пусть 10% все еще оформляют в офисе вручную).

• Сократить персонал кадровиков в 4 раза (или на 300 человек – 1 кадровик).

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

Кроме того, есть нефункциональные требования, которые спущены архитекторами, специалистами по ИБ и др. Они задают ограничения:

• Использовать только разрешенный стек технологий, не покупать внешние коробочные решения, нужно разрабатывать собственное.

• Также фиксируется требование по производительности – например, система должна выдерживать более 100 активных пользователей одновременно. Это важно, чтобы при оформлении командировок несколькими десятками сотрудников система не падала.

Бизнес-требования описаны, конкретные цифры получили, нефункциональные требования зафиксированы – можно переходить к процессу.

На схеме желтые и синие квадраты показывают разные уровни:

• желтые – действия пользователя,

• синие – системы и их взаимодействие.

Например, сотрудник организации заходит на портал и проходит авторизацию и аутентификацию. Синим обозначен слой систем: есть форма авторизации и корпоративный сервис аутентификации.

Есть сервис AUTH – это блок кода, который выполняет идентификацию, проверку учетных данных и их подтверждение. Данные он берет из таблицы Users. Если сравнить эту схему с обычной «кучей линий и стрелок», видно, что она прозрачнее и понятнее – при условии, что соблюдаются единые правила описания архитектуры.

Дальше идут функциональные требования. Пользователь проходит авторизацию и попадает на страницу оформления командировки.

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

Синим отмечено, что отправка документов на согласование происходит через систему Документооборота – этот процесс уже связан и отображен.

Как это происходит? Кружочек с палочкой – это веб-сервис. Он отправляет документы на согласование. Есть блок кода – сервис создания документа, который выполняется в системе корпоративного документооборота (корпоративной ДО). Есть руководитель сотрудника, есть бизнес-роль – он согласовывает документ.

Таким образом мы более детально показываем процесс. С первого раза не все понятно, но при повторном просмотре видно, за что отвечает каждый элемент и как с этим взаимодействовать.

Что важно: одни и те же функции используются в разных бизнес-процессах. Пример – сервис по выгрузке объектов недвижимости. В Archi сразу видны все связи: сервис по выгрузке объектов недвижимости взаимодействует с конкретным объектом недвижимости и связан с сервисом CRM.

Есть конкретные веб-сервисы с названиями GetONopportunity, GETON. В их свойствах можно указать URL и добавить детали. Можно переходить по объектам, сразу смотреть их связи и по кнопке видеть: есть такой объект, если мы его изменим, это заэффектит ряд систем.

Как я уже говорил, в Archi можно увидеть все связи – стрелки, показывающие, как элементы взаимодействуют. Есть отдельные вьюхи – представления, где проектируются бизнес-процессы. Каждая вьюха отображает конкретную часть архитектуры. Например, CRM-сервис по выгрузке объектов недвижимости используется сразу в трех вьюхах, и это видно на схеме.

Всю созданную модель можно выгрузить в Excel и на ее основе получить GUID’ы, с которыми затем можно работать как угодно.

Archi поддерживает работу с Git, поэтому несколько человек могут одновременно редактировать архитектуру: рисовать, пушить изменения, коммитить и обновлять общий репозиторий.

Далее данные можно снова выгрузить в Excel и использовать по-разному – например, передать их ИИ, чтобы он помог сконструировать процесс. Если систему и объекты можно выгрузить, возможности практически безграничны.

Цифровой двойник на платформе 1С

Мы разобрали ADR, Archi и TOGAF, теперь поговорим о цифровом двойнике, реализованном на платформе 1С.

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

У нас уже есть модель в ArchiMate, где зафиксированы взаимосвязи. Поэтому следующая задача – создать систему фиксации взаимодействий и цифровой двойник.

Огромное количество интеграций невозможно зафиксировать в Excel или переписках в чатах. Есть связи «точка-точка», брокеры, самописные шины. К самописной шине можно обратиться разными способами. Слишком много нюансов и взаимодействий.

Есть системы, задействованные в процессах или работающие на оборудовании, но они отображены некорректно. Например, за одной системой числится восемь серверов. Представим, сколько серверов крутится в рамках 300 систем, и при этом информация отображается неправильно. То есть нужно четко понимать, какая система закреплена за каким оборудованием.

И нет понимания, какая команда отвечает за систему, какой функционал и технологии в ней используются. На чем она написана – на 1С, .NET, Simple One – непонятно. Слишком много вопросов и мало ответов.

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

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

Сразу видны интеграции: мы собираем логи, выгружаем их, затем загружаем логи разных брокеров, шин, SQL и можем с этим работать.

Есть информация об используемом ПО в проекте. Есть инфраструктура, на которой система работает.

Например, два сервера: ITE1.PICompany.ru и ITE2.PICompany.ru на PROD, где развернута «Самая лучшая ретрофутуристическая система».

AI-агент на основе графа знаний

Мы создали систему, у нас есть ADR, у нас есть схемы, мы научились мыслить едино. Есть единая точка, где все можно посмотреть. Есть единая схема, по которой моделируем. Есть система принятия решений, по которой действуем.

Теперь сделаем AI-агента, рожденного на основании всех предыдущих пунктов. Как будем его делать – расскажу далее.

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

Делаем помощника, который будет отвечать на любые вопросы из этой системы:

• Выгрузим структуры данных по справочнику «Система» в JSON типовыми методами, которые будут содержать всю информацию, потому что для любого ИИ главное – стабилизация и структура данных. Если есть структура данных – проблемы не будет. В 1С есть конфигуратор и метаданные, структура четкая.

• Используем фреймворк graphiti, который использует построение графа знаний – кто, что, с чем связано.

• Напишем скрипт на Python для загрузки и поднимем необходимое окружение для graphiti: в Docker поднимаем graphiti, скачиваем его, запускаем скрипт на Python.

• Запустим выгрузку json в графовую базу NEO4j.

• Зададим вопрос и получим ответ.

На изображении мы видим JSON: «самая лучшая ретрофутуристическая система», ее описание, ценность. У системы есть реквизиты.

Когда запускаем скрипт на Python, JSON автоматически раскладывается в графовую базу: сущности разделяются, сразу видно, что с чем связано, какой у чего код, какие сервера, какие зависимости. Мой AI-агент может работать с этой структурой.

Когда мы все это подключили, мы задаем вопрос: «Расскажи про систему ретрофутуризма из графа знаний, используй только граф знаний». Не обязательно формулировать точное именование: агент сам это поймет, сам спросит и сам выдаст решение.

На запрос он возвращает всю доступную информацию: основные характеристики, описание, уникальную ценность («позволяет улететь и не вернуться»), перечень серверов, их ОС, дополнительные ресурсы (например, event.infostart.ru), график обслуживания системы. Все реквизиты он преобразует в ответы.

Отдельно агент говорит о концепции системы – что это такое и что она позволяет делать: сочетает классические технологические решения, поддерживает концепцию односторонних космических миссий – «улететь и не вернуться».

Это вся информация, которая есть в графе знаний.

Итоги и рефлексия

Изначально у нас была инициатива-проблема, которую обсуждали устно и фиксировали в разных чатах. Затем появлялись разрозненные документы – в Confluence, Wiki, Google- и Яндекс-таблицах. Информация дублировалась, решения принимались локально, без понимания глобального контекста: как конкретная система или изменение повлияет на остальные. В результате возникали скрытые последствия, инциденты и постоянное «пожаротушение».

Теперь процесс выглядит иначе. Есть инициатива-проблема – фиксируем ее в черновике ADR. Собираем архитектурный комитет, обсуждаем, формируем решение. Далее обновляем модель в Archi – визуализируем, как это выглядит в архитектуре. После утверждения ADR обновляем цифровой двойник в 1С: пишем простую обработку для загрузки Excel или JSON и синхронизируем данные. Затем выгружаем актуальную информацию в графовую базу, и AI-агент получает возможность отвечать на любые вопросы: по интеграциям, системам, взаимодействиям и статусам.

Давайте порефлексируем:

• Любое изменение начинается с четко выстроенного процесса. Без процесса – нет изменения.

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

• На этапе выстраивания процесса вы столкнетесь с непониманием, отторжением, принятием, саботажем – это нормально. Каждая команда – это живой организм с разным уровнем зрелости.

• Сейчас мы освежили около 50% интеграций и систем, но нам предстоит еще долгая и кропотливая работа.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.