敏捷架构是一组价值观,实践和协作,支持系统的主动,进化设计和架构。这种方法包含DevOps思维模式,允许系统架构随着时间的推移不断发展,同时支持当前用户的需求。它避免了与启动 - 停止 - 启动性质相关的开销和延迟,以及相位门过程和Big Up Front Design(BUFD)固有的大规模重新设计。
敏捷架构通过协作,紧急设计,有意架构和简单设计支持敏捷开发实践。与敏捷开发实践一样,敏捷架构也可以设计可测试性,可部署性和可发布性。快速原型设计,领域建模和分散式创新进一步支持了它。
细节
系统的体系结构可以加速或阻碍为业务提供频繁,独立的发布以实现其目标的能力。敏捷架构师通过优化架构来支持业务一致性,以支持端到端的价值流。这使企业能够实现在最短的可持续交付周期内持续提供“价值”的目标。敏捷架构师通过支持“足够”的架构跑道来支持不断变化的业务需求,从而引领这一过程。他们不断投资于传统的现代化计划,并知道在哪里重构以消除瓶颈。他们以明确的业务术语传达对这些持续技术目标的需求。
为了通过持续交付管道支持持续的价值流,敏捷架构:
- 随着时间的推移不断发展,同时支持当前用户的需要
- 避免与相位门和BUFD方法相关的开销和延迟
- 确保'系统始终运行'
- 突出紧急设计和意向性
- 采用整个价值流的系统视图
SAFe的精益敏捷原则为敏捷架构实践提供了信息。虽然都适用,但有三个与建筑特别相关。在进行特定设计之前,敏捷架构师使用快速学习周期(原理#4)来探索替代方案(原则#3)并获得最佳解决方案。他们还通过定义和传达架构愿景和战略,然后与构建它的团队协作和指导,为分散决策(原则#9)创造环境。
角色和合作
SAFe定义了三个架构师角色:企业,解决方案和系统架构师,它们在各自的级别(程序,解决方案和产品组合)中解决这些问题。他们定期在各级别之间进行协作,以确保协调一致并解决出现的问题和疑虑。如图1所示,角色需要所有必要的架构技能来做出技术决策。因此,角色可以由不止一个人填补,以确保足够的知识并防止瓶颈团队的架构决策。
图1. SAFe架构角色跨越架构域
架构也是与其他SAFe角色的合作。在Agile Release Train中,System Architects通过Architectural Runway,非功能需求以及Continuous Delivery Pipeline(CD管道)的设计和支持来传达技术路径。架构还可以实现内置质量。系统团队通过构建支持基础架构来实现架构愿景,使敏捷团队能够设计,实施,测试和交付价值。 System Architects与企业和解决方案架构师协调,以确保他们的解决方案与更大的愿景保持一致。最后,任何角色的架构师都是精益敏捷领导者,负责指导团队并提高贡献者的整体能力。
平衡意向性和出现
传统的架构方法导致了广泛的早期架构工作。这可以创建丰富的文档和未经验证的决策。设计架构以更好地符合业务需求的另一种方法是意向性和紧急设计的结合,其中架构从开发人员创建系统以查看哪些有效。敏捷架构平衡了意图和出现:
- 故意架构 - 定义一组有目的的,有计划的架构策略和计划,这些策略和计划可增强解决方案设计,性能和可用性,并为团队间设计和实现同步提供指导。
- 紧急设计 - 为完全演化和增量实施方法提供技术基础。这有助于开发人员和设计人员响应即时用户需求,从而允许设计随着系统的构建和部署而发展。
通过这种平衡,Agile架构是一种精益敏捷方法,可以解决构建企业解决方案的复杂性。它支持当前用户的需求,同时发展系统以满足近期的未来需求。一起使用,紧急设计和意向性不断建立和扩展建筑跑道,为未来的商业价值生产提供技术基础。
构建DevOps和按需发布
敏捷架构通过确保解决方案的架构以实现持续交付来促进DevOps文化。建筑师参与CD管道的设计和执行,并传播和举例说明SAFe的CALMR原则。它们允许通过定义最小可行(“恰好足够”)体系结构来确定决策,确保系统元素之间的松散耦合,支持接口的创建和发展,以及通过公共注释,属性和命名约定将体系结构作为代码培养。敏捷架构还通过自动化架构合规性检查来提高质量。
为了支持持续部署,Agile架构将部署与发布分离。功能部分持续部署到生产环境中,但只能按需提供给最终用户。频繁部署可在CD管道中建立信任,并减少由更传统的治理实践(例如,发布管理)引起的延迟。这种信任使各个团队和敏捷发布列车(ART)能够在真实的生产环境中独立探索和测试想法。
CD管道以值假设开始和结束,在Continuous Exploration中定义它并最终在按需发布中对其进行测量。系统架构提供必要的遥测来衡量假设,以支持团队和ART的创新会计和其他使用数据,以验证他们的假设。敏捷体系结构还支持CD管道,将其他系统因素视为一流的体系结构问题,例如测试体系结构和测试数据管理。
使架构与商业价值保持一致
在数字时代,企业依靠技术为客户创造价值。随着业务战略的变化,提供该战略的技术,系统和业务应用程序必须随之改变。图2显示了客户订单和产品交付的示例操作值流。操作步骤以绿色显示,系统和应用程序支持以下步骤。支持应用程序和系统的人员可以实现对客户体验的任何业务变更。架构师与业主和产品经理密切合作,以确保这些系统能够实现当前和未来的业务目标。
图2.支持客户订单放置和交付的系统。
战略主题,投资组合画布和投资组合愿景影响架构并推动架构跑道。它们为投资组合中的技术投资提供约束,方向和总体背景。从更广泛的角度来看,架构还必须考虑更大的企业战略,包括跨组合的意识,尤其是企业架构师。
开发解决方案愿景,解决方案意图,路线图
使架构与业务战略保持一致可以加速业务目标的实现。建筑师通过将战略从战略主题转化为解决方案来实现业务目标。这些解决方案由其愿景,解决方案背景和解决方案意图来定义。解决方案意图是一个知识的生存库,代表系统在需求,设计,结构,行为和所有其他架构问题上的单一事实来源。解决方案意图包括决策,模式,模型和其他技术信息,以作为最低限度的文档。解决方案意图捕获系统约束,包括非功能需求(NFR)。与所有其他要求一样,NFR通过自动化测试不断验证,以确保质量和合规性。
路线图定义了实现解决方案的计划。架构师和团队在路线图中协作定义推动因素,探索技术选项并构建架构跑道,提供实现这些里程碑的早期反馈。团队提供有关架构决策的反馈,因为他们在其上构建功能,平衡意图和出现。
该路线图推动了Backlog,它定义了ART的所有工作。架构师与产品管理部门合作,确定新功能与技术工作的优先级和平衡。他们预计技术债务会受到流量和建筑跑道需求的影响,并提倡优先排序。
为程序增量规划准备架构
每个增量,团队构建最高优先级的功能和启动器。架构师与产品管理部门合作,定义这些近期工作项目并确定其优先级。它们提供了可行性见解,有助于定义和确定当前功能及其验收标准。他们还会考虑未来的功能,并在积压中定义启动器,以便团队探索并获取确保未来功能可行性的知识。
建筑师还考虑其ART之外的技术依赖性,或者与解决方案培训中的其他ART或企业中的其他ART一起考虑,作为这些协调活动中的关键合作者。他们与团队协作以减少PI Planning期间的发现,并帮助确保团队在PI Planning期间做出必要的决策。
通过PI Planning协调架构
在PI Planning期间,架构师支持团队创建下一个增量计划。他们将建筑简报作为规划议程的一部分。随着团队在突破期间制定计划,建筑师在房间内漫游,以确保团队正确规划技术工作并确保他们正确地考虑到Program Enabler的工作。他们解决任何问题和疑虑。
建筑师支持管理评审,以解决潜在调整的架构和技术问题。他们还与业主一起参与,因为他们为团队的PI目标分配价值。从业务角度讲,他们解释了推动者和其他技术工作如何支持他们的总体目标,并游说他们的需求和重要性。
通过PI执行支持持续交付
建筑师在启动器中拥有计划/解决方案级别的技术和勘探工作,因此,指导团队的执行进度。他们可以参加这些团队的Sprint计划和/或Sprint演示活动,以跟踪进度,解决问题并调整方向。它们通常也可供团队使用,用于指导和指导,并确保快速解决问题和问题,以便架构不成为瓶颈。
每个增量,架构师都可以确保团队演示启动器工作的结果,包括新知识,架构跑道添加以及对Continuous Delivery Pipeline的任何添加。对于大型解决方案,Architect Sync事件可确保架构师保持一致并在大型解决方案级别共享进度,架构师定期在架构同步中会面,如图3所示。
图3.解决方案训练PI执行环境中的架构同步
支持新的战略主题和价值流
架构必须不断发展以满足不断变化的业务需求和机遇。否则,技术成为业务执行的瓶颈。业务战略的变化反映在新的或经过修改的战略主题中,尽管投资组合画布将其转化为新的或修改过的解决方案和/或价值流。 Enterprise Architects通过提供输入,参与价值流图制作研讨会以及设定对技术可行性的期望来支持和影响此过程。一旦制定了新方向,Enterprise Architects将与系统和解决方案架构师合作,以实现新的业务方向。他们传达新战略并展示其如何改变解决方案愿景,意图和路线图。
Enterprise Architects还协调整个产品组合中的架构工作,确保跨解决方案和价值流的一致性。它们为技术和平台的长期发展以及组合解决方案集的更大的非功能性需求(安全性,合规性,性能等)提供技术指导。他们经常担任投资组合级别推动者的史诗所有者,以确保技术的大幅度转变与业务战略保持一致。
引领精益敏捷转型
由于他们的知识和经验,建筑师经常受到开发社区的尊重和高度重视。因此,建筑师在任何SAFe转型中都发挥着关键作用。建筑师是精益敏捷的领导者,因此,模型更精简的思维和操作方式,以便开发人员从他们的榜样,指导和鼓励中学习。它们实现了自主权并鼓励掌握增长开发社区的知识库和技能。 SAFe架构师体现了新的工作方式,参与创建组织的(实施)路线图,并有助于加速作为精益敏捷领导者的采用。
Learn More
[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.
[2] Crispin, Lisa and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.
[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[4] Gregory, Janet, and Lisa Crispin, More Agile Testing: Learning Journeys for the Whole Team, Addison-Wesley, 2015.
原文:https://www.scaledagileframework.com/agile-architecture/
本文:https://pub.intelligentx.net/agile-architecture-safe
讨论:请加入知识星球或者小红圈【首席架构师圈】
Tags
最新内容
- 1 week 5 days ago
- 2 weeks 6 days ago
- 3 weeks 2 days ago
- 3 weeks 2 days ago
- 3 weeks 5 days ago
- 3 weeks 6 days ago
- 4 weeks ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago