概述
通常围绕平台开发难题比其它项目更为复杂。需要开发人员更多的战略性思维。花时间培养合适的团队，对于实现高质量的可利用代码是至关重要的。
问题点
开发
- 是否使用外包商。外包商可能更快的交付项目，但其成本很高，且有质量上损失的缺点。要依据情况作出正确的选择。
- 是否有在组织内部展示新技术来吸引顶级人才的手段
- 如何管理功能开发需求。沉重的需求可能导致缺乏开发资源，而使平台采用速度降低。也可能是成功的推销了平台，但是没有覆盖足够核心的功能的所有特性。对于这些问题，我们应该有一个整体的架构路线图，此举将让你的合作伙伴感觉到他们何时能够加入平台，以及加入平台涉及的成本。
- 开发人员是否清晰地理解你所寻求交付的服务质量。在开发人员的思维体系中是否有通过工具或团队中是否有标准来，全面的用于监控、配置和部署的运营工具来保证质量。
- 如何管理操作系统、JVM配置和其它工具或者服务。平台的文档管理水平可能高于典型的软件的文档管理水平。运行时和其它运营需求的正确文档，可能使新功能的投产变成简单的过程。
- 从现有应用程序迁移到平台应尽量对客户的影响最小
- 何时进行技术更新，应该在技术发展时保持相对的水平，保证平台的适用性，避免萎缩。重要的是，以最小化干扰、不放弃当前客户的方式更新技术。
- 考虑技术许可成本
- 部署成本考虑，云服务还是物理服务器上
认知与平台相关的成本
开发平台是有趣、激动人心的工作。然而，开发、维护成本高于其它项目。 由于使用平台的一组应用程序对平台有共同的依赖性，如果出现某问题，风险就会加大。如果应用程序没有进行正确的管理，他们也可能相互影响。
平台提出一个承诺：他们可以创建一个环节，显著减少开发应用程序的时间和精力，分担管理运营相关的成本。使用平台的业务单位可以将投资用于其他领域。由于平台的多维度特性，确定实际成本、成本节约、降低风险、提高产品的周转率以及可度量的正面利益（包括可归属收入）可能非常困难。
管理平台质量
平台质量直接与以下因素相关
- 专注功能之间的低耦合度
- 以高代码覆盖率为目标。专注于系统的错误路径，程序主逻辑能够自己照顾自己。
- 鼓励高级别模拟。这将有助于将测试集中在被测试的类上，而非其依赖性-包括其它类和数据库访问等费时的资源。
- 管理技术债务。如果有每个人都害怕的代码区域，删除它们；它们将在系统的那些领域导致混乱，使每个人都自然的想要绕开。
- 进行各种不同的测试（功能、规模、特别、自动、端到端和用户测试）。
- 确定向后兼容性的时限。如果将向后兼容性扩展到很长的时间，会增加代码库的复杂性；而如果不扩展，可能就要迫使客户在不合适的事点上应对变化。
- 对数据库和数据模型的变化保持谨慎。
平台集成
理解其它人与你的平台集成的愿望，有助于确定你的结构特征和访问点。故而在平台集成方面，必须考虑以下几点。
- 明确定义架构栈中的可访问点。在架构中定义访问点，可以帮助你的客户理解他们与平台集成的方法。
- 提供多重接入方式。根据不同等级客户的需要，可以分别提供可以快速配置，简单实用的功能；也可以提供服务接口，让用户自己决定如何嵌入自己的应用。提供不同的利用水平，将使你的平台对更广泛的潜在客户产生吸引力，但也有可能导致客户对应该利用的功能产生困惑。
- 通过利用其它平台已有的能力，减少拥有成本。
- 尽量使用公共资源，并实现清晰地集成。平台可能还应该有模块或组件的概念，可以让客户利用平台的最小单元，而无需消费整个平台，且每项功能和平台其它功能之间的耦合度越低，就会产生越多的正交开发和增长。否则，平台将逐步萎缩。
- 在将应用合并为平台时，应首先规划合并线路图，明确的表示如何合并应用程序，业务模型。路线图有助于缓解每个人对时机的担忧，有助于识别潜藏的问题。
- 定义接口的同步与异步。其它人与平台的继承方式，使用同步、交互性的方式还是面向大批量操作的方式可能对系统的伸缩性产生大量的影响。
- 确定系统是否需要提供移动端，如果提供移动端是提供简单的移动web还是原生应用程序。
指导原则
坚持指导原则，有助于确立稳固的平台，并在整个生命周期加以扩展。
追求质量的卓越
平台内部体现的利用和重用特性推动了比典型应用高得多的质量水平。平台广泛多样的使用方法在许多不同方面造成压力，从而需要高质量的代码和高质量的自动测试，以确保新功能的稳定和平台中不会有意外的更改，影响依赖其稳定性的人们。一般来说这使平台代码的开发工作更加昂贵，而且凸显了将重点仅放在被反复利用的那些功能上的必要性。
追求卓越运营
多租户平台的运营要求通常复杂的多。确保安全性、监管和隐私关注点得到处理的能力是平台环境中的筹码。花时间购买和开发合适的运营工具，以便：
- 确保平台运营中有成长规划所必须的深刻见解
- 诊断特定客户问题
- 检测安全漏洞
- 故障检测
- 在资源接近临界水平（如存储满）时发出警报
- 启用动态功能访问和控制
- 为平台配备合适的运营工具，可以是显著的增长变得可行且持续
追求可配置性
在平台代码开发中，在平台中添加分支逻辑以选择要执行的代码是很简单的。尽管这是一种权宜之计，但是增加了整体代码库的脆弱性。花时间学习如何通过外部配置、控制反转或者动态运营来实现相同的行为。
如果你引入了技术债务，就要加以跟踪，并创建故事，快速的处理它们。如果你不保持控制，技术债务可能显著地降低未来的开发速度。
追求可重用性
平台的开发必须支持广泛的用例和最大数量的合作伙伴。在平台上添加特定于合作伙伴的代码会稀释平台的总体价值。解决方法之一是与客户成为合作伙伴，得到新功能请求并归纳他们的请求。这能使功能更广泛适用，实现你为平台追求的利用机会。
追求冗余架构
平台应该内建多级冗余，以实现伸缩、可用性和可靠性。这包括有多个物理位置、适用集群技术、适用附近存储的缓冲、建立备份，并使用其他方法，实现关键组件失效时，整体系统可以继续工作，将干扰降低到最小限度。冗余性通常更适合水平扩展方法而非垂直扩展的方法。
追求线性的伸缩性
平台必须能够线性伸缩，确保平台流行时添加新用户的成本不会变得奇高。确保这一点的最佳方法之一是定期进行伸缩测试，随时监控系统中的关键指标，确保伸缩性不会随着系统中添加新功能而降级。
平台耦合
平台的每次更改可能造成平台内部产生更紧密的耦合。在引入更改时，花时间重构代码库和架构，以反映新的业务方向。平台必须进行更改，才能成长并保持关键性。
避免平台蔓延
在平台生命期中间，你很可能接受所有新开发项目。用于拒绝对添加不能清晰地与平台保持一致的功能，将有助于延长平台的寿命和实用性，而不会稀释它的核心目的。
坚持升级到最新技术
将保持平台使用最新技术的投资减少到最低限度是杀死一个平台最好的办法。平台和其它系统一样，必须在每一年或者半年中对其进行升级，因为技术会逐渐失宠，被更新、更好的方法及技术被取代。这应该采取滚动的方式进行，而不是“大爆炸”的方式。
总结
平台的开发之路从如下工作开始：
管理平台功能
- 定义平台目标集
- 定义平台功能集
- 专注于可利用的功能
- 开发强大的概念模型
- 以API、配置和时间处理作为平台的钥匙
专注于平台生态系统
- 了解平台用户
- 理解平台所有权
- 理解平台管理
- 推动平台开发
- 认识平台成本
- 管理平台质量
- 理解平台集成
通过原则指导平台成长
通过架构的角度开发平台时具有挑战性且充满趣味的，必须不断地进行客户互动学习，这使每天的工作变得激动人心。
引用
- 《软件架构师的12项修炼：技术技能篇/（美）Hendricksen,D.著；姚军译.-北京：机械工业出版社，2016.06》