做技术开发的同学，都要搞清楚一个很重要的问题：自己所做的工作到底是属于「业务」还是「平台」？
首先，什么是业务？这个很好理解，因为每个公司都有自己赖以生存的业务。是电商，还是社区？是短视频，还是直播？这些都是不同的业务类型的例子。当然这些业务类型还可以继续细分，而且每种业务都有各自不同的「业务逻辑」。
什么是业务逻辑呢？按照维基百科上的定义，它也叫领域逻辑（domain logic），指的是根据真实世界的业务规则编制成的那部分程序。总之，业务逻辑是针对特定领域的，这些代码不可能在不同的业务之间共用，因为他们各不相同。
但是，「平台」就不同了。平台就是要提供通用的功能。在很多公司里，我们大概都能见到以类似这样的名字命名的系统：XX平台，XX引擎，XX中心。一般来说，这些系统就算是平台了。举个例子，估计每家公司的系统里都会有一个「用户中心」，它可能提供基础的用户验证和授权服务，也可能提供基本的用户信息查询服务，等等，总之它不处理具体的业务逻辑。
这里有一点需要注意的地方，「平台」这个词含义非常广泛，也经常会被滥用。当不同的人口中提到这个词的时候，通常是在说不同的东西。这个词甚至不一定和技术有关。但很多技术同学在听到这个词的时候，首先可能会想到「开放平台」，比如国外的Facebook或谷歌的开放平台，或者国内BAT的各种开放平台。开放平台确实也是平台，而且是比较高级的一种平台的形式。它跨越了公司的边界，被开发者构建的服务所依赖。但是，本文所要讨论的平台，主要还是指公司范围内的概念。它在公司内是广泛存在的，通常负责提供业务所依赖的很多基础服务。
一个公司能赚钱，肯定是因为业务做得好；同样，提供不了有价值的业务，公司早晚死掉。所以说，业务才是一个公司发展的原动力。
那为什么还会有平台出现呢？根本原因在于降低成本。
公司在发展过程中，肯定会产生越来越多的业务，同时一个公司也需要尽量聚焦，所以各个业务之间一般来说也是有密切联系的。这样的话，多个业务之间必然存在一些相同的或相似的概念和逻辑。按照软件工程的思想，将这些相同的或相似的概念和逻辑进行复用，减少重复劳动，肯定是成本最小的一种方式。
当然，要进行复用，首先要经过抽象。这个抽象的过程本身也是要花成本的，但总比一点都不进行复用要来得好。
最开始，公司内的各个团队都维护着不同的业务。时间长了，经过不断地抽象、复用，必然有一部分功能沉淀下来，成为平台。
即使是在一些非技术团队中，团队成员之间的分工也会有平台型和业务型之分。比如，产品经理就可以细分成平台型产品经理和业务型产品经理，他们的关注点会有所不同。再比如，在一个运营团队中，也可能有人专门负责各类营销资源（平台型），而其他一些人各自负责具体的业务（业务型）。
所以说，不管是一个系统，还是一个团队，或者是扩大到一家公司，只要存活了足够长的时间，那么必然会进入一种「业务-平台」模式。这种运行模式是经过长期实践得到的一种成本最小化的架构形式。在这种模式下，业务和平台是下图所示的「多对多」的依赖关系：
这种「业务-平台」模式，大体上可以这样来概括：平台以最小成本提供通用能力，从而来支撑业务的快速试错。
虽然业务-平台模式是经过长期实践得到的，但世界上没有完美的事物，它仍然是有问题的。下面我们分成四个方面来讨论。
第一方面的问题，可以称为「排期错位」。这是什么意思呢？就是说多个人或多个团队一起合作完成一件事情时，各方由于自身当前的状况不同，很可能无法同时进行投入，从而无法给出一个能够互相紧密配合的排期，最终导致目标无法快速达成。
这个问题尤其是在平台早期建设的过程中更容易出现。平台在早期还缺少成熟的积累，通常没有现成的能力去支撑各种业务需求，所以需要跟着业务需求来同步发展。因此，平台方经常会被拉进一个个的业务项目中去。
假设有一个业务，它依赖三个平台提供的服务。现在业务方提出了一个产品需求，它也非常依赖三个平台方做出更改才能完成。这时候需求的提出方（通常是产品经理）就需要拉上至少四个团队的人（三个平台开发团队和一个业务开发团队）坐到一起来进行排期。这还没有算上前端、测试、设计等相关团队。
不同的人或不同的团队，做事情的优先级不可能完全一样。因此在实施的过程中肯定会出现一方等待另一方的情况。由于平台方被众多的业务所依赖，因此在一个快速发展的业务部门中，平台开发团队一般会非常非常忙，一方面要维护旧的服务，一方面也要对架构做大的升级（新一轮的抽象和复用），同时还要进行各种答疑解惑。
结果就是，平台经常会成为瓶颈。在实际中，这种情况发生了一般会怎么办呢？通常有三种做法：
需求降级。尽量采用已有能力，或者采用一种更改较小的方式进行。这样做有可能丧失了一次业务创新的机会。
业务方等待排期。这样上线时间会被拖长，而且会产生「排期消耗」，就是说你在一件事情真正做完之前的等待状态中，也没法投入精力到其它的事情中，从而白白浪费掉一些时间。这是因为人的大脑非常类似于单线程的工作模式，只有短期内专注在一件事情上，才有可能高效工作。
短期方案。也就是说平台方先提供短期实现，按照业务的要求快速上线，后期再慢慢优化。这样做其实容易给平台的发展引入技术债务。
第二方面的问题，称为「平台gap」。
有一个比较有意思的现象：虽然我们前面也讨论过，公司的根本在于业务，但大多数技术团队仍然是热衷于构建平台的。为什么呢？因为平台建立起来之后可以支撑很多业务，这意味着能发挥更大的价值。
然而，虽然平台的目的是为了支撑业务的，但却不是直接支撑业务。在平台的概念和逻辑里，它不直接理解各个业务的概念和逻辑，它是经过抽象了一个层次的。这就像是柏拉图关于实在与现象的学说，如果平台的概念里有一只「猫」，那么它一定不是特指这只猫或那只猫，而是某种普遍的「猫性」。而要构建一个业务，却是有很多特指的、具体的概念和逻辑需要去实现。多个平台拼凑起来并不能像搭积木一样搭起来一个业务，这中间还有大量的业务逻辑需要去实现，有大量的胶合逻辑需要去填补。而且，组合各个平台的服务，也不一定特别顺畅，这受限于平台提供服务的方式。毕竟平台并不只是为了支撑你的特定业务而存在的。
因此，平台之间是普遍存在gap的，就好像不是一个规格的插头和插座对不上一样。那这种gap由谁来填补呢？这就看谁对最终结果负责了。最终演变成：谁对最终结果负责，谁来操心。
第三方面的问题，是支持力度的问题。
前面我们提到过，平台的目的就是支撑业务的。但由于精力有限，未必都能很好地支持。我们分成三种情况来讨论：
平台已经有现成的方案，所需要做的只是提供文档和答疑解惑。
平台需要稍作改动，才能支撑某个特定的业务需求。
平台需要做大的升级，重新进行抽象，才能支撑某个较大的业务需求。
先说情况1。对技术人员来说，文档似乎永远是个硬伤。国内甚至很多开放平台对外的文档都写得一塌糊涂，更别说公司内给兄弟团队看的文档了。我曾经在《为什么有些技术书籍难以读懂？》一文中提到过，写作是需要一点点产品思维的。很多文档之所以难以读懂，就是因为作者不是站在读者的角度来写的，而只能是算作者本人的笔记，称不上真正的「文档」。
没有好的文档，必然产生很多疑问。而且，业务方在接入的过程中，必然会遇到很多调试问题、环境问题，等等。这么多答疑解惑的工作反过来又会对平台的技术人员造成很大的干扰，很容易陷入恶性循环。
再说情况2。为了支撑某个业务需求，平台需要稍作改动，比如传个参数或者加个字段之类的。这大概是平台的技术人员最不愿意干的一件事情了，既少不了修改代码的麻烦（还会额外引来一系列后续的麻烦事，比如代码review、测试流程、发布流程），又产生不了有突破性的价值。
这不由得让人想起了一个很尴尬的故事。在Scrum敏捷开发模式中，流传着一个关于猪和鸡的故事。剧情简单概括起来就是说，一只鸡邀请一头猪要一起合开一家餐馆，并建议餐馆就卖火腿和鸡蛋。结果猪很聪明，它回答说：“不同意！我全身投入，而你却无关痛痒！”事实也确实如此，火腿是猪身上的肉，割一片就少一片啊，而生个鸡蛋相对就轻松多了。
在前面的情况2中，就难免会出现类似的状况。平台站在了「鸡」的角色上，我只是加了个参数而已，其它事都跟我没关系啊。而业务方是「猪」的角色，就比较累了，需要不停地推动。
情况3，平台需要做大的升级。由于改动成本比较高，平台自然要集中精力做最有价值的事情，从而不得不评估业务需求的优先级。如果控制不好就可能会出现挑肥拣瘦的现象，精力全部投入到看似「更好」的业务中去。
第四方面的问题，也是最重要的问题，就是对于创新的判断标准问题。
新的业务需求到来的时候，对既有的系统肯定会产生一定的冲击，而这种冲击是创新所必须经历的，还是说只是一个扰乱，这个问题其实很难判断，特别是当这种业务需求在业界也没有参照的时候。
在一个大的团队内，业务需求的提出方其实很善于向系统既有的能力妥协，或者说懂得如何降级自己的需求，以达到新功能的快速上线。各个平台通常就是这种既有能力的代表。而真正的创新肯定不是基于既有能力的，而是采用一种新的颠覆性的思路来设计产品，不管是业务还是产品，也应该以颠覆性的眼光来看待整个系统。也许到了这个时候，就预示着一个全新的平台应该出现了。
对于前面提到的一系列问题，很遗憾，本文也没有完美的解法。
去年业界都在讨论中台战略。那中台战略能不能解决这些问题呢？应该说，中台思想确实是在试图解决类似的问题，但有没有真的解决呢，就不好说了。
在本文结束之前，我尝试性地给出一些建议。这些建议有没有效，读者可以自行判断。
首先，平台应该具有自助接入的能力，避免成为瓶颈。这包括完善的文档、接入和调试流程。
如果平台没有这个能力，那么你要想了解某个平台能够提供的能力，实际上是有很多障碍的。你首先需要找到一个接口人（也许辗转多次才找到合适的人），然后由接口人给你提供API文档以及一定的答疑解惑。
支持自助接入，就是由接口人模式，转变为开放文档模式。这样带来的好处是：
平台的能力便于由接入方自己去探索。其实很多时候你只是想评估一下某个平台是不是能满足你的需求而已。
接入方自己完成接入流程，不依赖平台的人工支持，从而避免让平台成为瓶颈。
其次，平台应该能够支持长尾的需求。要实现这一点，平台必须让业务方能够做定制化的开发。平台不应该只支持主流需求，这样平台就不是真正的平台了。能够用小成本支持长尾需求，才是平台真正的威力所在。而这些可定制化的功能，可能也正是业务能够创新的地方。
第三，平台也应该做一些垂直业务的尝试。平台可能离用户较远，听到的需求都是靠业务来转达的，平台只有尝试做了一些垂直业务之后，才能真正理解需求，并发现业务痛点在哪。
虽然我们前面讨论了「业务-平台」这一模式的很多问题，但平台积累的知识无疑是很珍贵的，它的价值不容置疑。当我们的业务成熟之后，我们仍然会义无反顾地向平台方向发展。在这个过程中，当然，最关键的还是人的因素。不管是平台还是业务，都随时需要有创新思想、并从用户的视角来看待问题和解决问题的人。
（完）
其它精选文章：
为什么有些技术书籍难以读懂
心流：写作、编程和修炼武功的共同法门
朋友，你的时间够用吗？
技术的正宗和野路子
蓄力十年，做一个成就
三个字节的历险
漫谈分布式系统、拜占庭将军问题与区块链
基于Redis的分布式锁到底安全吗（下）
知识的三个层次
扫码或长按关注微信公众号：张铁蕾。
有时候写点技术干货，有时候写点有趣的文章。
这个公众号有点科幻。