不同的人对术语“ 软件平台”提出了不同的定义。 让我简要地分享一下我的观点：我将这样一个平台视为几个产品使用的软件资产的集合，如下图所示。
在上图中，产品A，B和C构建在平台上并使用其资产。 换句话说，该平台提供三种不同的产品。
让我们来看两个成功的软件平台示例，即syngo和Amazon Web Services（AWS）。 前者是一个平台，用于标准化如何在MRI和CT扫描仪以及其他Siemens Healthcare产品之间读取，存储和共享医学图像。 后者提供基于云的服务，可以在其上构建其他产品，例如Netflix的视频流 。 在这两种情况下，一系列产品都可以利用每个平台提供的服务。
平台具有以下优点：它们可以帮助更快，更便宜地增长产品组合，还可以帮助增加收入。 例如，以Microsoft Office为例。 如果开发不同应用程序的团队都创建了自己的用户界面层，则将有大量的代码重复，增加了开发成本，并增加了开发时间。
一个标准化用户交互并提供其他共享服务（例如保存和打开文件）的软件平台可以避免这些问题，并使应用程序开发团队可以专注于创建特定于应用程序的功能，而不必开发基础结构代码。
此外，例如，与Amazon Marketplace一样，向其他公司开放平台可以创造新的收入来源并帮助业务多元化。 以亚马逊为例，该平台使第三方卖家可以与亚马逊产品一起出售产品，而亚马逊为每次第三方销售收取费用。
但是平台具有潜在的弊端。 我已经看到，随着时间的流逝，软件平台变得如此强大，强大，以致成为瓶颈，并减慢了面向最终用户的产品提供新功能和增强功能的速度。 我还目睹了一个全新的平台被淘汰，因为它使用起来过于复杂，并且不能满足应该使用该平台的开发团队的需求。
如这些示例所示，值得仔细考虑一个平台是否可以使您的业务受益，深思熟虑地构建它并仔细管理它。
虽然软件平台是一项技术，但就我而言，将其视为一种产品本身仍然是有益的，尽管这是技术性的：它通过使产品开发团队更轻松，更快速地构建自己的产品来为产品开发团队创造价值。产品，并通过降低成本，加快开发速度和增加收入为企业创造价值。 因此，一个平台应该具有自己的产品策略和路线图 ， KPI ， 产品积压 ，以及利用正确技术的精心设计的软件体系结构。
但是，请确保平台决策受其服务产品的需求指导。 毕竟，有一个平台可以帮助团队更快，更便宜地开发更好的产品。 换句话说，平台策略和路线图应从基于其构建的产品的策略和路线图中获得，并且其架构应设计为尽可能简化其服务的使用。
因此，一个软件平台不只是一组API。 它通常需要说明如何使用平台资产的文档。 此外，它可能需要工具来允许团队根据平台API进行编码。 在撰写本文时，AWS附带了一个云开发工具包，该工具包支持.NET和Java，并与不同的IDE集成，因此支持开发人员开发基于AWS的应用程序。
如果我们将平台本身视为产品，那么应该有明确的所有权和平台所有者 ，即管理平台并确保其创造所需价值的个人，如下图所示。
由于软件平台是技术支持产品，因此我建议寻找具有强大技术背景的高级开发人员或软件架构师，他们可以与产品开发团队的成员进行交谈，了解他们的需求并同情最终目标。用户，具体取决于软件平台的性质。 （对于提供面向最终用户的服务的平台，这当然是正确的。）
同时，该人员应具有必要的产品管理技能，以专业地管理平台，并确保该平台对用户（使用其API的产品开发团队）和企业发挥出色的作用。 我的一位客户是游戏开发公司，成功地采用了这种方法来管理其关键平台产品之一。
最后但并非最不重要的一点是，平台所有者还必须与管理在平台顶部构建的产品的个人一起工作（上图中的产品所有者 A，B和C），以了解他们的策略和路线图并讨论需要满足的需求发生冲突时优先考虑。
创建软件平台是一项新产品开发（NPD）的工作，应进行相应的管理。 如果您采用现有代码并将其封装在平台中，则也是如此，因为这通常需要更改或重写软件并找到有效的平台体系结构。
因此，我建议构建最小可行的平台 ，最适合少数产品。 这样，您就可以比较快速地获得第一个版本，并使它适应用户（产品开发团队）的反馈。 像其他NPD计划一样，您当然应该在开发平台时对其进行验证，例如，通过向产品开发团队公开新的或更改的API的早期版本，并要求他们针对它们进行编码。 但是，与其他新产品一样，您可能会发现只有认真使用该平台并且这些产品开始使用其资产后，平台才能发挥良好的功能。
一旦证明该平台在少量产品上能发挥出色的作用，就可以开始扩展其服务并提供其他产品。 这避免了前面提到的潜在缺点之一：启动一个过于宏大的软件平台，该平台太难使用了，可悲的是，我不止一次看到这种情况。
技术产品（如软件平台）具有阴暗面：由于它们是由专业团队开发的，因此最终可能会导致过度设计和过于复杂。 在最坏的情况下，平台可以很好地运行，但是对其进行编码很痛苦，并且产品和平台的整体性能很差。
有两种技术可以帮助您减轻这些风险：
- 通过为平台开发团队配备产品开发团队的成员来开始开发新平台。
- 使用将要用于面向最终用户的产品的解决方案验证技术，例如，产品开发团队成员参加的sprint审查会议以及开发团队成员测试的新的或增强的平台服务的早期发布 。
我已经成功地使用了这两种技术来开发新的telco软件平台 ，在这里我们由最初打算使用该平台的各种产品开发团队组成了最初的平台开发团队。 这确保了该平台在其所服务的产品方面做得很好，并且增加了产品开发团队的认可度。
我曾经与一个使用软件平台的组织合作，该组织如此成功以至于它变得越来越大：随着时间的推移，它提供越来越多的产品，并且提供越来越多的服务。 最初看起来像是一个惊人的成功故事，后来演变成一个艰难的经历：随着越来越多的产品争相使用平台资源，该平台开始放慢创收产品发布新功能和增强功能的速度。 该平台已成为瓶颈。
因此，我建议您仔细管理平台的增长。 在某些情况下，如果这可以帮助产品开发团队更快地推出新功能并为用户和企业创造理想的价值，最好接受一些代码重复。 或者，考虑分解软件平台并提供分别服务于一组客户端的平台变体，例如，存储平台和媒体服务平台。
与其他产品一样， 定期检查平台的性能并对其战略和路线图进行必要的更改。
翻译自: https://www.javacodegeeks.com/2020/03/leveraging-software-platforms.html