以下是对企业解决方案架构的核心工程阶段的精简回顾：
解决方案架构有什么用？
解决方案架构有许多不同的风味，而且几乎每家公司都有其混合的责任，这是个术语。
因此，有一个共同的基础来解释和分类解决方案架构中所涉及的核心功能和角色是至关重要的。
本文进一步细分的基础是TOGAF框架，这是一个著名的、成熟的框架，概述了软件开发和架构标准。
如果你正在阅读这篇文章，你很可能参与了软件开发，并且你正在问自己如何成为一个架构师，或者如何为你的团队找到一个架构师。你甚至可能想偷偷了解一下企业环境中软件开发的复杂性，或者想获得另一个认证，而TOGAF就在这个名单上。
什么是解决方案架构？
解决方案架构！=技术架构
Open Group对解决方案架构的定义明显地强调了业务操作。
对一个离散的、集中的业务操作或活动的描述，以及信息系统（IS）如何支持该操作。
然而，该组织既不承认 "解决方案架构师 "是一个角色，也没有将其纳入TOGAF的技能框架。
它在信息系统、技术和业务架构之间划出了一条细线。
- 解决方案架构的一个巨大范围在于对流程、框架和组织结构的定义。
- 信息系统架构和技术架构只是隐藏在其伞下的一些支柱。
业务架构
业务架构是一个先决条件，它为进一步的设计活动提供了基础和输入。
从本质上讲，业务架构必须证明技术架构和未来系统是如何与利益相关者的投资回报率相匹配的。
定义架构和组织价值之间联系的最常见方式是使用业务场景--技术架构可以实现的流程和应用。
一个好的业务场景必须是：
- 具体要求--需要做什么
- 可衡量的--成功的衡量标准
- 可操作的--确定解决方案的行动计划的基础
- 现实的--在组织、时间和成本限制的范围内
- 有时限的--机会到期时有明确的时间表
因此，有了一些软件工艺的经验，你会发现业务架构是敏捷中产品经理、产品所有者和业务分析师的工作。
尽管TOGAF并不关心敏捷方法论及其调整，但你可以在最常见的企业采用的敏捷中找到业务架构的参考。
作为参考，你可以查看一个大型组织的SAFe（Scaled Agile Framework）配置。
软件架构师可以成为解决方案积压（Solution Backlog）、解决方案背景（Solution Context）和解决方案意图（Solution Intent）的一个重要贡献者。
相比之下，在BAs的支持下，业务拥有者的工作是定义和确认未来技术架构的需求基础。
信息系统架构（ISA）
业务架构有明确的目标和范围，而信息系统架构则嵌入了一套基本的设计和分析活动。
简而言之，信息系统架构的主要目标是确保在企业的范围内，不管是已经建成的还是目前处于设计阶段的，都能得到充分利用，并与我们未来要开发的系统保持一致。它适用于数据治理、结构以及与现有应用和能力的整合。
当ISA被忽视时，即使是一个架构良好、看似成功的应用/系统也可能无法适应当前的企业生态系统，因此，它本身就会成为一个失败的例子。
ISA包括两个步骤。
- 数据架构
- 应用架构
两者都以业务场景、背景、意图、差距分析结果和组织的可重用构件为输入，并产生数据应用架构、蓝图和系统打算实施的目标架构的核心原则。
数据架构
在这个阶段，设定数据架构工作的界限和架构师的参与程度非常重要。
常见的错误是跳到数据库设计，数据层的逻辑和物理架构。然而，主要的目标是识别和定义与企业相关的数据实体及其关系，特别是关于我们正在设计的信息系统的范围。
ISA数据架构不是关于数据库图或ACID原则的。
通常情况下，这一步的工作背景是通过业务场景和架构愿景来定义的。
一旦收到所有的输入，数据架构师就必须建立一个基线数据架构。这种架构工件的格式在每个组织中可能有所不同，但它应该包括以下信息。
- 业务数据模型（实体、属性和关系）
- 逻辑数据模型（从系统的角度对数据的逻辑看法）
- 数据原则（安全、治理和管理模式）
一旦定义了基线，就会产生另一个基本文件--目标数据架构。
目标文件将包括数据模型和原则的定义以及其他支持性文件，投射到系统实现系统目标和业务目标的未来状态中。
所以，它是一个试图根据架构和业务信息来预测未来的尝试。
应用架构
在TOGAF中，应用架构的目的是审查与企业相关的能力和应用。
所以，这一步的工作将包括分析当前的应用、它们的互动以及它们对业务功能的影响。
在这个阶段审查的应用并不被定义为一个计算机系统，而是企业中的一个逻辑能力组，它管理着数据架构中的数据对象，并支持业务架构中的业务功能。
注意：ISA应用架构不是关于设计模式、服务或API的。
除了我们在每个设计和分析阶段收到的工件之外，还有一些专门针对应用架构的输入。
- 应用原则--应用架构的基本规则的集合，它们的理由和影响由架构负责人和架构委员会制定。
- 架构愿景--详细的目标、行动者和他们的角色、架构约束以及与目标架构相匹配的要求。
工作和产出将类似于数据架构，不同的是我们所分析的对象--应用程序。
- 基线应用架构
- 目标应用架构
- 解决关键利益相关者关注的观点
- 通用应用服务互操作性观点
需要注意的是，所有的设计工作都应该与应用背后使用的技术无关。
TOGAF良好应用架构的核心原则之一是技术独立和易于使用。
技术解决方案架构
祝贺你，我们终于到达了软件工程师所颂扬的解决方案架构的部分。
前面的步骤主要属于尽职调查，而技术解决方案架构通过使用面向服务的描述对构件和系统进行建模，定义了未来应用的具体特征。
这一阶段的目标是将需求、约束、分析、原则和指导方针转化为未来实施工作的基础。
在这个阶段，技术架构师的一个关键交付物将是一个目标技术架构--一个使用架构积木（ABB）的广泛的架构模型，提供对特定应用和全球企业功能的洞察力。
让我们简单回顾一下目标技术架构中必须要解决的基本部分：
- 原则--将ISA原则和约束实现为适用于实施工作的规则
- 参考模型和模式--构件的定义、功能的模型、服务和企业范围的框架
- 观点--整体架构的表述，展示如何解决利益相关者的关切，即服务互操作性观点、成本观点、处理观点等。
- 架构定义--对相对抽象的服务地图和详细的特定实施构件的全面表示
- 过渡架构--必须定义的中间架构，以展示在需要多个步骤时迁移到目标架构的复杂性
- 架构决策记录--在系统开发的每个阶段做出的架构决策的注册表
决策、承诺、重复
最后，我们审查的阶段中没有一个是一次性的行动。架构师和开发团队应该经常回到以前的结果，根据不断变化的业务和生态系统的要求来审查和重新评估决定。
在不断发展的技术、不断变化的趋势和客户需求的背景下--目标系统架构和系统架构作为一个整体总是一个移动的目标。难怪近年来，新兴架构与敏捷方法论携手并进，越来越受欢迎。
C4模型
C4模型是一个参考模型和框架的完美例子，它允许在技术架构中拥有必要的细节水平。
C4是一种用于技术架构建模的图形符号技术，吸收了UML和ERD模型的最佳部分。
它将架构分解为不同层次的观点。
- 第一层：上下文背景图--显示与外部系统和用户的关系
- 第二层：容器图--将系统分解为一组可作为单独组件部署的架构构件，以解决业务问题
- 第三层：组件图--使用建筑连续体中定义的原则和技术实现容器功能的技术和应用代码（不能单独部署）。
- 第四层：代码图--接口和实现细节等。
如果你还没有，请查看这个框架。它是一个简单易行的工具，可以简化你组织中的沟通。工程师、业务分析员、建筑师和其他人都可以用它来分享知识和做出决定。
更多C4模型介绍
构建块
构建块building block是一个功能包，它的定义是为了实现组织中的业务需求，并有公布的接口来访问这些功能。
TOGAF的技术架构是关于架构构建块（ABBs：Architecture Building Blocks）。
因此，架构是一组构件、规范和互操作性的映射，以实现业务需求。
重要的是要理解，定义和维护ABBs注册表的工作似乎是多余的，需要在一个大型组织中支持和接受可重复使用。
在架构工作从愿景到业务、IS以及最终的技术架构阶段（A到D，看ADM）的过程中，ABBs被逐渐定义和指定。
每一步，ABB都会有更具体的形状和特征，并被确定为延续、消除、定义为一种新的能力、开发或采购。