Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect

Привет Хабр! Меня зовут Рустем, IBM Senior DevOps Engineer & Integration Architect.

Сегодня я хотел бы взглянуть на современные паттерны интеграции: Enterprise Design Thinking и Event Driven Architecture.

Модернизация приложений

Модернизация приложений — это процесс перехода от монолитной архитектуры к облачным микросервисам.

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

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

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

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

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

Так называемые бенефиты:

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

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

• Повышение эффективности и стандартизации. DevOps поддерживает культуру автоматизации и трансформации.

Enterprise Design Thinking

Enterprise Design Thinking — это практика проектирования, которая может помочь вам спланировать дорожную карту модернизации приложений. Вы можете использовать корпоративное дизайн-мышление, чтобы определить желаемые результаты и минимально жизнеспособный продукт (MVP) вашего заинтересованного лица(всякие акционеры, инвесторы, бизнес смартхэды и т.п).

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

Enterprise Design Thinking сочетает в себе традиционные методы с новыми базовыми практиками.

Корпоративное дизайн-мышление начинается с объединения ряда традиционных методов проектирования, таких как персонажи, карты эмпатии, сценарии «2B/To be», идеи дизайна, будущие сценарии, наброски каркасов, проектирование, основанное на гипотезах, и определение минимально жизнеспособного продукта (MVP) . К этим традиционным подходам к проектированию Enterprise Design Thinking добавляет три основных метода: холмы(hills), плейбэки и спонсор юзеры.

Холмы

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

Плейбэки

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

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

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

Спонсор юзеры

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

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

Важные компоненты корпоративного дизайн-мышления

Enterprise Design Thinking включает в себя несколько компонентов.

Персонажи

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

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

Карты эмпатии

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

Карты сценариев «As is»

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

Идея дизайна и расстановка приоритетов

После того, как вы создадите персону, карту эмпатии и карту сценария «As is», вы поймете свою целевую аудиторию и проблемы, с которыми она сталкивается. У вас также, вероятно, будет несколько идей о том, как решить их проблемы. Во время создания идеи дизайна проводите мозговой штурм и генерируйте как можно больше идей. Сначала не беспокойтесь о том, что возможно, а что нет. Генерируйте как можно больше идей, независимо от того, знаете ли вы, как их реализовать. Затем сгруппируйте эти идеи в кластеры и решите, какие из них наиболее перспективны.

Карты 2B

На этом этапе ваша цель — создать карту to be. Эта карта сценария, называемая картой будущего сценария, описывает будущее состояние, к которому приводит внедрение ваших лучших идей. Зафиксируйте, что люди думают, делают и чувствуют во время этого будущего набора действий. Не забудьте захватить аспект «вау» в этом новом потоке сценария. Ключевой вопрос: «Захочет ли конечный пользователь купить продукт? Почему? Почему нет?»

Каркасные эскизы

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

Дизайн, основанный на гипотезах

Ключевым аспектом Enterprise Design Thinking является создание набора проверяемых и измеримых гипотез о том, что вы проектируете и реализуете. Гипотезы, как правило, имеют такую форму: «Если мы обеспечим персону А способностью достигать результата Б, тогда мы сможем измерить влияние с помощью показателей X, Y и Z». Эти проверяемые гипотезы помогут вам определить, создали ли вы привлекательный продукт, на создание которого надеялись.

Определение минимально жизнеспособного продукта (MVP)

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

Event-Driven Architecture

События(events) — это уведомления об изменении состояния. Уведомления выпускаются или публикуются, и заинтересованные стороны могут подписаться на события и реагировать на них. Как правило, отправитель уведомления не знает, какое действие было предпринято, и не получает соответствующей обратной связи о том, что уведомление было обработано.

События происходят в непрерывном потоке данных и в неограниченной серии. Приложения могут реагировать и рассуждать о будущем на основе того, что произошло в потоке. Источники событий(Event Sources) — это шаблон, используемый для записи изменений состояния и обновлений в распределенных системах.

Магистраль событий(Event Backbone) обеспечивает связь между компонентами, включая источники событий, потоки событий, потоковую аналитику и микросервисы.

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

Event Stream

Поток событий(Event Stream) — это непрерывная неограниченная серия событий. Запуск потока может произойти до того, как вы начнете его обрабатывать. Конец потока находится в каком-то неизвестном месте в будущем.

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

• Потоки, события которых определены и опубликованы в потоке как часть решения.

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

Loose Coupling

Слабая связанность(Loose Coupling) — одно из основных преимуществ обработки, управляемой событиями. Это позволяет производителям событий создавать события, не зная о том, кто будет потреблять эти события. Точно так же потребители событий не должны знать об источниках событий. Из-за слабой связанности модули, потребляющие события, и модули, создающие события, могут быть реализованы на разных языках или использовать разные технологии, подходящие для конкретных задач.

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

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

Cohesion

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

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

Вид базовой Event Driven Architecture

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

2) Event Streams предоставляет магистраль событий(event backbone), которая поддерживает связь публикации/подписки, журнал событий и простую обработку потока событий например с помощью Apache Kafka.

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

4) Streaming Analytics обеспечивает непрерывный прием и аналитическую обработку нескольких потоков событий. Decision Server Insights предоставляет средства для выполнения действий с событиями и потоками событий с помощью бизнес-правил.

5) Хранилища событий обеспечивают оптимизированную сохраняемость (хранилища данных) для источников событий, разделения запросов и ответов команд (CQRS) и аналитических вариантов использования.

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

Вот и все, краткий взгляд на довольно простые, но эффективные методики

В заключение рекомендую открытый урок по теме «Architecture As a Code», на котором будут обсуждаться вопросы:

— Предпосылки появления, преимущества и недостатки, границы применимости;
— Текущая ситуация в индустрии;
— Hands-On: знакомство с предлагаемым подходом на практике.

Зарегистрироваться на мероприятие можно по ссылке.