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

当前位置:首页 > 广场 > 我们应该期望软件架构师做什么?

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

2024-11-21广场8

最近,我接触到了Joseph Ingeno所著的《软件架构师手册》,这是一本由Pack Publishing出版的杰作。

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

随着现代软件系统的日益复杂,软件架构师的角色变得愈发具有挑战性。这本书旨在为软件开发人员向软件架构师角色的过渡提供帮助,同时也协助现有的软件架构师在他们的角色中取得更大的成功。它深入解读了成为软件架构师与开发人员的差异,以及成为一名成功的软件架构师所需具备的技能和素质。

我非常喜欢这本书,从一个信息系统架构师的角度对其进行了全面的评价。基于我在企业架构和企业应用领域的经验,特别是在实现数字协作和在整个扩展企业中使用众多异构的商用货架软件产品(COTS)方面,我深感共鸣。这意味着我们必须能够交换、共享和长期保存/归档数据,时间跨度远超一个软件产品的生命周期。

为了全面概述这本书的丰富内容,我创新性地制作了一套地图,每章一张。这种方法类似于思维导图,但融入了ArchiMate和Archi的独特元素。这套地图不仅捕捉了书的结构,还捕捉了主要概念,特别是与企业架构模型相关的概念,这些概念可以通过ArchiMate语言得以清晰表达:流程、参与者、角色、目标、原则等。

这种使用ArchiMate的方式虽不常见,可能并非企业架构师的常规推荐方法。但其独特之处在于,它能够直观地展现书中ArchiMate的内容描述。它可以用于识别ArchiMate的强项与局限,以及它不适合用于哪些场景。接下来,我们可以探讨是否应使用其他语言或元模型,如SPEM、带有模板的UML或其他工具。

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

从企业架构的角度来看,我对书的内容进行了深入分析。我发现ArchiMate考虑了一组专门针对明确识别的利益相关者视角,特别是参与企业架构设计的各种架构师。他们需要协同合作,确保信息系统及其底层技术基础设施与企业的目标和业务需求保持一致。在当下,企业更倾向于依赖商用现成软件(COTS)或云服务而非自主开发软件。代码的架构设计对他们来说并非必须。像敏捷(SCRUM等)这样的趋势可能会对他们产生误导。他们更多地会使用建模来指定支持信息系统的软件产品,部署和连接这些产品,从商业和技术角度管理它们。这也帮助他们更好地理解相关实践如DevOps或微服务如何融入其工作中。

关于本书内容的地图集描述:我在每个章节的描述中结合了前言的内容以及使用Archi生成的地图对章节进行的个人反馈。例如,《第1章:软件架构的意义》通过提供软件架构的定义来开启这本书的旅程。这一章明确了软件架构的构成及其对软件系统的重要性,并详细介绍了软件架构师的角色和所需的知识。这一章节深受我的喜爱,因为它清晰地阐述了架构师应该了解的核心内容,为更清晰地定义架构师的角色提供了坚实的基础。

在《第2章:组织中的软件架构》中,焦点放在了组织内部的软件架构上。除了技术主题外,还涵盖了一些非技术主题如项目管理、办公室政治和风险管理等。还探讨了软件产品线的开发和架构核心资产的创建等议题。在这一章中我部分认同作者的观点关于其他架构师角色的划分问题我有自己的见解我认为各个角色间虽有差异但更应注重合作与其他角色如项目经理安全专家等共同为企业的目标而努力我认为ArchiMate视图正是为了促进这种跨角色互动而设计的。

在深研技术的要想准确把握用户的需求和领域逻辑,有时并不容易。不过这对于架构师来说至关重要,因为只有这样,才能确保应用程序为用户创造价值。这也是我喜欢ArchiMate的原因之一,它能够从动机视角捕捉到这一点。

在探讨软件架构的过程中,第四章进入了我们的视线——“软件质量属性”。这一章节为我们深入解读了软件质量的重要性及其与软件架构的紧密联系。让我们一同了解几个常见的软件质量属性,如可维护性、易用性、可用性、可移植性、互操作性和可测试性等。它们虽然看似简单,但却是架构师在开发过程中最为关注的问题之一。它们在软件、应用程序、信息系统或企业中均占据举足轻重的地位。要想确保软件的稳定高效运行,必须重视这些属性。在实现PLM开放标准的解决方案过程中,对可测试性的追求一直是我们努力的目标。而多年来的实践也告诉我们,要想实现持续的安全协作,互操作性和系统的演进发展是关键。质量属性看似直观,但在实际操作中却是不断发现和深入的过程。对它们的深刻理解和合理运用,正是区分一个优秀架构师的关键所在。随着项目的不断推进和经验的积累,我们会发现更多有价值的洞察和实践经验。与此我们也逐渐发现一些新奇的架构设计方法和技术逐渐崭露头角。第五章便是深入探讨软件架构设计的重要章节。它为我们详细介绍了架构设计的内容及其在软件系统中的重要性。在这一章中,我们深入探讨了不同的架构设计方法、驱动因素以及设计原则的应用。从属性驱动设计到微软的架构和设计技术,再到以架构为中心的设计方法和架构开发方法,每一种方法都有其独特的优势和应用场景。在这里我发现了一种全新的视角去审视我们过去的项目和方法论,这样的探索使我对软件架构的理解更加深刻。这种不断求知和进步的态度同样适用于我们对软件开发原则与实践的探索中。第六章向我们揭示了经过验证的软件开发原则和实践对于构建高质量的软件系统的重要性。松耦合和高内聚等概念在这里得到了深入的解读和应用。我们也深入探讨了诸如KISS原则(保持简单)、DRY原则(不重复)、信息隐藏等原则的实际应用和价值。在关注SOLID原则的我们也探讨了单元测试、设置开发环境等关键话题。这些实践和经验都是确保代码质量的关键要素,值得我们深入学习和应用。接下来是第七章——软件架构模式的学习之旅。在这一章中我们深入探讨了多种实用的软件架构模式及其应用场景。从分层架构到事件驱动架构(EDA),再到模型-视图-控制器(MVC)等架构模式,每一种都有其独特的优势和适用场景。在探索这些架构模式的过程中,我们也意识到基于流程执行和消息导向的解决方案对于服务导向架构的进一步拓展的价值所在。当我们谈到现代应用架构时我们会提到第八章的学习重点这也是将目光投向未来的关键一环现代应用程序部署到云中所使用的软件架构模式和范例在这里得到了详细的解读从单体架构到微服务架构再到无服务器架构以及云原生应用的介绍背后所反映的是整个行业的不断变革和创新正如我们转向微服务时代同时也不能忽视那些已经存在并且仍在运行的传统技术它们也有其自身的价值和存在意义当我们转向横切关注点这一话题时我们会发现这是一个涵盖广泛但非常有趣的领域第九章详细介绍了如何处理系统中的横切关注点通过依赖注入装饰器模式和面向切片编程(AOP)等技术实现横切关注点的管理同时我们也探讨了缓存配置管理审计安全异常管理以及日志记录等不同的横切关注点最后我们进入第十章——性能考量的探讨这是一个复杂且庞大的领域涉及许多技术和策略本章为我们提供了对性能重要性的解读以及提升性能的技术手段从服务器端缓存到数据库性能再到Web应用性能分析每一个话题都值得深入探讨并付诸实践对于软件架构师来说对性能的深入理解和应用是其核心能力的体现同时也是构建高效稳定软件系统的关键所在以上章节构成了我们深入学习软件架构的旅程在这个过程中我们不仅收获了知识也收获了成长和进步每一次学习都是一次新的发现和探索让我们继续前行在软件架构的海洋中不断探索新的知识和实践经验为构建更好的软件系统而努力!第11章:安全考量

本章深入探讨了软件应用程序安全的关键主题,全面介绍了保密性、完整性和可用性(CIA)三元组等核心安全概念,并详细阐述了威胁建模的重要性。它为读者展现了设计安全软件的多种原则和实践。安全不仅仅是开发者和软件架构师的责任,它涉及众多安全贡献者,如安全官、安全审计员,以及应用程序用户。对于运用门户技术的开发者和软件架构师而言,这一章深入探讨了如何通过单点登录(SSO)、LDAP以及基于SAML的身份联合等方式,确保企业应用程序的安全访问。

第12章:软件架构的文档化与审查

此章主要聚焦于软件架构的文档编制和审查。内容详述了软件架构文档的多重用途,并解释了如何利用UML来记录软件架构。它还探讨了多种软件架构审查方法,包括软件架构分析方法(SAAM)等。虽然我更倾向于采用模型中心的方法而非文档中心的方法,但这一章仍然提供了对UML的深入理解及其在软件开发中的重要性。对于DevOps来说,虽然可能对UML的关注度较低,但它的价值不容忽视。我强烈推荐软件架构师进一步探索UML的潜力。

第13章:DevOps与软件架构

本章为我们揭示了DevOps的文化、实践、工具及其与软件架构的紧密联系。内容涵盖了关键的 DevOps 实践,如持续集成 (CI)、持续交付 (CD) 和持续部署。与敏捷开发特别是Scrum的联系也显而易见。随着虚拟化机器和容器的支持,以及云技术的自动化调整弹性,DevOps、微服务和云技术的互补性愈发显著。我曾经研究并使用了AndroMDA,支持向设计侧的左移,包括安全方面。但互连机器的基础设施平台是一个新的挑战,我在某些项目中已经原型化了基于模型的方法来解决这个问题。通过本书,我了解到了新型的“-aaS”类型及其潜力。

第14章:遗留应用程序的架构

这一章为处理遗留应用程序提供了深入理解。由于遗留应用程序在企业中的广泛应用,这一主题是软件架构师必须面对的挑战。它涵盖了如何重构遗留应用以及如何将它们迁移到云端。也讨论了如何现代化遗留应用的构建和部署流程以及如何与它们进行集成。对于企业架构师而言,重点在于能够管理遗留数据和迁移策略,而不是重构代码和应用程序。

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

本章主要探讨了成为有效的软件架构师所需的软技能。虽然这些技能对于任何领域的专业人士都具有一定的通用性,但在信息技术领域,沟通、领导力、谈判以及与远程资源合作等技能尤为重要。在软件架构领域,由于存在多种类型和职责的架构师,沟通显得尤为重要,以避免混淆和误解。

第16章:演进式架构

本章教导我们如何设计软件系统,使其具备适应变化的能力。随着技术的快速发展和需求的不断变化,软件架构必须能够随时间演进。该章深入解释了变化是不可避免的,因此软件架构师应设计能够适应变化的软件架构。通过我在PLM互操作性方面的经验以及对开放标准和动态重新配置平台的需求,我完全同意关于如何确保软件架构适应变化并满足其必要的特性的观点。数据的独立性和语义保留对于构建一个能够适应变化的进化平台至关重要。第17章:塑造更好的软件架构师之路

在这一章节中,我们深入探讨了软件架构师如何不断自我提升,实现职业成长。成长为一个优秀的软件架构师,绝不仅仅是一次性的成就,而是一个不断前行、不断学习的过程。为了与时俱进,软件架构师必须持续吸收新知识,磨练技能。

本章为软件架构师的成长之路提供了详细的策略建议。这些建议包括:持续学习,参与开源项目,撰写个人博客,通过教导他人深化理解,勇于尝试新技术,保持编码实践,积极参与用户群体和会议交流,对工作负责,同时关注个人的整体福祉以维持工作生活的平衡。

这些原则同样适用于企业信息系统。比起单纯阅读代码,我们更应该通过产品的部署来推动协作解决方案的产生,并在社区内得到应用。这涵盖了产品的整个生命周期,是架构师个人发展的重要组成部分,也是企业推动的必要个人发展途径。

结论部分

我深深被这本手册的内容所吸引,对于作者的专业和用心表示衷心的感谢。这本手册为我展现了软件架构师的全面视角,以及他们与解决方案架构师、应用架构师和企业架构师之间的微妙差异。

书中还揭示了一些影响开发人员以及其他架构师的重大趋势,如DevOps。为了更好地应对日益增长的复杂性,我们应该更全面地考虑模型,与其他架构师更好地合作,采用DesignDevOps方法和模型驱动的方法。

对于DevOps趋势和原则的更深入理解也是我所关注的。关于《敏捷规模化》中SCRUM的部分,我存在一些疑问。SCRUM是否过于侧重于开发和代码?是否能为其他类型的架构师制定类似的内容,并在ArchiMate框架中为他们定位?

在应对新兴技术如大数据、区块链、人工智能等与模式结合产生的新的技术模式时,书中也可以进行更深入的探讨。这些新兴技术与模式结合可能会产生新的解决方案和应用场景,对于架构师来说是非常重要的知识。

我在实际工作中使用了ArchiMate来识别与制造数据开放标准相关的利益相关者,以支持PLM方法。在这个过程中,我重用了用于PLM的框架,并加入了软件架构师的视角。我非常期待听到你对这个实践案例的看法。

对于下一篇文章的主题,我诚邀你积极参与讨论,分享你的兴趣和想法。我也希望你能反馈你对于使用ArchiMate和Archi生成书籍地图的方法的看法,你认为这种方法增加了哪些价值?你对此有何建议?你的反馈对我来说非常宝贵。

文章从网络整理,文章内容不代表本站观点,转账请注明【蓑衣网】

本文链接:https://www.baoguzi.com/68087.html

我们应该期望软件架构师做什么? | 分享给朋友: