2020-03-24 13:09:04 xuzhiyue
本文包含部分AI创作内容
伴随web 2.0这个概念的， 还有一个RSS Feed。
那是头条还没诞生的时代， 我们用着Google Reader， 阅读着从各个Blog, News平台生成的Feed流信息。这是我有关广域网下通过某一约定实现结构化数据的跨系统集成最早的记忆。
再后来， 有个云服务， 叫Yahoo Pipes， 可以把Feed流重新整合定义。而Feed可以来源于Twitter的关键词搜索信息。 那时候我就用Yahoo Pipes汇总各个平台关于shopex的信息， 生成邮件， 做舆情监控。当时还取了个名字叫ShopEx之眼。
这种玩转Feed流信息，重新糅合编排还有个专门的形容词叫Mashup， 在当时还是一种很极客的玩法。
再后来，SAAS服务兴起， 每个SAAS服务努力做好自己的本职工作。 就像《The Art Of UNIX Programming》一书里写到的，每个UNIX风格的应用程序做好自己的部分， 通过管道与shell将他们连接在一起。
那谁会成为SAAS服务的shell和Pipeline呢？
在企业级市场， 创立于2013年的Slack， 定位于2B企业协同的信息枢纽，在2019年6月登陆纽交所，上市之初市值高达195亿美金。至今仍是墙外在该领域的标杆。这里要提一句， slack的中国理念追随者Bearychat也是一款非常好的产品， 可惜国内的厂商接口开放的太少， 一缺生态水分， 二缺用户土壤, 尽管团队非常好， 但发展速度没起来。
倒是近两年钉钉与企业微信的聊天机器人又可能使人机互联的信息协作再度复苏。
双十一的时候， 那么多订单， 是怎么通知到仓库发货的？
商派有个叫“矩阵”的SAAS化中间件，帮助我们从天猫，京东等平台获取订单数据。经过去除敏感信息， 保留订单摘要， 统一格式进行统一转发与传输， 传到OMS， 传到仓库WMS.
相比局部的数据结构， 更多时候我会被系统的架构所吸引。 通常在所有能形成 “聚合－抽象－分发” 的环节都会让我痴迷。
比如上面谈到的订单聚合 ， 比如第三方支付形成的聚合收银， 再比如客户接触通路聚合， 比如短信通道聚合， 比如用户身份认证的聚合(Mozilla Persona)， 比如营销事件的聚合， 比如供应商采购链路的聚合。
上面这些聚合点有的已经诞生， 有的还在沉睡， 但无疑任何一个聚合点在形成规模优势后都有巨大的商业价值， 且形成生态后还具有排他性。
在零售领域，纵观人类历史， 从来没有一个时刻达到现在这样，可将前线阵地的消费者行为数据实时获取， 可对后端仓储储备情况进行实时洞察。
制造业终于迎来了挑战牛鞭效应的曙光。这更加考验数据整合与运用的能力。而一个以Event – Filter – Action 模型设计的数据总线会处于非常重要的位置。
无论是基于AI的方式， 还是基于传统的item-based/user-based 欧几里得距离计算相似度。数据通路的构建都是搭建数据中台的第一步。
在企业内部it，也有几个厂商巨头， 比如Mulesoft， 比如欧洲的software AG。 都是做的搬运工+数据总线的工作。
之前某一年双十一，若干货车等在某客户的仓库门外， OMS通过矩阵将订单打到客户的WMS, 而该WMS又没有对接批量接口，所有运货的工人都在等待每3秒一笔订单传输的时候， 我就下决心要做一个集成平台产品。来标准化多个系统间的对接方式。
最初我模仿的是Software AG，使用Golang搭建了一套ETL Pipeline引擎。这个名为Galaxy的产品如今也活跃在商派交付的内网跨系统对接上。
集成平台就是负责把数据从各家开放平台进行搬运的机器人。
但是系统中既有明确字段的结构化数据，也有混杂在文档中的非结构化数据。
既有API开放， 也有只存在浏览器上的HTML表结构。
于是一个名为RPA的新技术迅速火热，刚接触的一瞬间，这货不就是互联网上的按键精灵么。
所以， 从SAAS的强势发展， 到RPA的火爆。这里面有其必然性。
上一篇：
选择开发新零售系统的好处？给大家了总结了3点
下一篇：
新零售系统要如何去开发?看完这篇文章就了解了
沪公网安备 31010402000102号
电子营业执照
亲爱的市民朋友，上海警方反诈劝阻电话“962110”系专门针对避免您财产被骗受损而设，请您一旦收到来电，立即接听。
