Концепция гибкой интеграции

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

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

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

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

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

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

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

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

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

Конец планирования

«Планирования, каким мы его знаем, больше не существует, — заявил в своем выступлении на конференции Red Hat Summit Джим Уайтхерст, главный управляющий Red Hat. — Планирование в малоизученной среде неэффективно». В стремительно развивающейся бизнес-среде неспособность лавировать, своевременно корректируя свои действия, может обойтись чрезвычайно дорого. Это означает, что чем меньше информации вы имеете или чем менее стабильна среда, тем ниже ценность планов.

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

Рабочим группам, привычным к полугодовым или даже двухлетним циклам разработки, непросто приспособиться к быстрым переменам. Проблема усугубляется, когда традиционно структурированные компании бывают вынуждены конкурировать с начинающими компаниями, которые используют совершенно новые подходы. Очевидные примеры — Netflix и Blockbuster или Uber и традиционное такси, но подрыв устоявшегося порядка молодыми компаниями прослеживается с начала информационного века, с Amazon в 1993 году и персональных компьютеров в 1980-х (таблица 1).

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

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

Что необходимо для успеха

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

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

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

Марти Каган, менеджер продукта компании eBay, облагает каждый проект «налогом» — некоторое время и ресурсы из каждого обычного проекта выделяются для работы над новыми инфраструктурными проектами. Таким образом, новые проекты и новации становятся приоритетными.

Инфраструктура гибкости

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

Три столпа гибкой интеграции

Подход к гибкой интеграции базируется на трех основных технологиях.

1. Распределенная интеграция. Нес­колько десятков высокоуровневых шаблонов интеграции отражают потоки данных и рабочих процессов на предприятии. Если эти шаблоны интеграции развернуты в контейнерах, то их можно развернуть в нужных масштабах и там, где необходимо для конкретных приложений и рабочих групп. Это архитектура распределенной интеграции, отличная от традиционной архитектуры централизованной интеграции. Благодаря ей отдельные рабочие группы могут гибко определять и развертывать требуемые шаблоны интеграции.
2. API-интерфейсы. Стабильные, хорошо управляемые API-интерфейсы имеют решающее значение для взаимодействия между рабочими группами, разработчиками и специалистами по эксплуатации. API-интерфейсы заключают важнейшие активы в стабильные, повторно используемые интерфейсы, позволяя этим интерфейсам служить строительными блоками для многократного применения в масштабах компании, с партнерами и клиентами. API-интерфейсы можно размещать вместе с контейнерами в различных средах, что позволяет пользователям взаимодействовать с разными наборами API-интерфейсов.
3. Контейнеры. Это базовая платформа развертывания как для API, так и для технологий распределенной интеграции. Контейнеры позволяют развернуть нужную службу в определенной среде простым и единообразным для разработки, тестирования и обслуживания способом. Поскольку контейнеры являются доминирующей платформой для сред и микрослужб DevOps, их использование в качестве платформы интеграции обеспечивает более прозрачное и тесное сотрудничество между группами разработчиков и специалистами по инфраструктуре.

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

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

Распределенная интеграция

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

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

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

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

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

Обмен сообщениями способствует интеграции

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

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

Кроме того, Fuse поставляется с Red Hat JBoss AMQ, чтобы обеспечить инфраструктуру обмена сообщениями. Мощная инфраструктура обмена сообщениями гарантирует эффективную маршрутизацию событий и данных между системами. Обмен сообщениями — важный архитектурный инструмент для микрослужб, поскольку его асинхронная природа не требует зависимостей.

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

Следим за тенденциями

Контейнеры применяются все чаще, но насколько и почему? Аналитики компании 451 Research прогнозируют рост рынка на 250%, но это объем затрачиваемых средств, а не развертывания. Оценить развертывания несколько сложнее. В результате опроса, выполненного компанией Bain по заказу Red Hat, выяснилось, что около 20% клиентов сегодня развертывают контейнеры в производственной среде и примерно столько же в средах разработки и тестирования, но более 30% оценивают контейнеры и выполняют проверку концепции.

Что означает «использовать контейнеры»? В Enterprisers Project обрисованы четыре различных варианта применения контейнеров: в качестве общей платформы разработки и развертывания; как «облачной» платформы или платформы микрослужб; в гибридном «облаке» и для инновационных проектов. От способа использования контейнеров зависит, как пользователь рассматривает их внедрение.

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

Контейнеры

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

Благодаря более строгому и компактному подходу контейнерная технология становится идеальным инструментом для современной программной среды. Каждый экземпляр использует неизменяемое определение, от операционной системы до точной версии каждой библиотеки. В результате среда для каждого экземпляра оказывается в высшей степени повторяемой и согласованной, то есть идеальной для конвейеров непрерывной интеграции и доставки (CI/CD). Кроме того, поскольку образ контейнера определяет лишь все необходимое для одного приложения, контейнеры соответствуют микрослужбам, и в рамках оркестровки контейнеров можно также оркестрировать развертывание и управление большими инфраструктурами микрослужб.

Благодаря сочетанию компактности и повторяемости контейнеры — идеальная технологическая платформа для гибкой интеграции.

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

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

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

Контейнерам требуется оркестровка

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

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

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

API-интерфейсы

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

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

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

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

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

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

Архитектура гибкой интеграции

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

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

Информационные архитекторы или ИТ-администраторы должны четко определить процессы для отдельных рабочих групп, в том числе:

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

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

Архитектура инфраструктуры

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

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

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

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

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

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

Гибкость и культура

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

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

Преимущества быстро реагирующих, итеративных процессов, таких как DevOps, очевидны для групп разработки и эксплуатации, но реже для инфраструктурных групп. Однако в выполненном Фролихом анализе преимуществ и недостатков упущен один критический фактор: согласование инфраструктурных групп с группами разработки и эксплуатации. Рохан Пирс написал в CIO о преобразовании инфраструктурных групп из функциональных групп в гибкие рабочие ячейки. Группы разработчиков Telstra Enterprise Services просто игнорировали свои внутренние системы из-за сложности процесса проверки и обновления систем. Благодаря корректировке рабочих групп время цикла сократилось с 212 до 42 дней.

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

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

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

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

Применение принципов гибкости к планированию инфраструктуры

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

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

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

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

Оцениваем перспективы

Какова вероятность успешного завершения ИТ-проекта? Прежде всего это зависит от вашего критерия успеха — соответствие спецификациям, большее принятие пользователями или просто выпуск продукта. Группа обучения управлению проектами 4PM определяет успех как завершение проекта в срок, в рамках бюджета и в соответствии со спецификациями. По оценкам, согласно этому определению, примерно 70% ИТ-проектов завершается неудачей. Эти показатели начинают меняться. В результате опроса института Project Management Institute выяснилось, что в настоящее время больше проектов достигает плановых целей, чем в последние пять лет. Прогресс объясняют лучшим согласованием между отделом ИТ и бизнес-подразделениями, что способствует большей осведомленности о стратегии и нуждах потребителей.

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

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

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

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

Обеспечиваем гибкую интеграцию

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

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

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

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

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

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