Компонуемая архитектура: введение

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

При создании комплексных решений компонуемая архитектура может иметь сложную разработку и рабочие процессы. Составная (модульная, компонуемая) архитектура и архитектура MACH представляют собой подходы к управлению цифровым опытом, при этом составная архитектура фокусируется на API-интерфейсе «A» в MACH путем объединения API-интерфейсов в связную архитектуру. 

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

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

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

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

Что такое компонуемая архитектура и зачем ее использовать

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

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

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

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

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

Компоненты компонуемой архитектуры

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

Инфраструктура как приложение

С момента знаменитого мандата API в Amazon и широкомасштабного распространения облачных сервисов на предприятиях потребность в навыках и инструментах DevOps резко возросла.

Раньше распространенным подходом было использование монолитной архитектуры, в которой все приложения работали на одной машине. Это по-прежнему возможно, но если вы заинтересованы в разработке более продвинутых компонуемых архитектур, вам следует подумать о том, чтобы рассматривать каждое приложение как отдельный компонент. Такой подход позволяет управлять приложением с помощью кода с помощью API, а затем распространять его в соответствии с потребностями вашей компании в вычислениях, хранении и обработке в реальном времени, не нарушая работу других приложений, которые уже работают.

Автоматизация инфраструктуры

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

Расширение таких возможностей внутренних команд также означает, что основные компоненты облака (хранилище, идентификация, вычисления, сеть и т. д.) должны рассматриваться как отдельные приложения. Затем их можно творчески упаковать в решения, которые координируют различные элементы решения (базы данных, серверы приложений, кэши) для быстрой доставки при относительно низких затратах на поддержку.

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

Мультиоблачная стратегия

Согласно концепции компонуемого предприятия, ИТ-предприятия должны разделять рабочие нагрузки, используя мультиоблачный подход. Поскольку разные поставщики облачных услуг имеют разные сильные стороны и структуру затрат, мультиоблачный подход позволяет проводить арбитраж компонуемого облака по цене и/или функциям. Это также гарантирует, что поставщики облачных услуг не смогут применить привязку к поставщику. Он предпочитает решения с открытым интерфейсом, которые сохраняют возможность будущих реконфигураций.

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

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

Шаги по созданию компонуемой архитектуры

Работа над компонуемой архитектурой состоит из четырех основных этапов.

Понять экосистему

Первый шаг к компонуемой архитектуре, понимание экосистемы, в основном входит в компетенцию корпоративных архитекторов.

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

Такая инвентаризация обеспечивает понимание текущих операций организации и потребностей клиентов, а также уровней зрелости элементов решения и их текущих уровней компоновки.

Определение необходимости компоновки

Следующий этап — определить объем и оценить необходимость компоновки. В реальном мире затраты и ресурсы необходимо сопоставлять с техническим совершенством. Этот этап посвящен пониманию требований к компонуемости.

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

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

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

Информационный архитектор

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

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

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

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

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

Модульность означает способность создавать и пересобирать ИТ-ландшафт в соответствии с потребностями компании.

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

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

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

Стройте и повторяйте

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

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

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

Заключение

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