必要となる可能性があるサードパーティ コンポーネントを特定する
プロジェクトの実行中に、作業しているアプリが要求を満たすことができないことに気付く場合があります。 その時点で、次の 3 つのオプションがあります。
カスタム - 新しいアプリを作成する
サードパーティ製ソリューションを探す
顧客と協力して、必要なものを要件から除外する
可能な限り、すぐに使用できるソリューションを優先的に使用することをお勧めします。それは、ソリューションのライフサイクル全体にわたってその複雑さを軽減し、ライセンス/メンテナンスのコストが削減されるためです。 このユニットでは、サードパーティ製のソリューションを検討する際の考慮事項について説明します。
サードパーティ製ソリューションの入手先
Microsoft Power Platform および Dynamics 365 アプリと連携するサードパーティ製ソリューション向けの公式の Microsoft アプリ ストアは AppSource です。 独立系ソフトウェア ベンダー (ISV) は、そのソリューションを登録し、認定プロセスを実行して一覧に表示することができます。
ソリューションを調べながら、Microsoft Power Platform アプリと、使用している Dynamics 365 アプリとの統合レベルを検討します。 統合のレベルが低いほど、ソリューションを十分に活用するためにカスタム統合の実行が必要になる可能性が高くなります。
同じソリューション領域で作業するソリューション アーキテクトは、その領域の問題を解決する最も一般的な ISV を知っているはずです。 多くの場合、パートナーは、将来の案件で再利用できる特定の ISV 拡張機能のスキルを開発します。 ソリューション アーキテクトは、その内部評価と選択に頻繁に関与します。
ISV の評価
サードパーティの ISV コンポーネントをソリューション全体の一部として含めることを検討している場合、そのコンポーネントと仕入先の長期的な実行可能性に依存していることを理解する必要があります。 実装が成功するかどうかは、そのコンポーネントがアドバタイズされたものとして機能すること、そうでない場合はコンポーネントがその ISV によってサポートされることにかかっています。 ISV の評価の一環として、次の要素を考慮する必要があります。
ISV が事業を行っていた期間
ISV の規模、および必要な規模の実装をサポートする手段があるかどうか
ISV が Microsoft Power Platform または Dynamics 365 向けに構築している期間
ISV コンポーネントの評価
ISV コンポーネントを評価して、対象とする問題を解決できることを確認する必要があります。 多くの場合、提案されたソリューション設定のコンポーネントを試すまで、その欠点を発見することはできません。 多くの場合、概念実証のアプローチが役に立つ可能性があるケースが該当します。
コンポーネントを評価する際には、次の点を考慮してください。
セキュリティの統合 - コンポーネントが Microsoft Power Platform および Dynamics 365 アプリのセキュリティ モデルで動作するかどうかを判断します。 コンポーネントに別のモデルがある場合は、ソリューションの位置付けを容易に行い、まだ要件を満たすことができるかどうかを評価します。
カスタマイズの柔軟性 - Microsoft Power Platform と Dynamics 365 では、カスタマイズと拡張のための複数のオプションを提供しています。 コンポーネントによって提供されるオプションを検討し、コンポーネントが要件を十分に満たしているかどうかを確認します。
Microsoft リリースを最新状態に維持 - Microsoft は、場合によっては毎週更新し、時にはアプリを最新の状態に保つために古いアプローチを廃止することがあります。 ISV がリリースに対応しているか、および製品でサポートされている技術を使用しているかどうかを評価して、問題がないことを確認します。
ISV ロードマップ - ISV が計画されている機能強化のロードマップを保有しているどうかを判断します。 ISV に機能強化の計画があるかどうか、および製品が "現状のまま" 提供されているかどうかを確認します。
データの場所 - ISV コンポーネントが Microsoft Power Platform および Dynamics 365 アプリと統合されている場合、または独自のクラウドまたはその他のストレージ ソリューションを備えている場合、そのデータが格納される場所を確認します。
ギャップを埋める - チームがコンポーネントをさらにカスタマイズすることを計画している場合、コンポーネントのライセンスでそうしたカスタマイズと追加する技術的負債を考慮に入れていることを確認します。
ライセンスの評価
サードパーティ製コンポーネントをソリューションに取り込む場合は、ライセンスを考慮する必要があります。 ライセンスがプロジェクトの予算に含まれているだけでなく、使用する製品と互換性のある方法で実行されることを確認します。 たとえば、API 呼び出しの数や、ユーザーが対話するその他の方法の制限が、使用量に適していない場合があります。
また、オープン ソースの使用が、ビジネス アプリケーション ソリューションでも一般的になりつつあります。 通常は、自由に使用できるという魅力があります。 ただし、ソリューション アーキテクトは、コンポーネントのライセンス モデルおよび準拠する要件を依然として理解しておく必要があります。 また、多くの場合、顧客とのプロジェクト契約では、オープン ソースがソリューション全体に含まれている場合に、ある程度の承認が規定されることがあります。
サードパーティ製コンポーネントを使用することは、アプリのすぐに使用できる機能のギャップを解決する優れた方法です。 多くの場合、サードパーティ製コンポーネントを使用すると、類似のコンポーネントをカスタムビルドする場合と比較して、時間を節約し、進行中のメンテナンスを最適化することができます。 使用するコンポーネントの評価と選択に最初の時間を費やすことにより、適切でないコンポーネントを選択することから生じる望ましくないプロジェクトの問題を回避できます。
演習: 財務ソリューションに適した AppSource の検討
Woodgrove Bank が大規模なソリューションの市場に参入している場合、他社の取り組みとそれが提案されたソリューションにどのように適合するかを認識する必要があります。 AppSource に移動して、Woodgrove Bank が実行可能なソリューションに迅速に到達するのに役立つパッケージ製品を探します。