Архитектура Power Platform для сложных корпоративных решений с Ианом Тведди [MVP]

Microsoft Power Platform часто описывают как платформу low-code. Но что происходит, когда создаваемые приложения становятся критически важными для бизнеса, тесно интегрированными и слишком сложными для простого подхода «для мейкеров»?В этом выпуске M365 FM Мирко Питерс беседует с архитектором решений Power Platform Яном Тви о том, что происходит, когда Power Platform выходит за рамки простых low-code приложений и становится частью серьёзной корпоративной архитектуры.

LOW-CODE НЕ ОЗНАЧАЕТ ОТСУТСТВИЕ АРХИТЕКТУРЫ
Power Platform может быстро обеспечить значительную часть бизнес-ценности, однако корпоративные решения почти всегда содержат требования, выходящие за пределы стандартных возможностей low-code.Ян объясняет, почему low-code никогда не следует путать с no-code, и почему принципы традиционной архитектуры программного обеспечения по-прежнему важны при разработке с Power Apps, Power Automate, Dataverse, пользовательскими коннекторами, API и сервисами Azure.

КОГДА POWER PLATFORM СТАНОВИТСЯ КОРПОРАТИВНЫМ ПО
Не существует чёткой границы между «low-code» и «корпоративным» решением.Сложность начинает расти, когда приложения включают несколько пользовательских сценариев, команды разработчиков, интеграции, требования безопасности, критически важные для бизнеса процессы и взаимосвязанные сервисы.На этом этапе архитектура становится необходимой.Ян объясняет, почему решения следует делить на чётко определённые функции и модули с понятными интерфейсами, а не превращать в одно большое взаимосвязанное приложение.

ВЫХОД ИЗ ПРОБЛЕМЫ «ЗАДАЧИ КРОТА» В РАЗРАБОТКЕ
Исправляешь одну ошибку, и в другом месте появляется новая.Эта знакомая проблема разработки часто является симптомом жёстко связанной архитектуры.Ян рассказывает, как модульный дизайн может изолировать функциональность и уменьшить непреднамеренные зависимости. На примере доставки электронной почты он объясняет, как отделение бизнес-процессов от механизмов доставки может упростить тестирование, сопровождение, замену и масштабирование приложений.

LOW-CODE + PRO-CODE = ГИБРИДНАЯ АРХИТЕКТУРА
Power Platform не обязан конкурировать с традиционной разработкой программного обеспечения.Фронтенд на Power Apps может представлять лишь небольшую часть гораздо более крупного приложения, использующего Azure, AWS, GCP, API или пользовательские сервисы.Важный архитектурный вопрос заключается не в том, является ли что-то «low-code» или «pro-code».А в том, какая технология лучше всего подходит для каждой функции.

ГРАЖДАНСКИЕ РАЗРАБОТЧИКИ, МЕЙКЕРЫ И АРХИТЕКТУРА
Гражданские разработчики приносят чрезвычайно ценное: глубокое знание бизнес-процессов, с которыми они работают каждый день.Однако бизнес-экспертиза автоматически не превращается в хорошую архитектуру приложений.Ян обсуждает баланс между расширением возможностей мейкеров и внедрением достаточного уровня архитектуры, управления, нормализации и технической экспертизы, чтобы решения не стали трудно поддерживаемыми.

УПРАВЛЕНИЕ БЕЗ ПОДАВЛЕНИЯ ИННОВАЦИЙ
Слишком слабое управление создаёт хаос.Слишком жёсткое управление создаёт трение и может подтолкнуть сотрудников к неподдерживаемым обходным решениям, таблицам, VBA и теневой ИТ.Задача состоит в том, чтобы найти правильный уровень управления с учётом организационных рисков, критичности приложения, пользователей и влияния на бизнес.

POWER PLATFORM, API И AZURE
Где должна находиться бизнес-логика?Следует ли хранить секреты внутри Power Platform? Когда в архитектуру должны входить Azure Key Vault, Azure Functions или API Management?Ян объясняет, почему архитектура всегда должна начинаться с решаемой проблемы, а не с добавления сервисов Azure только потому, что они доступны.

GIT, СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ И CI/CD
По мере того как разработка в Power Platform становится более совместной, традиционные практики разработки приобретают всё большее значение.В беседе рассматриваются Git, репозитории, среды разработки, конвейеры, контроль версий, изоляция функций, перекрёстные зависимости и CI/CD.Не всегда существует идеальный подход к контролю версий в Power Platform — иногда цель состоит в выборе «наименее плохого варианта» для проекта.

ПЛЕЙБУК АРХИТЕКТУРЫ POWER PLATFORM ОТ ЯНА

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

РАУНД БЫСТРЫХ ВОПРОСОВ
Мирко задаёт Яну серию быстрых вопросов:Должно ли каждое корпоративное приложение использовать Dataverse?Может ли Power Platform создавать критически важные приложения?Может ли Power Automate заменить Logic Apps?Автоматически ли low-code снижает технический долг?Может ли Power Platform заменить традиционную разработку приложений?И, возможно, самое важное: что стоит заказать, приехав в Ньюкасл?

КЛЮЧЕВОЙ ВЫВОД
Low-code не означает отсутствие архитектуры.По мере того как решения Power Platform становятся крупнее, более связанными и важнее для бизнеса, основы программной инженерии остаются актуальными.Архитектура имеет значение.Моделирование данных имеет значение.Управление имеет значение.Безопасность имеет значение.Дизайн API имеет значение.DevOps имеет значение.И успешная корпоративная разработка на Power Platform всё больше сводится к пониманию того, как low-code, pro-code, Azure, API, автоматизация и традиционные практики программной инженерии работают вместе.

Станьте сторонником этого подкаста: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.