Всем привет! Недавно у нас в MTS DIgital прошла десятая научно-техническая конференция Hello, conference!, докладами с которой хотелось бы поделиться с сообществом. В этой статье руководитель центра RnD MTS Digital Дмитрий Дзюба и руководитель направления системной архитектуры MTS Digital Александр Петрухина расскажут про ArchOps.
Для любителей видео доклады с конференции доступны в записи.
Наш рассказ называется «Что такое ArchOps» и чтобы это было лучше понятно на примере, мы покажем, как вообще устроен архитектурный процесс в больших организациях.
Начнем с небольшой истории, которая произошла какое-то время назад у нас в компании. Задались мы, как архитекторы, целью навести порядок в интеграции, имеющейся в наших корпоративных приложениях.
Вы знаете, что в больших компаниях их может быть достаточно много, и это реально сотни типов информационных систем.
Архитекторам всегда хочется построить красивую и гармоничную архитектуру. И прежде чем начать глубокий рефакторинг IT-ландшафта, нам нужно определить принцип и порядок, как это должно происходить. Самый простой способ — начать с интеграционной архитектуры и декомпозировать ландшафт на набор bounded contexts, взаимодействующих через Open Host Service.
За основу мы взяли, наверное, многим из вас известный манифест Джеффа Безоса, который в какой-то момент времени задал общий принцип, как должны строиться приложения внутри Amazon.
Этот принцип заключается в том, что все должно иметь интерфейсы, приложения должны создаваться с учетом того, что их функциональность будет предоставлена через интерфейсы. Эти интерфейсы – единственный способ взаимодействия.
Очень важная составляющая этого мандата — его «мотивационная» часть. Что все, кто не будет так делать, будут уволены, и всем хорошего дня. Мы, конечно, так не могли сделать, поэтому решили пойти вглубь и немного его специализировать. Помочь нашим разработчикам понять, что такое интерфейсы, как они должны строиться.
Здесь нам на помощь пришла сервис-ориентированная архитектура – достаточно старый принцип, который содержит в себе части, описанные на картинке.
Мы взяли все эти принципы, подумав, что это будет хорошо. При этом нужно понимать, что внутри компании МТС большое количество продуктовых команд, которые развиваются более-менее независимо, т.е у нас нет каких-то точек контроля, в которых мы останавливаем процесс и проверяем, верны ли архитектурные решения. Команды принимают самостоятельно решения по своей архитектуре.
При этом сама корпоративная архитектура здесь больше как консультант-советчик и, конечно, автор различных стандартов, которые в компании внедряются.
Мы создали набор правил и политик с помощью которых описали все, вышеописанные принципы. И провели набор мероприятий по доведению новых принципов до команд.
Затем мы хотели получить классическую картину интеграции приложений на основе API Gateway. В ней у нас есть некоторая система, она взаимодействует с API Gateway по REST-протоколу, на API gateway происходят стандартные функции, такие как трансформация данных, изменение роутинга и так далее, а дальше происходят вызовы уже непосредственно самих систем. То есть такое контролируемое управление API.
В некоторых случаях мы действительно получили такую картину:
Но если приглядеться, она могла быть уже и не такая, то есть протоколы были уже не везде REST, где-то появился более старомодный SOAP (Xml WebServices), где мы обращаемся не к ресурсам, а вызываем какие-то функции. Просто потому что в данном случае команде было удобно вызвать какую-то функцию.
У нас неожиданно появилось несколько API gateways, потому что они оказались разными, какой-то удобнее, какой-то нет.
И самое неожиданное, у нас появилось еще то, что внутри некоторых API gateways стали зарождаться свои системы, реализующие custom-бизнес логику.
То есть, часть логики ушла из конкретных систем и продуктов в API gateway и там появилась уже полноценная enterprise service bus, которая непонятно, к чему относится и непонятно, как поддерживается. То есть результат мы получили не совсем такой, как хотели.
Итог такой, что вроде бы у нас стандартный процесс: мы как архитекторы придумали решение, мы его описали, мы его дали командам, но при этом единого решения у нас не получилось. И каждое отклонение от идеального решения, про которое я говорил, всегда имело какой-то смысл, всегда команда могла это обосновать. Как результат, у нас архитектура оказалась оторвана от реальности. Появляется логичный вопрос…
Я думаю, эта картина более-менее всем знакома, это типичная ситуация башни из слоновой кости, когда архитектор диктует некие правила, policy и стандарты и так далее, и высокоуровневый landscape кидает в команду.
Команда, естественно, слабо понимает, что из этого должно получиться. Какое-то представление конечно имеется, но непонятно как именно должно быть реализовано.
Минусы такого подхода в том, что диалог, по сути, односторонний, это монолог архитектора в сторону команды, обратная связь обычно слабая или отсутствует, и на выходе получается не то, что планировали изначально.
В команду сыплется целый поток артефактов: это и высокоуровневая архитектура, и какая-то solution-архитектура, которая, вполне возможно, им не понятна, это и разные policy и стандарты.
Какие из них применимы в текущей ситуации, а какие нет – команда почему-то должна решать сама, из-за этого сроки затягиваются, потому что у команды, возможно, не хватает экспертизы, бизнес еще дает задачи с дедлайнами, и поэтому команда принимает решение то, как она его видит, то, как она его может реализовать, а не то, как оно было запланировано изначально.
Чтобы разрушить эту башню из слоновой кости, у нас существует подход, который называется ArchOps, (да, почти как DevOps, но он про архитектурный процесс).
Начинается все с того, что нас есть какой-то продукт, есть типичный процесс команды по разработке этого продукта, и есть какие-то высокоуровневые требования на уровне компании.
Что делает ArchOps: у нас добавляется архитектурное планирование, на котором эта стрелочка показывает не одностороннее взаимодействие, это некий тачпойнт с командой, это диалоги – где в команду вбрасывается целевая архитектура именно их продукта, а не какая-то общая.
На втором этапе у нас есть архитектурное сопровождение, где команды и архитекторы общаются через артефакт, называемый Architecture decision records (ADR), дальше на нем остановимся подробнее. Они обмениваются артефактами и выстраивают то решение, которое должно получиться, так, чтобы оно угодило и команде, которая бы понимала его, и угодило архитектуре, потому что, по сути, enterprise архитектура – это требования бизнеса.
На последнем этапе у нас идет надзор и стандартизация. Если были выявлены какие-то отклонения в реализации – это, по сути, наполнение бэклога технического долга команды, то есть это то, что было реализовано в угоду скорости или еще чему-то, например, выводу фичи скорее в продакшн, не так, как планировалось изначально. И это тоже добивается этими же ADR.
Как итог, мы имеем диалог между командой и архитекторами, команда и архитекторы выступают почти на равных, то есть они могут принимать решения по изменению архитектуры или принимать другие решения и обосновать их. И на выходе всем проще, потому что изначально что планировалось, то и получилось, бизнес тоже доволен.
Теперь посмотрим, какие же артефакты у нас ходят. Это, собственно, сам ADR, Architecture decision records и solution-архитектура как набор подкрепляющих артефактов. ADR-log позволяет не только посмотреть эволюцию архитектуры на всех уровнях (от enterprise до продуктовой) но и понять мотивацию принимаемых решений.
Все остальные стандарты, policy и все высокоуровневое – укладываются в этот ADR, описывающий именно то инкрементное изменение, которое должна сделать команда. Соответственно, команде проще, потому что у нее теперь есть понятный артефакт, по которому она двигается.
Что же такое ADR? Здесь на иллюстрации показана реализация m ADR – стандартного шаблона ADR в формате MarkDown.
ADR состоит из двух файлов, это MarkDown-файл, который описывает шаблонизированный подход к описанию проблемы, какие решения были приняты, какие у них плюсы и какие минусы, и некий puml (PlantUML), который обычно описывает либо sequence диаграмму, либо С4 в зависимости от контекста и потребностей этого ADR.
В данном, упрощенном, примере ADR видно, что есть какая-то проблема, есть какие-то пути ее решения, есть плюсы и минусы, и итог, что же должно произойти. И, обычно это еще подкреплено некой диаграммой.
Диаграммы и сам ADR складываются в некий архитектурный лог, обычно он контролируется в version control в Git. Команда может обращаться к этому логу как к базе знаний. Еще, это облегчает онбординг новых сотрудников, которые из ADR (в котором все описано) смогут понять, почему были приняты те или иные решения.
Стоит добавить, что появляется еще и роль solution архитектора. Есть, конечно, простые продукты, где в принципе архитектура и команда могут общаться через ADR, но в больших корпорациях обычно есть еще продукты, которые реализуются несколькими командами, то есть это какой-то суперпродукт.
В экосистеме есть хороший пример, что есть несколько компаний участвующих в создании сквозного решения, и вам нужен кто-то, кто может курировать всю архитектуру сложного проекта. Обычно на эту роль выделяется solution архитектор, который общается с командами посредством ADR, и команды через архитектурный лог могут видеть, что происходит в соседних командах, и как-то принимать решения, которые позволят сделать его лучше.
Давайте постараемся понять — а всегда ли нужен такой сложный процесс, если мы хотим внедрять общие архитектурные паттерны в сложном ИТ-ландшафте. Для этого наш второй пример.
Как вы уже догадались из контекста первого примера в начале статьи, IT-ландшафт в крупных компаниях достаточно сложный, и часто возникает задача вообще понять, как реальные системы взаимодействуют друг с другом. Это называется решением задачи наблюдаемости на IT-ландшафте.
Как мы подошли к этой задаче? Во-первых, наблюдаемость, а это естественное свойство любой архитектурной системы, решается так или иначе в каждом конкретном IT-продукте.
Обычно это делается с помощью одного или нескольких аспектов:
Трассировка — когда мы все запросы, которые проходят через систему, как-то отслеживаем и понимаем логику прохождения общих сценариев и вариантов использования через наши компоненты внутри системы.
Логирование всех событий, которые вообще происходят в системе.
Подсчет различных ключевых метрик (например производительности), которые позволяют нам понять насколько наше приложение здорово. Обычно это делается внутри самой системы. Но теперь нам нужно было исследовать весь ландшафт.
У нас есть на ландшафте большой набор систем, которые взаимодействуют друг с другом (на картинке они показаны как A, B, C, D, E). Они могут решать какую-то непростую задачу, которая задействует десятки сложных систем – класса Business Support System или Operation Support System. И нам важно понимать, в каком состоянии находится процесс, где он тормозит, как он проходит через системы, какие системы работают эффективно, а какие не очень.
Здесь очень важно отслеживать сквозной процесс прохождения между всеми системами и для этого у нас в компании есть замечательная платформа наблюдаемости. Возможно, многие про нее слышали, мой коллега Филипп Бочаров, автор этой платформы, много выступает с ней на конференциях, поэтому я здесь сильно не буду сильно пускаться в детали и устройства.
Суть платформы наблюдаемости в том, что она построена на наборе опенсорсных компонентов, которые любая продуктовая команда может встроить в свой продукт и подключиться к единому полю наблюдаемости, которое формируется на IT-ландшафте. После чего мы начинаем получать информацию о том, как идут конкретные вызовы.
Что здесь было важно в этом процессе: мы точно так же определили принцип и конкретный способ решения задачи. Но вместо создания сложных артефактов мы создали платформу, и у нас появилась платформенная команда, которая помогала конкретным разработчикам внедрять внутрь себя вот эти инструменты, фактически реализовывать наш принцип.
В итоге большинство команд внедрило эту платформу, у нас появилась возможность автоматически строить карту вызовов на IT-ландшафте, стало проще им управлять и оптимизировать.
Можно сказать, ну вот же, задача похожая и все получилось без всяких ArchOps. В чем же здесь разница?
Разница действительно достаточно минимальна, основное отличие решения с платформой от ArchOps в том, что теперь мы дали разработчикам не только какое-то задание команде, но и предложили вариант решения, через который они могут зайти, с понятным порогом входа, с понятной документацией и с командой этой платформы, которая облегчала онбординг.
То есть теперь появился коридор, по которому команда может зайти на платформу и реализовать то или иное запланированное решение.
Это не конкретное решение, не конкретный инструмент, это набор базовых принципов, которые стоит применять, когда у вас действительно очень большая компания, очень сложный IT-ландшафт и вы хотите получить централизованное управление.
И здесь нужно фокусироваться на трех принципах:
На этом мы заканчиваем материал про ArchOps, надеемся, что он был полезен для вас.
Для любителей видео доклады с конференции доступны в записи.
ПРИМЕР 1: Когда хотели как лучше
Наш рассказ называется «Что такое ArchOps» и чтобы это было лучше понятно на примере, мы покажем, как вообще устроен архитектурный процесс в больших организациях.
Начнем с небольшой истории, которая произошла какое-то время назад у нас в компании. Задались мы, как архитекторы, целью навести порядок в интеграции, имеющейся в наших корпоративных приложениях.
Вы знаете, что в больших компаниях их может быть достаточно много, и это реально сотни типов информационных систем.
Архитекторам всегда хочется построить красивую и гармоничную архитектуру. И прежде чем начать глубокий рефакторинг IT-ландшафта, нам нужно определить принцип и порядок, как это должно происходить. Самый простой способ — начать с интеграционной архитектуры и декомпозировать ландшафт на набор bounded contexts, взаимодействующих через Open Host Service.
За основу мы взяли, наверное, многим из вас известный манифест Джеффа Безоса, который в какой-то момент времени задал общий принцип, как должны строиться приложения внутри Amazon.
Этот принцип заключается в том, что все должно иметь интерфейсы, приложения должны создаваться с учетом того, что их функциональность будет предоставлена через интерфейсы. Эти интерфейсы – единственный способ взаимодействия.
Очень важная составляющая этого мандата — его «мотивационная» часть. Что все, кто не будет так делать, будут уволены, и всем хорошего дня. Мы, конечно, так не могли сделать, поэтому решили пойти вглубь и немного его специализировать. Помочь нашим разработчикам понять, что такое интерфейсы, как они должны строиться.
Здесь нам на помощь пришла сервис-ориентированная архитектура – достаточно старый принцип, который содержит в себе части, описанные на картинке.
- Это стандартизированные сервисы, т.е вначале мы придумываем то, для чего должны быть сервисы, а потом – как они реализованы.
- Они должны опираться на стандартные контракты, которые должны не меняться идеально во времени.
- Сервисы должны быть слабо связаны, то есть при изменении одного сервиса не должно быть каскадных изменений других сервисов.
- Должна быть абстракция интерфейсов от реализации. Этот принцип позволяет менять внутреннюю реализацию сервиса без влияния на интерфейс.
- Reusability — более философский принцип. Нужно развивать сервисы, основываясь на их переиспользовании, то есть желательно, немного предугадывать будущее.
- Сервисы должны быть автономные, желательно не сохранять состояние, потому что мы знаем, что сервисов совсем без состояния, к сожалению, не бывает. Мы интерпретируем это как правило, что сервер точно должен ничего не знать о состоянии клиента.
- Они должны поддерживать discoverability, то есть быть доступны с помощью registry, и должны позволять составлять из них композитные приложения.
Мы взяли все эти принципы, подумав, что это будет хорошо. При этом нужно понимать, что внутри компании МТС большое количество продуктовых команд, которые развиваются более-менее независимо, т.е у нас нет каких-то точек контроля, в которых мы останавливаем процесс и проверяем, верны ли архитектурные решения. Команды принимают самостоятельно решения по своей архитектуре.
При этом сама корпоративная архитектура здесь больше как консультант-советчик и, конечно, автор различных стандартов, которые в компании внедряются.
Мы создали набор правил и политик с помощью которых описали все, вышеописанные принципы. И провели набор мероприятий по доведению новых принципов до команд.
Затем мы хотели получить классическую картину интеграции приложений на основе API Gateway. В ней у нас есть некоторая система, она взаимодействует с API Gateway по REST-протоколу, на API gateway происходят стандартные функции, такие как трансформация данных, изменение роутинга и так далее, а дальше происходят вызовы уже непосредственно самих систем. То есть такое контролируемое управление API.
В некоторых случаях мы действительно получили такую картину:
Но если приглядеться, она могла быть уже и не такая, то есть протоколы были уже не везде REST, где-то появился более старомодный SOAP (Xml WebServices), где мы обращаемся не к ресурсам, а вызываем какие-то функции. Просто потому что в данном случае команде было удобно вызвать какую-то функцию.
У нас неожиданно появилось несколько API gateways, потому что они оказались разными, какой-то удобнее, какой-то нет.
И самое неожиданное, у нас появилось еще то, что внутри некоторых API gateways стали зарождаться свои системы, реализующие custom-бизнес логику.
То есть, часть логики ушла из конкретных систем и продуктов в API gateway и там появилась уже полноценная enterprise service bus, которая непонятно, к чему относится и непонятно, как поддерживается. То есть результат мы получили не совсем такой, как хотели.
Итог такой, что вроде бы у нас стандартный процесс: мы как архитекторы придумали решение, мы его описали, мы его дали командам, но при этом единого решения у нас не получилось. И каждое отклонение от идеального решения, про которое я говорил, всегда имело какой-то смысл, всегда команда могла это обосновать. Как результат, у нас архитектура оказалась оторвана от реальности. Появляется логичный вопрос…
Почему так вышло?
Я думаю, эта картина более-менее всем знакома, это типичная ситуация башни из слоновой кости, когда архитектор диктует некие правила, policy и стандарты и так далее, и высокоуровневый landscape кидает в команду.
Команда, естественно, слабо понимает, что из этого должно получиться. Какое-то представление конечно имеется, но непонятно как именно должно быть реализовано.
Минусы такого подхода в том, что диалог, по сути, односторонний, это монолог архитектора в сторону команды, обратная связь обычно слабая или отсутствует, и на выходе получается не то, что планировали изначально.
В команду сыплется целый поток артефактов: это и высокоуровневая архитектура, и какая-то solution-архитектура, которая, вполне возможно, им не понятна, это и разные policy и стандарты.
Какие из них применимы в текущей ситуации, а какие нет – команда почему-то должна решать сама, из-за этого сроки затягиваются, потому что у команды, возможно, не хватает экспертизы, бизнес еще дает задачи с дедлайнами, и поэтому команда принимает решение то, как она его видит, то, как она его может реализовать, а не то, как оно было запланировано изначально.
ArchOps
Чтобы разрушить эту башню из слоновой кости, у нас существует подход, который называется ArchOps, (да, почти как DevOps, но он про архитектурный процесс).
Начинается все с того, что нас есть какой-то продукт, есть типичный процесс команды по разработке этого продукта, и есть какие-то высокоуровневые требования на уровне компании.
Что делает ArchOps: у нас добавляется архитектурное планирование, на котором эта стрелочка показывает не одностороннее взаимодействие, это некий тачпойнт с командой, это диалоги – где в команду вбрасывается целевая архитектура именно их продукта, а не какая-то общая.
На втором этапе у нас есть архитектурное сопровождение, где команды и архитекторы общаются через артефакт, называемый Architecture decision records (ADR), дальше на нем остановимся подробнее. Они обмениваются артефактами и выстраивают то решение, которое должно получиться, так, чтобы оно угодило и команде, которая бы понимала его, и угодило архитектуре, потому что, по сути, enterprise архитектура – это требования бизнеса.
На последнем этапе у нас идет надзор и стандартизация. Если были выявлены какие-то отклонения в реализации – это, по сути, наполнение бэклога технического долга команды, то есть это то, что было реализовано в угоду скорости или еще чему-то, например, выводу фичи скорее в продакшн, не так, как планировалось изначально. И это тоже добивается этими же ADR.
Как итог, мы имеем диалог между командой и архитекторами, команда и архитекторы выступают почти на равных, то есть они могут принимать решения по изменению архитектуры или принимать другие решения и обосновать их. И на выходе всем проще, потому что изначально что планировалось, то и получилось, бизнес тоже доволен.
Теперь посмотрим, какие же артефакты у нас ходят. Это, собственно, сам ADR, Architecture decision records и solution-архитектура как набор подкрепляющих артефактов. ADR-log позволяет не только посмотреть эволюцию архитектуры на всех уровнях (от enterprise до продуктовой) но и понять мотивацию принимаемых решений.
Все остальные стандарты, policy и все высокоуровневое – укладываются в этот ADR, описывающий именно то инкрементное изменение, которое должна сделать команда. Соответственно, команде проще, потому что у нее теперь есть понятный артефакт, по которому она двигается.
Что же такое ADR? Здесь на иллюстрации показана реализация m ADR – стандартного шаблона ADR в формате MarkDown.
ADR состоит из двух файлов, это MarkDown-файл, который описывает шаблонизированный подход к описанию проблемы, какие решения были приняты, какие у них плюсы и какие минусы, и некий puml (PlantUML), который обычно описывает либо sequence диаграмму, либо С4 в зависимости от контекста и потребностей этого ADR.
В данном, упрощенном, примере ADR видно, что есть какая-то проблема, есть какие-то пути ее решения, есть плюсы и минусы, и итог, что же должно произойти. И, обычно это еще подкреплено некой диаграммой.
Диаграммы и сам ADR складываются в некий архитектурный лог, обычно он контролируется в version control в Git. Команда может обращаться к этому логу как к базе знаний. Еще, это облегчает онбординг новых сотрудников, которые из ADR (в котором все описано) смогут понять, почему были приняты те или иные решения.
Стоит добавить, что появляется еще и роль solution архитектора. Есть, конечно, простые продукты, где в принципе архитектура и команда могут общаться через ADR, но в больших корпорациях обычно есть еще продукты, которые реализуются несколькими командами, то есть это какой-то суперпродукт.
В экосистеме есть хороший пример, что есть несколько компаний участвующих в создании сквозного решения, и вам нужен кто-то, кто может курировать всю архитектуру сложного проекта. Обычно на эту роль выделяется solution архитектор, который общается с командами посредством ADR, и команды через архитектурный лог могут видеть, что происходит в соседних командах, и как-то принимать решения, которые позволят сделать его лучше.
Пример 2: Платформизация
Давайте постараемся понять — а всегда ли нужен такой сложный процесс, если мы хотим внедрять общие архитектурные паттерны в сложном ИТ-ландшафте. Для этого наш второй пример.
Как вы уже догадались из контекста первого примера в начале статьи, IT-ландшафт в крупных компаниях достаточно сложный, и часто возникает задача вообще понять, как реальные системы взаимодействуют друг с другом. Это называется решением задачи наблюдаемости на IT-ландшафте.
Как мы подошли к этой задаче? Во-первых, наблюдаемость, а это естественное свойство любой архитектурной системы, решается так или иначе в каждом конкретном IT-продукте.
Обычно это делается с помощью одного или нескольких аспектов:
Трассировка — когда мы все запросы, которые проходят через систему, как-то отслеживаем и понимаем логику прохождения общих сценариев и вариантов использования через наши компоненты внутри системы.
Логирование всех событий, которые вообще происходят в системе.
Подсчет различных ключевых метрик (например производительности), которые позволяют нам понять насколько наше приложение здорово. Обычно это делается внутри самой системы. Но теперь нам нужно было исследовать весь ландшафт.
У нас есть на ландшафте большой набор систем, которые взаимодействуют друг с другом (на картинке они показаны как A, B, C, D, E). Они могут решать какую-то непростую задачу, которая задействует десятки сложных систем – класса Business Support System или Operation Support System. И нам важно понимать, в каком состоянии находится процесс, где он тормозит, как он проходит через системы, какие системы работают эффективно, а какие не очень.
Здесь очень важно отслеживать сквозной процесс прохождения между всеми системами и для этого у нас в компании есть замечательная платформа наблюдаемости. Возможно, многие про нее слышали, мой коллега Филипп Бочаров, автор этой платформы, много выступает с ней на конференциях, поэтому я здесь сильно не буду сильно пускаться в детали и устройства.
Суть платформы наблюдаемости в том, что она построена на наборе опенсорсных компонентов, которые любая продуктовая команда может встроить в свой продукт и подключиться к единому полю наблюдаемости, которое формируется на IT-ландшафте. После чего мы начинаем получать информацию о том, как идут конкретные вызовы.
Что здесь было важно в этом процессе: мы точно так же определили принцип и конкретный способ решения задачи. Но вместо создания сложных артефактов мы создали платформу, и у нас появилась платформенная команда, которая помогала конкретным разработчикам внедрять внутрь себя вот эти инструменты, фактически реализовывать наш принцип.
В итоге большинство команд внедрило эту платформу, у нас появилась возможность автоматически строить карту вызовов на IT-ландшафте, стало проще им управлять и оптимизировать.
Можно сказать, ну вот же, задача похожая и все получилось без всяких ArchOps. В чем же здесь разница?
Отличия ArchOps от решения с платформой
Разница действительно достаточно минимальна, основное отличие решения с платформой от ArchOps в том, что теперь мы дали разработчикам не только какое-то задание команде, но и предложили вариант решения, через который они могут зайти, с понятным порогом входа, с понятной документацией и с командой этой платформы, которая облегчала онбординг.
То есть теперь появился коридор, по которому команда может зайти на платформу и реализовать то или иное запланированное решение.
Что же такое ArchOps?
Это не конкретное решение, не конкретный инструмент, это набор базовых принципов, которые стоит применять, когда у вас действительно очень большая компания, очень сложный IT-ландшафт и вы хотите получить централизованное управление.
И здесь нужно фокусироваться на трех принципах:
- Прозрачность процесса внедрения архитектурных инструментов и изменений. Недостаточно, как в первом примере, придумать красивую картину и отправить ее в плавание, нужно работать вместе с командой.
- Сокращение разрыва планирования и реализации, то есть не давать большие изменения в команду, а делать это в цикле, инкрементально наращивая по этапам те решения, которые мы хотим реализовать.
- Выстраивание потока артефактов и обратной связи. Поток артефактов должен идти не только сверху, от корпоративной архитектуры, но и в обратную сторону, от команды, и это должно быть единое информационное поле, как, например, единый ADR-лог.
На этом мы заканчиваем материал про ArchOps, надеемся, что он был полезен для вас.