通过Mia-Platform的这款类似游戏的新型研讨会，组织内的利益相关者可以共同决定其内部开发者平台应该做什么。
译自 Platform Engineering: A Workshop to Help Map Your Strategy，作者 Jennifer Riggins。
Graziano Casto，Mia-Platform的开发人员关系工程师，他提供了自己对平台工程的定义：“平台是人们共享价值的地方。”
他敦促我们思考创建内部开发者平台（IDP）背后的策略。“因为当我们与开发者或技术人员谈论平台工程时，他们想到的是技术方面的东西，”他在10月份在伦敦举行的Kubernetes社区日英国会议上告诉The New Stack。“我们想要揭示公司必须采取的战略路径来构建自己的IDP。”
随着各组织争相采用 IDP 战略，他们往往关注的是什么——共享库、规则、基础设施、合规性、安全性——但并不总是停下来思考为什么。如果平台工程团队想要创建一个长期为开发者服务的平台，就必须将来自组织各方的利益相关者聚集在一起。
Mia-Platform 创建了其平台旅程图研讨会，以帮助团队找到一种共同语言来讨论平台工程的目标。该研讨会汇集了产品、技术和人员，并创建了一些内容供团队的内部开发者平台成熟时重新审视。
许多组织都陷入了将平台工程视为使用平台来告诉开发者该做什么的误区。实际上，情况恰恰相反。你必须构建开发者想要使用的工具。
“当你想到现在的平台时，你会想到一些管理DevOps和基础设施的东西，”说。但根据他与客户的经验，“公司通过尝试为开发者提供自助服务能力的工具来开展平台工程。”
然而，当你深入平台这个兔子洞时，你总是希望集成越来越多的东西。这可能是基础设施——他表示这通常是最容易集成的东西。然后，不同的利益相关者希望扩展 IDP 以集成数据，包括数据管道、目录和治理，这随后需要安全性和合规性。
到目前为止，这个定义可能是自科技行业诞生以来就存在的平台的传统描述。根据所说的，内部开发者平台与那些传统的自上而下的平台的区别在于，当一个组织达到一定的技术成熟度，并希望将平台用作组合能力的推动者时。
“多年来，他们构建了一些他们想要隔离并可以重复使用的东西，以构建其他东西并加快上市时间，从而推出新产品，”他说。这就是 Mia-Platform 创建平台旅程图研讨会作为其与客户合作的启动方式的原因。
解锁你的平台工程战略的关键不是什么，而是如何和为什么。
“我们创建的游戏是一个头脑风暴工具，用于协调技术人员与业务，”说，让他们讨论“整合技术和实现业务战略愿景的最佳策略”。
尽管看起来像游戏，但平台旅程图并不一定像传统棋盘游戏那样进行。说，它更像是一个概念图，“主要设计为讨论和比较的工具，有助于定义战略的范围”。
但如果你顺时针阅读棋盘，它会按照平台成熟度的方向流动，促进围绕以下主题的讨论：
- 基础设施现代化、软件交付效率、运行时优化。
- API 平台、微服务转型、遗留系统现代化、集成模式、演进式架构、数据产品。
- 基础设施和 DevOps 编排、环境即服务、模板和铺设道路、平台即产品、指标和可观测性以及团队拓扑结构
- 打包的业务能力；内部开发者门户和软件目录、微前端、应用组合、低代码和无代码治理
- 全渠道体验、软件即服务和平台业务、开放式X和嵌入式服务。
并非所有组织都会沿着这条路径一直走到外部公开平台功能。但大多数组织可能已经开始在云中构建并将其治理应用于软件开发生命周期。
并且，由于这是开发者使用内部开发者平台的首选方式，基于API的接口也应该是平台路线图的早期组成部分。治理也应该尽早且经常被考虑。
有趣的是，这个平台旅程游戏直到大约三分之一的路程才真正涉及平台工程。Casto认为，在定义了治理和软件生命周期之前，你无法真正拥抱平台工程。只有这样，你才能考虑如何以可发现和可组合的方式提供这些业务和技术能力。
最后，当探索游戏板时，他强调没有一条线性路径需要你的棋子遵循每一步：“相反，把它想象成一张地图，你只需要关注你认为的真正优先事项。”
当然，这些会随着时间的推移而改变。
平台工程的挑战之一是，由于每个技术组织都不同，其平台策略也会不同。这就是为什么研讨会从每个参与者群体中引发不同讨论的原因。
Mia-Platform 的研讨会让与会者使用真实案例进行工作，每个案例都包括：
- 公司身份识别信息。
- 公司旨在实现的目标。
- 公司当前的技术环境。
每个参与者的研讨会角色是：
- 在平台旅程图上确定他们的优先级。（15分钟。）
- 基于这些优先级定义采用策略。（15分钟。）
- 确定衡量成功的 KPI。（10分钟。）
- 分享他们高级别的战略计划。（4分钟。）
一个身份识别信息示例是一家零售公司，它有一个小型工程团队支持线上和线下合作伙伴，在美国和欧洲市场都有接触点。每个合作伙伴独立选择其技术栈，这导致代码质量不一致且低下。该公司还担心供应商锁定。
该平台既定的最终目标是利用 API 为所有合作伙伴提供标准化的用户体验，并提供一个自助服务、可发现的界面，以减少小型 IT 团队的负担。
当你想要创建一个平台工程策略时，你可能已经知道你公司的目标、目标和技术栈——但把它写下来是启动你自己的研讨会的好方法，以便让所有相关人员都清楚。
根据研讨会规模，分成更小的组，而研讨会主持人则充当利益相关者，包括开发人员和高管。然后使用这个棋盘游戏作为头脑风暴工具来确定优先级。这些可能包括：
- 作为起点，参与者必须构建一个 API 平台，以对现有的 API 层进行治理。
- 为了构建自助服务功能，小组成员需要添加基础设施和 DevOps 自动化，并考虑模板和开发者的“铺设道路”。
- 参与者的平台即产品策略会是什么样的？
鼓励参与研讨会的不同团队互相挑战。
“你必须向我解释你的策略，”Casto 说。“想象一下，我是一个技术人员，所以你可以和我谈论Crossplane，但我不知道我的 CEO 是否能理解这一点。” 研讨会鼓励与会者合作制定策略，然后再委任平台负责人组建平台团队来执行该策略。在组织内部，研讨会确保每个人都知道谁拥有哪些能力，从而帮助确定平台工程师的最佳人选。该角色必须兼顾技术和业务目标。
这条平台旅程应考虑预算和交付时间等限制——这是自建与购买之争中最大的因素。
Casto说：“假设你想在六个月内完成这个目标，所以你必须明白哪种方案更好。然后，[团队]制定策略来了解哪些是优先事项，并定义权力角色。”
回到零售的例子，一个合作伙伴是绿地合作伙伴，而其他合作伙伴是棕地合作伙伴——团队必须决定首先与谁集成。
Casto说：“对我来说，最后也是最重要的一点是，要了解如何衡量你的采用成功率”，因为衡量平台工程是一个常见的难题，但你无法改进你无法衡量的东西。
“重要的是要衡量你为组织带来的价值，以及如何利用这些数据来发现未来增加平台价值的机会。”
对于每个优先事项，研讨会与会者需要选择KPI，并将他们的用例和目标向其他利益相关者推介。
内部开发者平台就是这样一种平台，你可以不断在其之上构建和迭代。同样，组织也应该反复运行平台旅程图研讨会，因为利益相关者的需求会发生变化。
Casto说：“我们与客户定期举行活动，利用这个工具了解他们的采用情况以及我们有哪些机会将他们的平台提升到一个新的水平。”
根据你的组织调整研讨会，并且可以随意跳过第一次循环中的单元格。Casto说，平均而言，他发现围绕地图的第一圈——或平台路线图的第一次主要交付——需要六到八个月的时间。
他强调说：“单元格并非严格定义。它只是一个工具，用于促进与客户、同行和解决方案架构师的讨论。”
Casto说，平台旅程图旨在补充，而不是取代云原生计算基金会的平台工程成熟度模型。Casto说，CNCF模型旨在挑战平台团队，而地图练习旨在协调所有利益相关者。
大约一年前开发了这个游戏，因为Mia-Platform的解决方案架构师发现很难向客户解释内部开发者平台的采用历程。
Casto说：“解释一些视觉化内容要容易得多。”由于平台旅程图使IDP策略讨论游戏化，它促进了头脑风暴，以便“指导你或你的客户的路径，而不会强迫他们说出他们不想说的话。”
另请阅读：如何举办你自己的平台即产品研讨会