平台模型是我们在这个领域看到越来越多的方法，它源于负责产品或服务的端到端交付的产品团队的理念。

如果只应用于单一的产品，或者几个产品，它的效果很好。 但如果有数百种产品或服务，把一个产品团队用于这些产品，对每一个来说都是低效和昂贵的。

想象10个团队，每个团队都有自己的技术栈、工具链和流程。 会一直重复解决类似的问题、花太多的时间来评估技术、集成、维护基础设施等等。 这些时间可以更好地花在建立和改进产品团队负责的实际产品上。  

缺乏标准化的技术和流程也造成其他问题：

●管理变得昂贵，几乎不存在管理
●独立的堆栈减少了整个组织的知识共享
●许多产品团队实际上没有能力来运行完整的基础设施和应用程序。许多开发人员将基础设施操作视为分散他们实际工作的注意力，因此他们从不真正关注它。

虽然拥有多个端到端产品团队并不能很好地跨越大型复杂环境，但由清晰目标、边界和责任定义的平台模型却能做到 一个由用户建立在心中的平台，可以大大减少单个产品团队的辛苦和开销。

广义地说，平台团队提供基础设施、环境、部署管道和其他内部服务，使内部客户（通常是应用程序开发团队）能够构建、部署和运行其应用程序。
Evan Bottcher定义的数字平台在这时可以起作用：“作为一种令人信服的内部产品的自助服务API、工具、服务、知识和支持的基础。自主交付团队可以利用该平台以更快的速度交付产品功能，同时减少协作。”

自助服务是“一个好平台的一个关键特征。具体来说，它应该允许自助服务供应、自助服务配置、自助服务管理和平台功能和资产的运营。”  

平台模型通常与本地云环境相关联，也适用于从古到今的许多其他类型的体系结构。主要优势有：

●应用团队可有更具效率。他们不必是基础设施运维方面的专家，也不必对工具链中的每种工具都有深入的了解，因而他们能够专注于产品。应用程序开发人员不再需要等待集中化的团队来为他们提供测试环境或云资源，而由此产生的自治性使他们能够更快地工作。

●改善管理。如果您的所有应用程序都运行在完全不同的基础架构堆栈上，使用不同的流程，那么您就无法有效地管理成本、遵从性和审计。一个有效的平台能带来高效的IT治理，同时授权应用程序团队快速交付。

●结束环境切换。不断地在应用程序和基础设施操作之间切换注意力是对生产力和创造力的巨大消耗。当个体工人和团队能够专注于自己特定的环境时，他们的境况会更好。

●持续改善基础设施。一个提供面向客户解决方案的公共平台，而不仅仅是对基础设施的原始访问，使组织具有更大的灵活性。平台的消费者不与基础设施堆栈的具体实现挂钩，因此平台团队可以迭代地替换和升级组件，并且只需要与应用程序团队进行最小程度的交互。

内部平台的使用

在对平台的讨论中，我们使用“内部平台”一词来表示由组织和为组织构建的平台。我们将这些平台与外部供应商提供的平台区分开来——例如，许多人认为AWS或其他IaaS产品是 “平台”。在调查中，我们将平台团队定义为那些负责维护其他团队用于构建和交付应用程序或服务的自助服务平台的团队。

我们提出了两个问题来衡量一个组织对内部平台的使用：
• 您的开发人员使用自助服务平台的百分比是多少？

• 哪些服务可供自助服务？

我们发现平台的使用在调查受访者中非常广泛。百分之六十三的人说他们至少有一个自助内部平台。 在拥有内部平台的人中，60%的人在拥有二到四个平台之间。在拥有内部平台的公司中，几乎有三分之一的公司有26%至50%的开发者使用该平台。