在前几天，我专门写了一篇文章谈企业数字化技术发展趋势分析，整个分析比较宏观。今天主要还是想聚焦回IT和信息化部门，探讨下数字化转型下的IT架构和能力重构。
在谈这个这个话题前，首先还是对去年我在华南CIO大会上演讲时候谈到的企业IT从SOA和云计算发展到当前云原生下的一个演进趋势做下总结。
具体的文章可以参考：
传统IT架构转型-从SOA和微服务到云原生解决方案实践
这篇文章可以看做是在平台+应用，从内部集成到开放互联下，我对整个企业内部IT平台化思路的一些总结。但是这篇总结里面少了对于企业整体IT架构，业务和IT组织架构优化方面的一些思考。因此今天再写这篇文章进一步说明。
从SOA和云计算到云原生技术架构
对于SOA面向服务架构，其核心是一种架构思想。这个思想简单来说就是希望实现业务和IT的解耦，即业务流程或业务流程的实现最好是能够灵活地组装或复用已有的业务服务能力。
因此你可以看到为了实现这个思想你需要做两件事情：
其一是构建一个可复用的服务能力库
其二是对服务组装和编排，形成业务流程
因此SOA的重点是应用构建的模式发生了变化，从传统纵向烟囱式的构建，转变为了横向分层按原子服务-组合服务-流程服务的分层构建模式。在这个构建模式中本身又通过服务来实现了关键的业务和技术的解耦。
再次强调下SOA是一种思想，并不是特指SOA集成平台或ESB总线。不论信息技术如何发展演进，可以看到SOA这种通过服务分层解耦的思想始终存在，并不断发挥作用。
最近几年，每当我跟别人讨论SOA的时候，都会收到SOA思想过时，现在流行中台或微服务的声音，也希望这些人真正能够沉下心来好好理解下架构思想。
当讨论清楚SOA，再来看下云计算。简单来讲云计算的核心思想就是共性能力集中化建设，建设完成后再以服务的方式提供给你使用。
IT即服务
这个服务最初的形态仅仅是IaaS层的资源能力作为服务，而发展演进过程可以看到整个服务能力的提供不断在上移。从资源层能力到提供平台层能力，从平台层能力到直接提供SaaS应用服务等。
但是不论是哪一层，云计算核心思想始终都在于原来在终端或边缘端的能力全部迁移到云端进行统一提供和服务。SOA在强调已有能力集成，而云计算强调的是废弃已有能力，重新构建新能力再以服务的方式进行开放。
我们举个例子来理解下，比如企业内部IT，原来构建了OA系统，OA系统工作流引擎能力很强大，因此后续构建的其它应用都在集成或复用OA系统的流程引擎能力。这个即典型的SOA思想。如果我们将OA系统中的流程引擎剥离出来，充分考虑多租户，安全，管控需求统一构建一个公共流程平台，再对外提供服务，那么即云计算的思想。
在把前面的基础概念讲清楚后，我们再来回顾下企业IT架构演进过程。
即最初可能只是实现了IaaS虚拟化资源池，但是业务系统仍然是纵向独立构建。到了第二阶段开始规划PaaS平台，实现中间件资源池，一些类似4A，流程等共性技术服务能力的下沉。但是业务系统本身各个业务模块仍然紧耦合，同时业务系统里面还是存在一个私有的技术平台层。
而到了第三个阶段，目标就是业务系统里面的技术平台层全部移出到PaaS平台，这样业务系统可以彻底组件化大拆小，采用微服务架构进行设计，开发和集成。由于业务系统微服务化，颗粒度更小，因此PaaS平台本身也演进到更加轻量高效的容器云平台。
在微服务模块应用开发和容器云平台之间，我们需要一个衔接的平台，即我们常说的覆盖软件需求，设计，开发，测试，部署，交付完整生命周期的支撑平台。
所以从上图里面我们也可以清楚地看到，最底层对应到容器云，中间是DevOps，最上层是微服务，而这三点也就是我们当前说的云原生解决方案最核心的内容。
数字化转型下的IT架构演进
数字化转型，数字化很重要，但是转型两个字更加重要。
转型时刻都在告诉你你不是从0到1，而是你已有业务运作，已有IT系统和能力。你需要思考的是在新数字化趋势下如何去转变和重构，而不是全新建设。
数字化转型一定不要按全新建设方式来讨论，否则没有意义，或者简单来讲即使做了大而全的规划也服务真正落地实施。如何基于企业当前已有的业务和IT情况，在满足业务场景和目标情况下，对已有内容进行重构，并最大化保留当前遗留的IT资产才是重点。
在数字化转型中，企业传统IT架构演进的变化趋势如上图所示。
传统的IT架构，集成为主要诉求
传统企业IT一般IaaS层虚拟化的事情都做了，那么企业内部IT有无构建技术平台？实际上稍微信息化有发展基础的企业一般都构建了自己的技术平台，比如构建了统一的流程平台，也实施了ESB服务总线等。
这些技术平台统一规划建设，和业务无关，因此有效了避免了核心底层技术能力重复建设的问题，这个思路已经是云计算下构建PaaS平台的思路。
虽然核心技术能力统一建设，但是企业内部业务系统基本仍然是按照烟囱式的方式纵向独立建设，建设完成的业务系统再通过类似ESB总线进行接口集成。也就是说在这个阶段，ESB更多解决的是接口集成问题，而不是服务共享问题。
新架构下的演进-从SOA到云
在新架构下实际上出现了一些显著的变化。
对于平台层可以看到随着微服务，容器云，DevOps等各种云原生技术的推进。我们将技术平台层演进到云原生技术平台。
在这个阶段不仅仅是简单的4A或流程引擎，更加重要的是轻量的容器云PaaS平台，类似数据库，缓存，消息等各种技术服务能力提供。同时应用在微服务化后，提供一套服务完整的应用从需求到开发，从测试，集成到交付全生命周期的DevOps支撑能力平台。
也就是说我们提供的技术底座能力首先要加强。
在底层技术底座思考清楚后再回到IT应用这层。对于IT系统这层一个指导思想就是不应该是全部废弃掉，而是如何重构。基于上图，实际上已经表达出来IT重构的一个关键思想，简单总结就是：
企业已有的围绕ERP核心系统的应用群下沉为核心的中台层能力，同时进一步梳理和识别可复用的能力接口，通过能力开放平台暴露给前端应用使用。新构建的应用不是简单的使用微服务，云原生技术，而是应该最大化的使用底层已有的业务服务和数据服务能力来构建。
说来说去，还是SOA和云计算的思想。
可以看到企业原有IT能力下沉，共性能力提取是重点。其次就是从以集成为目标的ESB总线演进发展为提供共性服务接口的能力开放平台。同时可以看到，新思路的重点是新应用构建独立化，通过微服务方式快速构建和交付。
比如我们需要面对特定的B端客户，提供一个销售类APP应用。那么这个时候我们不是在传统的CRM系统上扩展模块，而是独立构建一个微服务应用。这个应用本身也会生成订单，但是订单属于底层核心数据，订单本身属于后台CRM系统统一管理。那么后端就应该围绕订单提供完整的API接口能力开放给前端应用。
后端提供的能力足够稳定和可复用，那么前端应用构建速度就可以足够快和敏捷。再次理解下就是后端能力不用基于多变的业务场景去进行变更了，而是提供稳定的后端共性能力，基于业务需求和场景的变化交给前端应用来做。
前端应用需要的就是短平快，但是前提是后端给力。
数字化转型下的IT组织演进
对于很多企业来说一般以业务核心价值链为导向，企业内部的IT部门往往是成本中心，一般也没有太多的话语权。IT部门更多的是提供IT服务能力，快速地响应业务部门的业务需求，并通过IT应用或系统去实现。
而在新的数字化转型趋势下，IT组织架构本身也需要进行调整，即将传统的基于ERP为核心的应用系统下沉为企业底层后台能力中心。而围绕具体的市场需求和业务场景来构建上层的多个业务人员+IT人员+运营整合的高度垂直化的细分团队。
简单来说你可以看到，原来IT部门的人进行了拆分。
对于原来本身做的IT系统就比较偏稳定的后台类功能的人员就保留在IT部门，下沉到IT后端能力提供中心中。而对于另外一部分需要业务敏捷响应，需要快速地开发定制应用的IT人员则单独划分出来，归并到上层的业务团队里面。
简单来说就是基于市场和业务场景的需求，我们构建一个个独立的能够快速响应市场和客户需求的敏捷业务单元。这个敏捷业务单元本身就是业务人员，技术人员和运营人员就是强绑定在一起的，形成敏捷铁三角。
这个敏捷业务单元实际和当前很多做互联网SaaS应用的小组织完全类似。
也就是说在企业内部，为了应对数字化转型，扩展自己的连接范围，扩展对客户的触达或对整个上下游供应链的触达能力，快速的基于业务需求来构建新的商业模式。企业内部在孵化类似互联网这种小的互联网SaaS团队。
这种SaaS小团队足够敏捷，直接面对市场，但是本身又依托企业原有IT系统建设沉淀下的后端IT服务能力。还是拿前面的例子进一步说明。
当我们经过市场调用分析，决策做了一个数字化营销新应用拓展B端客户和市场。这个时候我们快速组建了一个团队或小组织，这个团队里面业务人员，IT技术人员和运营人员全部打包在一起，商量业务模式，运营方法和需要提供的IT应用。而企业原来的后端IT系统能力仅仅提供可复用的开放能力接口给这个敏捷团队使用。
当把这个点想通了，整个传统企业IT架构如何配合数字化转型，如何在整个数字化转型实施过程中，在既要保证足够的业务敏捷性需求并开放互联，同时又要保证企业遗留IT资产的重复利用这两件事间才能够真正找到一个关键的平衡点。
