目录
4.2.1 提升技术能力，完成从集中式架构向分布式架构的转型
4.2.4 提升移动运营能力，从传统 PC 端向移动线上化转型
4.2.5 提升企业组织能力，建立与中台相适应的组织架构和方法体系
一、企业数据化转型概述
1.1 概述
不同企业由于发展历程或所处行业不同，其存在的问题和面临的困难也不一样，所以企业的诉求也会不同。传统企业数字化转型过程中遇到的这些困难，有偶然的因素，也有必然的原因。其中有一个非常关键的原因就是在应用建设过程中过度依赖昂贵的设备资源而忽视了技术能力的提升。在遇到性能瓶颈时，往往首先想到的是增加资源容量，而不是提升技术能力，改善应用效率，错失了技术演进的良机，以至于技术一直停滞不前。而当技术体系出现代差时，企业内各种问题就很容易爆发出来。
企业数字化转型是一个非常复杂的工程，也是企业能力全面提升的过程。但企业的数字化转型离不开企业技术能力、数据能力、业务能力和组织能力等多种综合能力的提升。这些能力属于不同的层面，企业首先要找到解决问题的根本和切人点，从提升基础技术能力入手，然后逐一解决业务模型统一、IT重复能力建设和组织能力建设等问题。
企业内全员要达成共识，站在企业高度围绕企业核心战略和企业需要迫切解决的问题优化组织架构，提升企业级综合能力，构建统一的业务模型，实现业务流程的复用和融合在数字化转型的过程中要细致规划，夯实技术基础，分步实施，小步快跑，不断检验和纠偏。
另外，企业数字化转型在不同的阶段会有很多不同的工作和任务，它们相互关联，相互依赖，有的是手段，有的是目标。手段千千万，而目标却只有一个。在学习其他企业的成功经验时，企业应该有清晰的顶层设计和战略目标，清楚哪些是手段，哪些是目标。确定目标后，根据企业实际情况选择适合自己的方法和手段来达成目标。如果错将手段当成目标，就很容易陷入邯郸学步的尴尬。
二、传统企业数字化转型的困难
由于企业发展历程、业务规模和自主研发能力不一样，企业在不同阶段的信息系统建设模式可能会存在差异。下面我们先来简单回顾一下传统企业数字化建设的历程和软件产品的建设模式。
2.1 传统企业数字化建设阶段划分
随着业务发展和自主研发能力的提升，传统企业信息系统建设可能会经历从产品外购外包、自主研发，甚至集团统一运营的建设阶段。
2.1.1 第一阶段，以产品外购方式为主
规模较小或初创传统企业由于IT人员较少，短时间难以形成自主研发能力，一般采用产品外购方式。
产品外购方式是指企业从软件供应商处购买成熟软件产品，或在购买成熟产品后，据企业内部业务需求进行定制开发的方式。
早期，很多成熟的套件化产品，往往会将很多功能打包在一个软件产品中。这样容易出现单体应用，即“一个系统包打天下”的问题，导致产品耦合度高，扩展能力不强，出现很多单体应用的通病。
2.1.2 第二阶段，自主研发为辅、外包为主
随着业务发展，当企业内部研发人员得到一定补充，达到一定规模，并具备了一定的研发和设计能力后，企业系统建设模式会慢慢转型为以自主研发为辅、外包为主的模式。
自主研发为辅、外包为主模式是指部分关键核心应用的项目管理、需求分析和系统设计由企业内部研发团队完成，而开发的工作仍然依赖外部人力提供商。这种模式下企业仍然需要采购大量成熟产品，或采用项目、人力外包方式完成信息系统建设。在这种模式下企业只能实现IT建设的局部可控。
2.1.3 第三阶段，自主研发为主、外包为辅
当企业内部研发人员达到相当规模，企业IT团队有能力实现核心业务全流程自主研发后，企业大多会选择以自主研发为主的模式。这时企业对自己的核心竞争力具有完全掌控能力，可以根据业务发展随时做出响应，持续保持企业核心竞争力。
自主研发为主、外包为辅模式是企业内核心业务领域全流程采用自主研发模式。但基于成本考虑，有些企业对于非核心业务领域可能仍然会通过项目外包或采购外部人力完成信息系统建设。在这种模式下，企业可以实现IT建设的完全自主可控。
2.1.4 第四阶段，集团统一运营模式
对于大型跨业经营的集团，不同子公司之间可能由于早期缺少统一规划，因此在技不栈和应用系统建设上存在较大的差异，导致集团内部出现大量IT重复投入和重复建设，难以在集团内实现交叉销售和商业模式创新。
集团统一运营模式是通过集团内统一规划、统筹管理、统一运营、重构中台业务模型统一技术标准、统一云环境和优化研发运营体系等，实现集团内各子公司之间业务流程的共享和联通、技术体系的标准统一和资源共享的信息系统建设模式。
近年来，越来越多的大型集团开始学习阿里巴巴，实施中台数字化转型战略。这种模式改变了集团内各子公司“山头林立、各自为政”的IT建设方式，可以在整个集团实现企业级业务能力复用和集团统一运营。
2.2 传统企业数字化转型的问题
过去这十年，移动互联等新型电商模式以及客户消费行为和习惯的改变，极大地刺和影响了传统企业固有的业务形态和商业模式。传统企业从封闭走向开放、借鉴互联网企业的成功经验，开始积极融人互联网商业生态圈。
但由于历史原因，传统企业背负了太多的技术债，长期的技术停滞导致技术能力严重落后，同时企业内各部门之间坚实的“部门墙”"，业务与技术之间的鸿沟，也给企业数字化转型带来不小的困难。
综合来看，传统企业数字化转型需要重点解决以下几个问题。
2.2.1 技术体系落后的问题
传统企业大多采用集中式架构，技术体系相对落后，可扩展能力不强。集中式架构过于依赖设备资源，基于稳定或性能考虑，大多运行在大型机或小型机上。同时，传统企业多采用“两地三中心”的容灾模式，高可用能力不强，难以实现多中心多活，也容易带来资源浪费的问题。
在运维能力上，过于依赖人工，难以实现自动化运维，面对突发高频访问的业务场景不能实现自动弹性伸缩。当业务量到达一定规模后，集中式数据库的容量和性能问题也容易成为业务发展的瓶颈。
总而言之、传统的集中式架构技术体系已经难以适应新形式下的业务发展要求
2.2.2 单体架构的问题
集中式单体应用往往会将多个功能放到一个应用中，经过日积月累，这个应用就会变成一个庞大而复杂的“怪物”。随着项目团队成员的更替，时间一长就很少有人能完全搞懂这些代码之间的逻辑关系了。有些人可能会因为担心修改遗留代码而出现不可预知的Bug而宁愿增加大量不必要的代码，这样会导致应用越来越庞大，越来越复杂，可读性越来越差，最终陷入恶性循环。对于整个项目团队来说，系统研发工作变成了一件极其痛苦的事情。
除了代码，单体应用还存在诸多问题。由于单体应用的各个模块之间耦合度高，很可能因为一个局部的小Bug，而导致整个单体应用不可用。另外，单体应用部署包过于庞大难以上云实现资源的弹性扩缩，导致应用扩展能力差且资源利用率不高。
同时，单体应用作为一个整体，也难以完成局部功能的技术升级。企业难以尝试新的技术，以至于技术能力一直停滞不前，无法及时完成技术升级，导致技术债越积越多。
2.2.3 研发和运维能力落后的问题
般单体应用的项目团队的规模较大，通常采用传统的瀑布开发模式。这种开发模式的弊端在于开发和测试周期耗时长，交付质量和周期难以保证，不能实现持续快速交付对业务需求和市场的响应能力相对较慢，难以实施敏捷开发。
另外，云计算平台和自动化运维工具对单体应用的生态支持有限，应用的部署和运维过程相对复杂。当应用出现问题时，基本靠人肉排查，且研发团队与运维团队难以快速定位和协同解决问题。
2.2.4 IT 能力重复建设的问题
为了支持企业内部业务发展，传统企业大多建设了一套集中式架构的单体核心系统。
而近十年来，随着互联网电商业务的快速发展，很多传统企业既要维持传统业务，又要向移动互联网生态圈开拓新业务。
由于传统集中式技术体系和研发模式难以支持互联网海量高并发的业务要求，为了免传统核心与移动互联应用之间的相互影响，不少企业在传统核心应用之外，采用分布技术体系建设了移动互联应用，但由于两者销售同质产品，在基本功能模块上存在交这样就出现了重复造轮子的问题。
除了传统核心应用和移动互联应用的重复建设外，在不同的业务场景或渠道也出现了业务同质化的问题。这些存在同质业务的不同渠道，可能也是重复建设的重灾区。
另外，在集团内部，由于缺少IT建设总体规划，不同子公司之间的公共业务能力(如客户等)的重复建设问题可能会更加突出。
所以很多传统企业出现了关于“双核心”或“稳敏双态”的争论。那么，为什么这类问题主要出现在传统企业，而没有出现在新型互联网企业呢?
我认为其根本原因是:“传统的技术体系、研发模式以及业务模型难以同时处理传统和移动互联业务发展的矛盾。”
综上，要解决IT重复建设的问题，就要从提升技术能力和重构业务模型入手，实现企业级业务能力的复用，这也是传统企业中台数字化转型亟需重点解决的问题。
三、AKF可扩展能力立方体模型
为了更好地理解企业数字化能力，我们先来了解AKF可扩展能力立方体模型，如下图所示，模型来源于《架构即未来》。它有X、Y、Z三个轴，分别从三个维度来定义软件产品的扩展能力。AKF可扩展能力立方体模型是软件扩展能力的理论基础，在云计算和微服务盛行的时代，该模型获得了越来越多的人的认可，在软件扩展能力建设方面也有很多成功的实践案例。
3.1 X轴，容量扩展能力
X轴关注无差别的服务和数据的复制，解决应用和数据库容量水平扩容的问题。当应用或数据库实例负载过重时，可以复制应用或数据库实例实现扩容。扩容后，任务可以通过负载均衡均匀分布到不同应用服务或数据实例，所有的实例都可以无差异地完成任务。
在分布式架构下，X轴的典型实践案例主要体现在**应用和数据库实例的水平扩展能力上**。如Nginx负载均衡，应用或数据库的多实例，应用的弹性伸缩，数据库多副本和读写分离等场景。
3.2 Y轴，业务扩展能力
Y轴关注应用的业务职责划分，如根据数据类型、交易类型或根据两者组合来划分业务和应用边界，在划分过程中会遵循单一职责原则。Y轴主要用于划分业务和应用边界，解决业务能力复用的问题。
Y轴的典型实践案例是从单体向微服务的演进。这个过程会有业务和应用边界拆分的问题。但是在单体拆分为微服务时经常会有人问：单体到底应该如何拆分为微服务?是否有成熟的方法来完成应用和业务边界的划分呢?
答案是肯定的!
DDD(DomainDrivenDesign，领域驱动设计)方法就是一种行之有效的划分业务领域边界的方法，以帮助完成应用的拆分和微服务的设计。它会按照流程或功能边界分解业务领域，根据业务上下文边界，构建领域模型，并将其作为微服务设计的输人。如将电商业务按照商品、订单、支付和客户等业务上下文边界进行轴拆分，构建基于不同业务边界的领域模型，最后完成微服务的设计和开发。
3.3 Z轴，数据扩展能力
Z轴关注数据的扩展能力，它按照业务类型或数据属性进行数据分片。根据数据分片策略将数据集划分为不同的数据子集，提升数据的扩展能力。如按照地域、机构或按照客户ID 哈希进行数据分片。
Z轴的典型实践案例有：数据库水平切分和单元化架构。
数据库水平切分是通过数据分片规则将一个大的数据集切分为多个数据子集，并分布到不同的数据库中，按照分片规则可以路由到具体数据库完成数据查询等操作。
单元化架构是按照业务特点或用户需求进行数据分片，将一个数据集水平切分为多个数据子集，然后根据数据分片分别部署业务应用单元。业务应用单元内包含若于依赖紧密的应用，应用在单元内可以不依赖单元外的服务独立完成单元内的业务全流程，以形成业务场景闭环。业务单元之间相互独立、天然隔离。当业务需要扩容时，只需增加和部署新的业务单元与数据子集就可以很容易实现扩容，从而提高业务的承载能力。单元化架构在很多多数据中心的多中心多活方案中都有实践。
3.4 AKF模型总结
综上，AKF可扩展能力立方体模型的X、Y、Z轴代表的三个维度相辅相成，涵盖业和技术的多个领域。通过克隆应用和数据库实例，可以提高应用和数据库的业务承载容最对应X轴扩展能力。通过划分业务职能边界建立领域模型，以拆分应用和设计微服务，以提高业务的复用和扩展能力，对应Y轴扩展能力。通过分片策略将数据集拆分为多个据子集或业务单元，可以提高数据的扩展能力，对应Z轴扩展能力。
企业将多个不同维度的扩展能力融合在一起，就可以实现应用能力的无限扩展了。
四、企业数字化转型的重要关注点
数字化转型是企业能力全面体系化提升的过程，远不是升级几个系统技术架构就能决的事情。这种能力的提升是企业从技术、业务到组织能力的全面提升，需要从技术能力、业务能力和组织架构等多方面，分步骤、有计划地统筹推进，从多个方面整体提升企业心竞争力。
4.1 技术能力方面和业务能力方面发展现状
4.1.1 技术能力方面
从技术能力来看，随着移动互联技术和电商业务模式的蓬勃发展，为应对海量高频业务场景，很多互联网企业研发并开源了大量的分布式技术，其中不乏成熟的解决方案。基于这些新的开源技术和方案，企业可以相对容易地用较低的成本完成企业信息系统技术升级和转型。
这些分布式技术大多开源于技术先进的一线互联网企业，且都经历过高频海量业务场景的考验，应该说完全有能力支撑传统企业未来很长一段时间内的业务发展要求。毕竟很少有传统企业，在业务上能够达到与一线互联网企业同等体量的业务规模。可以预见，随着开源的技术越来越多，未来企业技术升级的频率将会越来越快，技术(性能和扩展能力等)制约业务发展的短板也将会不复存在。
4.1.2 业务能力方面
从业务能力来看，企业之间的竞争会越来越激烈，企业面对的商业环境也会越来越复杂。为了持续保持核心竞争力，企业往往会根据市场发展和用户需求，持续调整企业整体战略，不断变革业务模式，快速推出与市场需求和发展相适应的新商业模式。
从长远来看，随着大量经过海量业务验证后的先进开源技术和云计算以及无服务器(Serverless)等技术的广泛使用，作为传统IT基础的技术能力，最终将会成为一种标准化和封装好的基础能力。就像使用操作系统一样，开发人员不再需要关注和陷入那些深奥的底层技术细节，而是可以真正将关注点放在业务能力设计和实现上。
不妨大胆预测，在不久的将来，这些基础技术能力将不再那么神圣，也不再成为制线企业业务发展的瓶颈。当然，这个过程还是免不了要提升传统企业IT从业人员的技能和认知能力，完成从集中式到分布式架构思维方式的转变。
反之，与基础技术能力相比，企业级可复用的业务模型构建能力、面对市场快速响的业务模型设计能力、数据智能驱动的精细化产品运营能力和快速的应用发布能力，将会在企业数字化建设中占据更加重要的位置，成为企业未来发展的核心竞争力。
这或许是阿里提出中台战略后能抓住很多企业眼球的原因吧。
4.2 企业数据化转型重点关注方面
结合传统企业数字化转型的困难和AKF可扩展能力立方体模型，我们一起来看一看传统企业数字化转型时应该提升哪些能力，以及重点关注哪些方面。
4.2.1 提升技术能力，完成从集中式架构向分布式架构的转型
技术能力是数字化转型的关键基础能力。技术平台统一、业务模型统一、数据整合和实时共享以及中台能力的建设等都离不开技术能力的强力支撑。
所以，企业数字化转型第一个重要关注点是完成从集中式架构到分布式架构技术体系的转型。
技术能力提升不仅仅是提升技术平台的能力，更应该提升人员技能、知识和方法体系等方面的能力，用新的思维和方法解决数字化转型过程中出现的新问题。
同时，要打破传统核心应用与移动互联应用的技术壁垒，促进两大关键技术和业务体系的融合。技术能力提升了，传统应用和移动互联应用才有统一的基础；应用统一了，才会有业务模型的统一；业务模型统一了，才能实现业务能力共享和复用，企业才会有实施中台战略的技术基础。
4.2.2 降低应用建设复杂度，完成从单体到微服务的转型
集中式单体应用承载了过多的业务功能，导致应用建设过程过于复杂、业务逻辑耦合度过高等诸多问题，因此，微服务应运而生。它采用分治的策略，降低了应用建设复杂度解决了单体应用建设过程中遇到的若干问题。
微服务业务职责单一，团队规模较小，可以更好地实施敏捷开发。微服务软件部署包较小，可以更好地上云，实现应用弹性扩展能力，提高自动化的运维能力，更好地管理和利用好资源。
所以，企业数字化转型的第二个重要关注点是完成从单体到微服务的转型。
4.2.3 提升业务复用能力，从 IT 重复建设到中台战略
企业可能由于缺乏总体规划，存在组织架构上的部门墙，技术对不同场景应用缺乏适配能力等原因，在应用建设时出现重复建设的问题，导致企业投入大量的人力和资源、却没有获得预期价值，还降低了业务响应速度和创新能力。
所以，企业数字化转型的第三个重要关注点是统一业务模型，实现企业级能力复用，降低IT重复建设。这也是企业数字化转型过程中最需要重点关注和解决的问题。
通过实施中台战略，重构企业业务模型，提升企业级业务的复用能力。在从单体应向微服务转型时，通过划分业务边界构建领域模型，将可复用的业务能力沉淀到中台领模型，建立企业级整体解决方案，实现业务和流程的组合、复用和融合。
4.2.4 提升移动运营能力，从传统 PC 端向移动线上化转型
随着电子商务销售模式的流行，客户消费习惯和行为已经悄然从线下场景转移到了线上移动端，这已经成为一个不可逆的趋势。智能技术在移植到PC端应用时，总是受限于PC端应用各种条件的限制，存在这样或那样的“水土不服”。但这些智能技术在移动端应用中却可以实现完美结合。移动端应用有更好的用户体验设计，正吸引着越来越多的用户也改变了用户的消费行为和使用习惯。
在企业级应用设计和中台领域建模时，可以分步骤统一传统核心和移动互联业务领域的领域模型、逐步完成传统核心和移动互联业务应用的融合，将内部员工和外部客户等用户逐步统一到移动端。在一个移动平台内实现企业内部、外部人员的一致性体验，完成移动线上化转型。
企业在制定IT资源投入策略时，可以将关键资源从传统PC端应用逐步转移到移动端集中企业核心力量打造和运营一个用户体验良好的移动平台。
所以，企业数字化转型的第四个重要关注点是统一传统核心和移动互联应用业务模型结合AI和大数据等技术应用，完成核心业务能力的移动线上化转型，进而实现企业业务能力的无限延伸。
在产品移动线上化后，企业可以将能力直接延伸到客户和前台一线，这样企业也就目备了实施数字化运营的前提和基础。
4.2.5 提升企业组织能力，建立与中台相适应的组织架构和方法体系
传统企业业务的割裂往往源于组织架构的边界和壁垒，在跨部门协同时往往存在部门墙现象，部门墙不仅存在于I科技部门与业务部门之间，也存在于业务部门之间。部门墙往往会形成应用系统之间的壁垒，导致业务复用能力差，应用和数据难以共享与融合。
其实很多企业早已经意识到，中台战略最终提升的是企业的整体组织能力。它不仅仅是IT科技部门的工作任务，更是企业一把手工程。如果不能站在企业高度来统筹协调，推动组织架构转型，中台的建设将会非常困难，也很有可能偏离中台建设的初衷。所以，中台建设要与优化组织架构同步进行。
也就是说，数字化转型的第五个重要关注点是提升组织能力，建立与中台建设、中台运营和商业模式创新相适应的组织架构。在企业全员建立统一的中台文化和方法体系，按照统一的标准和方法协同推进中台建设。
灵活敏捷的组织架构可以提升企业的业务响应能力，降低企业创新成本。组织优化企业数字化转型面临的最复杂、最棘手的问题，需要一把手用很大的魄力来推动。
好了，本次内容就分享到这，欢迎大家关注《DDD领域驱动设计》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
