Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

Microsoft Power Platform は、しばしばローコードプラットフォームとして説明されます。しかし、構築したアプリケーションがビジネスクリティカルで、高度に統合され、単純なメーカー中心のアプローチでは扱いきれないほど複雑になったらどうなるでしょうか?今回の M365 FM のエピソードでは、Mirko Peters が Power Platform ソリューションアーキテクトの Ian Tweedie と対談し、Power Platform が単純なローコードアプリケーションの域を超えて、本格的なエンタープライズアーキテクチャの一部になったときに何が起こるのかを語ります。

ローコードはローアーキテクチャを意味しない
Power Platform は迅速に多くのビジネス価値を生み出せますが、エンタープライズソリューションには標準的なローコード機能を超える要件がほぼ必ず含まれます。Ian は、ローコードをノーコードと混同すべきではない理由と、Power Apps、Power Automate、Dataverse、カスタムコネクタ、API、Azure サービスで構築する際にも従来のソフトウェアアーキテクチャの原則が重要であり続ける理由を説明します。

Power Platform がエンタープライズソフトウェアになるとき
「ローコード」と「エンタープライズ」の間に明確な境界線があるとは限りません。アプリケーションが複数のユーザージャーニー、開発チーム、統合、セキュリティ要件、ビジネスクリティカルなプロセス、相互接続されたサービスを含むようになると、複雑さは増していきます。その時点でアーキテクチャは不可欠になります。Ian は、1 つの大きな相互接続アプリケーションにするのではなく、明確に定義された機能とモジュールに分割し、クリーンなインターフェースを持たせるべき理由を説明します。

「もぐらたたき」型の開発問題からの脱却
1 つのバグを修正すると、別の場所で別のバグが現れる。このおなじみの開発上の問題は、多くの場合、密結合したアーキテクチャの症状です。Ian は、モジュール設計によって機能を分離し、意図しない依存関係を減らせる仕組みを説明します。メール配信を例に、業務プロセスと配信メカニズムを分離することで、アプリケーションのテスト、保守、置き換え、スケーリングが容易になることを示します。

ローコード + プロコード = ハイブリッドアーキテクチャ
Power Platform は従来のソフトウェア開発と競合する必要はありません。Power Apps のフロントエンドは、Azure、AWS、GCP、API、カスタムサービスを使ったより大規模なアプリケーションのごく一部にすぎない場合があります。重要なアーキテクチャ上の問いは、何が「ローコード」か「プロコード」かではなく、各機能にどの技術が最も適しているかです。

市民開発者、メーカーとアーキテクチャ
市民開発者は非常に価値のあるものをもたらします。それは、日々扱っている業務プロセスについての深い知識です。しかし、業務の専門性が自動的に良いアプリケーションアーキテクチャに結びつくわけではありません。Ian は、メーカーに権限を与えることと、ソリューションが保守困難になるのを防ぐための十分なアーキテクチャ、ガバナンス、正規化、技術レビューを導入することのバランスについて議論します。

イノベーションを阻害しないガバナンス
ガバナンスが少なすぎると混乱を招きます。多すぎると摩擦が生じ、従業員はサポートされていない回避策、スプレッドシート、VBA、シャドー IT へと向かいがちです。課題は、組織のリスク、アプリケーションの重要度、ユーザー、ビジネスへの影響に基づいて、適切なガバナンスのレベルを見つけることです。

Power Platform、API と Azure
ビジネスロジックはどこに置くべきでしょうか?シークレットは Power Platform 内に保存すべきでしょうか?Azure Key Vault、Azure Functions、API Management はいつアーキテクチャの一部になるべきでしょうか?Ian は、利用可能だからという理由で Azure サービスを追加するのではなく、アーキテクチャは常に解決すべき課題から始めるべき理由を説明します。

Git、ソース管理と CI/CD
Power Platform の開発が共同作業化するにつれ、従来の開発手法はますます重要になります。この対談では、Git、リポジトリ、開発環境、パイプライン、ソース管理、機能の分離、相互依存関係、CI/CD を取り上げます。Power Platform におけるソース管理には、常に完璧なアプローチがあるとは限りません。時にはプロジェクトにとって「最もましな選択肢」を選ぶことが目標になります。

Ian の Power Platform アーキテクチャ・プレイブック
Ian の中核となる原則は明快です。ソリューションを機能とモジュールに分割すること。各機能には存在する明確な理由があり、理想的には 1 つの特定の責務を果たすべきです。そのうえで、機能同士がどのように通信するか、ロジックをどこで実行すべきか、どのようにテストすべきか、そしてどの技術がそれを実装するのに最も適しているかを決定します。

ラピッドファイア・ラウンド
Mirko は Ian に一連のクイックな質問を投げかけます。すべてのエンタープライズアプリケーションで Dataverse を使うべきか?Power Platform はミッションクリティカルなアプリケーションを構築できるか?Power Automate は Logic Apps を置き換えられるか?ローコードは自動的に技術的負債を減らすか?Power Platform は従来のアプリケーション開発を置き換えられるか?そして、おそらく最も重要なのは、Newcastle を訪れたら何を注文すべきか?

重要なポイント
ローコードはローアーキテクチャを意味しません。Power Platform のソリューションが大きく、より接続され、ビジネスにとってより重要になるにつれ、ソフトウェアエンジニアリングの基本は引き続き関連性を持ちます。アーキテクチャは重要です。データモデリングは重要です。ガバナンスは重要です。セキュリティは重要です。API 設計は重要です。DevOps は重要です。そして、成功するエンタープライズ Power Platform 開発とは、ローコード、プロコード、Azure、API、自動化、従来のソフトウェアエンジニアリングの手法がどのように連携するかを理解することにますますかかっています。

このポッドキャストのサポーターになる: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.