問題領域を定義する

内部開発者プラットフォームの定義に向かう前に、最 も薄い実行可能プラットフォーム (TVP) を最初に定義することが重要です。 これは、従来の製品管理における 実用最小限の製品 (MVP) のアイデアのバリエーションです。

「 計画と優先順位付け」では、TVP の定義 (または強化) の詳細を確認できます。 しかし、この図は、時間の経過と共に進化する方法について考え方を変えるのに役立ちます。 organizationの主な問題により、既存の投資や組織のニーズにより、ここで説明されているものから逸脱する可能性があることに注意してください。 重要なのは、organizationに必要な場合を除き、次のステージに進む必要はありません。

ゼロから始める場合、これは一般的な進行を表します。 初期段階では、必要な機能の検出、圧縮ラップされた製品のフィットギャップ分析、最小数のツールまたはプラットフォーム機能の作成に重点を置きます。 次に、スケーリングを行うにつれて、再利用性に焦点を当て始め、再利用可能な資産を使用して事前に定義された舗装されたパスをユーザーに誘導します。 最後に、アプリケーションの構築と保守を容易にするために、コンシューマーのような "デジタル ストア" モデルに移行します。 製品の考え方に従う必要があるため、最後にジャンプすることはお勧めしません。具体的な取り組みも異なります。 これらの最終段階は、従来の意味では圧縮ラップされた "製品" に最も似ていますが、これは出発点ではなく目的地です。

このトピックのサイズが非常に大きい場合は、プラットフォーム エンジニアリングについて話す方法を 4 つのトピック領域に分割することをお勧めします。 このように考え方を分類すると、時間の経過に伴う投資の計画を立て、伝える方法を簡略化できます。 これらの領域は次のとおりです。

• エンジニアリング システム: GitHub や Azure DevOps などの DevOps スイートと、その他の開発者ツールとサービスが組み合わせてキュレーションされています。 CI/CD やパッケージ管理などの重要な DevOps ツールやサービス以外にも、この領域には、クラウドベースのコーディング環境、コード スキャナーとリットル、GitHub Copilotなどの AI アシスタントなどのコーディング プロセス中に直接使用される機能も含まれています。
• アプリケーション プラットフォーム: organizationがビジネス価値を提供するために使用する各 "アプリ スタック" (アプリケーション、アプリ モデル、言語のクラス) を対象とする、キュレーションされたサービス (IaaS、PaaS、可観測性など) の選択。 これには、アプリ スタック固有のサービスと、全体で使用される一般的なサービスの組み合わせが含まれます。 アプリケーション プラットフォームの例としては、Azure Container Apps、ストレージ用 Cosmos DB、シークレット用の Azure Key Vault、ID とロールベースのアクセス制御、コンプライアンスと監査のAzure Policy、Grafana による可観測性、関連するネットワーク トポロジなどがあります。
• アプリケーション テンプレート: 適切に定義された、organization作成されたクイック スタート テンプレートのセット。このテンプレートは、開始を適切にカプセル化し、特定のアプリケーション プラットフォーム、言語、一連のエンジニアリング システムに対して適切なガイダンスを維持します。 他の一元化されたテンプレートを参照し、スターター コード、API と SDK の参照、CI/CD パイプライン、ツール構成などを提供できます。
• 開発者のセルフサービス機能: これは、プラットフォーム エンジニアリング作業の接着剤です。 これは、API、オーケストレーター、カタログ、テンプレート、およびユーザー エクスペリエンスの組み合わせであり、開発者の手間を軽減し、開発チームがセルフサービスで自律的な状態を維持しながら、前の 3 つの領域からの選択とガイダンス/ガバナンスに準拠できるように設計されています。

計画と優先順位付け