任正非在一次早期的演讲上，说过一个很有意思的观点，如果当初他没有创立华为，可能他现在应该会成为一个养猪大王，意思是方法论是放之四海皆准的，只要有正确的方法论，发挥自己的聪明才干，都能把事情做好；笔者新近从之前的2C赛道转到SAAS的2B赛道，刚接触2B的时候，去着手技术体系与愿景建设的时候，也保持着这种方法论为王的思路，想把之前的方法论直接在团队和业务中去套用，才发现区别特别大，近乎把中年发福的胖子要套上自己年轻时候的笔挺衬衣，弄得自己臃肿不堪；
2B与2C的业务差异
表面的区别可能来自两方面：
一方面区别来自需求的确定性。
2B为企业提供服务，2C为直接的用户提供服务。2B中企业的业务千差万别，光体量这个维度，就不胜枚举，不能光靠大公司、小公司去简单定义，而在2C的技术中最强调的是技术对业务的最佳匹配，最简单的例子，同样是订单存储，不同的存储量级与查询量级，技术方案从单库单边、单库多表、多库多表到异构存储，再从一主一备、一主多从、多主多从到异地多活等等就不是简单的一一对应的选择题，需要综合考虑的主观题；
另一方面区别来自对服务质量的容忍度，也就是2B和2C都很强调的NPS。
但企业服务中的NPS，跟2C的NPS对公司的意义完全不一样，2C的NPS有点像文无第一，每家企业能满足细分用户的某个需求点，你只要在某一个点做得很突出，比如低价，比如便捷，其他方面不是太差，你就有活下去的空间；
而2B的NPS就是武无第二，每个2B的公司提供的都是企业中某个通用的场景解决方案，只要在一两家有其中任何一方面有对你不满意的地方，就意味着在其他企业也会类似遇到，只要你的竞争对手这些方面做得比你好，你们提供的服务没有本质的差别，就很难有生成的空间，属于赢者通吃的局面；
这两个表面的差别，借用第一性原理我们来做更深层次的抽丝剥茧和逐步推导，来看看导致这些表面不同下的核心区别是什么，从而为2B的技术体系和愿景建设理清最核心的诉求；
首先我们来定义问题的内核和边界；
第一个区别：需求的确定性。问题的内核是需求的确定性，边界其实是需求是随着业务发展不断变化的。支撑这个内核与边界其实是外部环境的不可控制，所以2C的场景是，他的需求是动态的，你需要在业务的演进过程中动态地去满足他的需求，这就要求每个技术选型在当前这个点都是根据业务实际情况做的最优选择，同时要求技术具有可扩展性和替代性，需要根据业务情况逐步演进，因为外部环境的不可控制，你在当前这个点，技术和业务都在变，你是完全不知道下一个点的最优解是什么，这从本质上导致2C的思路是解问题的思路；
这一点上，2B跟2C都外部环境不可控，但至少2C在某个时间点上看是确定的，外部环境的情况是可以定义清楚的，而2B完全不是，因为你要要同时满足的是多个企业的不同业务规模和场景，你是在某个时间点要同时满足不同外部环境的不同诉求的；第二个区别对服务质量的容忍度。这个本质是企业使用企业服务的成本远高于用户使用2C的服务，不论是费用，还是接入成本和适配成本；所以企业服务会有gartner等各种第三方的评测报告做各种维度的比较，来说明各2B产商在某个场景提供的企业服务的质量；但穿过这些各种维度比较的迷雾，我们可以看到企业服务质量最核心的诉求，无外乎两方面，能不能解决企业的问题，会不会带来新的问题；这两方面的诉求看起来很大，很虚很缥缈，但其实有几方面的原因，一是企业的业务，2B的公司是乙方，对业务不熟悉不理解，能不能解决问题必然成为企业对2B服务的头号问题；二是即使能解决企业的问题，企业真正用起来，也是使用这些服务来支撑业务的，使用这些服务的过程中的会不会带来新的问题，这些问题能不能得到及时解决；对企业来说，2B的公司是乙方，存在合作上的不可控，即使有合同上的各种保证，但“能不能解决企业的问题，会不会带来新的问题”更多的由2B公司的服务保证，不由合同保证，所以才非常看重gartner等各种第三方的评测报告，行业里的NPS口碑推荐；通过上面不同诉求的分析，我们再回到正题来看2B和2C技术体系和愿景的区别到底是什么，其实很简单了，就是怎么通过技术体系建设应对不同企业规模不同业务类型的不同诉求，实现需求的确定性；怎么通过技术体系的建设来实现2B公司的提供的服务对不同的企业都是可控的，保证服务的可靠和可控性就像是企业自身的服务一样；首先我们来看第一点，什么样的技术体系能应对不同企业规模不同业务类型的不同诉求，懂点技术都会知道这是个伪命题，没有技术能保证，一种技术能应对不同企业规模不同业务类型的不同诉求，因此，要实现这个核心诉求，要求的技术体系架构就是能根据企业规模和业务，多种技术体系可快速自定义、适配选择、无缝对接和组装的；要做的这几点，我们把技术架构从底往上分为4层，来依次明确其中的架构要点和要求；第一层是容器层，为屏蔽底层的具体操作系统细节，兼容SAAS公有云部署与企业私有部署各类操作系统的差异，以及各种数据量与访问量的量级的差异，这部分需要的是基于云原生的容器调度体系，可以屏蔽底层差异与资源环境的自定义。在软硬件基础环境这一项中，不同客户的从操作系统到网络、机型就有各种情况。因此基于云原生的底层资源调度架构，是2B高可用和高适配性的最佳选择；第二层是中间件层，这一层的挑战各种业务场景的中间件诉求，没有像云原生有标准通用可定义的通用组件，但正是因为没有，所以也是2B核心的技术门槛所在，总的说来，需要定义一个统一抽象的中间件适配层，可以通过业务场景具体要求自已定义的中间件层，并能做到对上的屏蔽具体中间件对业务层带来的差异；就拿数据库ORM中间件为例，在2C的场景中，会根据自己的业务场景选择自己合适的数据库，选支持这种数据库的中间件就好，而且ORM中间件已经匹配了底层数据库的差异，大家肯定会有即使是2B，有必要统一的中间件适配层的疑问；一来不同的ORM支持的数据库有比较小的差异，比如beego orm虽然都支持mysql，开发过程也是用的mysql，但2B的场景里，客户是可能有不同的诉求，需要支持oracle，sqlserver，或者tidb，但是就拿golang中间件为例，beego支持oracle，tidb不支持sqlserver，gorm支持sqlserver不支持oracle、tidb，而且底层的数据库也有不同的特性，比如select for update，不同数据库支持是不一样的，所以有比较统一规范的数据库，不同客户会有不同的数据库的需求支持上都会有不同差异，更不用说不同场景的千差万别的消息中间件、事务中间件、日志中间件等中间件了；统一的中间件适配层来灵活地选择不同的中间件，是2B技术架构体系不断演进的一个必然方向；第三层是业务层，这一层主要是核心的产品业务逻辑，但是面对的问题不像2C的业务是明确具体的，2B更多的是抽象可定义的，通过自定义的能力，为要解决的各种业务场景中的抽象出来的统一问题，提供统一可快速适配的产品方案，借鉴2C的思路，在业务层要做到能力复用和可定义，在业务架构里会演化出业务中台概念；2C的中台建设中强调：核心定义业务身份、活动、能力、产品、扩展点等一套抽象的体系和代码结构，来实现兼容差异扩展的能力复用与产品叠加，再逐步沉淀解决方案和产品功能可定义可视化的演进，逐渐形成某个业务领域的操作系统，让前台业务在上面快速自由生长。但这套思路在业务实践中，有点像体型庞大的超级航母，应付需要类似小舢板这样灵活性的还是显得太重。2B的业务中台需要更大的灵活性和可定制性，因为要应对的业务领域也是完成不一样的，跟2C有具体的业务领域不一样，2B的业务中台，为保持足够的灵活性，借鉴中间件的思路，可以实现类似中间件的的灵活性和开放性，并且中间件在能力复用上成本比之中台会更低。只是有别于基础中间件，这部分更多的是将核心业务抽象出来的不同的业务中间件，业务中间件支持扩展点在不同业务场景，开箱可用式的的选择式可定义，并在整体解决方案中可插拔，从而将业务中台转换为支持不同业务场景的插拔式业务底座；有个底层还不够，还需要配合低代码平台的业务流程定义能力和业务差异性的快速开发能力，比如同样是财务数据的分析解决方案，不同业务场景底层核心数据分析方案是一样的，在业务底座里能找到具体的解决方案，但是不同的业务的跟财务数据对应的具体业务字段是不一样，这就需要有低代码平台支持不同业务表单的创建，来实现具体字段的录入对接与展示，再根据业务具体场景的具体差别（即插头不一样）跟业务底座做定义式插口对接上，才能实现2B技术体系架构里核心的真正灵活开放的能力复用，这也就是跟具体业务产品方案平排的第四层，低代码平台层；低代码平台，在2C与2B里都会有类似的诉求和场景，但大部分的低代码平台都忽略了一点，在2B的场景中，有快速开发能力只是第一步，核心要解决的是快速开发之后的服务发布、服务治理与服务数据分析能力；低代码平台不但解决是2B实施的支持问题，更应该解决的是企业在上面不断演进的能力，因为企业业务是在不断发展和变化的，没有这样的能力，就会逐渐地变得不好用、不可用。这就回到上面问题分析要解决的第二点，“保证服务的可靠和可控性就像是企业自身的服务一样”；这个低代码平台需要帮助这套方案变成企业自身的一部分，不论是企业自身的技术在上面二次开发，还是服务提供商自己或者其他第三方在上面二次开发，都不是推倒重来，是基于核心能力的根据新的业务场景的升级，这就需要有不影响客户业务正常运行的新服务发布与升级能力；在服务使用过程中，服务的治理：服务的隐患、服务的稳定性、服务的异常情况的应对，也是客户就行在自身的运维系统里一样可以快速定位快速解决的；而使用过程的数据沉淀和分析，不论是分析出对客户更好使用服务的建议，还是客户通过自定义数据分析找到自身组织中可以改进流程，只有服务和数据长在一起的低代码平台，才能让解决方案为客户提供的不止是一套服务，更是一套可以帮助客户不断演进进化的企业的数据底座，帮助企业数字化转型；低代码平台在2B的场景比较火，相关论述比较多，在这不做进一步展开，这只就支撑低代码对外围系统其中非常关键的一个要求：业务底座层或者业务产品方案的自身提供的可集成能力，集成很重要的一部分是各个接口各个字段的再组合，最简单的实现可能就是提供尽量原子的接口就可以了，因为2B场景中很多情况是针对业务场景的会有专门投入实施人员来开发定制。但是要实现低代码平台，只做到这一步是不够的，可以借鉴一个方案是前后端应对多变的页面需求使用的GraphQL方案，GraphQL是一种接口查询语言，能够类SQL的模式对多个接口的数据进行查询或对数据进行操作，有自己的语法和各开发语言的对应开源实现，它原本用于前端与后端的数据中间层建设，减少前后端的耦合，后端提供一套统一接口，前端通过GraphQL转换适配到三端不同展示或操作诉求，从而避免不必要的接口数据转换和冗余的接口定义，他有schema用于定义新的接口逻辑，resolver用于定义新接口每个字段与后端接口的对应关系以及取数逻辑，通过聚合绑定在某个type的字段上单个resolver（DataFetcher），可以实现多个不同接口不同字段的组装；这些原生的resolver（DataFetcher）的实现，可以在业务底层和业务产品方案层接入统一的框架实现rpc或RESTful接口的自动实现与转换；在业务层通过GraphQL的引入能极大地提高2B服务的平台定制能力，是2B企业服务实现集成共生的重要手段；上述是从各层来说明2B企业服务的技术架构体系，从而形成上图所示的架构图，以应对不确定的外部业务场景与高要求的服务质量，至于各层中实现中是否使用微服务、DDD等流行的技术架构，需要保证的一点是局部服从整体，保证2B企业服务整体方案的多场景适应性和稳定性，是各层具体实现中需要优先考虑的一个点；基于上述2B企业服务多场景适应性和稳定性的架构体系，再回头来看2B的技术愿景，2C的技术愿景更多的是从技术赋能商业，技术扩展商业边界的角度，2B的技术愿景基于2B企业服务要解决的问题和提供的架构体系，如果说赋能和扩展边界，他更多的是赋能企业和扩展企业边界，但这更多是整个企业服务商业公司的立身之本、价值所在，不适合做为2B技术部门的愿景，2B技术部门的愿景更多从技术出发，应该是通过可定义、可集成、可低代码开发、有保障的技术体系，实现企业服务解决方案对客户的价值最大化；换句更容易理解和打动人心的：为客户提供最佳匹配的共生共建共发展技术平台！
