定義問題空間
當您開始定義內部開發人員平臺時，必須先定義最精簡可行的平臺 （TVP）。 TVP 是傳統產品管理中最低可行產品 （MVP） 概念的變化。
若要瞭解哪些工作應該是TVP的一部分，最好是使用 平臺工程功能模型來評估貴組織的平臺工程實務。 平臺工程功能模型可讓您查看貴組織目前平臺工程的優勢，並設定未來的目標。
此圖表可協助您針對開發人員平臺如何隨著時間發展而思考。 請記住，由於您現有的投資或組織需求，貴組織的首要問題可能會導致您偏離此處所述的專案。 除非您的組織需要，否則您不需要繼續進入下一個階段。
如果您從頭開始，此序列代表常見的進展。 在早期階段，專注於探索所需的功能、壓縮包裝產品的調整差距分析，以及建立最少數目的工具或平臺功能。 接下來，當您調整規模時，您可能會開始專注於可重複使用性，並引導人們使用可重複使用的資產來降低預先定義的鋪路路徑。 最後，您會轉向消費者般的數位商店模型，以便更輕鬆地建置和維護應用程式。 您應該在整個過程中遵循產品思維，因此不建議跳到結尾，而您的特定旅程會有所不同。 這些最後階段最類似於傳統意義上的壓縮包裝產品，但這是一個目的地，而不是起點。
平臺工程主題領域
假設本主題的大小，建議您將您內部討論平臺工程的方式細分為四個主題領域：
工程系統：精心策劃的DevOps套件組合，例如 GitHub 和 Azure DevOps 和其他開發人員工具和服務。 除了 CI/CD 或套件管理等重要 DevOps 工具和服務之外，此區域也包含直接在程式代碼撰寫程式期間使用的功能，例如雲端式編碼環境、程式代碼掃描器和升階，以及 GitHub Copilot 等 AI 助理。
應用程式平臺：組織想要用來提供商業價值的每個應用程式堆疊（應用程式類別、應用程式模型、語言）的服務（例如 IaaS、PaaS 和可觀察性）的策劃選擇。 這包括混合應用程式堆疊特定服務，以及整個使用的一般服務。 應用程式平臺的範例可能包括 Azure Container Apps、適用於記憶體的 Cosmos DB、適用於秘密的 Azure 金鑰保存庫、身分識別和角色型存取控制、Azure 原則 合規性和稽核、透過 Grafana 的可檢視性，以及相關的網路拓撲。
應用程式範本：一組定義完善的組織所建立的快速入門範本，可封裝正確開始，並針對指定的應用程式平臺、語言和一組工程系統保持正確的指引。 他們可以參考其他集中式範本，並提供入門程序代碼、API 和 SDK 參考、CI/CD 管線、工具設定等等。
開發人員自助功能：這是平臺工程工作的黏附。 它是 API、協調器、目錄、範本和使用者體驗的組合，其設計目的是減少開發人員的辛勞，並允許開發小組自行服務並更具自主性，同時仍堅持前三個領域的選擇和指引/治理。
整合工程系統、應用程式平臺、應用程式範本和開發人員自助功能，是平臺工程策略的基石。 藉由結合DevOps工具、雲端服務和自助功能，組織可以大幅減少開發人員的辛勞、提高生產力，並確保符合治理標準。