我们应该期望软件架构师做什么？

介绍

我最近发现了Joseph Ingeno（一位软件架构师）在Pack Publishing出版的《软件架构师手册》。

随着现代软件系统的复杂性，软件架构师的角色变得颇具挑战性。本书旨在帮助软件开发人员过渡到软件架构师的角色，并协助现有的软件架构师在他们的角色中取得成功。它帮助读者理解成为软件架构师与开发人员的不同之处，以及成为有效的软件架构师所需具备的条件。

我非常喜欢这本书，并从一个信息系统架构师的角度对其进行了全面的评价，依赖于企业架构和企业应用的受控城市化，并基于我在PLM领域的经验，即在整个扩展企业中实现数字协作，并使用许多异构的商用货架软件产品（COTS）。这意味着我们必须能够交换、共享和长期保存/归档数据，时间跨度远远超过一个软件产品的生命周期。

为了全面概述这本书，我制作了一套地图，每章一张，采用的方法类似于思维导图，但使用了ArchiMate和Archi。这不仅捕捉了书的结构，还捕捉了主要概念，特别是与企业架构模型相关的概念，这些概念可以通过ArchiMate语言捕捉到：流程、参与者、角色、目标、原则等。

这是一种不常见的使用ArchiMate的方式，可能不是企业架构师推荐的方法。但其有趣之处在于，它能够识别ArchiMate在书中描述的内容。因此，它可以用来识别ArchiMate能做什么，不能做什么，以及不应该用于哪些场景。然后，可以考虑使用其他语言或元模型，例如SPEM？带有模板的UML？还是其他？

这也是一个使用 Archi“玩”的机会，通过文件夹和“Group” ArchiMate 模型构建来试验工具在模型结构化方面的能力。我尝试捕捉一组个体，这些个体可能有多种类型，但没有能力用 ArchiMate 构造对其进行分类。我还使用它们来捕捉章节，这可以被视为一种将多个元素分组的方式。因此，这是一种反映书籍结构及其内容的好方法，即一组使用 ArchiMate 形式化的相互关联的概念。从这一点出发，可以探索一致性，并提取一些元素以从书中推导出某些 Archi 模板的内容，这些模板可以后来重复使用。

然后我分析了内容，从企业架构的角度来看，了解到ArchiMate考虑了一组专门针对明确识别的利益相关者视角，特别是参与企业架构设计的各种架构师，他们需要协同合作，确保整个信息系统及其底层技术基础设施与企业的目标和业务需求保持一致。这里应该考虑到，企业不再倾向于为非核心业务开发软件，而是依赖于商用现成软件（COTS）或云服务。因此，代码的架构设计对他们来说既不一定是可见的，也不一定是必需的。因此，像敏捷（SCRUM等）这样的趋势，其中提到“架构在代码中”，对他们来说可能会产生误导，因为他们将更多地使用建模来指定支持其信息系统的软件产品，部署和连接这些产品，从商业和技术角度管理它们，确保应用程序、业务部门和网络之间适当的信息/数据流。这也帮助他们更好地理解一些相关实践，特别是DevOps或微服务，如何融入其中。

描述本书内容的地图集

我在每个章节的描述中使用了前言中提供的内容，然后结合使用Archi生成的地图以及对章节的一些反馈。

第1章：软件架构的意义

它“通过提供软件架构的定义来开始这本书。这本书明确了构成软件架构的内容及其对软件系统的重要性。它还详细介绍了软件架构师的角色，包括软件架构师的责任以及他们需要掌握的知识。»

我喜欢这一章，因为它阐明了架构师应该了解的内容。这为更清晰地定义架构师的角色提供了一个良好的基础。在一个希望建立一支具有明确目标的架构师团队的组织中，这也是识别实现这一目标所需资源和能力的一种方式。

可以适应其他类型的架构师：解决方案架构师、应用架构师、企业架构师

第2章，组织中的软件架构

它侧重于组织中的软件架构。它涵盖了你可能遇到的不同类型的软件架构师角色和软件开发方法论。非技术主题，如项目管理、办公室政治和风险管理也进行了解释。软件产品线的开发和架构核心资产的创建也被涵盖。

在这里我不完全同意作者认为其他提到的架构师实际上是软件架构师的观点。我认为他们有着真正不同的角色和所需技能。然而，他们应该紧密合作，与其他角色如项目经理、安全专家等一起合作。我认为 ArchiMate 视图正是为了促进这种互动而设计的。

第3章，理解领域

它“讨论了作为一名软件架构师的业务方面。它涵盖了熟悉组织业务、领域驱动设计（DDD）以及如何从利益相关者那里有效提取软件系统需求等主题。”

在专注于开发技术时，有时很难拉开距离，从而能够捕捉到目标用户的需求和领域逻辑。然而，这对于有效支持以及确保应用程序如何为用户创造价值至关重要。这也是我喜欢ArchiMate的原因之一，因为它通过动机视角（和建模构造）捕捉到了这一点。

第4章，软件质量属性：

它涵盖了软件质量属性及其对软件架构的重要性。介绍了几个常见的软件质量属性，包括可维护性、易用性、可用性、可移植性、互操作性和可测试性。

质量属性可能是架构师最关心的问题之一，无论是对于软件、应用程序、信息系统还是企业。这些属性并不总是显而易见的。多年来，我一直关注支持持续安全协作的互操作性和演进系统。实现 PLM 开放标准的解决方案的可测试性是 SIP 项目的主要驱动力。

第5章，设计软件架构

它集中讨论了软件架构设计这一重要主题。它详细介绍了架构设计的内容及其对软件系统的重要性。本章讨论了不同的架构设计方法、驱动因素以及在设计过程中可以利用的设计原则。本章介绍了各种系统化方法在软件架构设计中的应用，包括属性驱动设计（ADD）、微软的架构和设计技术、以架构为中心的设计方法（ACDM）以及架构开发方法（ADM）。

我喜欢这些之前不了解的技术。

第6章，软件开发原则与实践，

它“描述了经过验证的软件开发原则和实践，可用于构建高质量的软件系统。涵盖了松耦合和高内聚等概念，以及KISS（保持简单）、DRY（不重复）、信息隐藏、YAGNI（暂时不需要）和关注分离（SoC）等原则。章节还包括对SOLID原则的讨论，包括单一职责、开闭、里氏替换、接口隔离和依赖倒置等原则。章节最后讨论了帮助团队成功的话题，包括单元测试、设置开发环境、结对编程和审查交付成果。”

我不知道所有确保代码质量的实践，很欣赏这一章。

第7章，软件架构模式

它“讨论了最实用的软件架构设计概念之一。学习可用的架构模式及其适当的应用场景是软件架构师的一项关键技能。本章详细介绍了多种软件架构模式，包括分层架构、事件驱动架构（EDA）、模型-视图-控制器（MVC）、模型-视图- presenter（MVP）、模型-视图-视图模型（MVVM）、命令查询职责隔离（CQRS）和服务导向架构（SOA）。”

很好的概述。我认为基于流程执行（带有引擎）的解决方案缺失了，这比服务编排的面向服务架构（SOA）更进一步。基于消息的解决方案（如消息导向中间件）和关于复杂事件处理（CEP）的更多细节我认为也缺失了。对象管理架构提供了一种相当有趣的对服务的分类，软件架构师也可以研究一下。

第8章，现代应用架构

它“解释了现代应用程序部署到云中所使用的软件架构模式和范例。在描述了单体架构之后，该章节详细介绍了微服务架构、无服务器架构和云原生应用。”

高度面向微服务，尽管生态系统尚未完全成熟。我能理解对这一技术框架的关注，今天也不能忽视它。但同时，对于一些其他框架，例如 CORBA3、基于传统 Web 服务的 SOA 解决方案、应用服务器、J2EE、OSGi 等，也应有所了解。当然，不提供详细信息，但可以简要介绍并提供一些参考。对于企业架构师或解决方案架构师来说，许多遗留应用程序和当前的 COTS 产品仍然是单体架构或使用这些技术。

第9章，横切关注点，

它“将重点放在系统多个领域中使用的功能上。它解释了如何在应用程序中处理横切关注点。涵盖的主题包括使用依赖注入（DI）、装饰器模式和面向切片编程（AOP）来实现横切关注点。该章节还提供了对不同横切关注点的介绍，包括缓存、配置管理、审计、安全、异常管理以及日志记录。”

介绍一个有趣的模式。

第10章，性能考量

它“重点关注性能。它描述了性能的重要性以及提升性能的技术。讨论了诸如服务器端缓存和数据库性能等主题。章节中还包括对 web 应用性能的分析，包括 HTTP 缓存、压缩、最小化和捆绑资源、HTTP/2、内容分发网络（CDNs）、优化 web 字体以及关键渲染路径等内容。”

这里也有一个复杂且非常庞大的领域，涉及许多技术。这只是对该主题的一个简要介绍，该主题值得更深入地研究。

第11章，安全考量，

它“涵盖了软件应用程序安全的关键主题。介绍了诸如保密性、完整性和可用性（CIA）三元组以及威胁建模等安全概念。该章节为读者提供了多种设计安全软件的原则和实践。”

正如标题所述，这里只涉及安全方面的考虑，我认为这是一个庞大且复杂的主题。开发人员和软件架构师只是众多安全贡献者中的两个，还包括安全官、安全审计员以及应用程序用户。对于考虑门户技术的开发人员和软件架构师来说，这可能很有兴趣，因为门户技术如何确保通过单点登录（SSO）、LDAP、基于SAML的身份联合等方式，为所有企业应用程序提供安全的访问点。

第12章，软件架构的文档化和审查

“它侧重于软件架构的文档编制和审查软件架构。它描述了软件架构文档的各种用途，并解释了如何使用 UML 来记录软件架构。该章节讨论了各种软件架构审查方法，包括软件架构分析方法（SAAM）、架构权衡分析方法（ATAM）、主动设计审查（ADM）和中间设计的主动审查（ARID）。 ”

描述应用程序并在仓库中共享这些描述是TOGAF定义的连续体中绝对必要的。我更倾向于采用模型中心的方法而不是文档中心的方法，这依赖于现代OMG技术，因为我使用了对象管理集团提出的模型驱动方法和模型驱动架构。因此，我认为对UML的描述相当薄弱。然而，我也理解对于DevOps来说，这可能没有DesignDevOps那么重要。我强烈建议软件架构师探索UML的潜力和兴趣。

第13章，DevOps与软件架构

它涵盖了 DevOps 的文化、实践、工具和文化。该章节解释了关键的 DevOps 实践，例如持续集成 (CI)、持续交付 (CD) 和持续部署。

我喜欢这段对DevOps、持续集成/持续交付/持续部署的简短解释。与敏捷开发（尤其是Scrum）也有明显的联系。一旦虚拟化机器和容器支持应用程序和机器（虚拟化）的交付和部署自动化，并且通过云支持自动调整弹性，那么DevOps、微服务和云技术相辅相成的原因就显而易见了。是否应该进一步推广？在过去，我研究并使用了AndroMDA，它支持向设计侧的左移，包括安全方面。然而，互连机器的基础设施平台超出了其范围。我在SIP项目中原型化了基于模型的方法，依赖于ProxMox进行互联系统的实验和模拟。所使用的容器基于LXC，而不是Docker。能够自动配置和参数化机器依赖于一组预配置的设备。我通过这本书了解到了一种新的“-aaS”类型。

第14章，架构遗留应用程序

它为读者提供了如何处理遗留应用程序的理解。由于遗留应用程序的广泛使用，这一主题对于软件架构师来说非常重要。本章涵盖了对遗留应用程序进行重构以及如何将它们迁移到云端。它还讨论了如何现代化遗留应用程序的构建和部署流程，以及如何与它们进行集成。

对于企业架构师而言，实施和迁移总是必要的，信息系统是一个不断演进的环境。这里重点不是重构代码和应用程序（这是解决方案提供商的工作），而是能够停用应用程序并最终迁移需要保留的数据。

第15章，软件架构师的软技能

它“主要讲述了软件架构师应该具备的软技能，以成为一个有效的软件架构师。在描述了什么是软技能之后，该章节继续讨论了诸如沟通、领导力、谈判以及与远程资源合作等话题。”

这一章相当标准，并不特定于软件（或企业）架构师。在处理信息技术时，一个困难是不同类型的架构师之间可能存在混淆，他们的职责范围和术语也有所不同。一些术语，如过程、服务或数据，被过度使用，带来了许多沟通问题。

第16章，演进式架构

它“教导如何设计软件系统，使其具备适应变化的能力。它解释了变化是不可避免的，因此软件架构师应该设计能够随着时间演进的软件架构。该章节解释了处理变化的一些方法，并介绍了使用适应性函数来确保架构在变化过程中继续满足其所需的架构特性。”

我不知道莱曼定律（Leman’s law）或适应性函数（fitness functions），但通过我在PLM互操作性方面的活动，我对持续变化和依赖开放标准的进化平台的需求非常熟悉。因此，我完全同意约瑟夫·英格诺（Joseph Ingeno）关于标准重要性的观点，这些标准不仅有助于互操作性，还能够提供可以动态重新配置并适应其业务和技术环境的进化平台。此外，数据应该独立于用于生成它们的应用程序/工具来保留其语义。

第17章，成为一名更好的软件架构师

它强调读者应该认识到职业发展是一个持续的过程。成为软件架构师之后，必须不断获取新知识并提升技能。本章详细介绍了软件架构师如何进行自我提升的方法，包括持续学习、参与开源项目、撰写自己的博客、花时间教导他人、尝试新技术、继续编写代码、参加用户组和会议、对自己的工作负责以及关注自身的整体福祉。

我认为这同样适用于企业信息系统。与其仅仅阅读代码，更应该通过部署产品来促进协作解决方案的产生，并支持其在一个社区内的使用，这在可能的情况下非常有价值，涵盖了它的整个生命周期。这应该是架构师个人发展的一部分，由企业推动，并成为其绝对必要的个人发展途径。

结论

我真的很喜欢阅读这本手册，并想感谢作者。我推荐它。

这本书系统的“地图”让我对软件架构师有了整体的认识，以及他们与解决方案架构师、应用架构师和企业架构师之间的区别。

它还揭示了一些趋势，比如 DevOps，这将影响开发人员，但也应该影响其他架构师。不幸的是，这一切可能过于以代码为中心，应该扩展以考虑模型，以便更好地与其它架构师合作，采用 DesignDevOps 方法和模型驱动的方法来帮助更好地应对日益增长的复杂性。

更好地理解DevOps趋势和原则

另外，回到《敏捷规模化》这篇文章，我对SCRUM仍然有很多疑问，因为它似乎非常注重开发。我是对的还是错的？

SCRUM 是否过于侧重于代码和面向开发的大规模敏捷？

为每种类型的架构师制作类似第一章中为软件架构师所做的内容可能会非常有价值，然后在ArchiMate框架中定位他们。

其他架构师是否也采取了类似的方法？

关于每个模式的要点，包括与新兴技术（如大数据、区块链、人工智能等）相关的模式，也可以考虑得很全面。

与新兴技术相关的新的模式应该有用

在我的之前活动中，我使用了ArchiMate来识别与制造数据开放标准相关的不同利益相关者，以支持PLM方法。由于提供的应用程序协议涉及在运营业务和技术环境中部署的PLM应用程序之间交换信息，重点在于作为信息系统一部分的应用程序，而不是尚未部署的软件产品，这些产品与其他合格资源（无论是自动化还是个人）一起使用。我重用了我用于PLM的框架，并添加了软件架构师，因为我将其视为全局图景的一部分。你对此有何看法？

下一个文章的主题？

不要犹豫，提出反馈并表达你的兴趣。

此外，不要犹豫提供对你采用的方法的反馈，该方法依赖于ArchiMate和Archi来生成书籍的地图。你喜欢这种方法吗？它增加了什么价值？