企业转型的三个“小趋势” | 商业洞见
2018对我来说是有很多收获、很有意义的一年。整个上半年完成了一个产品、包括分布在东亚和东南亚三个研发中心的分布式团队转型工作。从上周团队负责人反馈的成效来看，确实给产品的质量和团队的工作氛围带来了提升。我很荣幸能够参与到这个产品和团队的转型过程当中，见证了从开发人员到组织管理层一步步的变化。下半年的工作比较零散，主要帮助了几个团队完成了对当前状态的识别和下一步的规划。领域驱动设计社区的影响力在团队的协作之下进一步扩大，年底的大会对整个社区的实践做了一个全方位的检阅和整理，与企业和国外社区的合作也打下了明年尝试构建更广泛生态的基础。
就在刚才，我打开Google日历，回顾了2018年经历的事情和服务过的客户，以及和不同企业、不同层级、不同部门、以及ThoughtWorks同事的每一次沟通，我想可以把我的2018的所思所想，总结成三个我能看到的，并没有那么小的“趋势”。
一、数字技术本身，已经成为企业转型和创新的核心引擎
回顾过去几年我所经历的企业转型，在转型之初，企业一般都会选择从组织和管理的角度入手开启自己的转型步伐。造成这种选择的背后原因有很多。从组织本身来说比如由于历史原因，组织并不具备技术研发能力，更希望从IT管理侧驱动转型；又比如组织确实具备一定的研发能力，但是由于技术水平有限，希望先通过管理的转型进而拉动技术实践的变革。外部来看，市场上管理领域转型方法论的商业运作及影响力要远远好于技术转型的方法论，这可能也是原因之一。从过去若干年的实践经验来看，管理的转型会前置于技术的转型，甚至管理的转型可能是企业转型当中的唯一一个切片。
但在过去几年社区方法论的发展情况来看，技术实践的演进速度要远远快过管理实践的演进。从极限编程到持续交付、再到DevOps，技术实践本身已经超越了所谓仪式（Ceremony）的范畴，逐渐走向真正的“一切Dev说了算”。从企业的具体实践来看，先突破技术的瓶颈，进而逐渐引入管理实践和组织变革，也成为一种可行的转型思路。
举个例子，在第四季度我参与了一家日本汽车制造企业的供应链管理变革项目。与我们同时进行的，是该企业集团内部的精益生产变革项目。两个改进小组同时进场，同时开展工作。精益变革小组的改进举措包括了自动化掉现有的人工工作、加强组织间的信息共享和协作等。我们小组的方案是以数据为核心，首先提升数据的质量，利用新技术（区块链等）强化数据的收集渠道，然后通过数据的透明，尽早（8周之前）将供应链的风险与问题暴露给企业，从而加强供应链本身的可预测性和可管理性，进而赋能供应链生态中的日本企业在精益生产方面的诉求。在落地过程中，仍然建议要从管理和组织的维度去变革，来更好的收集数据、分析数据、利用数据指导生产。
在这个案例中，过程还是有些波折的。例如处于差异化竞争的考虑，我们一直在避免走到管理咨询的道路上去，但是最后发现如果没有管理方面的配合，即使技术转型的基础搭建起来了，整体上的转型过程仍然可能遇到组织配合和合作的陷阱，使得转型方案没有办法100%落地。但当我们站在企业的角度（要知道日本是精益生产的起源地，大多数客户自身都是精益专家）来看，另外一条精益改进的道路，即从管理的维度逐步展开持续改进，并没有给出一个全局性的问题识别结论和解决方案。这种从管理维度逐步改进的方案，风险可能是经过了一段时间之后发现并没有带来什么效果。对于这家企业来说，像我经历的其他很多企业一样，从逻辑上看风险更低、投资回报比更合理的选项，是让技术变革成为驱动整个供应链变革的核心动力。
这个案例给我的另一个启示是，在转型的过程中数据的收集策略和分析策略应该是转型的前置条件。不能说清楚数据上的收益、没有技术手段及时收集和分析数据、亦或不能及时反馈数据上的进展，转型的过程就好像是在黑夜里摸着石头过河。组织活动的开展看上去轰轰烈烈，但是当咨询顾问一走，或者当这阵风过去，一切又恢复到了老样子上。
二、业务和技术的融合，成为企业转型的焦点
2017年，我的工作重心还聚焦在微服务和敏捷转型上。在那个时候我和我的同事经常会跟客户讲，转型项目成功的关键是能够加入业务部门，让业务人员真切地看到转型的好处。获得了业务部门的支持，转型的影响力就能出来，变革项目也会持久。到了2018年，几乎同样的话我们已经没有机会再主动提出，而客户在第一次或者第二次交流的时候，就会主动问到你们有什么手段和方法可以让业务部门更主动的加入进来，可以让我们的转型得到业务部门的支持。
在这一年中，我的另一个主要客户一直在努力寻找这个问题的答案。企业为了追求业务的响应能力，从根本上认识到了机构业务的实质是基于技术提供的服务。基于这个基础假设，该机构打破业务和技术的壁垒，将业务和技术做了重新的整合，实现了IT能力前置，以赋能业务。2018年，我同样很荣幸能够参与到这个企业的转型过程当中，亲眼见证他们是如何重新定义了业务和技术的协同合作方式，并且用新的方式来推进新产品研发的。
业务和技术的融合也对技术团队间的合作带来了新的挑战。一般来说，企业除了赋能业务的技术团队之外，还会存在负责企业级支撑和治理的IT团队。如何处理前端业务技术融合团队与后端支撑治理的平台团队之间的协作关系，就又成为了一个新的课题。其实在很多年以前，我还是个新手咨询师的时候，就听到过我的前辈们在和客户沟通平台与应用团队之间的合作原则：做小平台、做大应用。平台做小只实现基本的治理，做大应用提升对业务的响应能力。这个当年似乎是真理的建议放到今天看来，似乎显得不合时宜。阿里的中台概念一抛出，企业都纷纷表示希望引入中台来帮助自己提升业务响应力，降本增效，同时打破数据的壁垒来建立统一的数据中台。2018年，伴随着《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书的火热，中台已经成了国内技术市场的焦点，并且可以确定的事，中台的概念在2019年会进一步的放大和强化。
三、架构的转型是企业转型成功的拱心石（keystone）
中台概念一出现，一开始我个人的理解是这是一种企业架构治理手段，或者说是企业架构风格的一种新发展。但是经过了几个月的摸索和实践，中台的范围和目标要远大于企业架构的范畴。作为一名领域驱动设计的实践者，分清问题域和解决方案域是基本要求。我认为中台作为一种解决方案，主要解决了企业的三个主要问题。
第一、降低企业架构治理成本和开发成本。在之前的企业架构实践当中，治理各个不同业务单元的IT系统建设一直是一个普遍的痛点。企业架构师的很大一部分工作，是来评审各个业务单元所要开发应用的设计文档和实施规划，最终给出一个结论“这个应用是否可以开发建设”。有了中台以后，企业架构师可以将企业级的业务规则，统一封装在中台内部；而将业务应用和创新的职能，以及业务部门内部的应用级规则，交给了业务部门本身。因此，不需要由企业架构师进行统一审核，这提升了企业架构落地的效率和有效性。
第二、打通数据壁垒，提升数据利用能力。在以前的企业应用构建方式当中，由于种种原因，各个业务单元的系统之间的数据是很难打通的，或者打通以后反而使得数据质量出现下降，使得利用数据产生业务洞见的效果大打折扣。中台从概念的维度上可以改变这种现状。业务中台可以让企业范围内的数据更有效的收集，数据中台通过数据湖和湖畔市集的建设，利用自服务的方式，赋能业务团队去利用数据来指导业务发展。通过阿里的案例来看，业务中台和数据中台的整合是最大化利用数据的一个很好的方式。
第三、降低应用开发的上市周期。中台提供的企业级服务能力，可以让前端的业务团队更快的组织自己的业务应用，并且依据自己的业务目标来规划自己应用的上线周期。而后段企业级业务规则的变化，会被合理在中台范围之内。一旦业务规则发生变化，中台的变化可以独立于应用，并且可以以最快速度在整个企业的所有应用中生效。这也是中台能够给企业级业务带来的最直接的好处。
从实现落地的角度看，中台的建设很难脱离三件事。
首先，是对于企业级业务规则和企业级服务能力的识别。记得在三年前做微服务咨询的时候，遇到过一个在南京的团队。他们在做的微服务从技术架构的角度来看还是很先进的，但是当我们讨论服务应当如何拆分的时候，就陷入到了复用和可变的细节当中。企业中台的建设也是如此。我们发现很多企业在讨论中台的时候仍然没有去分清“企业级业务规则”和“应用级业务规则”，使得基于复用的中台设计方案看起来边界模糊不清，在落地的时候也会和前端应用团队产生各种合作上的问题。可以预见在2019年，如何去界定中台的边界会是要经常被讨论的问题。我个人仍然认为，在识别企业级业务规则和服务的领域，领域驱动设计（DDD）可以发挥它的作用，帮助企业识别中台的边界在哪里。站在赋能业务的角度看，小平台、大应用的思路仍然是可以工作的。具体平衡点的选择首先要基于最大化的增强业务响应能力，其次是如何使企业业务规则更有效地被执行。
其次，中台是难以脱离现有系统，尤其是后台核心系统的架构治理和改造。在过去十几年的时间内，企业都通过不同手段构建了自己的业务核心系统。这种情况从金融行业到电信行业，再到汽车制造行业都是普遍现象。构建中台能力就要求对既要继承现有核心系统的业务规则，又要将核心系统的能力通过服务化的手段暴露出来，变成中台的支撑或者中台的一部分。如何将核心系统从传统的封闭平台迁移出来，以及如何保证架构改造的过程是安全和完备的，这对每个行业的架构师都是一个巨大的挑战。
最后，是难以脱离对业务目标和愿景的支撑。中台建设的过程相对比较复杂，既需要对现有系统进行改造，又需要构建中台所需要的各种技术基础设施。这样一个复杂的企业级平台系统的构建过程必然是复杂和长期的。这个过程当中如何引入业务部门，如何在MVP版本的中台中就能够为前台应用带来支撑，如何通过DevOps实践最大化赋能中台的构建过程，就成为中台规划和建设过程中必然要考虑的因素。
写在最后
2018年下半年开始到现在，我们和几个企业的团队合作企业核心系统的改造工作，主要以金融行业为主。通过架构改造不仅仅可以让后端核心支撑更多的业务场景，同时也提升了企业内部的开发者体验，提升开发效率，我们也在逐渐完善面向传统海量代码（支持Java、C++、和plsql）的架构分析和治理工具，这些都是在尝试为企业中台建设打下一个好的基础。
希望在2019年能把工具本身开源出来，同时向技术社区和企业介绍面向大规模金融核心系统的架构改造和微服务化的成功经验，希望能够为更多的企业大型核心系统的改造工作提供工具和案例上的支撑。
- 相关阅读 -
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。