平台主要有解决以下几个：

许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。

▎烟囱式架构

早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。

因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。

分层是指在大的层面上要分好层，基础设施层、OS适配层、数据层、中间件及服务层，核心业务组件层，产品层。一般基础设施层、数据层、中间件和服务层由基础平台提供；核心业务组件层为业务平台提供；产品层由产品研发提供。

模型化分解是指，将现有业务模型化，分解为有限的、核心的、可复用的组件、中间件、系统。

标准化接口协议依赖于模型化分解，能最大程度解决管理成本、维护成本、沟通成本、升级成本的关键，大家基于有限的稳定接口定义开发。模型化和分解的合理性可以最大程度的保证接口的合理性、有限性和稳定性；

另外要聚焦可以被抽象和分解的部分，解决一部分问题而不是所有问题。达成业务组件中间件化。与代码层面的面向接口编程异曲同工。可以参照JDBC和对象存储等中间件的设计。

基于层次划分我们分别建设基础设施的基础平台、以及核心业务的业务平台。

业务平台：聚焦核心中间件和业务组件，不断加强组件能力支撑关键技术能力突破。

每个人心目中的平台都不一样，我们首先需要统一认识。我非常认同一个说法：架构师的根本职责是降低软件产品落地的复杂度问题，而软件产品复杂度的核心就是成本（工作量、复用度、质量、管理成本、维护成本、沟通成本、升级成本）。架构师的精力是有限的，不能事无巨细也不能全都从头建设，所以平台作为工具来降低成本。