Архітектура Power Platform для складних корпоративних рішень з Ian Tweedie [MVP]

Microsoft Power Platform часто описують як платформу низькокодової розробки. Але що відбувається, коли створені вами застосунки стають критично важливими для бізнесу, тісно інтегрованими та занадто складними для простого підходу «для мейкерів»?У цьому епізоді M365 FM Мірко Пітерс розмовляє з архітектором рішень Power Platform Яном Твідом про те, що відбувається, коли Power Platform виходить за межі простих низькокодових застосунків і стає частиною серйозної корпоративної архітектури.

НИЗЬКИЙ КОД НЕ ОЗНАЧАЄ НИЗЬКОЇ АРХІТЕКТУРИ
Power Platform може швидко забезпечити значну частку бізнес-цінності, але корпоративні рішення майже завжди містять вимоги, що виходять за межі стандартних можливостей низькокодової розробки.Ян пояснює, чому низький код ніколи не слід плутати з відсутністю коду, та чому принципи традиційної архітектури програмного забезпечення досі важливі під час створення рішень із Power Apps, Power Automate, Dataverse, власними конекторами, API та службами Azure.

КОЛИ POWER PLATFORM СТАЄ КОРПОРАТИВНИМ ПРОГРАМНИМ ЗАБЕЗПЕЧЕННЯМ
Насправді немає чіткої межі між «низьким кодом» і «корпоративним рішенням».Складність зростає, коли застосунки охоплюють кілька користувацьких сценаріїв, команди розробників, інтеграції, вимоги безпеки, критично важливі бізнес-процеси та взаємопов'язані сервіси.На цьому етапі архітектура стає необхідною.Ян пояснює, чому рішення слід розділяти на чітко визначені функції та модулі з чіткими інтерфейсами, а не перетворювати на один великий взаємопов'язаний застосунок.

ВИХІД ІЗ ПРОБЛЕМИ «ГРИ У ВИБИВАЛКУ» В РОЗРОБЦІ
Виправили одну помилку — з'являється інша десь в іншому місці.Ця знайома проблема розробки часто є ознакою тісно зв'язаної архітектури.Ян розповідає, як модульний дизайн може ізолювати функціональність і зменшити небажані залежності. На прикладі доставки електронної пошти він пояснює, як відокремлення бізнес-процесів від механізмів доставки може спростити тестування, супровід, заміну та масштабування застосунків.

НИЗЬКИЙ КОД + ПРОФЕСІЙНИЙ КОД = ГІБРИДНА АРХІТЕКТУРА
Power Platform не обов'язково має конкурувати з традиційною розробкою програмного забезпечення.Інтерфейс Power Apps може становити лише невелику частину значно більшого застосунку, що використовує Azure, AWS, GCP, API або власні сервіси.Важливе архітектурне питання полягає не в тому, чи є щось «низькокодовим» або «професійним кодом», а в тому, яка технологія найкраще підходить для кожної функції.

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

УПРАВЛІННЯ БЕЗ ШКОДИ ДЛЯ ІННОВАЦІЙ
Надто слабке управління створює хаос.Надто жорстке управління створює перешкоди й може підштовхнути співробітників до непідтримуваних обхідних шляхів, електронних таблиць, 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?Чи автоматично низький код зменшує технічний борг?Чи може Power Platform замінити традиційну розробку застосунків?І, мабуть, найважливіше: що варто замовити, відвідавши Ньюкасл?

ГОЛОВНИЙ ВИСНОВОК
Низький код не означає низьку архітектуру.Оскільки рішення Power Platform стають більшими, більш пов'язаними та важливішими для бізнесу, основи інженерії програмного забезпечення залишаються актуальними.Архітектура має значення.Моделювання даних має значення.Управління має значення.Безпека має значення.Дизайн API має значення.DevOps має значення.А успішна корпоративна розробка на Power Platform дедалі більше полягає в розумінні того, як низький код, професійний код, Azure, API, автоматизація та традиційні практики інженерії програмного забезпечення працюють разом.

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