企业架构学习
企业架构学习
企业架构的基本概念
企业架构（Enterprise Architecture， EA）经过几十年的发展，有很多专家、组织、企业、研究机构都提出了企业架构的基本概念。总的来说，企业架构是一种描述企业的组织结构的技术，它是一种解决企业组织结构的方法。通过架构的思考方式将一个企业、一个公司、一个系统复杂的内部关系进行结构化、体系化的抽象，并把相关的目标和当前现状通过不同视图进行直观展示，方便相关人员达成一致的认识，指导和驱动数字化项目落地实施。
关于企业架构，我们来看看一些人员和组织给出的定义。
- 麻省理工学院：企业架构是业务流程和IT基础设施的组织逻辑，反映企业运营模式的集成和标准化需求。
- SearchCIO.com：企业的概念蓝图，定义了一个组织的结构和运营，企业架构的意图是确定组织如何能够最有效地实现其当前和未来的目标。
- John Zachman：企业架构是构成企业的所有关键元素及其关系的综合描述，是企业的描述性表达，以及企业创建后进行改变的基线。
- 美国的Clinger-Cohen法案（1996）：企业架构是一个集成的框架，用于演进或维护现存的信息技术和引入新的信息技术，来实现组织的战略目标和信息资源管理目标。
- The Open Group：企业架构主要定义所有构成企业的不同元素，以及这些元素怎样相互关联。
- Gartner：企业架构是通过创建、沟通和优化用以描述企业未来状态和发展的关键原则，以将业务愿景和战略转化为有效的企业变更的过程。
- 微软：企业架构是一种概念性工具，可以帮助组织了解自身的结构和工作方式。它提供了企业地图，并将其用于业务和技术变更的路线规划。
从以上诸多定义可以看出，企业架构并没有统一的定义，不过我们可以发现在上述定义中的一些共性。
在传统模式中，企业从战略规划到项目实施是脱节的，没有经过顶层思考和有效的架构规划，而企业架构作为战略和项目的桥梁，从企业的整体战略规划出发，将业务战略和IT战略通过企业架构进行呈现，通过业务架构明确企业关键业务流程和逻辑，进一步明确与之匹配的IT架构，进而分解为应用架构、数据架构、技术架构，并通过数字化转型项目实施交付，进而进行运营治理，通过持续迭代反向推动战略规划，完成闭环。
企业架构可以帮助企业解决数字化转型中的许多问题，如业务创新、降本增效、风险控制、组织协同、技术升级等。
2017年，麦肯锡与亨利商学院开展了一项关于企业架构影响的调查，调查结果显示，使用企业架构的企业对比没有使用企业架构的企业
- 数字化转型成功率高62%
- IT复杂度降低67%
- 成本节约47%
- 产品推向市场快34%
- 稳定性提高26%
企业可以基于企业架构的指导，优化业务运营模式，落实企业战略，改进业务流程，使企业运转更加高效。企业架构可以使企业在同一语义、语境下协同开展跨领域合作。
Tips:
数字化转型的难点并不在于理论、方法、工具等，而在于整个企业结合相关方法，内部多方协同，进而通过项目落地，最终达到企业整体战略目标的过程。
企业架构整体结构
企业架构方法论概述
什么是方法论
百度百科对方法论的定义：方法论，就是关于人们认识世界、改造世界的方法的理论。
方法论，即“方法”+“论”。
- 首先，它是解决某种问题领域的方法的方法，这个方法更加体系化、全面化，并且有足够的通用性和普适性，如前文提到的Zachman、TOGAF等框架理论
- 其次，它是对事物讨论、分析、总结的过程，除了照搬公式，更重要的是讨论的过程，是可以基于此指导具体参考、可适配和实践的，如设计模式、最佳实践等
一个好的方法论要对解决问题的方法高度总结和提炼，探讨问题的本质，通过体系化地分析问题，重复讨论内部各种因素的关系和矛盾，并通过相关的指引可以适配到具体子问题领域。这么看，方法论既抽象又具体。
方法论的三种策略模式
方法论需要参考架构的思维模式，如抽象思维、分层思维、多维思维和演化思维。此外，我们可以通过以下三种策略模式来进行分析。
- 自上而下：总体规划，分步实施。这是一种演绎的方式，经过从宏观上把握顶层方向，洞察客户背后的本质需求，定义问题，分析问题，然后将具体问题分解为子系统工程实施。
- 自下而上：由点到面，步步为营。这是一种归纳的方式，通过用例堆积，分类归纳，逐步扩大范围，在实践中通过试点工程，场景聚焦，积累经验，由个性形成共性，全面推广。
- 上下结合：将自上而下的演绎分解和自下而上的试点规划相结合。这是我十分推荐的一种方式，自上而下关注战略层面，从全局出发，从业务痛点和诉求出发，高屋建瓴；而自下而上关注战术层面，从具体的试点工程进行落地验证，反复迭代并优化整个过程。这是一个动态的过程，两个步骤相辅相成，可以交替或者同时进行。
企业架构方法论的内容
企业架构涉及整个企业，是一个系统过程，是对企业多层面、多角度地规划和描述，包括企业的关键业务、应用、数据和技术战略，以及对业务功能和流程的影响。
我们可以看出，企业架构可以帮助企业分析业务与技术的相互影响，使企业采取适当的行动，帮助企业建立快速响应变化的能力。企业架构可以系统地描述、分析、改变企业的结构和组成，从而达到企业战略目标。在构建企业架构的方法论时，我们需要结合经典的企业架构框架及先进的云原生技术。这里给出企业架构方法论参考，主要包括四个部分。
企业架构规划
企业架构规划可分为八个阶段，所有阶段都围绕需求管理这个核心，需求管理过程是一个动态的过程，关注企业痛点的识别和需求的输入和输出。从生命周期和内部的迭代，这八个阶段又可分为四次迭代，相关描述如下所述。
迭代一：获得战略计划
准备阶段架构愿景：这是做好企业架构规划的准备阶段，关注企业愿景、范围、业务驱动力及准备情况评估，获得高层的承诺和支持，建立企业架构的基本框架、策略和原则等。
这个阶段与业务架构设计紧密相连，可以反复进行迭代。
迭代二：企业架构设计
阶段一，业务架构设计
创建业务架构，独立于技术，关注企业的价值链、业务能力、业务流程等，是企业架构的基础。业务架构也涉及企业组织和治理间的结构和交互关系。这个阶段也要识别业务需求，分析现状和目标之间的差距，明确业务架构和业务模型。
阶段二，企业IT架构设计
顺接业务转向IT的重要架构，内部又分为应用架构、数据架构和技术架构，明确对应的场景和模型，最终明确IT架构。
阶段三，应用架构设计
描述对应的应用及系统的规划和设计，包括应用间的相互关系、核心流程的呈现，应用架构也包括系统、产品、解决方案等层面的系统级抽象。
阶段四，数据架构设计
描述企业架构的数据模型、数据分布、数据资产之间的结构和关系，确定数据访问及持久化机制，最终明确数据架构。
阶段五，技术架构设计
进行技术体系设计，包括开发体系、测试体系、运维体系，以及基础设施、中间件、网络、通信等综合的企业IT软硬件技术架构。
迭代三：云原生IT架构方案
阶段六，云原生IT架构
承接技术架构设计，应用先进的云原生核心技术，如容器、微服务、Service Mesh、Serverless、DevOps等，构建云原生应用平台和对应的云原生基础设施，完成云原生数字化转型的方案。
迭代四：落地实施、持续治理
阶段七，项目实施管理
包括架构迁移和实施管理所需的各项活动，对项目进行成本和收益分析、风险评估、制订详细的实施计划，并通过先进的敏捷开发、DevOps等理念进行项目管理。
阶段八，架构运营治理
包括日常运营和架构治理的保障，建立治理机制，构建架构成熟度模型和评估机制、架构委员会管理机制、架构原则规范制约机制等，促进组织架构优化、人才能力管理，完成架构持续演进与架构资产管理。
每个阶段的关注点有所不同，特别是企业架构规划阶段，企业基本可以按照以下方法来创建和管理企业架构。
- 选择参考模型、视角和工具
- 描述基线架构
- 描述目标架构
- 进行差距分析
- 定义候选路线图
- 解决对架构愿景的影响
- 进行正式干系人评审
- 架构定稿
- 创建架构定义文件
业务架构规划
企业业务类型繁多，业务架构强调从战略计划业务逻辑转化，通过对业务能力的识别和管理，优化业务流程，共同完成业务整体性蓝图。企业可以将组件化业务模型（CBM） 作为业务模型化的指导，以此来整合和指导业务流程。
组件化业务模型涉及以下步骤。
- 通过战略分析与评估，将企业战略转化为具体指标及实现指标所对应的关键能力。
- 从企业当前组织架构、业务和产品服务等角度，以目标、资源、活动、治理、服务五个维度对企业当前业务能力进行抽象，形成业务能力组件地图。
- 分析业务组件服务，梳理当前的所有流程，形成流程和服务体系。
- 结合战略分析，得出企业具体需要的核心业务能力组件。
- 寻找热点业务能力组件，对业务能力组件进一步从组织、流程、IT、治理、资源等维度进行分析。
IT架构规划
通过业务架构的规划，企业业务以结构化的方式定义，为结构化的企业IT架构的规划提供了支撑的基础。IT架构规划如下所示。
应用架构的规划
根据领域设计来进行设计，可以分为领域、实体、值对象、领域服务、应用、应用组件、功能组件、服务等多种概念，进而完成领域的识别、服务的划分，以及服务对业务能力和流程的覆盖和映射，并通过层次化的划分（如表现层、应用层、服务层、基础设施层等进一步的分层），进一步指导应用、系统和相关功能的设计，包括接口、范围、实体的关系等，在此过程中可以借鉴和参考DDD（领域驱动设计）、服务化、微服务等相关理论知识。
数据架构的规划
要从企业的整体、长期的数据层面出发，构建企业数据的规范化、一致性、准确性和完整性，并基于此挖掘数据的价值，支撑企业数据管理和经营决策分析。
在此过程中，企业要通过数据标准、数据治理、管控流程和技术工具等制定规划，并协同业务架构、应用架构、技术架构层面的数据形成统一、完整的数据标准，形成相应的数据模型、数据关系及进行对应的数据管理。
技术架构的规划
通过构建企业开发平台、运维平台来协助系统的统一管理，助力上层应用架构、数据架构的落地，结合云原生技术、容器化技术、敏捷交付、精益管理等构建开发和运维一体化的平台，并结合项目管理来推进数字化的落地实施
业务架构设计
业务架构（Business Architecture）来自业务，我们先来看看什么是“业务”。
- 在百度百科中，业务被定义为“各行业中需要处理的事务，但通常偏向指与销售有关的事务，企业最终主要以销售产品、销售服务、销售技术等为主要盈利模式。”
- 在
TOGAF中，业务被定义为“任何与产品和服务的售卖相关的组织行为”。
可以看出，业务最终的目的是“售出产品，换取利润”，业务是为企业产生盈利的工作和经营活动，一般指面向客户销售商品。
业务架构是企业架构的基础，它是一个企业蓝图，提供一种业务层面的共识，是为支撑企业业务的目标而定义的一套运作管理体系的结构化描述，描述各级组织日常业务运作、模块化和层次化的业务能力结构，为应用架构、数据架构、技术架构提供指引。
业务架构与企业战略计划直接相关，是企业战略计划转化为实际项目及日常运营的关键。
广义的业务架构与企业的业务板块和组织结构有密切的关系。
- 涉及企业的核心业务板块，如技术研发、生产制造、采购供应、市场销售、客服服务等纵向业务
- 涉及支撑企业日常运营的运营部门和财务、人力、行政、仓储、IT等支撑部门的横向业务
业务架构可以明确企业人员、资金、信息化、服务等企业资源如何进行部署和分配。
应用架构
应用架构设计框架
应用架构构建业务架构、数据架构、技术架构之间的关联关系。应用架构以企业业务架构为基础，规划整个企业所有应用系统的蓝图，将业务架构中业务流程、业务能力等落实到应用系统的具体功能和服务，并对数据架构的数据分析和管理提供诉求，对技术架构中涉及的开发平台、技术选型、基础设施、集成、安全等提出要求，指导后续架构的部署与构建。
数据架构
数据架构的设计框架
数据架构注重从总体上规划企业的数据资源，比如数据架构规划、数据架构设计方法、数据架构设计步骤、数据架构技术及数据架构原则和规范。
图例：数据架构的设计框架
- 数据架构规划：对企业数据资产进行梳理，形成数据资产目录，同时对业务流程和领域模型等进行数据映射，通过顶层的数据分层规划，实现与其他架构的松耦合和数据共享、复用。
- 数据架构设计方法：包含数据模型、数据分布和数据治理，构建统一的数据体系。
- 数据架构设计步骤：进行具体、可实操的数据准备、数据采集、数据建模、数据处理及数据分析，并且应按步骤进行。
- 数据存储技术：包含数据存储的相关技术选型，比如数据库、存储、云原生数据库、相关产品工具等，本质上属于技术架构体系，由于与数据架构紧密相关，因此也放在数据架构的设计框架中。
- 数据架构原则和规范：比如存储选择、数据库设计、数据开发治理规范、参考行业模型等，提供指导和约束。
技术架构
技术架构设计框架
技术架构涉及技术架构规划、技术平台、基础设施，以及技术架构标准原则、最佳实践等。
图例：技术架构设计框架总览
- 技术架构规划：对技术架构统一规划的指导，包括架构模式、架构方法、架构制图等。
- 技术平台：技术架构的平台组件能力，包括开发平台、数据平台、移动平台、低代码平台等，以及核心的典型技术，如服务治理、监控告警、流量调度、消息服务、缓存等。
- 基础设施：支撑技术架构的基础设施，比如计算、存储、网络、安全及云原生基础设施等，可以充分考虑企业上云相关技术。
- 技术架构标准原则：企业技术方向性的通用原则，如通用技术原则、技术框架原则、服务开发设计原则、架构制图原则等。
- 技术架构最佳实践：技术架构典型的实践，如一致性、高并发、高可用、安全生产、压测、秒杀、企业上云等。
架构评估方法
ATAM软件架构评估方法
ATAM介绍
ATAM(Architecture tradeoff Analysis Method)是卡梅隆大学软件工程协会提出来的一套架构权衡分析方法。
ATAM的评估目的是根据系统的质量属性和商业需求评估设计决策的结果。
ATAM希望揭示出架构满足特定质量目标的情况，使我们更清楚的认识到质量目标之间的联系，即如何权衡多个质量目标。
ATAM评估过程详细描述
ATAM评估方法的的阶段：
第0阶段 建立评估小组， 建立评估组织和待评估组织间的合作关系 第1阶段 以架构为中心，重点获取架构信息并对其进行分析。 评估阶段，上面的9 个步骤 在这时完成
第2阶段 以风险承担者中心，重点为获取风险承担者的观点，并对第1阶段的结果进行验证。 第3阶段 后续阶段，形成最终报告，对后续活动做出规划，评估组织在此阶段实现文档和经验的更新。
什么是架构
架构的本质
架构本身是一种抽象的、来自建筑学的体系结构，其在企业及IT系统中被广泛应用。
架构的本质是对事物复杂性的管理，是对一个企业、一个公司、一个系统复杂的内部关系进行结构化、体系化的抽象，并把相关的目标和当前现状通过不同的视图进行直观展示，方便相关人员达成共识，指导和驱动数字化项目落地实施。
那到底什么是架构？下面我们先来看几个定义。
- 百度百科的定义：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
- 维基百科的定义：架构即软件体系结构，是指软件系统的基本结构，以及创建此类结构的规则及这些结构的文档。每个结构包括软件元素，它们之间的关系，各个元素和它们之间的关系的属性，以及每个元素引入和配置的基本原理。
- ISO/IEC 42010的定义：一个系统在其所处环境中所具备的各种基本概念和属性，具体体现为其所包含的各个元素、它们之间的关系，以及架构的设计和演进原则。
- IEEE的定义：架构是环境中该系统的一组基础概念和属性，具体表现就是它的元素、元素之间的关系，以及设计与演进的基本原则。
- CMU软件工程研究院的定义：架构是用于推演出该系统的一组结构，其具体是由软件元素、元素之间的关系，以及各自的属性共同组成的。
- TOGAF（The Open Group Architecture Framework，开放组架构框架）的定义：一个系统的形式化描述，或指导系统实现的构件级的详细计划。一组构件的结构、构件间的相互关系，以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。
综合上述定义，可以看出，对于架构的定义有几个高频关键词：元素、结构、关系、原则、演进。
一句话总结：架构是将相关元素按照一定的结构连接在一起，同时提供相应的原则和规范进行持续演进的一种方法、活动和模型。
架构就像建筑学中的体系结构，比如在故宫平面图中，整体的结构、房间的主次、彼此连通的道路通过一张图可以直观地展现出来，同时各个房间的大小也按照实际情况进行了精准的绘制，这其实就是架构的美妙之处。
四个重要的架构思维方式
在这个管理事物复杂性的过程中，有四个非常重要的架构思维，分别是抽象思维、分层思维、多维思维和演化思维。
抽象思维
抽象是对某种事物进行简化描述的过程，关注关键元素，忽视其他细节。
抽象在架构设计中非常重要，抽象能力的强弱，直接决定着我们所能解决问题的复杂性和规模大小。
例如积木城堡游戏，一个城堡由若干子模块组成，而每个模块最终由不同形状的积木搭建而成，这种自上而下或者自下而上的抽象组合过程在架构设计中十分重要。
抽象关键元素，忽视其他细节，下图所示的毕加索抽象画，毕加索对一只复杂的公牛进行了高度的抽象和简化。
图例： 抽象思维举例：毕加索《公牛》
比如，从电商角度，一个系统可能被我们抽象出不同的模块，以下订单为例，可能需要经过商品价格查询、库存更新、优惠方式计算、支付方式校验、物流方式更新等一系列流程，这一系列流程本身就是对高度抽象过程的总结。
分层思维
分层是在抽象的基础上进一步体系化地分析事物，因为抽象出来的元素可能不在同一层次，比如可能需要我们从业务模块的垂直层面或者系统功能的水平层面进行思考。
分层思维是很重要的架构思维，比如我们看到的操作系统，就可能被分为内核、内存管理、输入和输出管理、文件管理、用户界面层。
图例：网络分层模型
如上图所示的网络分层，经典的七层模型即物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
比如，人们经常讨论的技术架构包含部署架构、集成架构、开发架构、测试架构、运维架构、安全架构等，这些都是从不同层次进行划分的。
多维思维
随着事物复杂性的提高，我们往往需要从不同维度对事物进行分析。
分层思维帮助我们从不同层面对事物进行分析，而多维思维要求在架构分层的基础上，从更广、更高的维度对事物进行综合分析。
比如，一般我们在做架构设计时，需要分析业务需求、业务流程、领域建模、技术支撑，除了对每层进行分析，我们还需要分析什么业务与什么流程匹配、什么流程与什么模型对应、什么模型使用什么技术，同时要结合组织阵型、项目运营管理，从不同维度来进行全面的分析。
多维思维更多强调矩阵分析，比如衡量客户价值和客户创利能力的典型模型——RFM模型，通过三个维度不同分类的组合，分解出八种客户画像。
图例：RFM模型 - 阿里云
演化思维
架构是设计出来的，更是演化而来的。
架构的形成是一个不断迭代的过程，而这个过程其实是对整个企业进一步有序化地重构和升级，以实现进化并支撑业务快速发展。
可以说，人类世界是以分层方式一层一层搭建和演化而来的。
架构模式不是固定的，比如架构经历了从单体模式到SOA（Service Oriented Architecture，面向服务架构）模式，从SOA到微服务架构，从微服务架构到云原生架构的演变。
再以云原生技术中的Serverless为例，图从物理机（Physical）时代、虚拟机（Virtualisation）时代、云计算（Cloud Compute）时代、容器（Container）时代到达无服务器（Serverless）时代，使用户无须关注程序运行环境、操作系统、网络配置、资源及容量，只要将精力聚焦在业务逻辑和技术上即可。
图例： Serverless演化
典型误区
基于架构的本质，反观我们平时接触到的架构，往往有一些典型的误区，具体体现在以下几个方面。
缺乏全局架构视角
数字化转型的首要切入路径是“全局战略，总体架构规划”，然而很多企业缺乏全局架构视角，认为架构仅指IT架构，或者更小的运维层面，其实架构涵盖企业的战略、业务、应用、技术、数据、产品、运维、部署、集成等方方面面，总体规划和全局视角非常关键。
缺乏架构治理演进
架构设计不是静态的，而是动态演进的。只有不断应对变化的架构，企业才有生命力，因此企业需要借助相应的架构治理来推进架构的持续演进。
这个过程也是体系化的过程，如相应的架构成熟度评估、相应的组织和决策机制、架构的设计原则和规范，以及长期的运营治理意识和机制保障是必不可少的。
组织缺乏有效保障
架构需要组织的保障，一些传统企业仅仅要求IT部门的运维人员进行系统维护，对架构不够重视。
其实，架构既需要全方面构建，也需要对应的组织保障，比如企业应设立对应的架构委员会，提升对架构的认知，同时明确对应的角色、权责，以及相关的人才培养和考核机制等，企业应更加包容和开放。
架构设计原则
基于对架构本质的理解，关于架构设计业界有一些非常好的基本原则。
SOLID原则
《架构整洁之道》一书中提到的SOLID原则（下面各个原则的首字母）。这些虽然是面向服务设计的原则，但对于架构设计同样适用。
单一职责原则（Single Responsibility Principle）
基于康威定律的启示，每个模块有且只有一个被更改的理由。在架构设计过程中，特别是在抽象和封装过程中，应尽量设计得没有互相重叠（如相关的流程、服务功能），有明确的使用者和操作者，比如订单核心能力的最终修改，需要聚集在一个单独共用的模块上，这样职责清晰，也便于后续架构演进。
开闭原则（Open Closed Principle）
企业应对扩展开放，对修改关闭。也就是说，企业的架构要尽可能考虑扩展性，减少不必要的修改，比如企业可以采用模型的扩展、服务接口的继承、流程的编排、能力的组合等方式，通过分层和扩展解决用户不断变化的诉求，这样也有利于快速支撑业务发展。
里氏替换原则（Liskov Substitution Principle）
任何基类可以出现的地方，子类也可以出现，二者是“IS-A”关系，如绵羊是羊的一个种类。企业在进行架构设计时，如果有些架构是相互继承的，则要关注其中的继承关系，如从应用架构到具体部署架构的分解过程。
另外，我们通常把核心的原子能力进行最小集的封装，在架构扩展设计中，任何对原子能力的扩展都需要维持原子能力的定位。
迪米特法则（Law of Demeter）
如果两个模块无须直接通信，就不应当发生直接相互调用，可以由第三方转发。在架构设计过程中，要尽可能减少不必要的相互调用，降低模块之间的耦合度，提高相对独立性。
接口隔离原则（Interface Segregation Principle）
在架构设计过程中，企业需要避免不必要的依赖，也就是最小化组件（或模块）之间的依赖度和耦合度。在架构设计中，主要要求尽量保持组件之间的耦合，这样既可以降低相互的变化影响，也可以增强组件的可复用性。架构的设计尽量不要依赖不必要的东西，比如业务架构应聚焦能力、流程，应用架构应聚焦领域、服务，技术架构应聚焦技术组件支撑等，避免修改一种架构要连带修改其他分层的架构。
依赖反转原则（Dependence Inversion Principle）
企业的高层策略不应该依赖底层细节，而底层细节应该依赖高层策略。比如，当设计服务的时候，下层服务不应该修改上层服务，如电商中的订单分层高于商品和促销，在订单层级可以修改商品库存、促销状态等，而反向操作是不允许的。
其他经典架构设计原则
业界还有一些比较经典的架构设计原则。
正交性
架构设计要考虑全面，保持正交，职责独立，边界清晰，没有重叠。这类似于结构化思维中的MEMC（Mutually Exclusive, Collectively Exhaustive）法则，即相互独立，完全穷尽。
高内聚
同一层架构内应该是高度内聚的，就像一个不可分割的整体，否则就应该拆开。
低耦合
不同层的架构间应该尽量降低耦合度，这样既可以减少相互的变化影响，也可以增强组件的可复用性。
简单适用
架构并不是一成不变的，规划要全面，落地时要讲究合适原则和简单原则，应以符合当前业务发展需要为主要目标，而不是单纯为了设计架构而设计架构。
