来源：杨杨洒洒说
O 一个办法
O 一个好的解决方案
O 具有成本效益的解决方案
作为一个事物
作为一项活动
我们在哪里寻找架构？
应用程序是 IT 领域的核心功能单元。它们也可以称为系统、子系统或软件。应用程序架构定义了如何通过将应用程序划分为与人类或其他系统交互、存储和检索数据、表示和执行业务规则等的组件来交付业务或技术功能。
应用程序架构的典型模式是——客户端-服务器、分层、模型-视图-控制器、移动、微服务等。例如，销售应用程序、客户关系管理应用程序、人力资源应用程序、经销商管理应用程序、报告系统等的架构.（更多信息请参阅本文 →功能性 IT 系统的实用抽象）
所有 IT 都是按原样写入和读取信息或将其转换为各种用途。信息架构定义了应用程序如何存储、非规范化、复制、更改、访问、查询、连接、保留、备份、清除、保护等信息。信息架构对IT系统的成本和性能影响最为显著。
信息架构师使用层次结构、数据库、线性、目录等架构模式来提供用户所需的功能和质量。（请参阅本文了解更多→企业数据存储库模式和进展）
系统需要相互通信，信息需要在存储库之间交换。集成架构考虑了客户端、服务器、请求、响应和有效负载的特征，以提供连接应用程序和信息功能的最佳机制。
一些典型的集成架构模式有消息传递、队列、发布-订阅、代理、编排器等（请参阅本文了解更多→企业集成架构模式）
运行IT软件的服务器、机架、存储系统、网络设备、安全设备、备份设备、数据中心、电源、空调、中间件、管理系统等也必须进行架构设计。
技术设计作为一种适当的主流架构学科经常被忽视。随着云计算和“无服务器”等范式的出现，这种情况变得更加恶化。不可避免的结果是容量、性能、可用性、弹性、安全性等问题的处理都是被动且昂贵的。因此，我们不能弃用基础设施解决方案的架构方法、制品、模式和治理。技术架构是SDLC架构设计阶段中至关重要的、不可或缺的学科和步骤。
商业和非商业企业的设计需要能够良好运行。业务架构为组织制定适当的结构，以满足其产品、服务、客户、供应商及其工作的外部环境的需求。它通过静态和动态业务模型提供战术和战略业务架构解决方案。
业务架构师考虑的一些方面是企业价值流（愿景、战略、战术、产品和服务、计划和项目）所需的功能能力以及信息（指标和措施、事件和决策、政策、他们需要的规则、法规）和组织（领域、子领域、利益相关者、人力和其他资源、层次结构）。
企业架构是最高、最广泛的架构学科。企业是任何创造价值的组织，从最小到最大，可以赚钱或从事慈善、行政、娱乐、政治、公共服务等。
企业IT架构提供了业务战略和信息技术之间的联系。它塑造 IT 以从整体、战术和战略角度支持业务。它通过企业 IT 架构（模型）、差距分析、过渡计划和架构治理来实现这一点。与其他架构学科一样，它提供功能、质量和效率，但是在企业级别。
企业架构师与业务领导者和利益相关者、学科架构师和 IT 合作伙伴合作来交付企业架构。（请参阅这些文章了解更多 →敏捷企业架构战略与规划技术、如何进行 EA 适合差距分析来修复有问题的 IT 系统，以及如何通过 4 个阶段成为企业架构师）
业务用例——捕获业务需求的最明确、架构最优雅的方式是通过用例。每一项离散且完整的业务任务都应该有一个用例。例如，登录、查看过去的订单、提出投诉等。
对于每个用例，详细说明功能需求 (FR) 步骤序列，其中包含有关前提条件、参与者、用户界面、事件、操作、输入、读取、修改、删除、健康和错误路径以及后状态的信息等等。对于每个独特的响应，捕获非功能性需求 (NFR)（例如容量、延迟、可用性等）。
常见的 NFR 可以放在最后的一个地方（例如，增长、安全等）。对于操作用例也执行此操作。确保解决方案范围内的所有参与者和功能涵盖所有业务领域。
用例从简单到复杂各不相同。如果文本描述不够，请在用例中添加流程图和交互图。
请参阅下面的口头用例描述示例（第二个和第三个用例不完整）。
上下文图 -绘制它是为了显示解决方案需要与之交互但不在解决方案范围内并且可以假设保持不变的外部人员和 IT 系统。这是解决方案的上下文或环境。它有助于定义和限制解决方案。为解决方案画一个椭圆形，将外部参与者和系统连接到其轮廓，并简要说明每个连接器上发生的情况。
请看一下这个说明图。
EA 政策、原则、指南和标准 —从企业架构师或 CIO/CTO 收集这些内容。这些也是解决方案架构师需要满足的要求或约束。有关详细信息，请参阅下面的治理部分。
约束 -整理对其他项目的依赖关系、财务和时间限制、技能限制、技术限制等。随着架构的开发更新此信息。可接受的解决方案必须考虑这些限制。
架构决策代表了架构思维的本质理性和理智平衡。架构师以开放的态度思考如何将业务功能分布在软件和硬件组件上并进行操作。做出正确的架构决策是架构师最出色的技能，它决定了整体解决方案及其成功。
制定架构决策有四个步骤。
1 收集相关 参考架构 和 架构模式
2 将业务需求转换为 功能布局、数据存储库/源和集成方法的 架构问题陈述。
3 让 参考架构和架构模式提供尽可能多的 有意义的决策。 例如，对于问题陈述“结账组件从哪里获取订单交付时间？” 如果参考架构显示了物流系统上合适的 API，那么这可能就是决定。
4 对于其余的问题陈述，使用架构决策模板来 陈述问题， 列出考虑到约束的所有合理的解决方案选项，选择最好的方案，证明其合理性，并捕获其对技术、其他决策、设计等的影响。
请查看下面的决策模板和示例。
一旦您有了上下文图并做出了架构决策，您就拥有了绘制解决方案的基本模型并对其进行描述所需的一切。
架构概述图——为不同的受众绘制两个或三个级别的架构概述图。例如，对于业务领导者，制作一个零级或 L0 级图表，显示将满足业务需求的技术领域；对于项目经理，制作一个 L1 图，显示需要交付的系统和子系统及其广泛的连接。 （有关更多信息，请参阅这篇文章 →如何绘制史诗般的 IT 架构图）
架构概述描述 -对于您创建的每个概述图，简要描述每个项目的角色以及与主要业务和运营用例的其他项目的交互。
下面是一个示例 L1 图，显示了主要业务功能和底层 IT 系统。
功能架构阶段详细说明了在步骤 2 中先前决定的系统和应用程序的组件和子组件，用于交付业务和运营用例。在指定组件时，以下架构原则促进了开发和维护的简便性。遵循它们可以显著节省时间并降低 IT 解决方案的成本。
1 重用——如果现有组件在架构上合理并且具有全部或大部分功能，则使用或扩展它。例如，如果有一个用于用户身份验证的目录组件，请重用它。如果它没有必要的层次结构，请扩展它。
2 内聚性（和粒度） ——统一的目的或概念应该定义一个架构组件，以便它包含属于在一起的方法和数据。这使得功能的清晰分离和独立开发成为可能。一个相关的目标是实现组件的正确粒度级别，即分配给组件的功能数量。
它既不能太小，也不能太大，即既不能做得太少，也不能做得太多。如果说熟练的架构师能做对一件事，那就是内聚力和粒度。它是优秀架构的核心。例如，信用风险评分数据和 API 应位于信用风险组件中，与包含整体贷款审批数据和 API 的贷款审批组件分开。但如果贷款审批部分变得太大，就像在典型的银行业务中一样，它应该分为承销、贷款融资、质量检查部分等。
3 松耦合——架构组件不应该需要了解其他组件的内部数据结构和规则。这允许对组件进行更改，而不会影响其他组件的设计。
例如，如果组件A需要处理组件B持有的项目的聚合值，在松耦合的情况下，组件B将有一个API操作来向组件A提供聚合。即使组件B的内部设计发生变化，也不会影响组件A的设计。在紧耦合（已弃用）的情况下，组件 B 将没有这样的 API。组件 A 需要知道组件 B 拥有多少个项目以及如何获取每个项目并聚合它们的值。如果组件 B 的设计发生变化，则会迫使组件 A 的设计发生变化。
以下是捐赠用例序列图的示例。
O 所选即用型服务的提供商和规范。 例如，支付网关、信用检查服务、地理定位服务等。
O 所有软件组件位于自己或合作伙伴的私有数据中心或公共云中
O 服务器物理/虚拟核心、RAM 和操作系统
O 网络架构，包括 LAN、WAN 和外部连接和容量、设备位置和大小
O 存储类型和带宽
O 根据可用性架构，将软件和硬件分布在机箱、框架、机架等中
O 以上所有中间件组件， 例如 HTTP 服务器、Web 服务器、集成系统、日志记录和监控系统等。
O 备份与恢复以及灾难恢复解决方案
对于解决方案验证，SA 依赖以下内容。
O 内部——可追溯性矩阵 ，将需求、架构和设计映射到相应的测试和 测试 结果。例如，业务和操作需求映射到用户验收测试、序列图映射到字符串测试、接口规范映射到集成测试、功能设计映射到系统测试、代码映射到单元测试、NFR 映射到性能测试等等。
O 外部—— 设计机构 （见下一节）。
1 出发点是确保 企业领导层理解并要求架构思维的价值，从企业架构到其他学科。
2 捕获 当前的 业务和技术架构。
3 使架构 检查点（或检查门）成为每个战术和战略变革过程的一部分。
方法——确定解决方案的系统方法。上面我们已经看到了一般的架构开发方法。
技能——拥有合适的人才。我们已经在上面看到了架构学科技能。
工件——为方法和实践者提供有效且一致的工具。上面的架构方法显示了关键的工件。但每个架构学科和阶段还有更多。
两个主要的架构治理机构是企业架构审查委员会和项目设计机构。
架构审查委员会 (ARB)
ARB 是在企业级别协调业务与技术的主要架构治理机构。它由 CIO/CTO 和首席企业架构师担任主席，并由企业架构师、学科架构师、业务利益相关者、财务主管、首席安全官和其他需要的人员组成。ARB 执行以下操作。
提供企业架构方向
批准架构倡议
监督项目设计机构的工作（见下文）并解决提出的任何问题。
与赞助者联络并获得利益相关者的支持
制定政策、原则、指南和标准，通过避免重新发明和不兼容或不合适的系统来提供速度、效率和质量。它们的定义如下。
政策 规定了如何在架构和技术的不同方面完成工作（任务）。 例如，所有数字解决方案均应由合作伙伴 x 提供。
原则 反映了企业的意图，有助于确定大方向（建议）。 例如，将尽可能采用开源解决方案，以降低成本并鼓励开源运动。
指南 有助于决定小问题（建议）。 例如，B2B 集成应通过企业 B2B 集成网关完成。
标准 可实现可重复性、速度和效率（决策）。 例如，所有 API 将基于 TMForum Open API。
设计专家组 (DA) 或解决方案审查委员会 (SRB)
设计专家组确保每个项目都遵循通用和特定于企业的架构实践，并帮助解决方案架构师做出决策和解决问题。一名企业架构师主持该小组，该小组由经验丰富的学科架构师、IT 部门负责人、项目经理、运营经理和其他利益相关者组成。该解决方案由解决方案架构师、业务分析师、项目经理以及开发和测试主管代表。
DA 执行以下操作。
开发和维护企业级架构
与项目团队进行架构审查
为架构所有领域的项目团队提供建议和指导
担任企业ARB代表
识别并解决问题，并在必要时上报给 ARB
管控、技能和治理机构到位后，通过组织的 项目管理办公室或其他监督机构将其应用于三个层面的变革：
根据业务驱动因素制定 一到三年的企业级 IT 战略和计划(S&P)
指导 从上述战略和规划流程中入围交付的IT 项目
管理 现有 IT 系统中的常规变更
不要只称自己为架构师。学习架构，用至少 80% 的工作时间进行实践，遵循方法，交付物并进行认证。这很容易，特别是如果您热爱并享受架构，而不是仅仅为了它的声望或报酬而这样做。
一些大型全球 IT 服务公司（令人惊讶的是，很少）将架构作为明确的职业道路，并提供内部或附加架构培训。如果您属于这样的公司，请接受其培训。你也可以通过阅读书籍和文章学到很多东西，这是你应该做的。但请记住，不要开始认为你吸收的一些大杂烩就是架构。
你必须去做才能得到它并成为它。这也适用于建筑。寻找您可以担任首席架构师或支持架构师的项目。确保团队的其他成员和管理层了解架构的价值和必要性。按照方法并交付文物。了解每个人在不同程度上都是架构师的客户，并与他们互动以收集需求和约束并传达架构思想 - 业务人员、BA、PM、设计师、编码员、测试员、操作员、其他架构师和合作伙伴。
IT 架构师与各种各样的人一起工作。他们必须从许多人那里获取信息，说服和哄骗其他人，并带动所有人。因此，他们拥有或获得有效沟通、正直、幽默、影响力、有条不紊的方法和领导力的特征。广泛的常识、对时事和全球趋势的兴趣以及哲学倾向帮助他们看到并展示大局。
与其他职业一样，从较小的视角到更大的视角、从深度到广度的工作是更自然的。编码、设计和技术方面的经验造就了一名优秀的架构师。其他架构学科的经验造就了一名优秀的企业架构师。
下面列出了架构领域的一些典型职业道路（按发生顺序和平稳过渡）。当然，可以有其他序列和起点。你需要弄清楚你的兴趣如何维持或发展。
编码员→设计师→应用架构师→集成架构师→企业架构师。
编码员→设计师→应用架构师→信息架构师→企业架构师。
技术专家→基础设施架构师→企业架构师。
据统计，99%的大咖都关注了这个公众号
