业务始于中台

用户体验大火之后，尤其是App形式已经变得深得人心，提到一个业务功能，首先想到的是：App如何和用户交互。当大家争论用户交互细节时，没人关心用户是否需要，还为这个做法找了个理由：用户不会说出自己想要什么，只有把产品拿到用户面前才知道。
这种情况下，前端会被大致确定下来，开发过程中缺少哪个接口就向后端要。后端可能有个差不多的，就让前端自己适配将就一下，如果没有则会协商一个。

产品很快做出来了，被拿到了用户面前，大家都很兴奋地收到了用户反馈。于是乎，一轮一轮的修改开始了。此时，大家预期的很快改完上线，即快速迭代，和开发迟迟不能完成，形成了最大矛盾。然而没人关心开发遇到的困难，只要不停地加班就可以了。

如何能让开发变快呢？
当快速变更成为一个基本需求时，功能的实现/设计/架构就必须具备可快速变更的属性。
前端要做到能快速变更，就需要前端之下有一层“半产品”的组件，让前端可以通过配置管理或胶水语言快速完成DevOps。所以真正的业务都是在这一层定义和实现的，我们把这层称为“中台”或“平台化”。

和后端的关系呢？
后端很大一部分是提供基础设施的访问，而基础设施分散在公有云或私有云，基础设施的管理不一定需要自己来投入。随着生态的成熟，能分化的职责都会有自己的运行时，以协议接口的方式提供基础设施服务；也就是说基础设施会全部标准化，业务在此之上实现领域之内的“基础设施”，供前端使用。

进一步，前端标准化
前端大量是重复的工作，很容易形成标准化组件；这样中台输出的业务信息，可以按照既定的协议自动渲染成前端界面。

如此，业务只存在于中台。