所以2B产品设计思路不是完成某一个功能，一定要脱离“穷举法”，要采用建模的思维，构建一套解决方案、或者一套套体系，把这套体系推到全局，解决一片的问题，而被解决这一片的问题，却是变成了这套体系或方案下的数据；
建模思维的九九乘法表：
第二个观点2B产品是构建可被积累的一套套体系，并把体系推到全局进行使用，而具体的一个个功能，却变成了这些体系里面的数据；
我这里谈论的IT架构不是那种NB的分表分库、负载均衡、微服务等等，我就谈论那种傻傻的编码层面的，我默认这些NB的一塌糊涂的东东都被大牛搞定了，毕竟我只是一个做产品的啊！
第一：构建一模一样的控件群
这点大家能明白，基本上所有的2B框架都提供了这样的控件群，我这里想说的是为什么要这样做？在2B的应用领域，强调的是解决对方的问题，而不同客户的问题又无法通用，这时如果用张小龙的说法做产品要“克制”这个说法只对了一半，对全量产品来说是无法做到克制的，但是对于具体的某个需求功能，我们要尽量保持功能的“克制”，因此维持相同功能的操作一致性就变得非常重要，比如同样的表格控件，如果在一套产品里有N种表格控件，用户在不同界面操作使用的控件都不一样，操作模式、附带功能都不一样，我想客户也该疯掉了！因此保持整个产品维持统一的控件风格和相同功能的控件只保持一个，并且保证该控件功能足够强大。
对于具体的某个实际的使用者，在2B领域对于具体的某个岗位的用户来说数据量大是刚性的，不像2C数据量小，例如携程，如果是用户那么我们每天坐飞机最多也就5次把，但是如果携程对应的2B运营者，他一天经手飞机订单数据，应该有几千条、几万条把；你说对与他这个岗位来说，界面是什么样的风格最好了？肯定是这样的：
在2B产品界面里，如果我们仔细统计下，估计至少50%的页面的60%界面的面积都是被这样的表格占据，那么这样的表格控件的强大性就变得无比重要了，而2B对表格数据的处理，如果到极致将是既要有Excel的灵活性，还要有系统的逻辑性和控制力；
类似这种控件类在IT架构中我归为“硬件”的部分，我们需要做的是如何让该控件的功能变得更加强大灵活，然后只要引用这个控件界面，都将继承了该控件的强大功能集合，让具体做功能开发的只需要考虑业务逻辑，而无需考虑界面逻辑和操作逻辑，因为“硬件”部分已经帮忙全部搞定。
在来看一个“软件”的例子：SAP的筛选、搜索帮助体系
先看下效果：
这4张图是SAP对同一个字段“公司代码”在4个界面的搜索帮助，他们完全长得一模一，可能很多人会说，这简单啊，我在每个界面都要求用一样的代码应用不就OK了么？实际确实是这样的，但是我们来细化下，开发场景中如果功能都让一人开发，完全有可能保持产品的一致性；如果开发功能的人很多了？开发类似界面的人还是很多？而且还很多次？那么对同一个字段搜索框的筛选还能做到一致性么？
其次SAP这个搜索帮助框，他根本就不是用代码实现的，他是构建了一套搜索帮助体系，只要你引用该字段就自动带入该搜索帮助，无需任何代码！我们来看看，他是如何构筑起这样的搜索帮助体系的：
定义数据元素：
定义搜索帮助：该数据元素被引用到的次数：
类似这样搜索帮助，对SAP来说已经积累了10W多个:我们发现，对应公司代码字段这样一个如此小的“颗粒”，居然被2.5万多个地方应用到，而且这只是一个字段，在SAP体系类似这样的字段，有10万多个；而只要做搜索帮助，都必须采用这样的标准，那么对他来说就是构筑了一套对各种字段的搜索帮助的仓库集群，以后只要是搜索帮助类的需求，对他来说就是数据，对应搜索帮助这类问题，他就构建起了一套基于时间轴积累的产品体系，而现在很多2B的公司，对这样的需求还是用一行一行代码来实现的，可是人家SAP在几十年前就已经构建起了这样一套产品体系，并在全局进行实现，这对2B这个领域来说才叫产品，而不是用敲代码的方式搞定了几十个、几百字段的搜索帮助；而这样的搜索帮助体系，是搞定了全产品线所有的搜索帮助，不管是过去、现在、还是将来，都搞定了，这才叫真正的2B的产品，他搞定的是这个细分板块在时间轴上全量的问题，剩下的就是时间了，只要时间足够的长，他所积累的搜索帮助体系的数据就足够的丰富，如果谁要在搜索帮助这个小产品上超越这个产品，那么你首先的有这样一套体系，同时的要积累够这么长的时间轴才行，当然你也可以在搞定了这套体系的同时，做大空间轴可以缩小时间轴上的差距追上SAP步伐！
SAP构建的一个个产品体系架构，上面列举到搜索帮助控件只是他众多控件中最常见的一种，但是总体来说他的控件分成两大类，一类让单一的控件在功能维度上无限的强大，只要使用了该控件，就自动附带上该控件的所有技能，我把这里控件叫“硬件”；这类控件的价值可以类比拥有了一把倚天剑，即使是峨眉小道姑手握倚天剑那也是了不起的人物；另一种控件他构建了一套体系，极少成多、积沙成塔最终就是蚁多咬死象；最终随着时间的推进构筑起无可撼动的高墙，也就是把所有的功能对他这套体系来说，居然变成了一条条的数据了，这类控件我把他叫做“软件”，后续所有人都是在丰富他的数据记录，你以为他是在做功能，其实是它只是在沉淀数据！
第二、把模块化程序做到极致
有个故事我想大家都听过无数遍了，可是我还是想讲讲，德国人扭螺丝的一种标准是扭三圈回半圈，人家德国人就是老老实的执行，真的扭三圈回半圈，可是在中国绝大多人就认为这是脱裤子放屁，就只扭二圈半；这样的做事模式在SAP里也是体现的淋漓尽致，其实在开发这个行当，这样的技术不难，这样的模式也不难，难的是执行，长期不懈的执行，并且是让所有人长期不懈的执行！SAP长期不懈的执行铸就的成果，对于不做开发的人，应该很难理解，这代表着什么？
SAP产品开发者，会对所有的小功能、小应用封装成一个个的函数，供自己或者大家调用，而且只要有这样的函数，后面的人基本上也不会重复去开发相同的功能，大多数都是去开发新的小函数，共大家调用，而已经开发出来的函数，则不断的迭代，直至朗阔这个小函数所有遇到的需求为止，也就是说在这样一个封装的小功能中所有的BUG、所有的问题、所有的情况只要是对应的这样一个小功能，都有且只会碰到一次，只要修复了，以后永远不会在碰到；这是多么NB的做法，但是这又是多么简单的做法，让我再次想起了曾国藩那句“结硬寨，打呆仗”至理名言！
我们来看一个例子：
函数名：CONVERT_TO_LOCAL_CURRENCY 函数的功能：将外币金额换算为本币
函数的代码：代码总行数235行，有效代码行数差不多200行，200行的代码我相信以各位大神的能力，那简直就是不值一提啊！我们继续往下看。
就是这样一个有效代码只有200行的函数，我们看他被引用了多少次：
就这样一个小小的功能，被728个地方引用了，如果把开发这个转换汇率小功能的人，工时算一下成本，预估1万欧元（每行代码50欧元，400人民币）按照现在的汇率算成人民币大概是77876元，我们在来按照时间轴和空间轴来摊薄下他的成本是多少钱：
大家可以感受下，到现在即使当初的投入是多么的巨大，他的成本都是无限的趋近于“0”。
而在SAP这套产品体系里这样的小模块却有2.2万个之多啊，2.2万如果换算成文字，就是2.2个汉字，中国人引以为傲的四大名著，用到的总汉字量也才7千字！人家就是这样的小模块功能就有2.2万个，如果要组合他可以组合出多少种功能，这就是人家为什么能适用全球的底蕴了，咱们只要7千个汉字能组合四大名著流芳百世、世代传颂！可是人家却掌握了2.2万个类似汉字这样的小功能，能否组合出全球500强80%客户也就是400强；或者是42.5万家客户的解决方案出来了？
对于2B产品公司来说，我们需要研究的不是他这一个一个的小功能，而是他是怎么造成这一个一个小功能的，就像写出四大名著的7千个汉字，对于我们这些人来说，需要研究的是如何造出这7千个字，至于怎么用这7千个字组合出四大名著，那是下一步的事情，我们首先需要研究的是如何造出这2.2万个小功能。
上面讲的小故事我们认为对于真正的德国人来说，是有瑕疵的，人家真的做到了转三圈，回半圈，可是对于实际操作的那个人来说，他却只做了2.5圈，剩下的一圈对德国人来说是怎么实现的了？他们造了一个工具，借助于工具他们让所有人都能做到转三圈回半圈；我还是以SAP模块化函数举例；
他们制作了一套工具： SE37（制造小模块的工具）； BAPI（制造出来后用这个管理这些小模块的工具）
先来看下这个SE37的制造工具：就长这样，是不是很简单、很傻，可是就是这样一个工具，他却框住了那些天马行空的海量“码农”，如果想要制造小模块功能，那么就得在这个工具里类玩，否则就不是小功能模块；当然他可能在管理层面也配合了其他的管理制度，这里不谈；我们只谈技术，当通过这样的工具，就会源源不断的产生千奇百怪小功能块，就这样随着时间轴的延伸诞生了2.2万个小功能，但是重要的是确实这个SE37的小工具，他让所有的这些小功能，在这套工具构建的体系下，却都变成了一条一条的数据。
当这些小功能都造出来后，就像一个一个的积木，肯定是杂乱无章的，因此需要对每个小功能进行定义、管理、分类、等等维度的标记，于是又有了一个工具：BAPI
BAPI对SAP来说，也不是把所有的小功能小模块都这样管理起来了，他这里管理的，是一些非常重要，代表核心业务意义的应用小模块，在小一点的模块可以直接在SE37里去查找。
但是这都不重要，重要的是，我们需要理解，并掌握这样一种2B的产品设计思维IT框架，对2B产品来说，不是我开发出某个功能，而是我建立了某种体系或者构建起某个模型，并把这套体系在全局产品中应用；当有这套体系后，相识的问题在时间轴上和空间轴上都被解决了，我们唯一需要做的只是在时间轴和空间轴上做到长效的积累，让类似的功能对于这套产品体系来说，都是数据！就好像“相对论”这套解决方案出来已经100多年了，我们现在的认知还是被他框住的，我们只是找到了更多佐证相对论正确的证据而已，可是人家早就推到出来了啊！
这里不再分析SAP产品往下细分具体包括了那些产品机制，暂且做了一些简单的归纳，当然SAP体系比这更多！对与2B的产品开发、设计来说，千万不要落入穷举法去打造一个一个具体的功能而乐此不彼、不能自拔的陷阱；我们需要跳出穷举法，要用建模的思维去构建出这一类问题的解决方案，构建起一套具体的模型，然后基于这套模型构建起自己的2B产品；传统穷举法，与构建一套套产品体系的产品实现方法论，在我看来就好比，一个是拥有原子弹、氢弹这样武器的存在，而另一个是拥有“二向箔”这样的降维打击武器的存在，这是一种从本质上直接被彻底解决掉问题的打法，这两种产品思想不在同一个维度上，也就是俗称的降维打击吧！
对与2B产品来说我们需要的是打造出可被积累的IT产品架构在纵向IT架构分层角度看全是各层级的配置，在横向同层看全是属于本层逻辑建模下产生的数据，整体形成一套可被积累、沉淀的IT架构，在时间轴+空间轴上在各自层收集并沉淀出属于本层的海量数据，当拥有这样的IT架构后，我们的架构和数据会让我们在时间轴上随着时间流逝变得深不可测，在空间轴上随着空间轴的扩张变得广漠无垠！从而让这套产品架构+产品功能数据铸就起百年2B的存在！