许多企业声称，开放组架构框架 (TOGAF) 是一种瀑布模型，无法满足他们对现代企业架构的期望。相反，他们采用规模化敏捷框架 (SAFe) 方法来设计他们的企业。¹

需要注意的是，企业架构的三大支柱是：一致性、洞察力和质量。

• 一致性：企业架构 (EA) 将战略与运营、业务需求与 IT 供应保持一致，并确保变更符合企业战略和目标。
• 洞察力：EA 提供对组织、信息系统和技术的当前和期望状态的洞察力。
• 质量：EA 有助于提高单个解决方案的质量并简化其开发和维护。

作为背景，每一个都用于解决企业今天面临的最大挑战，例如：

• 变得敏捷
• 全球化和数字化
• 系统复杂性增加
• 产品型开发
• 市场竞争

采用 EA 的陷阱

根据作者最近作为企业架构师的经验，以下内容通常与企业架构的采用有关：

• 组织专注于 EA 的技术方面，因为大多数 EA 计划都是由 CIO 或 IT 主管推动的。
• 企业架构团队花费更多时间选择 EA 框架和 EA 工具，而不是定制和使用它来开发企业架构。
• 企业架构师经常被拖入运营活动或日常项目工作中。这意味着虽然他们看起来很有生产力，但实际上他们在解决企业层面的组织问题方面几乎没有做任何事情。

然而，跨行业对企业架构师的看法正在发生变化。为了赢得组织的尊重，企业架构师应该在编码的同时参与制定战略和端到端的实施。今天的企业架构师现在需要与定义企业的业务战略密切合作。此外，企业架构师监督如何以实施的形式实现业务战略。

基于以上问题，定义企业架构需要敏捷最佳实践。以下部分展示了敏捷方法与企业架构之间的联系。还详细解释了企业架构师在敏捷开发中的作用。

敏捷企业架构

敏捷是一种用于软件开发和项目管理的方法。在敏捷方法中，单个项目被分解成更小、更易于管理的部分，以加快设计过程并尽快生产出高质量的产品。

敏捷 EA 框架

使用敏捷，企业架构师的重点是：

• 通过早期和持续交付有价值的软件使客户满意；
• 接受需求（无论处于开发阶段）；
• 交付频繁工作的软件，从几周到几个月不等（越短越好……）；
• 在整个项目中与业务部门和软件开发人员保持持续的日常协作；
• 制定向开发团队和在开发团队内部传达信息的有效方法（通常通过面对面的会议）；
• 衡量工作软件的持续开发进度；和
• 持续关注卓越的技术和良好的设计。

下面描述的敏捷 EA 框架 (AEAF) 的安排是为了打破 IT 和业务之间的障碍，从而通过单位和通过为新项目联合的快速形成的团队来提高协同定位的水平。它的功能是根据实时客户反馈发展和迭代改进最小可行产品 (MVP)。 AEAF 同样通过实施必要的架构来支持云、DevOps、微服务、数据分析、测试自动化和 API 来帮助企业数字化。

AEAF 通过使用迭代生命周期来定义架构，以允许架构设计随着各种问题和约束变得更加清晰而逐渐演变。体系结构和系统的逐步构建必须齐头并进，其后续迭代必须解决或实施任何和所有问题和决策，以促进真正灵活的体系结构。

AEAF 以下列方式涵盖每个活动、目的和相关架构关系的详细信息：

(a) 敏捷 EA 规划

此步骤涵盖架构愿景和所有前期架构规划。在这个阶段，目标是解决核心业务问题和利益相关者的担忧。

架构愿景期间的努力提供了进行进一步目标架构开发所需的文档。它涵盖了问题的整个范围，同时也解决了利益相关者的担忧、优先事项和偏好。

架构待办事项涵盖了产品的价值、复杂性、依赖性和紧迫性。

(b) 敏捷架构定义

此步骤涵盖了与业务、应用程序、数据和技术相关的领域架构的定义。它建立了一组利益相关者批准的域架构，其中包含一致同意的差距列表以及清除它们的相应方法。它还解决了使企业能够满足利益相关者偏好的变化。作为敏捷架构定义的一部分，迭代计划将通过每日“站立”会议和“燃尽/燃尽”图表进行。

在此规划期间，每日站立会议和自组织团队共同开发架构。

(c) 敏捷 EA 分类法

敏捷 EA 分类涵盖了要在整个企业中采用的敏捷架构原则和敏捷价值观等工件。它还涵盖了最佳实践、指南和清单，以帮助那些遵守敏捷架构领域工件的人。

Sprint 交付工作产品的有用部分。 EA backlog 的核心是适当限制的 EA Landscape。

工作软件清楚地表达了预期的结果，而无需详细讨论如何开发和执行某些东西。它将工作限制在相对较短的时间间隔内，以最大限度地减少正在进行的工作量。此外，它还标识了所有的前任和后继包。工作产品可​​以追溯到一个目标，因此如果它的交付延迟（或失败），企业将面临改变目标架构的后果。

(d) 执行

敏捷团队不是采用大爆炸式的方法来决定整个程序的架构需求，而是采用增量方法来确保设计可扩展并与愿景保持一致，同时详细说明和满足企业需求。为了最有效，它有助于架构团队继续着眼于更大的图景，而团队则专注于他们基于冲刺的可交付成果。所有决策都应该一起做出以确保适当的平衡——无论是从商业价值的角度对项目阶段的协议、接受新的技术债务，还是特定框架或组件的设计细节。

作为敏捷架构实施的企业架构师，应重点关注：

• 有意架构（架构即协作）；
• 构建可能可行的最简单架构（既定设计原则）；
• 对其进行编码或建模（尖峰、原型、域和用例模型）；
• 构建它，测试它（为可测试性而设计）；和
• 实施架构流程（架构史诗和投资组合看板）。

(e) 敏捷 EA 组织

EA 实践需要相应的敏捷环境才能蓬勃发展。架构团队必须由企业架构师和解决方案架构师组成，业务架构团队必须将企业架构师与业务专家相匹配。 EA 团队需要每天与敏捷团队密切合作，以确保成功执行愿景，同时整合团队和客户的挑战和反馈。

• 敏捷首席架构师：敏捷首席架构师在整个企业中推广敏捷方法。这个职位的作用各不相同，就像仆人、领导者和促进者一样，可以顺利执行并消除可能的障碍。敏捷首席架构师是组织企业架构计划的最佳产品所有者。作为产品所有者，ALA 确定组织所需的架构。 ALA 拥有 EA 开发冲刺中使用的验收标准。
• 企业架构师：企业架构师是敏捷团队的组成部分，有助于开发、改进和维持企业架构。敏捷架构师是开发团队的活跃成员。他们在适当的地方开发软件，并担任团队的架构顾问。
• 敏捷团队：服务很小，由小团队开发。敏捷使得以小块频繁发布成为可能，从而显示业务进展。遵循 CI/CD 以提高弹性水平。

使用 LeanIX 实施 TOGAF 的敏捷框架 [海报]：逐步说明如何使用精益 EA 工具遵循 TOGAF 原则。 »

(f) EA 存储库

EA 存储库有助于存储敏捷架构和开发工件。

(g) 敏捷 EA 治理模型

敏捷 EA 治理就是在整个组织内创造价值，而不仅仅是在单个项目中。敏捷治理在高层管理人员和正在完成项目的团队之间架起了一座桥梁。

已建立的敏捷 EA 治理模型支持：

• 敏捷团队的自主决策；
• 跨学科敏捷团队处理复杂主题的能力；
• 减少企业架构的管理开销；和
• 企业架构的范围和影响。

概括

不要将所有这些都视为 EA 与敏捷。

敏捷 EA 框架对于任何企业转型都起着重要作用。这种转变有四个维度：功能性；技术的;操作;和业务。在这四个维度中的每一个维度中，EA 和敏捷都支持对方的目标。

在敏捷中，架构师需要始终与团队保持投资。重要的是他们要有远见，同时管理变化和复杂性。敏捷架构师必须参与项目所有功能规范的定义，同时与业务团队共同审查功能规范以了解期望并确保所写的内容是预期的。

不断与利益相关者和团队核对，以确保他们没有偏离既定的设计。架构师必须在很多时候保护团队免受不必要的官僚主义的影响。

产品负责人、敏捷架构师和团队应共同决定 sprint 的范围。架构师应仅在范围界定期间出现问题（或在最后一刻引入更改时）进行干预。

向业务部门演示冲刺输出以获取客户反馈，适应所有必要的更改，并确保团队由经验丰富的工程师和新晋工程师组成。最后，虽然敏捷并未明确推荐文档，但它确实有助于创建尽可能多的文档，以简化未来支持团队的生活。

原文：https://www.leanix.net/en/blog/agile-and-enterprise-architecture-a-stra…

本文：https://jiagoushi.pro/node/1892