企业架构师、解决方案架构师和技术架构师的异同 - Briqi

企业架构师、解决方案架构师和技术架构师的异同 - Briqi
SDLC是软件开发生命周期 Software Development Life-Cycle简称，软件架构是 SDLC中初始设计阶段和每次迭代（作为设计质量控制）的主要阶段。重要的是利用不同的架构角色为组织业务增加价值，如果不了解架构师这个角色，就无法实现这一点。
无论软件架构师的角色是什么，最终都是关于做出设计决策。
实际上，架构景观是一个描述设计决策集合的可视化图表。
这提出了一个关于软件架构边界的观点，因为这些边界在 SDLC 中的架构师、开发人员、经理和其他利益相关者之间以某种方式（具有不同的范围）共享。
就像任何职业一样，有人负责输出，另一方面，另一个人处理该输出。就像医生在完成所需的诊断后写了一份药物清单，然后患者以对症状和治疗的良好知识（或背景）来处理该输出，但不喜欢医生知识的深度和广度。另一个民用建筑的例子，虽然建筑师创造了设计，但土木工程师和建筑商必须使用他们自己的建筑设计技能来审查建筑。
似乎我们有两个术语：专业和技能。这意味着，架构设计是 SDLC 中每个角色都必须具备的一项技能，但在将架构师视为负责整体设计的专业人士时要特别考虑.

软件架构师在 SDLC 中的作用是什么？
这取决于 SDLC 期间的设计范围：

• 在应用程序设计中，角色将是应用程序架构师（.NET、JAVA、iOS 或 Android 应用程序架构师），负责在编程技术、框架、组件、层和集成接口。
• 负责 SDLC 自动化设计的 DevOps 架构师。
• 负责使用不同方法和技术设计托管环境的平台架构师（例如，云上或 on-prim 或混合解决方案上的容器管理系统。
• 基础架构和网络架构师负责直流拓扑和网络。
• 负责编写跨技术和/或应用程序的解决方案的解决方案架构师（例如 Azure 解决方案架构师、AWS 解决方案架构师或特定程序解决方案架构师）。
• 企业架构师，他负责在组织范围内为 SDLC 设计整体架构基础，描述主要架构视图（业务、应用程序、数据和技术），有时也被引用以 EA 架构师为 IT 架构师。

角色
软件架构角色具有共同的技能，并且共享为业务需求提供技术解决方案设计的相同概念，但是在组织范围和技术专业化方面的职责和输出是不同的。
这导致我们将架构角色组织为三个主要类别：企业架构；解决方案架构；和技术架构。

​

1. 企业架构
它是关于跨越组织内或多个组织内的跨系统的解决方案类型。
企业架构是指组织级别的整体设计工件，描述健壮和弹性设计，考虑适合业务需求的不同架构视图，并根据需要灵活应对变化。
企业架构师的角色扩展到业务和管理。与高层管理人员合作，了解组织的业务目标，并与底层架构委员会合作，定制 EA 解决方案，从业务、信息和技术原则方面描述组织数字产品和服务的景观设计。企业架构师负责设计原则的持续发展，作为参考架构的一部分，以指导组织中任何架构师可以处理的任何类型的潜在设计的创作。
在深入了解更多细节之前，了解 TOGAF 和 Gartner 等其他权威机构对企业架构的标准定义会很有用：

• TOGAF 将企业架构定义为组件的结构、它们的相互关系以及随着时间的推移管理它们的设计和演变的原则和指南，这些原则和指南描述了组织的最高级别（通常），通常涵盖所有任务和功能。一个企业通常会跨越多个组织。
• Gartner 将企业架构 (EA) 定义为通过识别和分析变革的执行以实现期望的业务愿景和结果，主动和全面地领导企业应对破坏性力量的学科。EA 通过向业务和 IT 领导者提供可用于调整政策和项目的签名建议来实现价值，以实现利用相关业务中断的目标业务成果。

尽管这是一个重要的架构角色，但在现实世界中，该角色可能会被遗漏或隐含地作为另一个角色职责的一部分，例如首席架构师或 CTO 职责。
关键技能：

• 商业意识和设计
• 组织分析和客观性
• 富有洞察力和远见
• 技术设计能力
• 具有 EA 框架的经验和知识

2. 解决方案架构
它是一种模糊的架构类型，因为它跨越了SDLC的不同领域，如预售、管理、开发和运营。它意味着为与特定行业、供应商或组织内的特定程序相关的应用程序程序提供端到端解决方案。不知何故，这类架构类型被故意或错误地与其他架构类型（EA 和 TA）一起计算。
那么，为什么这种类型的架构与其他类型混合在一起呢？让我解释。
企业架构师主要是指从方法和实现细节中抽象出来的组织内软件应用程序的通用技术标准和参考架构的全局设计。而技术架构师是指如何使用特定系统和特定技术实施解决方案的详细设计。因此，解决方案架构师在这里填补了这两个角色之间的差距，因为该角色具有提供跨越不同技术和不同系统的解决方案的技能。
我们可以在 SDLC 中按供应商的产品或组织程序分组的标题下看到此角色。

​
微软、亚马逊、谷歌等供应商正在提供旗舰产品/服务，例如 AWS 云、Azure 云等。
而对于像大公司、政府（例如部委）、研发实验室、新兴业务（例如加密和物联网）或任何其他类型的组织，它们倾向于在特定计划下在内部管理一组产品（或服务）。例如，一个大组织决定在程序结构下组织产品和服务，而每个程序管理一组应用程序。
解决方案架构师可以在软件架构中扮演不同且更多的角色，通过组合的技术解决方案来体现业务商业价值，而业务不会停止。
解决方案架构师与企业架构师和技术架构师协同工作，在 SDLC 的不同阶段进行所需的设计输出。
关键技能：

• 业务需求分析
• 利益相关者分析
• 具有分布式系统和广泛的软件工具和编程技术的经验
• 具有企业集成解决方案的经验
• 解决方案建模和文档（以每个利益相关者都能理解的方式）
• 技术实施的解决方案治理

3. 技术架构
它是一种架构类型，是指基于特定技术对系统进行底层设计，以提供系统子组件及其相互之间和与其他系统交互的详细技术解决方案。
技术解决方案的复杂性因每个业务案例而异。例如，像 .NET 应用程序这样管理基本业务场景的简单数据输入/输出的案例，可能不需要技术架构师，因为技术最佳实践本身的文档足以涵盖技术解决方案。而对于其他复杂的场景，分布式事务将发生在系统之间，需要一致的事务提交和安全回滚，或者复杂的逻辑将发生在系统内，需要特殊的设计模式，因此这里需要技术架构师的角色.
这是否意味着企业架构师和解决方案架构师不是有关技术解决方案！？当然，技术架构是根据企业架构师设计的技术策略和解放方案师的技术高级设计来设计详细的技术实现。
在现实世界中，这个角色可以由熟练的开发人员或解决方案架构师扮演，以防他/她具有技术经验，并且工作地点强加了架构角色（如初创公司和小型组织）之间的合并。
技术架构师是技术极客，主题专家（SME），具有设计与特定技术领域相关的纯技术解决方案的技能

• 应用程序编程技术，例如 .NET、Java、Python、iOS、Android 等。
• 数据技术，如数据库、大数据、ML&AI、API等。
• 基础设施技术，例如网络和虚拟化
• 平台技术，例如 Terraform、Ansible、Azure DevOps、ArgoCD、Jenkins 等。
• 区块链技术，例如超级账本结构
• 物联网技术，例如思科物联网

下图描述了每个类别的架构角色

架构层次
每个架构角色都被视为设计中的一个层，相互结合形成不同利益相关者理解的清晰设计形象，并反映在最终的软件产品上.
这里对架构角色采用的分类可以换一种说法来解释。其中企业架构是识别概念架构风格的层，解决方案架构是识别逻辑架构模式的层，技术架构是识别物理设计模式的层。

​

我们可以想象一个架构解决方案设计的最终图像的说明性示例，如下图所示，它将企业架构描绘为主要框架（或景观），技术架构描绘为框架中的点，解决方案架构描绘为线条将点相互链接。

角色举例
让我们举一个简化的例子，放弃像新电信公司这样的组织中的角色，考虑到在现实世界中，我们可能有不同的情况和业务需求，以对组织有利的方式使用架构师（例如架构团队结构和组织结构图中的角色）。
让我们假设一个理想的架构团队具有一个企业架构师、三个解决方案架构师和许多技术架构师的结构！（稍后声明）。他们将共同交付可用于 SDLC 后续步骤的目标设计文档。
此示例描述了企业和解决方案架构的逻辑应用程序视图的简化设计。而其他视图（例如应用程序、数据、拓扑、技术堆栈、集成等）未在此处描述。 每个架构视图都可以用三种形式来描述（概念、逻辑和物理）。有时将视图混合在一起（或简化）以赋予目标利益相关者以意义。
收集、分析和与不同利益相关者讨论业务需求后，每个架构师角色将按以下方式工作：

(1)
企业架构师对业务需求和利益相关者进行分析研究，然后处理景观架构的设计工件，从信息系统和技术的角度描述产品和服务的核心业务。交付物工件因组织而异，架构框架因架构框架而异，但可以说企业架构师根据原则和不同的架构视图绘制高级技术策略。该解决方案的重点是强调主要系统、它们的特性、拓扑、它们的通信方式以及它们的技术。Enterprise Architect 负责整个企业解决方案的治理模型，
下图描绘了电信组织系统的企业架构的逻辑视图

​

(2)
Solutions Architect 与企业架构师和技术架构师合作，为企业解决方案（例如自我保健计划）中的特定领域提供解决方案设计，比在企业架构中具有更多和更深入的技术潜水。
解决方案架构师将为每个架构视图提供更多详细信息。描述层、组件以及它们与外部系统之间的集成。因此，让我们使用下图作为描述自助解决方案的逻辑应用程序视图。

​

该图描绘：

1. 客户端渠道和每个渠道的一般规范，例如（网页、移动应用程序、聊天机器人等）。
2. 与身份和用户访问管理器 (IAM)、API 管理器和静态内容等边缘组件的接口。通信协议和认证机制。
3. 与内部系统之间的交互。和环境服务。

解决方案架构师将详细介绍每个架构视图，以根据每个利益相关者（例如客户、管理人员、开发人员、测试人员和操作员）从不同的视图涵盖解决方案。
除此之外，解决方案架构师将更多地关注可重用性（例如代码模板、包和服务）和系统质量属性（例如可靠性、可用性、性能、可移植性）。
下图中的另一个解决方案架构示例描述了物联网解决方案的逻辑应用视图。

​

这里的最后一个示例是针对MS Azure 灾难恢复解决方案架构的

​


(3)
技术架构师比解决方案架构师和企业架构师更清晰。技术架构师正在从原理和理论走向实际和具体的实现，因此在代码设计和支持开发人员、系统管理员和运营商的战场上找到技术架构师是很正常的。手牵手，但仍然戴着设计的帽子。
技术架构师提供的文档类型是低级设计文档，它根据设计模式描述代码结构、数据库低级设计、描述系统之间复杂交互流程的特殊流程图等。
技术架构师不承担开发任务，而是通过代码模板、POC和技术咨询支持开发过程. 这与敏捷交付并不矛盾，因为技术架构师负责最终的技术输出，支持正在运行的开发过程，并监控每个 SDLC 迭代的输出. [在心态文章中详细说明]。

​

现实中的角色
首先，在着手构建架构团队的层次结构和他们的职位之前，我们必须非常了解组织业务和组织结构图。
初创公司、小型企业、中型企业和大型组织都将拥有自己的图表和架构角色。例如一家初创公司，几乎都会从一位专家架构师开始。而大公司将拥有更成熟的组织结构图和标准架构角色。
每个架构师都有 t 型技能，在特定架构领域（垂直领域，例如应用程序架构师）的专家，同时在水平领域（例如其他架构角色）与其他人很好地协作。
架构师正在做一个共同的活动，无论角色如下：

1. 支持业务价值流的解决方案设计。
2. 架构治理以监控设计的执行或根据进度更正设计本身.
3. 根据需要提供技术支持和咨询。
4. POC 和研发支持解决方案设计并保持敏锐的技术技能。
5. 自我发展（架构师思维和软技能）

所有这一切都将导致我们发现架构角色之间存在交叉，这可能导致职责之间的混合，以及通过产生昂贵的设计而导致架构师或架构师自己对架构的不良利用。
另一个事实是，架构技能已经存在于软件开发中的所有成员之间。但这里的问题是：谁有能力做出设计决策并跟进，直到它变成商业价值？
最大化团队之间的协作模型并尽可能分离他们之间的职责非常重要。因此，将设计责任赋予正确的架构师角色将为业务带来巨大价值.
下图描绘了现实世界中架构角色之间的横截面，以及从一个组织到另一个组织的角色的存在与否。

​

架构师承担不同架构角色的责任是没有问题的，同时符合真实案例和T型架构技能的事实。问题是将架构师的角色（主要是设计角色）与 SDLC 中的非设计角色混合在一起，或者以某种方式忽略角色。

软件架构中的其他角色
当将软件视为一个集成行业时，这将导致我们在软件架构下包含更多角色，例如用户体验 (UX) 设计师和业务/产品分析师。
架构师角色是 SDLC 中管理设计活动的职位或技能。

我们需要 SDLC 中的角色软件架构师吗？
每个人都有建造房屋的技能，但有多少人能够正确建造它而不会变得丑陋或很快被摧毁？此外，我们是要建造小型/简单的房子、很棒的房子还是摩天大楼？在软件领域也是如此，如果您正在开发一个小型产品/服务，并且您拥有具有良好设计技能的熟练开发团队（这已经依赖于现有的架构知识，例如架构模式），那么您可以在没有明确的架构师的情况下进行。如果组织拥有多个开发团队和多个产品/服务，则情况会有所不同，那么架构师的角色就会出现，以统一设计思维并在设计阶段支持 SDLC。此外，在使用旗舰产品时情况会有所不同，您不能没有架构师。
我更愿意将软件架构作为组织内部或外部的咨询服务，作为在 SDLC 中分离角色以减少团队之间的耦合并加速 SDLC 流程的一种方式.