1.2 数字化转型企业架构
数字化转型对架构的要求越来越高，从软件开发和系统设计的角度来看，IT人员一般接触比较多的是技术架构、系统架构、应用架构、部署架构等。但是，什么是架构，它的本质是什么，架构还有什么其他类型，什么架构适合企业数字化转型，有哪些典型的架构参考框架，如何做好企业级别的架构设计等，让我们带着这些疑问进入这一节。
1.2.1 什么是架构
架构本身是一种抽象的、来自建筑学的体系结构，其在企业及IT系统中被广泛应用。回想笔者自己的从业经历，一直在和架构打交道，在欧洲攻读硕士学位期间主要研究企业架构与领域建模，在北美洲攻读博士学位期间主要研究云计算和微服务在建模领域的理论和应用，以及一些云平台、中间件、大数据等的跨领域实践，在工作后一直从事与架构设计相关的工作，并且一直在思考什么是架构、架构的本质什么、有什么理论方法可以帮助我们做好架构等。
什么是架构？下面我们先来看几个定义。
（1）百度百科的定义：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
（2）维基百科的定义：架构即软件体系结构，是指软件系统的基本结构，以及创建此类结构的规则及这些结构的文档。每个结构包括软件元素，它们之间的关系，各个元素和它们之间的关系的属性，以及每个元素引入和配置的基本原理。
（3）ISO/IEC 42010的定义：一个系统在其所处环境中所具备的各种基本概念和属性，具体体现为其所包含的各个元素、它们之间的关系，以及架构的设计和演进原则。
（4）IEEE的定义：架构是环境中该系统的一组基础概念和属性，具体表现就是它的元素、元素之间的关系，以及设计与演进的基本原则。
（5）CMU软件工程研究院的定义：架构是用于推演出该系统的一组结构，其具体是由软件元素、元素之间的关系，以及各自的属性共同组成的。
（6）TOGAF（The Open Group Architecture Framework，开放组架构框架）的定义：一个系统的形式化描述，或指导系统实现的构件级的详细计划。一组构件的结构、构件间的相互关系，以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。
综合上述定义，可以看出，对于架构的定义有几个高频关键词：元素、结构、关系、原则、演进。架构相关元素按照一定的结构连接在一起，同时提供相应的原则和规范进行持续演进。架构就像建筑学中的体系结构，比如在故宫平面图中，整体的结构、房间的主次、彼此连通的道路通过一张图可以直观地展现出来，同时各个房间的大小也按照实际情况进行了精准的绘制，这其实就是架构的美妙之处。
1.2.2 架构的本质
架构的本质是对事物复杂性的管理，是对一个企业、一个公司、一个系统复杂的内部关系进行结构化、体系化的抽象，并把相关的目标和当前现状通过不同的视图进行直观展示，方便相关人员达成共识，指导和驱动数字化项目落地实施。在这个管理事物复杂性的过程中，有四个非常重要的架构思维，分别是抽象思维、分层思维、多维思维和演化思维。
1）抽象思维
抽象是对某种事物进行简化描述的过程，关注元素，忽视其他细节。抽象在架构设计中非常重要，抽象能力的强弱，直接决定着我们所能解决问题的复杂性和规模大小。例如积木城堡游戏，一个城堡由若干子模块组成，而每个模块最终由不同形状的积木搭建而成，这种自上而下或者自下而上的抽象组合过程在架构设计中十分重要。抽象关注元素，忽视其他细节，如图1-5所示的毕加索抽象画，毕加索对一只复杂的公牛进行了高度的抽象和简化。再比如，从电商角度，一个系统可能被我们抽象出不同的模块，以下订单为例，可能需要经过商品价格查询、库存更新、优惠方式计算、支付方式校验、物流方式更新等一系列流程，这一系列流程本身就是对高度抽象过程的总结。
图1-5 抽象思维举例：毕加索抽象画
2）分层思维
分层是在抽象的基础上进一步体系化地分析事物，因为抽象出来的元素可能不在同一层次，比如可能需要我们从业务模块的垂直层面或者系统功能的水平层面进行思考。分层思维是很重要的架构思维，比如我们看到的操作系统，就可能被分为内核、内存管理、输入和输出管理、文件管理、用户界面层；或者如图1-6所示的网络分层，经典的七层模型即物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。再比如，人们经常讨论的技术架构包含部署架构、集成架构、开发架构、测试架构、运维架构、安全架构等，这些都是从不同层次进行划分的。
3）多维思维
随着事物复杂性的提高，我们往往需要从不同维度对事物进行分析。分层思维帮助我们从不同层面对事物进行分析，而多维思维要求在架构分层的基础上，从更广、更高的维度对事物进行综合分析。比如，一般我们在做架构设计时，需要分析业务需求、业务流程、领域建模、技术支撑，除了对每层进行分析，我们还需要分析什么业务与什么流程匹配、什么流程与什么模型对应、什么模型使用什么技术，同时要结合组织阵型、项目运营管理，从不同维度来进行全面的分析。多维思维更多强调矩阵分析，比如衡量客户价值和客户创利能力的典型模型——RFM模型（见图1-7），通过三个维度不同分类的组合，分解出八种客户画像。
图1-6 分层思维举例：网络分层
图1-7 多维思维举例：RFM模型
4）演化思维
架构是设计出来的，更是演化而来的。架构的形成是一个不断迭代的过程，而这个过程其实是对整个企业进一步有序化地重构和升级，以实现进化并支撑业务快速发展。可以说，人类世界是以分层方式一层一层搭建和演化而来的。架构模式不是固定的，比如架构经历了从单体模式到SOA（Service Oriented Architecture，面向服务架构）模式，从SOA到微服务架构，从微服务架构到云原生架构的演变。再以云原生技术中的Serverless为例，图1-8所示为Serverless的演化，从物理机（Physical）时代、虚拟机（Virtualisation）时代、云计算（Cloud Compute）时代、容器（Container）时代到达无服务器（Serverless）时代，使用户无须关注程序运行环境、操作系统、网络配置、资源及容量，只要将精力聚焦在业务逻辑和技术上即可。
图1-8 演化思维举例：Serverless的演化
当然，基于架构的本质，反观我们平时接触到的架构，往往有一些典型的误区，具体体现在以下几个方面。
（1）缺乏全局架构视角。我们前文提到的数字化转型的首要切入路径是“全局战略，总体架构规划”，然而很多企业缺乏全局架构视角，认为架构仅指IT架构，或者更小的运维层面，其实架构涵盖企业的战略、业务、应用、技术、数据、产品、运维、部署、集成等方方面面，总体规划和全局视角非常关键。
（2）缺乏架构治理演进。架构设计不是静态的，而是动态演进的。只有不断应对变化的架构，企业才有生命力，因此企业需要借助相应的架构治理来推进架构的持续演进。这个过程也是体系化的过程，如相应的架构成熟度评估、相应的组织和决策机制、架构的设计原则和规范，以及长期的运营治理意识和机制保障是必不可少的。
（3）组织缺乏有效保障。架构需要组织的保障，一些传统企业仅仅要求IT部门的运维人员进行系统维护，对架构不够重视。其实，架构既需要全方面构建，也需要对应的组织保障，比如企业应设立对应的架构委员会，提升对架构的认知，同时明确对应的角色、权责，以及相关的人才培养和考核机制等，企业应更加包容和开放。
1.2.3 架构设计的基本原则
基于对架构本质的理解，关于架构设计业界有一些非常好的基本原则，比如《架构整洁之道》一书中提到的SOLID原则（下面各个原则的首字母）。这些虽然是面向服务设计的原则，但对于架构设计同样适用。
1）单一职责原则（Single Responsibility Principle）
基于康威定律的启示，每个模块有且只有一个被更改的理由。在架构设计过程中，特别是在抽象和封装过程中，应尽量设计得没有互相重叠（如相关的流程、服务功能），有明确的使用者和操作者，比如订单核心能力的最终修改，需要聚集在一个单独共用的模块上，这样职责清晰，也便于后续架构演进。
2）开闭原则（Open Closed Principle）
企业应对扩展开放，对修改关闭。也就是说，企业的架构要尽可能考虑扩展性，减少不必要的修改，比如企业可以采用模型的扩展、服务接口的继承、流程的编排、能力的组合等方式，通过分层和扩展解决用户不断变化的诉求，这样也有利于快速支撑业务发展。
3）里氏替换原则（Liskov Substitution Principle）
任何基类可以出现的地方，子类也可以出现，二者是“IS-A”关系，如绵羊是羊的一个种类。企业在进行架构设计时，如果有些架构是相互继承的，则要关注其中的继承关系，如从应用架构到具体部署架构的分解过程。另外，我们通常把核心的原子能力进行最小集的封装，在架构扩展设计中，任何对原子能力的扩展都需要维持原子能力的定位。
4）迪米特法则（Law of Demeter）
如果两个模块无须直接通信，就不应当发生直接相互调用，可以由第三方转发。在架构设计过程中，要尽可能减少不必要的相互调用，降低模块之间的耦合度，提高相对独立性。
5）接口隔离原则（Interface Segregation Principle）
在架构设计过程中，企业需要避免不必要的依赖，也就是最小化组件（或模块）之间的依赖度和耦合度。在架构设计中，主要要求尽量保持组件之间的耦合，这样既可以降低相互的变化影响，也可以增强组件的可复用性。架构的设计尽量不要依赖不必要的东西，比如业务架构应聚焦能力、流程，应用架构应聚焦领域、服务，技术架构应聚焦技术组件支撑等，避免修改一种架构要连带修改其他分层的架构。
6）依赖反转原则（Dependence Inversion Principle）
企业的高层策略不应该依赖底层细节，而底层细节应该依赖高层策略。比如，当设计服务的时候，下层服务不应该修改上层服务，如电商中的订单分层高于商品和促销，在订单层级可以修改商品库存、促销状态等，而反向操作是不允许的。
此外，业界还有一些比较经典的架构设计原则。
（1）正交性。架构设计要考虑全面，保持正交，职责独立，边界清晰，没有重叠。这类似于结构化思维中的MEMC（Mutually Exclusive, Collectively Exhaustive）法则，即相互独立，完全穷尽。
（2）高内聚。同一层架构内应该是高度内聚的，就像一个不可分割的整体，否则就应该拆开。
（3）低耦合。不同层的架构间应该尽量降低耦合度，这样既可以减少相互的变化影响，也可以增强组件的可复用性。
（4）简单适用。架构并不是一成不变的，规划要全面，落地时要讲究合适原则和简单原则，应以符合当前业务发展需要为主要目标，而不是单纯为了设计架构而设计架构。
1.2.4 关于企业架构
从前文可以看出，应对数字化转型，企业需要将业务、应用、数据、技术等架构领域紧密关联，使得各领域形成一个有机整体，快速响应外部驱动、技术进步、战略调整等带来的各种变化，精确控制和协调各部分的协作，以打造敏捷性企业。因此，建立有效的机制使IT与业务更好地融合，进而产生更多的业务价值，提高企业核心竞争力等，成为企业亟待解决的问题，结合了战略、业务及IT系统的企业架构由此产生。
很多企业管理者缺乏数字化转型的指导和方法，因而往往无从下手。事实上，从企业架构入手是企业进行数字化转型的不错选择。笔者第一次接触企业架构这个概念是多年前在欧洲读研的时候，当时学习了相关的企业架构方法、建模理论、企业管理和整合管理等体系，刚学完没有体会到企业架构的作用，但在后来的工作中，特别是在阿里云做云原生解决方案架构师时发现企业架构对于整个架构设计有非常大的指导作用。企业架构有几十年的发展历史，有很多成功的案例，在各国都有较为广泛的应用，其在推进信息化建设方面可以起到很大的作用。在如今的云计算、移动互联和大数据时代，企业架构基础非常有效，如果结合先进的互联网和云原生技术，应用和实施与时俱进，并融入最新运营模式，就能助力企业数字化转型。
企业要想实现长期可持续发展，需要保证企业战略、业务、IT的一致，而企业架构就是其中的“黏合剂”。企业架构的基本组成如图1-9所示。
图1-9 企业架构的基本组成
（1）业务架构：把企业的业务战略转化成日常运作的渠道，承载了企业所从事业务的核心逻辑，涉及从战略到商业模式、价值链的转化，以及业务能力、业务流程，还包括组织结构和运营体系等。
（2）IT架构：指导IT设计，是企业信息化建设的蓝图，包括应用架构、数据架构、技术架构。应用架构更多关注领域、服务和对应的功能，我们常说的应用、系统、组件等一般属于应用架构范畴；数据架构突出数据模型，包括相关的实体、属性、关系等，以及相关的数据分布和管理，数据架构强调对数据的管理和运营，如电商的“千人千面”等；技术架构是支撑整个架构体系的技术部分，涉及传统的单体架构、服务化、平台化，以及云计算中比较前沿的云原生技术架构体系，支撑系统的稳定、可靠及高性能。
1.2.5 企业架构给企业带来的好处
企业架构可以给企业带来很多好处，主要体现在以下几个方面。
1）创新
企业架构可以帮助企业实现业务的快速创新。企业架构设计可以根据市场的变化灵活地调整，以平衡IT效率与业务创新之间的关系，同时可以帮助企业管理创新。
2）提高效率
企业架构可以优化各个业务流程，打通各个业务流程环节，使得各流程充分协同，各部门可以安心地进行创新并合力助力企业形成市场竞争优势。
3）降低成本
在IT架构层面，企业架构可以避免重复建设，节约IT成本，并通过全局架构充分利用业务流程和人力资源，避免形成信息孤岛。
4）降低风险
企业架构是一个整体，可以帮助我们了解企业各个流程的风险，实现企业内部信息的对称，并通盘考虑和优化，避免信息不一致，从而降低风险。
5）组织协同
企业架构提供统一的沟通方式，可以保证组织的紧密协作，并通过对利益相关者之间的需求管理及显示的架构视图，让决策者缓解冲突，提高协同效率。
6）人才培养
企业架构可以帮助企业员工提高业务运营能力、增强全局意识，使其成为既懂业务又懂技术的核心战略人才，从而帮助企业培养全面的人才。
1.2.6 企业架构的基本框架
企业架构经过几十年的发展，已经形成比较系统的理论和方法体系。自1987年约翰·扎克曼（John Zachman）开展开创性工作以来，这个领域积累了大量的研究和实践，国内外很多专家和学者从不同角度做过探讨和分析。此外，企业架构已经形成TOGAF、FEAF、DoDAF、Gartner等，还有大量的咨询公司和研究机构等提出了各自的理论框架。
尽管目前企业架构的定义并没有统一标准，但可以明确的是，企业架构是企业战略和总体规划的组成部分，目的是帮助企业有效地组织资源和完成IT战略。企业架构要从企业整体业务战略出发，从整体运作和提升竞争力角度出发，站在全局的高度，明晰企业所处的行业、发展阶段、目标和竞争环境等，认清核心业务战略和IT战略，提出关键业务流程和业务逻辑，明确总体目标，并根据进一步与之匹配的IT架构进行多方位呈现，同时通过实施的落地项目进行架构落地，最后通过架构治理，提升日常运营及架构治理能力，完成迭代闭环。
企业架构的基本框架主要包括四个阶段，如图1-10所示。
1）企业战略分析
企业架构是为实现企业战略服务的。企业战略包括业务战略和IT战略，二者之间互相影响，环境的变化也会影响战略的制定，业务战略和IT战略要保持对齐。企业战略的分析需要通过需求调研，了解企业所处行业及其目标、发展阶段、战略、优势和劣势、竞争对手、信息化能力、核心竞争力，以及对应的商业模式，然后根据这些战略信息形成企业的基本组织框架、流程框架、业务逻辑框架，帮助企业找到最为紧迫的业务、信息化痛点和瓶颈问题，为后续阶段的发展奠定基础。
图1-10 企业架构的基本框架
2）企业架构规划
企业架构是战略设计和数字化项目的桥梁，具有承上启下的重要作用。业务架构用来落实业务战略，包括流程、组织、逻辑等；IT架构用来落实IT战略，包括应用架构、数据架构、技术架构。业务架构和IT架构要保持对齐。
3）企业项目实施
企业项目实施承接企业架构规划，关系着企业战略是否能够落地。企业项目覆盖数字化项目，根据轻重缓急分阶段实施，包括IT项目和一些管理类项目。在企业项目实施过程中要分析各项目的前提条件、风险、投入和成效。
4）企业运营治理
日常运营是架构实施的保障，需要通过运营指标和相关机制来驱动架构的持续演进，并优化和完善架构体系。企业应通过相关决策权分布对投资、规划、预算、服务、安全、业务连续性及法律合规等进行控制和绩效度量。企业运营治理对架构演化和组织优化有重要的作用。
企业架构强调从现状到目标的整体管理过程，如果一个企业已经具备一定的架构沉淀，需要通过企业架构进行优化和迭代演进，那么很多架构理论可以提供一定的架构演进思路，其中通用的部分可以参考图1-11。
企业需要重点分析当前架构与目标架构的关系，并通过相应的业务架构、应用架构、数据架构、技术架构进行架构规划，同时通过实施治理进行架构的建设或迁徙。企业架构可以看作一种描述工具或者描述手段，对企业的业务、信息系统及它们之间的关系，通过不同的视角和维度进行描述，进而形成企业内共同的语言基础。同时，企业架构为企业提供了一个架构知识库，帮助形成可以分类管理、便于访问的企业架构资产。更重要的是，企业架构提供了一个企业数字化的系统过程，使企业内的业务需求与信息技术相结合，并提供了一套构建方法和实施准则。
图1-11 企业架构演进总体示意图
综合上面的分析，对企业架构我们可以有一个初步的定义：企业架构涉及整个企业，是一个系统过程，它表达了企业的关键业务、应用、数据和技术战略，以及它们对业务功能和流程的影响，是对企业多层面、多角度的规划和描述，主要包括业务架构、应用架构、数据架构和技术架构。企业架构可以帮助企业构建业务与IT之间共同的愿景和目标，制定一致的原则和方法，通过标准的交付物和流程来提高企业的整体运营效率，同时通过运营治理完成架构迭代和演进。