干货 | 互联网新业态下的IT架构

（UR服饰信息总监  余宏标）

其实，今天的话题里有转型两个字，我是第一次听到转型这个议题出现在信息化领域。以前所有商业变化都是商业模式的变化，但从来没有听过IT在转型之中起到引领的作用，所以我觉得今天这个会议挺有意思的，而且很有创意。

首先我想和大家回顾一下企业数字化发展历程——电脑（电子化）-ERP（BI）-数字化（智能化）。我是70后，经历过三次，刚毕业时做的事很简单。那个时候最出名的东西就是电算化，那是最基本的IT基础，站在某个角度上来说就是单兵作战。最疯狂的时代，也就是IT发展过程中的第二个阶段——天天围绕ERP、围绕BI报表在做。在那个时代我觉得也算是一种进步，毕竟打通了各种业务流程的协同和业务数据的展现。但这些只是基础，IT还是挂在人力资源和财务下面。我相信现在很多企业还停留在这个阶段，但如果现在还要干这件事情，那我觉得大家干脆换一个行业可能会好一点。

在数字化或者互联网时代， IT带来的作用确实是指挥性的。IT的变革就像战争一样，解放战争是协同作战，现在的战争如果靠战区司令去指挥作战我相信一定是失败的，现在更多的是科技的、信息化的战争，所有的商业也是同样的道理。

在新的情况下，企业在IT方面有什么特点？业务部门对IT的需求很多，对IT的期望很大；老板希望IT部门能做智能化改造，零售改革，其实大家可能在这个过程当中会有一种抵抗情绪甚至是对抗状态。但IT现在真的是作为战略性部门、是指挥变革的部门了。它有这样的特点：

第一是灵活、降低成本。互联网最大的差别就是变化，现在各种费用成本很高，既要做的好还要便宜，这个是每个老板的期望。我觉得以前的IT更多的是造成浪费，像特步做了15年，IT部门不断换领导换系统。我们抱怨政府在这里修路，其实老板也在抱怨我们IT不断换系统，其实很多时候是我们没有从长远去考虑，造成了很多浪费。第二是现在业务部门也不是那么好忽悠，他们对IT的成熟度要求比较高，IT部门不能等待业务需求，更多应该是走出去，由技术转向做业务的转型。比如说以前做ERP有人会找很多借口“ERP系统都这样，500强都在用，改不了”。如果现在还跟业务部门干这件事情，我相信老板肯定是有意见的。

IT变革其实只有两个点，一个是业务走向互联网，IT自己的技术也走向互联网，通过互联网进行变革。不管是移动、电子商务，还是全渠道、社交、智慧、人脸识别都是物联网化的一种。这些技术需要IT进行内部的变革，现在开源技术，在IT里面非常疯狂，而且我本人也是特别喜欢玩这个，因为是自己做出来，感觉还是很有成就感的。我再想分享几个字，我上课经常讲的，现在很多公司喜欢讲ROI这个事情、如果你以ROI做IT规划或预算的话会很痛苦，而且你做完之后如果较真也很难做出实际效果来，所以IT创造的价值在于：一是通过“产品和服务的价格降低”以及“产品和服务的增值”两种形式转移到了企业的下游客户身上。二是ERP的价值（成本降低、产品增值）并不一定能够反映在财务指标的盈利能力上。这是思维的改变，也是做IT应该要改变的地方。

这是传统的架构图，有N个数据库不断的平行去做，如果阿里这样做肯定会出问题的。

简单分析一下，以前的做法会有什么问题？第一个前端会有不同的技术原理，会有很多接口，现在公司的安全问题不是网络攻击造成的，是因为我们做的程序、接口没有做到安全的认证和加密做法，这个才是安全的最大风险。现在大家做的东西很多，却没有容错性、交互性很差。另外，每个业务板块都有共性，有时候代码可以复制使用。但是代码重复性就导致开发效率成本非常高。第三个是复杂度，就像有些公司做系统的时候，可能原来想的比较简单，五六个功能，这个系统越做越大，几百个功能在里面。想一下这个系统对硬件的要求就会出现很大的问题，它的复杂度和偶合度会被你拉得越来越深，越来越长，你做分布式云计算时就会很痛苦。第四个是数据交换、接口太多，会导致很多数据上的问题，或者数据上一致性、完整性的问题也都会出现，只要做了接口就一定会发生。

这是SOA和微服务的区别，以前讲究中心化，现在要打破中心化，去做最小融合的架构。随着互联网企业内部IT越来越丰富，应用会越来越多，功能也越来越多。我不建议大家看到市场有好的产品就买回来，买了很多小系统和小功能，到时候这个东西就会出现很大的问题，我更喜欢学习和了解，然后转化成自己的东西。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

现在做IT建设已经不是以系统为单元了，当一个企业像组织架构一样进行中台化的构建，你不要做多套库存管理模式，采购也不能做多套模式。每一个业务板块都有它的共性，你要把它的中台的共享服务中心整理出来。通过互联网的技术，微服务、API Gateway和分布式事务来打造前端的应用。

前端就是打造企业内部的统一门户，从应用、用户、流程、功能整体打造一个服务中台。现在每个企业都一样，做很多的是品牌拓展、渠道拓展和国际化拓展，但同时我们要考虑，是不是真的要做多品牌化、多渠道化和国际化多品牌地去打造IT系统，我们做这个系统要往这个角度去考虑才能适应公司的趋势。

技术门槛不详细讨论了，一般来说，外部的系统要收，内部的系统要紧。另外，现在的企业运维平台管理是需要完善的，因为我们帮应用打造很多工具，偏偏自己没有工具，自己还在敲命令，跑到机房里面摁按钮。

这是传统的微服务架构的做法，这个过程中各种打通其实都是IT在后面打通。

这个是真正的服务中台，以会员、商品、交易、支付甚至促销为中心，保证线上线下各种业务同意还真考虑各种事情，将这些模块搭建起来就好。

再讲一下大数据，做了那么多系统系只是一个数据，要变成数字化必须通过理解、学习、推理，将你的想法、不相关的和相关的通过推理变成关联的东西出来。真正的对用户有价值的不是算法，是执行，就是所谓的AI，变成一种指令。IT做数据的几个阶段，传统的做法是看KPI、看指标，但这只是发现问题，我们未来应该要知道这个问题发生在哪里，这个问题发生后有什么措施解决，能不能预测这个问题，这个才是未来做大数据的价值点，或者对业务有帮助、指挥作用的概念。

 前面做了预测模型，通过前面的模型将这些指令发放给业务部门的指令，将你的商品告诉设计师怎么做设计，你能告诉消费者去买什么商品，将你的指标模型告诉业务部门应该做什么动作，这是真正的由大数据得到指令型结果给到业务部门的执行。

以下是大数据的基础架构图，左边传统，右边是真正希望做的事情，下面是内部数据、外部数据和第三方数据。

你做任何事情，做好规划，再做迭代和敏捷开发就有基础了。在敏捷开发情况下，IT组织架构不能以传统的做法，不能又对运维组，又对项目组。现在很多IT部门都喜欢这样操作：项目组负责项目，运维组负责运维。但我认为现在更多是以产品的方式去做，就是是以板块的方式、以产品经营的方式去做你的IT基础架构，然后做这个模块的迭代开发和满足业务的需求，带来业务的变化。

我的分享到此结束，谢谢！

温馨提示