随着信息系统的飞速发展，到了今天遍地都在讨论企业的数字化转型，那么我们是否意识到，在数字化转型的洪流中系统的架构对企业的重要性？如果说企业数字化转型是企业的方针政策的话，那么系统的架构就是企业在执行政策过程中的一枚基石 ，拥有一个良好的架构设计会为企业当下以及未来的发展提供强有力的支撑，扫除许多的障碍，相反没有 一个良好的架构来支撑，随时业务的变化，企业会发现问题越来越多，运维 的压务会越来越大，
可以说，企业IT系统架构的优劣决定着企业的发展命脉，企业相关架构的知识且听我娓娓道来！
2. 企业架构理论首先我们来了解下企业架构的基本理论，就是所谓的架构指的是什么，这是先给也一个官方定义：“一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在指定环境和原则下进行设计和演变”咋一看会有些抽象，我从另一个角度来诠释一下企业架构对于企业的意义。
企业的架构就如同一栋大楼的结构与设计，我们要盖一栋大楼之前需要有专门的建筑设计人员先进行图纸的设计，有了完善的图纸后，再进行打地基的工作，有了稳固的地基后，后面就会有所谓的“万丈高楼平地起”的景象。了解了这个原理后，我们就可以很好的理解企业的架构设计，就如同大楼的前期图纸设计，是属于企业战略层面与实际运营之间的桥梁，有助于战略的落实。
企业的战略选择是企业的定位问题，应该具有较高的稳定性与前瞻性，如果决策者一旦制定了错误的战略，100个行动也无法挽救。我们国内有很多企业，信息化建设普遍存在一种现象：信息化成为苦干信息化项目的总和，很多时候我们总是通过建设新的项目来弥补系统的不足，但此时总体规划往往会抛到了脑后。
这些都是对政府领导、企业决策者和管理者特别是科技部门领导和CIO的挑战，至此对于企业架构是什么，以及对企业的重要程度大家已经有了一个初步的了解，接下来我们再来了解下企业在传统架构设计的一些方法。
3.架构的参考模型无论在传统领域中还是在目前的数智化时代，企业的架构的设计一般会参考Zachman架构框架，它是全球第一个企业架构框架理论，是其它企业架构框架的源泉模型。在架构的执行落地层面一般会参考TOGAF架构框架，该框架是由欧州共同体的IT协会The Open Group开发的一个企业架构框架理论，是一个跨行业的、开放的、免费的架构框架，在全球范围得到了广泛的使用。
TOGAF整体架构
接下来我们重点来说TOGAF（The Open Group Architecture Framework）这个通用性，落地性更强的实战型架构，该架构提供了一整套方法和工具的企业架构框架。之所以说它落地性更强，是因为该架构中有一套核心的落地的设计方法叫ADM, Architecture Development Method.该套方法是TOGAF架构的核心部分，里面对于开发企业架构所需要执行的各个步骤及它们之间的关系进行了详细的定义，以发展能够满足客户需求的企业架构。
其中ADM核心设计方法共发为五个阶段，是企业架构设计的关键阶段，分别是准备阶段、架构原景、业务架构、信息系统架构和技术架构。以下是该设计方法的架构流程图
ADM架构设计方法架构展示
重点来啦！接下来我就重点说说该方法在传统领域中以及云上环境领域中的设计方法和注意事项 ，让您快速的了解两者之间的优劣势的对比，为您的企业架构设计提供非常有价值的参考依据！
4.传统架构设计方法准备阶段：在准备阶段需要明确企业架色的一个结构、框架和范围归纳下：
- 界定将要受到影响的企业组织的范围。
- 确定治理和支持框架。
- 定义并建立企业架构团队和组织结构。
- 明确并制定架构原则。
- 选择架构框架，并对其进行定制。
- 落实相关架构工具。
A架构愿景：该阶段是为了明确企业架构原景，明确项目的范围，一般来讲传统的架构设计方法都是基于未来5年规划的，能过包括如下的规划内容：
- 建立架构项目
- 识别干系人、关注点和业务需求
- 确定业务目标、驱动力、约束
- 评估业务能力
- 业务转型准备情况
- 定义范围
- 确定架构原则
- 开发出架构愿景
- 定义目标架构价值主张和主要性能指标
- 明确业务转型风险和缓解措施
- 开发出企业架构计划和架构工作说明书，并被批准
B业务架构：在该阶段，将开发一个支持架构愿景的业务架构。架构愿景中概括的基线和目标业务架构将在此被细化，从而使它们可以作为技术分析的有用输入。当前阶段是一个复杂且又繁琐的阶段，各个步骤归纳如下：
- 选择参考模型，视角和工具
- 开发基线业务架构描述
- 开发目标业务架构描述
- 进行差别分析
- 定义架构路线图组件
- 通观整个架构景观来明确和解决相关影响。
- 进行正式的干系人审查
- 最终确定业务架构
C信息系统架构（数据架构）：信息系统架构共分为两个部分，一个是数据架构的设计，另一个则是应用架构的设计，其中数据架构建设的目标是通过一种完整、一致、稳定且能够为干系人所理解的方法对支持业务所必需的数据的类型与来源进行定义。传统的设计方法如下：（干什么都要靠“关系”）
- 主要方法：E-R设计
- 输出：CDM、LDM、PDM
- 传统步骤（关系“硬”才靠谱）需求调研：数据字典、表单、数据流概念分析：概念数据模型（CDM）、ERD实体关系图、DFD数据流图逻辑设计：逻辑数据模型（LDM）、数据角色矩阵物理设计：物理数据模型（PDM）、存储、读取、关联
C信息系统架构（应用架构）：应用架构需要定义处理数据并支撑业务运行所需的各种应用系统。描述被部署的单个应用系统、系统之间的交互，以及他们与组织核心业务流程之间关系的蓝图。传统的设计方法如下：
- 主要方法：UML设计
- 输出：系统数据交互、系统功能框架
- 传统步骤系统外部设计：U/C矩阵系统划分、系统关系图、接口列表系统内部设计：用例图、类图、序列图、状态图、活动图、组件图、部署图
D 技术架构：在技术架构阶段，完成对IT系统基础服务设施的设计，定义了架构解决方案的物理实现，包括硬件、软件和通信技术。
技术架构建设阶段的目标是将应用架构中定义的各种应用组件映射为相应的技术组件，这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。由于技术架构定义了架构解决方案的物理实现，因而它与实施和迁移规划有着很强的关联。传统统的方法如下：（大而全）
- 技术参考模型（TRM、NGOSS、SOA）
- 基础架构：计算、存储、网络、安全
- 通用系统架构：三层架构、四层架构
- 行业架构：电商、游戏、金融、政务
- 输出：集成架构、技术无关架构、技术相关架构
- 传统步骤（慢且烦）选定技术参考模型集成架构：集成技术、接口技术、集成平台技术架构：应用、应用平台、中间件、应用服务器、数据库技术选型基础架构：计算、存储、网络、安全
接下来我再来说说云上架构的设计方法，云上架构整体来讲较传统架构要“轻便”的多，借住云原生的能力（高弹性、高可用、高性能）等优势 ，只需要关注当下的业务形态和未来业务扩展的架构描述即可快速勾勒出方便可行的架构设计。
准备阶段：该阶段充分利用云上的服务特性，选择云上的各类产品推荐的架构模式及应用场景，同时通过云上架构持续优化平滑过度，在实践中去验证架构。举一个电商搬站上景云的举子，在该场景中，主要是搞清楚4W1H即可（JUST DO IT）。
- 礼品电商Where——阿里云What——迁云 改造Why——弹性、可扩展、高性能、高可用、安全Who——架构师How——阿里云上架构方法
A 架构愿景：上述我有讲过，云上的架构设计侧重短期目标，所以在愿景设计的环节中也是侧重短期目标，并不断快速迭代的策略，并且架构具有非常实际的针对性，可参照公有云上的一些最佳实践的文档来部局。再举一个某电商云上的架构愿景设计思路：（关注眼前）
- 电商业务，主营礼品有明显的节日爆发消费特点，为了扛住双11，圣诞节等节日，需要灵活调整资源用量的架构架构项目(把架构当回“事”)目标、业务驱动(不做不行)项目因素(这“事”怎么干)
B 业务架构：云上业务架构的设计重点侧重于业务的原子性（原借住于云原生的能力，划清边界），以及随着未来业务的起伏变化，设计相关的业务拆分，对应压力的分解，以及业务合并，服务能力提升等思路。对于某电商的云上业务架构准备阶段需要做如下的定义（简而又简）：
- 迁移哪些业务上云？
- 业务压力来源于哪里？有没有优化的空间？
- 组织层面(“人”以群分)
- 业务层面(“务”以类聚)
- 分析业务的意义
C 信息系统架构（数据架构）：借住于云原生的能力（旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性如弹性、韧性、安全、可观测性、灰度等，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。）该阶段更多是关注分析数据结构特点，关注数据结构优化程分析数据访问业务特点，关注数据访问的优化这两点，比如云上的某电商数据架构的设计就打破了在传统数据架构设计的强关系理念，更多关注如下几个方面。
- 迁移哪些数据上云？
- 业务传导的数据压力在哪里？有没有优化的可能？
- 数据分析(卡在哪里)
- 架构优化(找到合适的路子)
- 分析数据的意义
C 信息系统架构（应用架构）：在应用架构阶段主要是对应用的分析，包括系统集成关系，应用压力分析等。架构的优化：对承载业务压力的应用进行优化，解耦和服务等。
例如某电商云上应用的架构设计：（压力山大）
- 迁移哪些应用上云？
- 业务传导的应用压力在哪里？应用于数据调用压力在哪里？有没有优化的可能？
- 应用分析(压力在哪)
- 架构优化(解耦与整合)
- 分析应用架构的意义
D 技术架构：该阶段主要是摒弃一些传统的技术，更多的是参考云上的选型工作，通过云上几十基至上百款的云服务，总有适合企业部署的云服务。例如某电商设计的技术架构就是即开即用特性的：
- 直接选用云服务
- 技术分析(淘汰落后)
- 架构优化(更新换代)
- 分析技术的意义
好啦，经过上面的描述，相信大家对于架构的传统设计方法和云上设计方法会有一个非常明确的了解，接下来我再做一下两者之间的特性对比，也算是对两者的设计方法做一个提炼和总结。
传统设计方法与云上设计方法的基础是一致的，只是着眼点有会有所不同，在传统的架构设计方法中比较关注如下几点：
- 架构愿景是中长期的，例如3-5年系统迭代周期长，完整的体系实践要一年左右解决有、无的问题大而全相对厚重，架构设计不连续
而云上架构设计的方法则是：
- 架构愿景是短期的，例如4-6个月系统迭代周期短，云上快速交付方式解决多、快、好、省的问题针对性强相对轻便，架构设计平滑
好了上述就是本期带给咱们关于企业架构设计的思想的全部内容，最后再预告一下下期的内容，也是本期内容的延续，云上架构的三类典型设计，分别是弹性架构、高性能架构、高可用架构，预知后事如何？且关注我们，听我下回继续分享！
BYE
关注山东云管家，带你了解更多云上知识。
,
