中台团队是一个共享服务团队，与前台（业务开发方）是服务与被服务的关系。一个庞大的中台规划因为其长期性和复杂性，很难在短期内满足前台的业务需求，中台团队也很可能因为要服务于多个前台业务而出现资源竞争的矛盾。而我们的中台是以类似拼图的方式逐渐积累而成，现做现用，能快速响应前台业务方需求。与阿里这种大厂打造的有成百上千人员规模的中台团队来说，我们这种小快灵的精英特种部队机动灵活，打一枪换一个地方（做完一个中台项目再做别的项目），具有先天的优势，且构建成本极低，是最适合中小型企业的构建方式。
分析业务，设计功能明确需求之后，就可以进入当前议题的设计阶段。和任何软件开发流程一样，设计是不可或缺的阶段，作为需求和实现之间的桥梁，它将业务建模转变为技术方案，并保证实施的正确性。对于中台来说，设计阶段的内容又有其特殊的地方：就是通过对各个领域的业务进行分析，寻找出可以抽象的共性能力。因为中台要服务的是多个前台业务线，必须要对整体业务进行分析并找到通用的部分，才能满足复用这一核心价值。如果仅仅是从单一业务出发，只满足当前需求，就等于为当前的微服务实现了它独有的业务逻辑而已。
为避免出现这种问题，在议题分析阶段，我们会通过头脑风暴的方式进行思维碰撞，当某一个人在描述自己的需求时，具有相同或相似痛点的人也会产生共鸣，并提出自己的补充观点，最终整合出一个既满足通用需求，又满足特性需求的技术解决方案。举例来说，我们开发的 Job 中间件是一个基于 Golang 和 Redis 的轻量级定时任务系统，除了具备最基本的定时任务功能外，还根据客户的需求做了个性化扩展。比如“Dynamic Cron”功能支持客户在任务运行期间动态的修改执行周期；“Hook”功能可以让客户定制任务执行后的回调流程，比如调用三方接口，将执行结果发送邮件，或是上传到 AWS S3 等，对个性化的业务操作做到即插即用。目前 Order、Forecast、Partner、Inventory 等服务都接入了 Job 系统，满足了各业务线复用的需求。
需要指出的是，所谓的共性能力包括业务数据、业务功能以及通用的技术能力。比如 Placement（广告位）就是一个几乎被各个业务都使用到的业务数据，同时它又具有一定的变体，在广告预测（Forecast）业务中它会具有额外的预测属性，在合作方（Partner）业务中它又会具有中间商相关属性。它们都共享 Placement 的基本数据同时又具有自己的特殊字段。对于这样的情况我们会把对核心数据模型的操作抽象出来作为模板方法，各业务在此基础上做个性化定制。
对通用技术能力的抽象也有很多例子。比如为了更方便的开发一个新的微服务，我们设计了一套轻量级的服务通信层框架，新服务只需要实现应用初始化接口（AppInitializer），并在配置文件中定义好对应的端口号，就可以实现一个同时支持 HTTP 和 gRPC 协议的 Web 服务器，并可以在 ServerOption 中添加中台里实现的各种拦截器，完成追踪、请求日志、API 权限控制等一系列服务治理功能。而新服务的开发者只需要在标准的 protobuf 文件中定义自己的业务接口并实现即可。
总的来说，在设计阶段的主要工作就是首先对识别的痛点做根因分析，再基于多个业务线进行领域分析，讨论业务的重合度，并抽象出共性业务，引入中台架构并制定出相应的解决方案。
在实现阶段我们采用了精益创业中的 MVP（Minimum Viable Product）原则。MVP 即最小价值化产品策略，是指开发团队通过提供最小化可行性产品，获得用户反馈，并在其基础上持续的快速迭代，最终让产品达到一个稳定完善的形态。下图是一个经典的 MVP 示例，产品的愿景是开发一种交通工具，可以将用户从 A 点带到 B 点。使用 MVP 设计的产品一直遵循着产品的核心价值，即运输能力，从一辆简单的滑板车开始，逐步演进，最终完成了汽车的制造。在任何一个迭代阶段，产品都是可用的且能满足客户需求。而没有遵循 MVP 的实现方式就犯了眼高手低的错误，从一开始就设计了一辆汽车但只能提供轮子，其结果就是在大部分迭代阶段都不可用，也无法得到用户反馈，最终很可能会偏离设计目标，与用户的需求不符。
