大约一万年前，人类开始沿着河流定居并耕种土地。他们留下了洞穴、岩石露头和用树枝和树叶搭建的庇护所，开始建造泥屋和石头房屋，并发明了砖块。人口成倍增加，城镇得到发展，并按一定顺序布局，设有下水道、宗教建筑和行政办公室。随着人类思想变得复杂，金字塔、金字形神塔、天文建筑和精致的寺庙被建造起来。

在文明的早期阶段，成年家庭成员必须弄清楚如何为小屋、墙壁、窗户和倾斜的屋顶建造基础。他们可以看到自己更大的需求，并想出如何组装合适的东西来满足这些需求。他们观察到石头坚固、耐用并且可以塑造形状；这种木材轻而柔韧，适合制作框架；他们不关心，也不需要关心，石头或木头的内部是什么使他们如此。这就是建筑思维的本质；他们是第一批可识别的建筑师。从这个意义上说，每当我们做这样的事情时，即使是现在，我们所有人都是建筑师。

随着人口和土木结构的增加，对原材料、规划和标准化的需求也随之增加。一些有志于此的人专门从事这些方面的指导，并成为每个文明中的第一批专业建筑师，例如印度河流域、美索不达米亚、埃及等。我们知道的一些历史建筑师有伊姆霍特普（萨卡拉阶梯金字塔）、伊克提努斯（帕台农神庙）和乌斯塔德·艾哈迈德·拉霍里（泰姬陵）。阅读本文了解更多信息，包括现代伟人。

与此同时，宗教、政治、政府、贸易、金融和其他人类系统的发展也需要解决方案。那些概念化和指导其整体框架的人也是建筑师。 

价值

O  一个办法

O  一个好的解决方案

O  具有成本效益的解决方案

作为一个事物

作为一项活动

我们在哪里寻找架构？

架构和设计是密切相关的术语，经常互换使用。这并没有什么太大的问题，但是对于IT来说，它可以帮助我们区分它们的细微差别。

“设计”让人感觉仔细而专心地观察单个事物（也许是一个物体），并找出使其发挥作用的细节。“建筑”给人一种退后一步，审视由许多部分组成的大事物的感觉。 

这几乎就是建筑领域区分这两个术语的方式。无论建筑结构的某个组件内部发生什么，都“留给”架构和设计师。只要它具有其他组件所需的有用的外部属性，体系结构和架构师就不会特别关心它的内部结构，即它的设计。事实证明，这种范例对于通过架构师和软件或硬件设计人员之间的思想和技能分工来交付 IT 解决方案是有效的。

应用程序是 IT 领域的核心功能单元。它们也可以称为系统、子系统或软件。应用程序架构定义了如何通过将应用程序划分为与人类或其他系统交互、存储和检索数据、表示和执行业务规则等的组件来交付业务或技术功能。 

应用程序架构的典型模式是——客户端-服务器、分层、模型-视图-控制器、移动、微服务等。例如，销售应用程序、客户关系管理应用程序、人力资源应用程序、经销商管理应用程序、报告系统等的架构.（更多信息请参阅本文 →功能性 IT 系统的实用抽象）

02

所有 IT 都是按原样写入和读取信息或将其转换为各种用途。信息架构定义了应用程序如何存储、非规范化、复制、更改、访问、查询、连接、保留、备份、清除、保护等信息。信息架构对IT系统的成本和性能影响最为显著。 

信息架构师使用层次结构、数据库、线性、目录等架构模式来提供用户所需的功能和质量。（请参阅本文了解更多→企业数据存储库模式和进展）

03

系统需要相互通信，信息需要在存储库之间交换。集成架构考虑了客户端、服务器、请求、响应和有效负载的特征，以提供连接应用程序和信息功能的最佳机制。 

一些典型的集成架构模式有消息传递、队列、发布-订阅、代理、编排器等（请参阅本文了解更多→企业集成架构模式）

04

运行IT软件的服务器、机架、存储系统、网络设备、安全设备、备份设备、数据中心、电源、空调、中间件、管理系统等也必须进行架构设计。 

技术设计作为一种适当的主流架构学科经常被忽视。随着云计算和“无服务器”等范式的出现，这种情况变得更加恶化。不可避免的结果是容量、性能、可用性、弹性、安全性等问题的处理都是被动且昂贵的。因此，我们不能弃用基础设施解决方案的架构方法、制品、模式和治理。技术架构是SDLC架构设计阶段中至关重要的、不可或缺的学科和步骤。

05

商业和非商业企业的设计需要能够良好运行。业务架构为组织制定适当的结构，以满足其产品、服务、客户、供应商及其工作的外部环境的需求。它通过静态和动态业务模型提供战术和战略业务架构解决方案。

业务架构师考虑的一些方面是企业价值流（愿景、战略、战术、产品和服务、计划和项目）所需的功能能力以及信息（指标和措施、事件和决策、政策、他们需要的规则、法规）和组织（领域、子领域、利益相关者、人力和其他资源、层次结构）。

06

企业架构是最高、最广泛的架构学科。企业是任何创造价值的组织，从最小到最大，可以赚钱或从事慈善、行政、娱乐、政治、公共服务等。

企业IT架构提供了业务战略和信息技术之间的联系。它塑造 IT 以从整体、战术和战略角度支持业务。它通过企业 IT 架构（模型）、差距分析、过渡计划和架构治理来实现这一点。与其他架构学科一样，它提供功能、质量和效率，但是在企业级别。企业架构师与业务领导者和利益相关者、学科架构师和 IT 合作伙伴合作来交付企业架构。（请参阅这些文章了解更多 →敏捷企业架构战略与规划技术、如何进行 EA 适合差距分析来修复有问题的 IT 系统，以及如何通过 4 个阶段成为企业架构师）

业务用例——捕获业务需求的最明确、架构最优雅的方式是通过用例。每一项离散且完整的业务任务都应该有一个用例。例如，登录、查看过去的订单、提出投诉等。 

对于每个用例，详细说明功能需求 (FR) 步骤序列，其中包含有关前提条件、参与者、用户界面、事件、操作、输入、读取、修改、删除、健康和错误路径以及后状态的信息等等。对于每个独特的响应，捕获非功能性需求 (NFR)（例如容量、延迟、可用性等）。常见的 NFR 可以放在最后的一个地方（例如，增长、安全等）。对于操作用例也执行此操作。确保解决方案范围内的所有参与者和功能涵盖所有业务领域。

用例从简单到复杂各不相同。如果文本描述不够，请在用例中添加流程图和交互图。

请参阅下面的口头用例描述示例（第二个和第三个用例不完整）。

上下文图 -绘制它是为了显示解决方案需要与之交互但不在解决方案范围内并且可以假设保持不变的外部人员和 IT 系统。这是解决方案的上下文或环境。它有助于定义和限制解决方案。为解决方案画一个椭圆形，将外部参与者和系统连接到其轮廓，并简要说明每个连接器上发生的情况。

请看一下这个说明图。

EA 政策、原则、指南和标准 —从企业架构师或 CIO/CTO 收集这些内容。这些也是解决方案架构师需要满足的要求或约束。有关详细信息，请参阅下面的治理部分。

约束 -整理对其他项目的依赖关系、财务和时间限制、技能限制、技术限制等。随着架构的开发更新此信息。可接受的解决方案必须考虑这些限制。

架构决策代表了架构思维的本质理性和理智平衡。架构师以开放的态度思考如何将业务功能分布在软件和硬件组件上并进行操作。做出正确的架构决策是架构师最出色的技能，它决定了整体解决方案及其成功。

制定架构决策有四个步骤。

1 收集相关 参考架构 和 架构模式

2 将业务需求转换为  功能布局、数据存储库/源和集成方法的 架构问题陈述。

3 让 参考架构和架构模式提供尽可能多的 有意义的决策。 例如，对于问题陈述“结账组件从哪里获取订单交付时间？” 如果参考架构显示了物流系统上合适的 API，那么这可能就是决定。

4 对于其余的问题陈述，使用架构决策模板来 陈述问题， 列出考虑到约束的所有合理的解决方案选项，选择最好的方案，证明其合理性，并捕获其对技术、其他决策、设计等的影响。

请查看下面的决策模板和示例。

03

一旦您有了上下文图并做出了架构决策，您就拥有了绘制解决方案的基本模型并对其进行描述所需的一切。

架构概述图——为不同的受众绘制两个或三个级别的架构概述图。例如，对于业务领导者，制作一个零级或 L0 级图表，显示将满足业务需求的技术领域；对于项目经理，制作一个 L1 图，显示需要交付的系统和子系统及其广泛的连接。 （有关更多信息，请参阅这篇文章 →如何绘制史诗般的 IT 架构图）

架构概述描述 -对于您创建的每个概述图，简要描述每个项目的角色以及与主要业务和运营用例的其他项目的交互。

下面是一个示例 L1 图，显示了主要业务功能和底层 IT 系统。

功能架构阶段详细说明了在步骤 2 中先前决定的系统和应用程序的组件和子组件，用于交付业务和运营用例。在指定组件时，以下架构原则促进了开发和维护的简便性。遵循它们可以显著节省时间并降低 IT 解决方案的成本。

下面是上面第 3 节中的 L1 图的促销系统的说明性 L2 架构概述图。 为解决方案的每个系统制作一个。

以下是捐赠用例序列图的示例。

以下是运营架构考虑的一些主要方面。

• 部署架构——在这里，基础设施架构师根据软件组件的性质确定需要什么。下面列出了一些已解决的重要方面。
•  所选即用型服务的提供商和规范。 例如，支付网关、信用检查服务、地理定位服务等。
•  所有软件组件位于自己或合作伙伴的私有数据中心或公共云中
• 服务器物理/虚拟核心、RAM 和操作系统
• 网络架构，包括 LAN、WAN 和外部连接和容量、设备位置和大小
•  存储类型和带宽
•  根据可用性架构，将软件和硬件分布在机箱、框架、机架等中
•  以上所有中间件组件， 例如 HTTP 服务器、Web 服务器、集成系统、日志记录和监控系统等。
•  备份与恢复以及灾难恢复解决方案

对于解决方案验证，SA 依赖以下内容。

O 内部——可追溯性矩阵 ，将需求、架构和设计映射到相应的测试和 测试 结果。例如，业务和操作需求映射到用户验收测试、序列图映射到字符串测试、接口规范映射到集成测试、功能设计映射到系统测试、代码映射到单元测试、NFR 映射到性能测试等等。

O 外部—— 设计机构 （见下一节）。

下面对整个方法进行了高层次的说明。

1 出发点是确保 企业领导层理解并要求架构思维的价值，从企业架构到其他学科。

2 捕获 当前的 业务和技术架构。

3 使架构 检查点（或检查门）成为每个战术和战略变革过程的一部分。 

B. 建立架构实践

1. 方法——确定解决方案的系统方法。上面我们已经看到了一般的架构开发方法。

2. 技能——拥有合适的人才。我们已经在上面看到了架构学科技能。

3. 工件——为方法和实践者提供有效且一致的工具。上面的架构方法显示了关键的工件。但每个架构学科和阶段还有更多。

两个主要的架构治理机构是企业架构审查委员会和项目设计机构。

架构审查委员会 (ARB)

ARB 是在企业级别协调业务与技术的主要架构治理机构。它由 CIO/CTO 和首席企业架构师担任主席，并由企业架构师、学科架构师、业务利益相关者、财务主管、首席安全官和其他需要的人员组成。ARB 执行以下操作。

1. 提供企业架构方向

2. 批准架构倡议

3. 监督项目设计机构的工作（见下文）并解决提出的任何问题。

4. 与赞助者联络并获得利益相关者的支持

5. 制定政策、原则、指南和标准，通过避免重新发明和不兼容或不合适的系统来提供速度、效率和质量。它们的定义如下。

• 政策 规定了如何在架构和技术的不同方面完成工作（任务）。 例如，所有数字解决方案均应由合作伙伴 x 提供。

• 原则 反映了企业的意图，有助于确定大方向（建议）。 例如，将尽可能采用开源解决方案，以降低成本并鼓励开源运动。

• 指南 有助于决定小问题（建议）。 例如，B2B 集成应通过企业 B2B 集成网关完成。

• 标准 可实现可重复性、速度和效率（决策）。 例如，所有 API 将基于 TMForum Open API。

设计专家组 (DA) 或解决方案审查委员会 (SRB)

设计专家组确保每个项目都遵循通用和特定于企业的架构实践，并帮助解决方案架构师做出决策和解决问题。一名企业架构师主持该小组，该小组由经验丰富的学科架构师、IT 部门负责人、项目经理、运营经理和其他利益相关者组成。该解决方案由解决方案架构师、业务分析师、项目经理以及开发和测试主管代表。

DA 执行以下操作。

1. 开发和维护企业级架构

2. 与项目团队进行架构审查

3. 为架构所有领域的项目团队提供建议和指导

4. 担任企业ARB代表

5. 识别并解决问题，并在必要时上报给 ARB

管控、技能和治理机构到位后，通过组织的 项目管理办公室或其他监督机构将其应用于三个层面的变革：

1. 根据业务驱动因素制定  一到三年的企业级 IT 战略和计划(S&P)

2. 指导  从上述战略和规划流程中入围交付的IT 项目

3. 管理  现有 IT 系统中的常规变更

不要只称自己为架构师。学习架构，用至少 80% 的工作时间进行实践，遵循方法，交付物并进行认证。这很容易，特别是如果您热爱并享受架构，而不是仅仅为了它的声望或报酬而这样做。

一些大型全球 IT 服务公司（令人惊讶的是，很少）将架构作为明确的职业道路，并提供内部或附加架构培训。如果您属于这样的公司，请接受其培训。你也可以通过阅读书籍和文章学到很多东西，这是你应该做的。但请记住，不要开始认为你吸收的一些大杂烩就是架构。

你必须去做才能得到它并成为它。这也适用于建筑。寻找您可以担任首席架构师或支持架构师的项目。确保团队的其他成员和管理层了解架构的价值和必要性。按照方法并交付文物。了解每个人在不同程度上都是架构师的客户，并与他们互动以收集需求和约束并传达架构思想 - 业务人员、BA、PM、设计师、编码员、测试员、操作员、其他架构师和合作伙伴。

IT 架构师与各种各样的人一起工作。他们必须从许多人那里获取信息，说服和哄骗其他人，并带动所有人。因此，他们拥有或获得有效沟通、正直、幽默、影响力、有条不紊的方法和领导力的特征。广泛的常识、对时事和全球趋势的兴趣以及哲学倾向帮助他们看到并展示大局。

最通用且被广泛接受的认证是 The Open Group的认证。如果您的公司有内部架构认证，并且您不打算很快离开，请获取其证书。如果它隶属于 Open Group，您也可能获得 OG 认证。如果您的公司没有对架构师进行认证，请进行 Open Group 认证。或者，您可以获得 Microsoft、Google 和 Amazon 等公司的技能鉴定。但这些将特定于其技术和架构，并且对于与技术无关的解决方案来说不可移植或有效。

与其他职业一样，从较小的视角到更大的视角、从深度到广度的工作是更自然的。编码、设计和技术方面的经验造就了一名优秀的架构师。其他架构学科的经验造就了一名优秀的企业架构师。

下面列出了架构领域的一些典型职业道路（按发生顺序和平稳过渡）。当然，可以有其他序列和起点。你需要弄清楚你的兴趣如何维持或发展。

免责声明：

本文转载自【杨杨洒洒说】，版权归原作者所有，如若侵权请联系我们进行删除！

易知微以自主研发的EasyV数字孪生可视化搭建平台为核心，结合WebGL、3D游戏引擎、GIS、BIM、CIM等技术，协同各个行业的生态伙伴，围绕着数字孪生技术、数字驾驶舱和行业应用，共同建设数字增强世界，帮助客户实现数字化管理，加速数字化转型。

易知微已经为3000+ 客户提供数字孪生可视化平台和应用，覆盖智慧楼宇、智慧园区、智慧城市、数字政府、数字乡村、智慧文旅、工业互联网等众多行业领域，包括国家电网、移动云、中交建、中铁建、融创、云上贵州、厦门象屿、天津火箭、上海电视台、金华防汛大脑、良渚古城遗址公园、李宁、浙江大学等典型案例！