读数字化转型的道与术以平台思维为核心支撑企业战略发展

　　今天整理和分享下钟华老师的新书《数字化转型的道与术-以平台思维为核心支撑企业战略可持续发展》的阅读笔记。
　　详细很多人都阅读过钟华老师几年前出版的《企业IT架构转型之道-阿里巴巴中台战略实践》，这本书可以说是当时很多人了解阿里中台，理解中台架构基础思想，微服务的一个启蒙类书籍。在前面我也分享了这部分的一个读书笔记整理，可以参考：
　　读《企业IT架构转型之道-阿里巴巴中台战略实践》
　　9月中去参加华南CIO大会，刚好也碰到了该书的作者钟华老师，现在已经从阿里出来自己创业，方向仍然是中台和产业互联网相关的，而且公司发展也很快。钟华老师给人的感觉就是技术和务实，值得大家学习。
　　而钟老师的这本书新书，整套阅读下来还是相当推荐，值得企业内部的CIO，IT经理，技术总监类推动企业数字化转型的人员阅读。同时在阅读完这本书后，里面很多内容和我头条上分享的技术文章的思路基本还是一致的，也可以做为这本书中内容的延伸阅读。
　　因此我先整体对这本书推荐理由做下总结，然后再对书籍里面的一些关键章节内容做下梳理和说明，当前书籍已经在当当，京东等可以购买。由于书籍还没有正式开始发售，因此我总结的时候会尽量少地引用书籍里面的原文内容。本书内容总结
　　首先我还是引用这这本书封面的一句话，即本书系统化，理论化地介绍了数字化转型的思路与方法，以及产业互联网平台的建设思路，为各种业务模式的数字化转型提供了有价值的参考。同时该书详细地披露了企业数字化转型的真实案例，生动展示了数字化转型过程中的实践经验。
　　这本书应该是作者从阿里辞职创业后，结合自己实际创业过程中协助传统企业数字化转型相关的规划架构咨询，中台建设等方面的实践经验而写作而成。简单来说就是上本书是结合阿里中台建设实践，而这本书则是阿里中台建设思想在传统企业内部数字化转型中实际应用。因此如果是传统企业的读者话，整体会感觉这本书更加接地气。
　　整本书的核心在第二章到第四章，在第二章详细阐述了数字化转型过程中平台思维的十大要素，后面两章重点讲解了中台架构的建设思路和中台服务化和运营体系设计。即这些内容是在结合阿里中台思想后实际在企业内部建设过程中的一些重新梳理和总结。因此对于传统企业的数字化转型会更加有借鉴意义。
　　相当对作者的第一本书，这本书整体式思维和架构方法，实践案例占的内容更多，而技术化的内容篇幅则做了大幅的缩减。在我前面很多文章就提到过，中台本身是一个业务概念，首先要从业务上去理解中台架构思想，其次才是如何选择相应的技术来实现中台。
　　包括我自己在最近数字化转型的整理中，也更加明确了企业的数字化转型实际上包括了两个方面的关键内容，即业务层面的中台架构和思想，其二是技术层面的云原生。
　　企业数字化转型 =》 中台架构思想 + 云原生技术架构
　　这本书书名里面就提到了数字化转型的道与术，如果结合书里面的内容就是平台架构思维是道，而中台架构和服务设计是术；业务战略和业务重构是道，而中台技术实现是术。如果按我谈的数字化转型的两个关键来说，中台架构思想是道，云原生技术是术。
　　注意，道和术是一种相辅相成的关系，思想再重要你也需要有技术手段去实现你的业务战略思想。对中台架构和技术也一样，技术本书没有价值，只有技术实现了业务目标才是真正的价值。因此我们真正要做到的就是以道驭术。
　　所以对于这本书可能对于技术类人员阅读后会感觉将具体的技术实现和细节的地方不多，但是对于技术人员往往最缺的就是中台思维的转变。作者的前一本书更加偏中台技术，而这本书则偏平台思维和中台架构思想在企业内落地，两者刚好起到相互补充的作用。数字化转型和中台架构
　　对于传统企业数字化转型，我在前面分享过一篇文章可以参考：
　　传统企业数字化转型-从消费互联到产业互联
　　数字经济是当前所有企业在数字化时代都要考虑的问题，不久的将来它会成为社会经济中的新引擎，也会逐步推动产业互联和企业商业生态的数字化转型。企业的数字化应立足于顶端设计，结合企业的核心竞争力，如产品设计能力、社会化服务能力、渠道终端覆盖力，以及未来的产业互联、生态发展方向，依托企业自身优势，抓取企业自身的数字化本质。
　　那企业数字化的本质是什么？其主要特征包括三个方面：第一是连接，连接员工、连接客户、连接物联设备；第二是数据，也就是连接之后实时产生的数据；第三是智能，是数据驱动的智能应用。
　　在企业数字化转型过程中，实际上可以看到第一阶段是前面几年谈得多的消费互联，即对C端用户的直接触达能力；而当前谈得比较多的产业互联，即对整个产业上下游生态链的整合能力。而在整个过程中，企业内部IT建设的演进可以参考下图：
　　在这本书里面也进一步提到了：
　　中台架构所基于的理论基础正是SOA，是将核心的业务能力以服务的方式进行有效沉淀，实现服务在不同场景下的业务能力重用。中台的本质是通过数据统一，实时，在线实现全业务链的贯通，个性化需求扩展以及业务实时联动等价值。
　　当我今天阅读这本书的时候，又进一步重新思考企业数字化的本质究竟是啥？
　　前面谈到的连接，数据，智能这些不是企业数字化的本质而是数字化体现出来的特征。而消费互联和产业互联也不是数字化转型的本质，而是转型要达到的一个业务目标或期望。
　　如果不深入理解清楚数字化，那么我们始终就会和传统的IT信息化混淆。
　　在我们谈信息化的时候更多地解决的是纸面单据和数据的问题，实现了这些数据进入到IT系统，但是我们常说的信息流，物流，资金流之间仍然存在两张皮或者没有整合的情况。
　　比如我们常说的一个典型例子，一个商品出库，对应了一个出库单。但是往往存在商品出库了，人员并没有在系统里面创建出库单的情况。也就是说实物流信息和信息流没有匹配。其次来说我们执行了付款操作，但是没有对应的业务流程和单据，也就出现了业务流和资金流不匹配。
　　因此在企业数字化阶段，更加期望的是进一步解决信息流，物流，资金流的一致性和协同问题，在这个过程中在传统信息化基础上进一步借助类似物联网等技术来实现三流的自动合一，而不是靠人工去干预和比对。也就是在数字化阶段，我们认为事物本身的移动也是应该网格化和数字化的，应该可以自动跟踪和追溯，而不是需要人工去录入和匹配。
　　在这个基础上，数字化转型的第二个本质才是对企业自身价值链和生态的不断扩展，包括从消费互联网到产业互联网全生态价值链的构建。
　　为何消费互联或产业互联下对中台架构和技术要求更高。因此在这个过程中，我们需要更加的敏捷响应业务，需要通过能力开放来获取更快的上下游协同，而这些业务目标的达成需要我们采用更加敏捷，高效，可扩展的技术和管理手段。数字化转型中的平台思维
　　企业数字化转型的关键在于以平台思维构建系统。所谓平台，就是给存在相互影响和依赖的双边或多边提供一个空间或系统，满足不同群体在这个空间中的利益。
　　对应这句话，个人理解和我前面讲生态构建思路是一致的。
　　即企业的数字化转型应该是一种以一种开放生态的思维来构建整个数字化体系。而生态构建是通过对整个产业链上下游，外围辅助服务提供商的链接而形成的一种相互依存并共同获利的体系。个体不能单独存在，而必须围绕整个生态获利，同时只有完整生态才能够为用户提供最大价值交付。
　　这些链接可以是资源，也可以是服务，也可以是资源 + 服务的整合，但是最终都必须通过信息流实现贯穿。信息的贯穿和整合往往提升了整个生态体系的价值和可达性。一个好的生态体系一定不是静态的，而是动态的可自我调整的，这个生态体系可以通过外在需求的变化及时进行内部链接和信息重构。
　　对于本书里面提到的平台思维十大要素，我不准备按顺序逐个叙述，而是对里面谈到的一些关键思维要素进行总结。
　　业务全局视角贯穿业务链
　　中台架构一个核心思想是从业务全局视角来贯穿业务链，沉淀可复用的核心数字资产，实现业务需求快速响应和创新探索，真正实现以技术驱动业务。
　　这个是书里面提到的第一个关键思维，什么意思？
　　简单来说就是需要基于业务端到端流程分析和梳理，来识别可复用的业务能力，来沉淀核心业务和数字资产。中台构建的目的是支撑整个端到端业务的，不是简单地解决某个点上业务问题的。因此简单来说中台构建的是否成功判断很简单，即企业端到端的效率是否有提升？
　　这个思路本身也是SOA进行业务和应用整合的思路。
　　即我在前面文章里面就谈到的：
　　IT构建的思路应该从传统纵向烟囱建设=》横向分层建设
　　上层是核心业务流程和价值链，下沉是可复用的业务能力和数字资产。在我们进行规划和分析的时候你必须以端到端流程驱动思路来进行分析和分解，来识别和沉淀复用。那么最终形成的中台能力才能够真正满足上层业务链组合和组装的需要。
　　中台能力核心是可复用
　　中台能力的构建一个重点就是可复用，我们可以下构建中台的目的是为了更加敏捷地响应业务目标和业务模式的重组。那么如何才能够更加敏捷响应？
　　简单来说就是当我们业务需要重构的时候，我不是需要去重新设计和开放一个新能力和新接口，而是基于当前中台能力库中就能够找到可复用的能力和接口，直接进行组装或编排。这个跟我们经常谈到的SOA思想完全是一致的。
　　正如书里面说的，在企业数字化转型过程中，真正能够大幅提升业务需求响应和业务创新的关键是依赖又多少业务层面的能力是可以复用的。
　　企业业务重构和整合是中台的基础
　　对于中台构建中，业务的重构往往是基础，比如我们在早期实施的一个案例可以看到，一个大集团企业存在诸多的事业部，对于物流，售后，分销等诸多业务本身都没有整合。那么前期的重点一定是打破纵向模式，首先实现业务能力的整合。
　　业务能力整合后才是考虑技术上面如何去支撑。
　　这也是我一直强调的中台本身是一个业务概念。各种微服务，云原生仅仅是中台实现的技术手段。业务能力不重构，共性业务不整合，那么无法真正构建可复用，有价值的中台能力。
　　中台和前台，前端和后端
　　还是有太多的人把这些概念混淆，所以再次强调。中台核心是共性业务能力下沉，那么非共性业务能力还是在前台各个模块中。即中台可以有业务逻辑层，也可以有前端界面层。同时对于前台模块也一样，不是只有前端界面层，同样也会有业务逻辑层，这个业务逻辑为私有逻辑或无法复用的业务逻辑。
　　中台和前台本身是业务层面的概念，不涉及到具体的技术实现。前端和后端是技术实现和层面的概念，比如我们常说的前后端分离开发。
　　构建中台不一定必须前后端分离开发。
　　你采用前后端分离开发，不是所有业务逻辑层在一起就是中台，如果这个逻辑层或提供的API接口服务没有复用的价值，无法支撑上层灵活多变的业务，那么就没有形成中台。
　　中台团队构建
　　首先我们看到中台团队应该和前台应用构建团队分离。比如我们说的支付中心这个中台模块可以是一个独立的团队，用户中心可以是一个独立团队。而前台的应用类似分销APP，CRM等都是独立的开发设计团队。
　　团队的分离可以方便我们进一步实现模块间的解耦，实现中台能力的沉淀和稳定性。因为一个中台团队往往会接收到前台多个应用团队的业务需求。
　　当接收到这些需求后自然就会考虑这些需求如何抽象和共性化提取。
　　一个好的中台团队一定涉及到业务和技术两个方面的专家和人员。对于业务人员重点就是业务流程梳理分析，业务建模和业务服务能力设计；而对于技术人员则是具体的技术实现。也就是说必须熟悉业务你才能够真正值得业务如何抽象，数据模型和接口服务如何设计才能够复用。中台架构建设思路
　　业务中台建设目标是实现企业业务数据的实时，统一，在线。在书里面提到了业务中台中的各个业务服务中心的落地形态需要具备以下特征。代码和数据库完全隔离仅提供该业务领域的公共能力仅以服务方式对外提供访问支持服务中心的独立运营
　　针对书里面提到的几点再简单总结说明如下：
　　即中台的各个业务服务中心数据库必须是相互独立自治的，即我常说的各个中心必须数据库也进行了拆分，中心和中心之间只能够通过接口服务进行交互和协同。其次书里面强调了业务中心本身尽量不要去实现任何差异化的业务需求，而应该将这些放到前台应用模块去实现，以区别业务中心本身的稳定性和接口的可复用度，这点完全赞同。
　　业务中台和数据中台的关系
　　简单来说就是企业核心业务流程的支撑通过业务中台，实现业务的数据化，而数据中台刚好相反即实现数据本身的业务化，进一步反哺业务。企业一个开始建设企业中台，如果仅仅是满足业务流程和业务处理需求，只会涉及到业务中台构建。在业务中台构建完成后，考虑到后续端到端流程监控分析，大数据分析的需求才会涉及到数据中台的构建。
　　在书里面强调了一个关键概念，数据链路闭环。
　　简单来说就是我们通过业务中台沉淀下来的业务数据，就应该是数据中台用于存储和大数据分析的数据。业务流程执行本身形成的数据，最终又通过数据中台的集成和加工，形成数据分析能力再反馈回业务流程执行中，这就是一个完整的闭环。
　　在这个过程中我们还需要解决数据本身的实时，高效，一致性等问题。
　　中台的建设和发展路径
　　如果一个企业全新构建中台反而简单，但是对于大部分企业存在遗留IT架构和系统，这个时候不可能说完全全新建设一套。因此对于这类企业更多的还是要考虑如何最大化的保留企业IT遗留资产，来通过逐步平滑迁移的方式构建中台。
　　对于这部分，我在头条过一篇文章，即通过适配的方式来构建企业的能力中台，然后逐步进行遗留系统的平滑迁移。对于该文章可参考：
　　传统企业应以业务驱动构建中台，最大化保留IT遗留资产
　　在这本书里面本书也提出了三种构建中台的方法，包括全新建设，平滑迁移等，本身也可以作为企业中台构建的重要参考。
　　中台架构和微服务关系
　　对于中台和微服务，我在前面专门分享过。
　　对于传统架构转型过程中，刚好就是中台和微服务两者思想的一个融合过程。中台强调的是横向分层和能力共享，而微服务强调的单体纵向拆分更细。如下图：
　　在谈中台的时候更多的是业务层面用词，而谈微服务的时候更多是技术层面用词。在谈中台的时候你首先考虑的是业务模块如何划分，服务如何识别，而实现技术是微服务。而谈微服务的时候本身就是技术实现和架构方法，是否一定用于中台倒不是必须。
　　因此要回答两者区别这个问题，我们首先还是要看下中台和微服务这两个概念是针对什么来说的。中台：说中台一定会说到前台，原来是中台前台不分，现在是拆分为中台和前台。微服务：说微服务一定说单体应用，原来应用粒度太大，要垂直拆为更小的微服务。
　　这个搞清楚后，我们就更加容易理解两个概念的区别，即：
　　中台更多的是指横向拆分，即共性业务能力的下沉，然后再将服务能力开放给前台应用使用。而微服务更多是技术用词和软件架构开发方法，强调的是大单体要拆分和进一步解耦。
　　而我们现在构建企业中台，基本是中台和微服务都会使用到，即既需要进行横向拆分，共性能力下沉。同时对于下沉的共性能力又需要按微服务思想进一步拆分多个微服务模块。在中台思想里面更加强调了共性能力下沉和能力开放，能力开放以微服务里面常见的轻量API接口方式进行。
　　了解了这个我们看区别就比较清楚了，具体如下：
　　中台强调横向拆分和分层，微服务强调纵向拆分和解耦。
　　中台建设的目标更多的是下沉共性能力，识别和暴露可复用的API能力接口，供前台应用快速开发和组合，这才是中台构建的目的。而对于微服务来说，更多强调的是单体应用进一步的拆分和解耦，并通过轻量API接口高效协同，只要满足这个要求本身就是微服务思想实现。
　　对于这部分，建议参考我前面整理的两篇文章。
　　从SOA架构思想到中台和微服务，太多的基础概念需要澄清
　　传统企业IT架构转型-不是简单去追逐中台，微服务等热点
　　对于整个微服务，实际上经过三个技术发展阶段：
　　SOA阶段ESB=》微服务阶段的API网格-》ServiceMesh服务网格
　　我在前面也提到了，对于微服务治理，去中心化的ServiceMesh将是最终发展的趋势，虽然说现在还不是大面积应用和成熟，但是最终将成为一个主流的技术解决方案。中台服务设计和运营
　　这个部分主要是介绍中台服务中心的设计和实践。
　　在前面提到中台架构设计中，服务中心的设计是一个关键点。而对于中台的服务中心本身又涉及到两个关键内容，即中台应该构建哪些服务中心，服务中心的拆分颗粒度究竟应该如何？其次就是中台服务中心应该暴露哪些接口服务能力，如何保证接口本身的复用性和粗粒度特征。
　　中台服务中心建设的基本准则
　　书里面提到了中台服务中心构建的基本准则可以参考，其中关键还是中心本身能力可复用，可独立自治等关键方面，具体如下：功能和数据具备共享价值有价值的业务数据能够不断沉淀功能有不断完善和丰富的需求功能边界清晰，具备独立运营的价值
　　业务中台的服务中心应该随着业务的不断发展逐步沉淀，其本身是一个渐进发展和逐步落地实施的过程。其核心仍然是围绕业务目标的实现。
　　中台设计方法和流程
　　这里面包括了业务调研，需求分析，中台设计，开发实现几个关键方面。其中谈到业务中心的分析和业务中心的设计，可以参考。
　　业务中心分析部分谈到了，通过业务域和实体对象之间的依赖关系，业务域复杂度，业务实体之间的亲密度对业务域做进一步的聚类，这样就可以将业务实体归到具体的业务域。
　　在业务中心设计中提到了业务模型设计，数据模型设计和接口服务设计三个方面的内容。同时对接口服务设计的原则进行了展开描述，包括接口契约先行，接口服务独立自治，粗粒度等关键接口服务特征等。
　　对于中台设计，我在前面也专门分享过多篇文章，大家也可以参考。其核心还是基于企业架构规划的思想，从端到端业务流程分析入手进行业务域划分，业务中心的识别。同时结合领域建模思路对整个中台+前台进行分层规划和建模。
　　我在华南CIO大会上专门分享了微服务下的企业架构规划思想，可以参考：
　　参加华南CIO大会：平台+应用-传统IT架构的微服务化改造
　　同时还有一篇文章详细阐述了业务中台建设方法论，对传统企业架构规划方法的演进。
　　业务中台建设方法论对传统企业架构规划方法的改进
　　在这篇文章里面，梳理了传统企业架构规划思想的具体优化点。从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构基于业务组件规划设计微服务技术架构规划新增加PaaS和技术中台服务内容
　　从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。
　　能力开放平台
　　能力开放平台，即企业将自身的业务能力以API的方式开放给外部合作伙伴。能力开放平台本质是通过服务能力的方式赋能给外部合作伙伴生态，一起更好的服务平台上的企业用户，是企业打造产业生态重要的一个步骤。
　　对于能力开放平台的构建，我专门写过文章，可以参考：
　　能力开放平台-最大化体现企业中台对外价值
　　在该文里面给出了能力开放平台的一个完整架构。
　　首先对于能力开放平台我在前面的思考里面做了一件重要的事情，就是将能力引擎和能力运营两者分开，能力引擎即我们常说的能力聚合网关，ESB服务总线，API网关等。可以看到能力开放平台构建你可以选择任何一个能力引擎都没有关系，只要能力引擎能够满足标准的能力注册接入，能力基础管控（安全，日志，流控）即可。
　　在能力引擎剥离后，最重要的就是能力运营平台。
　　在我们没有谈能力开放平台的时候，我们会在能力引擎上方增加一个能力管控平台。而能力管控平台主要做两个方面的事情，一个是实现API接口服务的全生命周期管理，一个是实现接口运行后期的运行监控治理。因此对于能力引擎上方，我们可以考虑拆分为三方面内容能力开发中心：面向开发者，帮助开发者快速地进行能力接入和消费能力运营中心：将能力服务作为商品去卖，因此涉及到服务订购，计量计费等关键功能能力运维中心：实际上包括运维中心和运行监控中心两个方面的内容。
　　而在这之上即是我们常说的门户层，实际的门户也应该包括了运营门户，开发者门户，合作伙伴门户。这里要注意的是门户层更多的是集成和聚合了底层各个业务模块的功能，只是区分业务场景和角色进行聚合。产业互联网
　　谈数字化转型一定会谈到企业信息化的发展整个过程，从企业内部的信息化发展到消费互联网，再到现在我们谈得比较多的产业互联网。正是这种发展可以看到连接的范围，连接的类型都做了很大的扩展。只有有了连接才可能产生数据，有了连接才能够形成协同。
　　互联的一个核心就是连接，只有连接才能够产生数据。
　　而在整个连接里面我们看到本身又分了几个阶段，从最早的企业内部的各个业务单元的连接，企业内部的三流协同，再到企业到消费者的连接和直接触达，再到企业整个供应链的连接和产业协同。连接里面有另外一个重点就是直接触达，减少中间环节，这个也是需要重点能够呈现的内容。
　　基于以上思考，整个构图需要能够展现从企业内部信息化到消费互联，到产业互联的全连接，通过构图能够呈现这种边界上的差异，通过构图能够呈现整个互联协同和中间环节上的差异，如下图：
　　在本书里面将产业互联网作为企业数字化转型的高阶形态，这个本身没有问题。可以看到产品互联本身已经跨过企业内部边界，而实现整个上下游，合作伙伴生态的整合。
　　我们可以举两个简单的例子来说明。
　　客户需要一批量的电器产品，那么电器生产企业如何能够快速响应客户承诺，如果有库存的情况下简单，但是如果没有库存那么就涉及到整个产业链，下游供应商间的快速信息协同，只有协同后才能够最终响应客户承诺。
　　其次，客户购买的电器出现问题，如何追溯到最终是哪个原材料，零部件的问题，这个同样需要构建一个完整的跨越企业内部，衔接外部生态的供应链追溯流程才能够解决。
　　书里面也提到产业互联网能够真正推动实体产业的转型升级，通过产业链的不断打通优化，通过服务的不断集成，从而为产业链上下游创造新的价值，带来新的商业体验。
　　产业互联网构建关键-硬件，连接，中台
　　实际上在数字化转型就需要提到硬件或物联网的应用，前面已经提到，即真正解决物流和信息流之间的完整通过问题。
　　在我谈万物互联的时候就谈到数字化阶段必须解决人和人，人和物，物和物之间的万物互联问题。通过连接并产生数据，通过数据进一步阐述价值。而中台本身就是围绕数据来解决价值创造中的两个方面问题，其一就是通过业务协同来阐述数据，其二就是形成数据闭环，将数据分析后反哺业务。
　　不同的产业，应该都有属于自己的中台建设，因为产业不同往往需要整合的资源不同，沉淀的共性业务能力不同，这才是产业互联网中台真正构建的难点。案例分享
　　这部分内容选择了两个典型案例，一个是关于特步构建新零售数字化转型的案例，一个是生猪养殖企业的产业互联网转型案例。
　　在这里不再详细叙述，大家可以参考书里面的内容。
　　当我在很早谈互联网+的时候就谈到类似的场景和整合规划，即企业加速自身上下游企业的整合，企业发展自建电商等各种模式，核心还是希望通过企业自身原有的核心竞争力和客户资源，尽快地打通和整合整个供应链，通过完整的生态链环境和绑定模式来减弱互联网企业的进入壁垒。一个企业容易被轻松攻破，但是一个完整的生态链环境绝对不容易简单替代。
　　提这点有个前提，即企业本身在传统模式下已经拥有较大的优势而不是一无所有。通过互联网，电子商务等的引入更多的还是加强原有的供应商和客户和企业之间的粘性，同时在这种模式下尽可能的减少了中间渠道和环节，真正做到降低成本和让利给最终客户，形成双赢。
　　当前我们看到，对于农业里面的农产品电商和农产品全流通链追溯和食品安全跟踪也是一个典型的诸多上下游企业通过信息技术，IC卡，物联网等各种技术实现的一个供应链整合模式。